From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041012 Firefox/0.10.1 Description of problem: This might be a bug somewhere else, but I've experienced it just with k3b so far. Sometimes (this is not really reproducable) starting k3b causes all available memory to be used up. I've experienced this twice now. k3b starts up normally and shows it's splash screen. When the "Scanning for CD devices" stage is reached, the system becomes almost instantly unresponsive because of disk I/O (I admit, the disk with the swap file is not the fastest one around). Some time later the kernel oom killer kicks in and kills a process (dmesg attached, in this case openoffice was killed). The system then returns to normal (k3b did not complete it's start, and is not running). Starting k3b again succeeds without any problems. I do not know what triggers this. The machine has 512MB RAM and 1GB swap (the swap is hardly touched at any time) Version-Release number of selected component (if applicable): k3b-0.11.14-2 How reproducible: Sometimes Steps to Reproduce: 1. start k3b 2. 3. Actual Results: Extreme memory usage when searching for drives, causes oom. Expected Results: Normal startup Additional info:
Created attachment 105374 [details] OOM caused by k3b startup
The kernel is kernel-2.6.8-1.624
and after it killed k3b, it killed soffice.bin... will you file a bug against openoffice now as well?
So you consider it normal that starting k3b uses all available memory? That openoffice was killed was just a side effect.
no... but it looks like you are low of memory, if soffice.bin gets killed also.. hmm.. strange, because a second start of k3b succeeds.. maybe because now the kernel has DMA memory?
I do not know how the oom killer works, exactly. Maybe k3b did not die fast enough? "Ordinary" workload on this machine takes ~300MB "used" memory, the rest is in buffers and caches. I have a gkrellm running, so I spot irregular memory usage quite fast. I think it is safe to assume that at least 1GB of memory (consisting mainly of swap space) was available before I tried to start k3b. Can the amount of available DMA memory be determined from /proc somehow?
[harald@jever devel]$ free total used free shared buffers cached Mem: 1033460 631352 402108 0 48828 337792 -/+ buffers/cache: 244732 788728 Swap: 1052216 0 1052216 [harald@jever devel]$ k3b [harald@jever devel]$ free total used free shared buffers cached Mem: 1033460 641176 392284 0 49316 344844 -/+ buffers/cache: 247016 786444 Swap: 1052216 0 1052216 [harald@jever devel]$ k3b& [1] 24136 [harald@jever devel]$ free total used free shared buffers cached Mem: 1033460 647752 385708 0 49340 344820 -/+ buffers/cache: 253592 779868 Swap: 1052216 0 1052216 Hmm... nothing suspicious...
I'll try to construct a reproducable case.
The OOM killer isn't 100% accurate, and sometimes kills the wrong processes before killing the right one in its desperate attempt of saving the system.
Happened again today, still no luck on a reproducable case. I did (in anticipation of a possible failure) do a "free" before starting k3b, and after it tried to start and was killed by OOM: [sun@nausicaa ~ :) 2]$ free total used free shared buffers cached Mem: 515744 492700 23044 0 26656 266556 -/+ buffers/cache: 199488 316256 Swap: 1052216 0 1052216 [sun@nausicaa ~ :) 3]$ free total used free shared buffers cached Mem: 515744 513228 2516 0 916 45768 -/+ buffers/cache: 466544 49200 Swap: 1052216 460220 591996 I do not know what process actually uses all that memory that is "missing" between 1 and 2.
Since it seems to happen at least once when I try to start k3b, any advice what information I ought to capture in order to track this down? Please notice that doing anything "while it happens" is almost impossible, since the system becomes almost instantly unresponsive due to heavy swap activity.
I think, I know what's going on... Because of bug #134822, we have bug #136982 and this bug. The inquiry does not return any value... so the "new" is called with an incredible amount of memory... Try to start k3b with a disk inserted in your SCSI drives...
You might have found it. I did not manage to OOM k3b anymore with the current rawhide, but I have gotten SIGABRT at the same point during the startup process instead (as with the OOM, not always). Without any disks in the SCSI drives k3b seems to start up without problems (tried multiple times, came up every time). Inserting a CD caused k3b to bail out with SIGABRT during multiple tries.
Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -181975360 (LWP 12797)] [KCrash handler] #4 0xf6fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #5 0xf53e7955 in raise () from /lib/tls/libc.so.6 #6 0xf53e9319 in abort () from /lib/tls/libc.so.6 #7 0xf55b310b in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6 #8 0xf55b0e1d in __cxa_call_unexpected () from /usr/lib/libstdc++.so.6 #9 0xf55b0e52 in std::terminate () from /usr/lib/libstdc++.so.6 #10 0xf55b0f9b in __cxa_throw () from /usr/lib/libstdc++.so.6 #11 0xf55b13ec in operator new () from /usr/lib/libstdc++.so.6 #12 0xf55b1489 in operator new[] () from /usr/lib/libstdc++.so.6 #13 0xf691d97b in K3bCdDevice::CdDevice::init (this=0x9a5a240) at k3bdevice.cpp:219 #14 0xf692854d in K3bCdDevice::DeviceManager::addDevice (this=0x9a1b9a8, devicename=@0x9a552d0) at k3bdevicemanager.cpp:504 #15 0xf692b361 in K3bCdDevice::DeviceManager::readConfig (this=0x9a1b9a8, c=0x99d6108) at qvaluelist.h:110 #16 0xf68e0515 in K3bCore::init (this=0x9a1b5d8) at k3bcore.cpp:132 #17 0x080817ba in K3bApplication::init (this=0xfee83940) at k3bapplication.cpp:98 #18 0x0809f388 in main (argc=0, argv=0x0) at main.cpp:120 #19 0xf53d4e33 in __libc_start_main () from /lib/tls/libc.so.6 #20 0x0807df61 in _start ()
kernel issue, see #134822
oom problems should be much better in current kernel update, so closing this bug. for the other scsi related bug, please follow up in 134822