| Summary: | Possible memory leaks from SQLite3 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mark van Rossum <mvanross> | ||||||||||
| Component: | sqlite3 | Assignee: | Paul Nasrat <nobody+pnasrat> | ||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 15 | CC: | lucilanga, mbarnes, mcrha | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | i686 | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Whiteboard: | abrt_hash:f31ca75309ce9abbdb6afadf40afcd706f4bf9e1 | ||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2012-08-07 18:06:11 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Attachments: |
|
||||||||||||
|
Description
Mark van Rossum
2011-06-13 11:35:17 UTC
Created attachment 504419 [details]
File: backtrace
Created attachment 504420 [details]
File: maps
Thanks for a bug report. I see in a backtrace that this happened while you were printing a message, when it was trying to print an image in it, but it failed to allocate new memory. Is it possible to either attach here or send me privately (as an attachment) that offending message for testing, please? If so, then please sanitize all private information from it, by replacing it with "x" or similar letter, after you right click over it and choose "Save as mbox", and then edit the message in a text editor, like gedit. I would like to try to reproduce it, and see whether there was an issue with message or with the code, and whether the crash is avoidable. Thanks in advance. Thanks for providing me the test message. When I print it as is, then it is printed properly, with inner message including images as well. I do "Print" and then "Print preview" button, and my evolution doesn't crash. Maybe that yours was really out of memory due to some earlier memory leaks? I mean, when you close evolution and then run it again and try to print the message, will it survive like it did for me? Unfortunately, the bug seems erratic. I tried again and I did get a few more crashes, but also some successes. Bit weird. First doing the preview seems to help. However, memory use is very high, about 1.5 Gb. gnome-system-monitor nicely shows it. Note, this machine has only 3G mem (+ 10G swap). Created attachment 504661 [details]
Another crash report of the same bug, this time with SIGNAL 11
(In reply to comment #6) > Another crash report of the same bug, this time with SIGNAL 11 It's a different crash, at least different part, when a D-Bus message was received, though it can be caused by the memory usage or evolution. All that because evolution is leaking memory too much. I'll check with valgrind whether I'll find anything to help to lower memory leaks. Hrm, I cannot reproduce those memory leaks I saw yesterday, I do not know how to do that :( My valgrind leak summary log was like this:
> ==9944== LEAK SUMMARY:
> ==9944== definitely lost: 17,451,404 bytes in 104,003 blocks
> ==9944== indirectly lost: 23,481,806 bytes in 1,256,068 blocks
> ==9944== possibly lost: 5,764,589 bytes in 30,261 blocks
> ==9944== still reachable: 44,780,323 bytes in 961,974 blocks
Those "definitely lost" are most important, because they are clearly lost. I know I didn't have it running for a long time, because under valgrind it's too slow for a usual work (mail reading), but I think I didn't do anything special.
Maybe if you can try to find some leaks, then it'll be helpful. Only make sure you've installed debug info packages for gtkhtml3, evolution-data-server and evolution of the same version as their core packages (rpm -qa | grep evolution), and then you can run evolution under valgrind like this:
$ G_SLICE=always-malloc valgrind --num-callers=50 --leak-check=full \
evolution &>log.txt
and the log.txt file will contain the information when you stop evolution and the command will be finished. At the end is similar leak summary table, so you can check how many leaks you captured. Some of that 1.5GB memory might be memory leaks for sure.
Thanks for the detailed instructions. I have tried this (log.txt) attached. Unfortunately, when I try to print then the message in question, evolution hangs unresponsively, without cpu use. I had to kill it. Printing another message with included graphics went fine. Created attachment 505050 [details]
valgrind log
Thanks for the update. I see there are quite many possible leaks from SQLite, and because this is used really often from the mailer part, then it can do the difference. I'm moving this there for thoughts from the maintainer. This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |