Bug 136155 - k3b startup causes kernel oom
k3b startup causes kernel oom
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On: 134822
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-18 08:23 EDT by Ralf Ertzinger
Modified: 2015-01-04 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-27 16:33:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
OOM caused by k3b startup (2.02 KB, text/plain)
2004-10-18 08:24 EDT, Ralf Ertzinger
no flags Details

  None (edit)
Description Ralf Ertzinger 2004-10-18 08:23:31 EDT
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:
Comment 1 Ralf Ertzinger 2004-10-18 08:24:44 EDT
Created attachment 105374 [details]
OOM caused by k3b startup
Comment 2 Ralf Ertzinger 2004-10-18 08:28:11 EDT
The kernel is kernel-2.6.8-1.624
Comment 3 Harald Hoyer 2004-10-18 08:29:04 EDT
and after it killed k3b, it killed soffice.bin... will you file a bug
against openoffice now as well?
Comment 4 Ralf Ertzinger 2004-10-18 08:31:08 EDT
So you consider it normal that starting k3b uses all available memory?
That openoffice was killed was just a side effect.
Comment 5 Harald Hoyer 2004-10-18 08:43:17 EDT
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?
Comment 6 Ralf Ertzinger 2004-10-18 08:55:04 EDT
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?
Comment 7 Harald Hoyer 2004-10-18 09:02:09 EDT
[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...
Comment 8 Ralf Ertzinger 2004-10-18 09:04:32 EDT
I'll try to construct a reproducable case.
Comment 9 Warren Togami 2004-10-18 09:06:40 EDT
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.
Comment 10 Ralf Ertzinger 2004-10-19 08:01:48 EDT
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.
Comment 11 Ralf Ertzinger 2004-10-20 09:16:06 EDT
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.
Comment 12 Harald Hoyer 2004-10-25 11:48:47 EDT
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...
Comment 13 Ralf Ertzinger 2004-10-25 13:12:04 EDT
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.
Comment 14 Ralf Ertzinger 2004-10-25 13:12:32 EDT
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 ()
Comment 15 Harald Hoyer 2004-11-23 08:06:46 EST
kernel issue, see #134822
Comment 16 Dave Jones 2004-11-27 16:33:04 EST
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

Note You need to log in before you can comment on or make changes to this bug.