Bug 124512
Summary: | Evolution hangs, consuming excessive memory | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Phil Schaffner <philip.r.schaffner> | ||||||||||
Component: | gtkhtml3 | Assignee: | Matthew Barnes <mbarnes> | ||||||||||
Status: | CLOSED WONTFIX | QA Contact: | |||||||||||
Severity: | high | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | 4.0 | CC: | fortran, jan.iven, jturner, lordmorgul, philip.r.schaffner, tao | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | i386 | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | RHEL4U3NAK | ||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2006-09-05 20:07:05 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Attachments: |
|
Description
Phil Schaffner
2004-05-27 03:57:10 UTC
Problem is much worse (as might be expected) on my notebook with 256M of RAM than on the home system with 768M that was the source of the original report. Have not seen it on main workstation system with 3G. Notebook system is virtually unusable, freezing every few minutes. Forgot to note in the text that I have only noticed the problem when editing a message, although that is covered in "Steps to Reproduce". I had this same issue when the first 1.5.7 rpms were built (when Dave Malcolm took over in building them) and got nowhere in debugging it. The problem happened around 10 times.. and seemed to disappear (I assumed it was a newer gtkhtml3 but could never reproduce it again after I noticed it was gone). I posted this bug but as the comment says.. it doesn't help. http://bugzilla.ximian.com/show_bug.cgi?id=57930 Well, happening right now on the 3GB system with evolution-1.5.9.1-2 top - 15:38:18 up 3 days, 7:05, 6 users, load average: 2.02, 1.66, 0.85 Tasks: 152 total, 1 running, 150 sleeping, 0 stopped, 1 zombie Cpu(s): 1.2% us, 2.6% sy, 0.0% ni, 47.5% id, 48.2% wa, 0.0% hi, 0.5% si Mem: 3116308k total, 3107116k used, 9192k free, 26852k buffers Swap: 2096440k total, 1465444k used, 630996k free, 172172k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 41 root 15 0 0 0 0 S 3.6 0.0 0:08.10 kswapd0 24356 root 15 0 89032 6840 76m S 1.3 0.2 6:53.66 X 24566 prs 15 0 30012 4664 26m S 1.0 0.1 0:03.01 kdeinit 2447 prs 15 0 3789m 2.6g 32m D 1.0 87.8 1:54.01 evolution 12123 prs 16 0 2744 960 1620 R 1.0 0.0 0:00.16 top 2305 root 15 0 10116 1784 7596 S 0.3 0.1 10:13.37 nmbd 24588 prs 16 0 16704 3832 13m S 0.3 0.1 0:34.67 jpilot 1 root 16 0 1916 436 1316 S 0.0 0.0 0:01.27 init Can you reproduce the problem with the latest evolution packages? Evolution 2.0.0 is now in Rawhide. I have a similar problem with evolution-2.0.0-2 from Rawhide. I have several IMAP accounts and the system mail (/var/spool/mail/). Everything works fine except that when I tried to rad any mail for the system mail folder, CPU usage goes to 100% and evolution freezes. I'll try to look for more info and possibly file a separate bug. Well, but the bullet and upgraded my workstation to FC3T2. On the second day of use, again encountered this evolution but. Evolution (evolution-2.0.0-2) and the system became unresponsive. Top shows: top - 14:20:35 up 1 day, 23:31, 9 users, load average: 0.70, 0.35, 0.18 Tasks: 161 total, 2 running, 159 sleeping, 0 stopped, 0 zombie Cpu(s): 37.7% us, 37.9% sy, 0.3% ni, 22.4% id, 1.0% wa, 0.0% hi, 0.7% si Mem: 3112984k total, 3111048k used, 1936k free, 52228k buffers Swap: 4128652k total, 293332k used, 3835320k free, 69476k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6792 prs 18 0 2804m 2.6g 33m D 91.7 88.0 5:20.65 evolution 42 root 16 0 0 0 0 R 53.1 0.0 0:08.61 kswapd0 2919 root 15 0 9052 764 7576 S 1.3 0.0 9:59.57 nmbd 18985 root 15 0 117m 32m 81m S 1.3 1.1 42:34.51 X Problem again happened while editing a message. Killed evolution, restarted, and things seem to be working again - until the next time if past experience is a guide. Tends to bite once a day or more. Can't type today. Probably obvious, but the above should read: "Well, bit the bullet and upgraded my workstation to FC3T2. On the second day of use, again encountered this evolution bug." Thanks for the reports. Looks like there's a memory leak somewhere; am I right in thinking it happens every now and then when you start composing an email? I've had a go at tracking this down by running Evolution under valgrind but couldn't reproduce it. What version of gtkhtml3 are you using? Does it happen as you are typing in the main composer window, or when editing the To/CC fields, or does other activity trigger it? Or is it a gradual thing that builds up? If you set up the system monitor to view memory usage, can you identify when the memory usage increases, and get an idea of what might be causing it that way? Have you got autocompletion turned on? (there used to be a memory leak in the LDAP autocompletion code, though I believe that's been fixed now) Generally seems to happen after working on a message for some time, int the compose window, not at start of composing; although seemingly, if it is something to do with the process of composing, doing it longer gives more chance of encounte3ring the bug. Seems to buind up rapidly, not gradually; however, will try monitoring memory usage. $ rpm -q gtkhtml3 gtkhtml3-3.3.2-3 Autocompletion is on for the Personal folder only. The way you are describing the 'triggers' that seem to set off the bug are identical to the 1.5.7 bug I was experiencing. It always began while editing an email, normally after I had it open a period of time, I do not think it was strictly size of an email, several times I had a new or reply email open with only a few lines typed in the body. I'm fairly certain it never happened when editing any fields other than the body, however it is hard to say when it really started. I'm surprised I haven't come across it again. Adding to CC and I'll see if I can trigger it again. Have been running evolution-2.0.2-3 (FC3 version + dependencies yum pulled in from FC3) successfully on FC2 for some weeks. Seems to be fixed. Closing bug. BTW, to what extent were you using calendars? Were you using the Exchange connector? In my experience with the bug I was never using connector, and hardly ever used the calendar at all. Not using calendar nor Exchange connector. It's back. Apparently closed prematurely. Have had several cases of excessive CPU/memory usage hanging the system this week. FC3 on x86_64 evolution-2.0.2-3 kernel-smp-2.6.10-1.766_FC3 Should add - again, always while editing a message. Bug still present in evolution-2.0.2-16.x86_64 on EL4, kernel-2.6.9-11.ELsmp. System (with 4GB RAM) became so sluggish due to swapping that the GUI was unresponsive. Had to log in remotely via ssh to kill evolution before I could regain control. Just finished upgrading to evolution-2.0.4-4 - rebuilt (along with requires/depends) from FC3 SRPMS - in an attempt to escape this major annoyance. Created attachment 119579 [details]
full gdb backtrace on looping evolution
Me too: evolution sometimes starts consuming memory quickly while editing a new mail message, typically triggered by typing too fast. gdb shows it is looping somewhere around html_link_dup() (see attachement). (breakpoint on malloc) shows #0 0x00a05b36 in malloc () from /lib/tls/libc.so.6 #1 0x00d47963 in g_malloc (n_bytes=8) at gmem.c:136 #2 0x059dc35f in html_text_free_attrs () from /usr/lib/libgtkhtml-3.1.so.11 #3 0x059dc48d in html_link_dup () from /usr/lib/libgtkhtml-3.1.so.11 #4 0x059ca3cb in html_object_copy () from /usr/lib/libgtkhtml-3.1.so.11 #5 0x059ca403 in html_object_dup () from /usr/lib/libgtkhtml-3.1.so.11 #6 0x059dde25 in html_text_convert_nbsp () from /usr/lib/libgtkhtml-3.1.so.11 #7 0x059c9d72 in html_object_split () from /usr/lib/libgtkhtml-3.1.so.11 #8 0x059a70fd in html_engine_reset_blinking_cursor () evo keeps coming back to the breakpoint with this backtrace. So it looks like something is allocating 8bytes in a quick loop. Versions: gtkhtml3-3.3.2-3 evolution-2.0.2-16.3 Thanks for the updated information, and for these backtraces: it looks like they isolate a cause (the cause?) of the problem. I've changed the "Product" field from Fedora Core to Red Hat Enterprise Linux (although it affects FC3), and I've marked this bug for consideration in a future update; I'm keen to get this one fixed (in both EL4 and FC3). Moving from "evolution" to "gtkhtml3" as I'm fairly sure this is a bug in the latter package. A couple of thoughts based on Comment 19: (i) Looks like the cursor flash might be introducing a time-dependent element to this bug, which is why it's been so hard to come up with a reliable way of reproducing it. (ii) Comment 19 also suggests you have to be typing fast to triggger the problem. I've tried patching gtkhtml3 to greatly speed up the cursor flash and to add various debug instrumentation, and then tried various torture tests on the code, but I haven't come up with a good reproducer yet. If anyone can come up with more backtraces, please attach them to this bug, specifying the version of evolution and gtkhtml3 in use. If possible, please generate them using "t a a bt" in gdb, and try to get all of the output. What GTK input methods are you using when you seen the bug? (if you right-click in the composer have a look in the context menu's Input Methods submenu: are you using Default?) I'm trying typing quickly and slowly, pasting in large and small HTML fragments (especially those containing nbsp entities and URLs), and generally abusing the email composer. Further suggestions/hints/hunches on ways to get the bug to manifest reliably would be most welcome; I'm continuing the investigation, I'll try some more angles on this tomorrow. Thanks. I have not been able to reproduce the memory leak with gtkhtml3-3.3.2-6.EL evolution-2.0.2-22 Possibly related to your gtkhtml changes?: after cut&paste of a largish HTML chunk (30 paragraphs, 2888 words, 19725 bytes of Lorem Ipsum, from http://www.lipsum.com), I noticed that typing more text into the HTML block became rather sluggish, with X taking 50% of CPU. The cursor blinked frantically and typing 'faster' than the output made it to the screen became rather easy (so after stopping to hit keys, a few lines of text would still appear by themselves). If this does not sound related, please disregard. Created attachment 123679 [details]
gdb backtrace
backtrace of gdb attached to rampant "evolution" process
Created attachment 124247 [details] gdb backtrace for comment28 One more memleak occurence, again while quickly typing a reply. PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND 4070 ? Tsl 1:42 2295 134 671237 169224 33.4 evolution-2.0 --sm-config-prefix /evolution-2.0-Ff3xdu/ --sm-client-id 117f000001000113898709100000037100020 --screen 0 gdb backtrace attached, see above. I am using the "Default" input method. Created attachment 126463 [details]
gdb backtraces while eating memory
Occured while trying to delete (mark with mouse, hit "Del") a snippet of HTML
previously cut&paste from a different mail.
Still happens with RHEL4U3: evolution-2.0.2-27 gtkhtml3-3.3.2-6.EL Could somebody please change the Status? NEEDINFO_REPORTER no longer applies, I don't know what else to report.. Neither do I. Tried changing status to "NEEEDINFO/ASSIGNEE" but was prevented by BZ despite being the reporter. Still experiencing the bug with some regularity. Some meaningful change in status or indication of attention to the problem would be nice. Maybe in RHEL4U5? The component this request has been filed against is not planned for inclusion in the next update. The decision is based on weighting the priority and number of requests for a component as well as the impact on the Red Hat Enterprise Linux user-base: other components are considered having higher priority and the number of changes we intend to include in update cycles is limited. Product Management has reviewed and declined this request. You may appeal this decision by reopening this request. |