[Bug 803518] New: X huge memory usage on rpm install
https://bugzilla.novell.com/show_bug.cgi?id=803518 https://bugzilla.novell.com/show_bug.cgi?id=803518#c0 Summary: X huge memory usage on rpm install Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Normal Priority: P5 - None Component: X.Org AssignedTo: bnc-team-xorg-bugs@forge.provo.novell.com ReportedBy: andrea.turrini@gmail.com QAContact: xorg-maintainer-bugs@forge.provo.novell.com Found By: --- Blocker: --- Created an attachment (id=524466) --> (http://bugzilla.novell.com/attachment.cgi?id=524466) Xorg.0.log relative to the session with huge memory usage User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 Sometimes, when I install/update an rpm via zypper, the desktop becomes almost unresponsive, the memory (4Gb ram + 2Gb swap) is saturated with 100% of CPU usage until I suppose the oom-killer kills some process and this makes the system to run again as usual. /var/log/messages as well as dmesg does not contain any useful information while /var/log/zypper.log just contains a big delay in the events. The only interesting info is in /var/log/Xorg.0.log: [ 23981.919] [mi] EQ overflowing. Additional events will be discarded until existing events are processed. [ 23982.982] [ 23982.982] Backtrace: [ 23985.902] 0: /usr/bin/X (xorg_backtrace+0x36) [0x564686] [ 23985.903] 1: /usr/bin/X (mieqEnqueue+0x26b) [0x54594b] [ 23985.903] 2: /usr/bin/X (0x400000+0x4c422) [0x44c422] [ 23985.933] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fb5bb907000+0x6524) [0x7fb5bb90d524] [ 23985.933] 4: /usr/bin/X (0x400000+0x73347) [0x473347] [ 23985.933] 5: /usr/bin/X (0x400000+0x97780) [0x497780] [ 23985.933] 6: /lib64/libpthread.so.0 (0x7fb5c34c7000+0xf140) [0x7fb5c34d6140] [ 23985.933] 7: /usr/bin/X (0x400000+0x168830) [0x568830] [ 23985.933] 8: /lib64/libpthread.so.0 (0x7fb5c34c7000+0xf140) [0x7fb5c34d6140] [ 23985.933] 9: /usr/bin/X (0x400000+0x40c50) [0x440c50] [ 23985.933] 10: /usr/bin/X (0x400000+0x43581) [0x443581] [ 23985.933] 11: /usr/bin/X (0x400000+0xff1cb) [0x4ff1cb] [ 23985.934] 12: /usr/bin/X (0x400000+0x12000f) [0x52000f] [ 23985.934] 13: /usr/bin/X (mieqProcessDeviceEvent+0x1b5) [0x545d75] [ 23985.934] 14: /usr/bin/X (mieqProcessInputEvents+0xf8) [0x545e98] [ 23985.934] 15: /usr/bin/X (ProcessInputEvents+0x9) [0x4733c9] [ 23985.934] 16: /usr/bin/X (0x400000+0x386c6) [0x4386c6] [ 23985.934] 17: /usr/bin/X (0x400000+0x27965) [0x427965] [ 23985.934] 18: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7fb5c2375455] [ 23985.934] 19: /usr/bin/X (0x400000+0x27c3d) [0x427c3d] [ 23985.934] [ 23985.934] [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack. [ 23985.934] [mi] mieq is *NOT* the cause. It is a victim. [ 24020.637] [mi] EQ processing has resumed after 77 dropped events. [ 24020.724] [mi] This may be caused my a misbehaving driver monopolizing the server's resources. [ 24175.374] [mi] Increasing EQ size to 512 to prevent dropped events. that roughly correspond at the problem, since zypper.log contains: 2013-02-13 13:51:47 <1> orodruin.lotr(11302) [zypp++] ExternalProgram.cc(start_program):229 Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--force' '--nodeps' '--' '/var/cache/zypp/packages/repo-update-non-oss/x86_64/opera-12.14-1.12.1.x86_64.rpm' 2013-02-13 13:51:47 <1> orodruin.lotr(11302) [zypp++] ExternalProgram.cc(start_program):381 pid 11318 launched 2013-02-13 13:56:23 <1> orodruin.lotr(11302) [zypp++] ExternalProgram.cc(checkStatus):482 Pid 11318 successfully completed and hopefully /var/log/messages allows to relate clock time and uptime via: Feb 13 13:48:42 orodruin kernel: [23713.742530] ISO 9660 Extensions: Microsoft Joliet Level 3 Feb 13 13:48:42 orodruin kernel: [23713.750394] ISO 9660 Extensions: RRIP_1991A I have not found any other information in the system logs. By using htop (in an open terminal) during the memory saturation I have found that the culprit is X that at some point has reached 50% of the memory (then no other samples from htop, probably the system was completely unresponsive). However the X session has not been killed or is crashed, since after the system has restored its functionality, the running X is still the original but /proc/<pidOfX>/status contains: VmPeak: 3682976 kB Attached you find the Xorg.0.log Reproducible: Always Steps to Reproduce: 1. 2. 3. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=803518
https://bugzilla.novell.com/show_bug.cgi?id=803518#c
Stefan Dirsch
https://bugzilla.novell.com/show_bug.cgi?id=803518
https://bugzilla.novell.com/show_bug.cgi?id=803518#c1
--- Comment #1 from Andrea Turrini
https://bugzilla.novell.com/show_bug.cgi?id=803518
https://bugzilla.novell.com/show_bug.cgi?id=803518#c2
Stefan Dirsch
participants (1)
-
bugzilla_noreply@novell.com