Merge lp:~gue5t/midori/bitesize-leaks into lp:midori
Status: | Merged |
---|---|
Approved by: | gue5t gue5t |
Approved revision: | 6674 |
Merged at revision: | 6682 |
Proposed branch: | lp:~gue5t/midori/bitesize-leaks |
Merge into: | lp:midori |
Diff against target: |
36 lines (+4/-0) 3 files modified
midori/main.c (+1/-0) midori/midori-browser.c (+1/-0) midori/midori-frontend.c (+2/-0) |
To merge this branch: | bzr merge lp:~gue5t/midori/bitesize-leaks |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Cris Dywan | Approve | ||
Review via email: mp+216813@code.launchpad.net |
Commit message
Fix a few simple leaks
Description of the change
Fix a few simple leaks. The first is the MidoriApp singleton, whose ownership is never given to a container, but which is also never unreffed after the main loop ends. We should create the app, run our main loop, and then unref the app.
The second is that while a browser unsets its bookmarks when disposing, it doesn't unset its history. History holds a reference on the MidoriApp via midori_
The third is that the MidoriApp is set as the parent of the KatzeArray used to store the session to be restored. This feature doesn't work right now with tabby, and nothing ever stores this session anyhow, so it's safe to unset the parent and unref the array after the last time it's used, to avoid leaking it and its reference to the MidoriApp.
Those looks sane… do you by any chance have ideas on how to verify that these stay fixed? Say a ref count check in a test case before and after doing something.
I'll approve and leave it up to you whether to merge now or if you have some ideas.