Bug 7404

Summary: konsole dumps core
Product: [Retired] Red Hat Linux Reporter: lok
Component: kdebaseAssignee: Bernhard Rosenkraenzer <bero>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: lok
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-02-28 22:36:49 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:

Description lok 1999-11-29 05:56:26 UTC
konsole dumps core for me if I do the following:
- window is resized to height of the screen
- font is set to Large (using Options->Font)
- telnet to another machine (Solaris machine)
- ftp back into my desktop box
- use binary and hashes for transfer
- start transfer of 32MB file - transfer usually crashes before completion
- window dies, core dump is generated

konsole has also dumped core for me at other times which I have not been
able to diagnose.

Even if this is a ftp problem, I don't think that konsole should crash and
dump core :)

I have run gdb on the core file, and the output follows. While running
konsole from inside gdb, the crash was reproduced, as above.

Hope this information helps,

Lachlan Cameron-Smith
Systems Specialist, ITS, University of Adelaide
lok.edu.au


> gdb -c core /usr/bin/konsole
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you a
re
welcome to change it and/or distribute copies of it under certain conditio
ns.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details
.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
   00-00-c0-4b-16-e8   7/7 [ALL]`!#220   00-00-c0-16-5a-f3   7/7
[ALL]8? )...
done.
Reading symbols from /usr/lib/libjpeg.so.62...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libtiff.so.3...done.
Reading symbols from /usr/lib/libz.so.1...done.
Reading symbols from /usr/lib/libpng.so.2...done.
Reading symbols from /usr/lib/qt-1.44/lib/libqt.so.1...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /usr/lib/libkdeui.so.2...done.
Reading symbols from /usr/lib/libkdecore.so.2...done.
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Reading symbols from /usr/lib/libstdc++-libc6.1-1.so.2...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x4052aea4 in chunk_free (ar_ptr=0x405bf040, p=0x8126968) at
malloc.c:3036
3036    malloc.c: No such file or directory.
(gdb) list
3031    in malloc.c
(gdb) next
The program is not being run.
(gdb) run
Starting program: /usr/bin/konsole
Qt: gdb: -nograb added to command-line options.
         Use the -dograb option to enforce grabbing.
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
chunk_alloc (ar_ptr=0x405bf040, nb=72) at malloc.c:2750
2750    malloc.c: No such file or directory.
(gdb) list
2745    in malloc.c
(gdb)
(gdb) finish
Run till exit from #0  chunk_alloc (ar_ptr=0x405bf040, nb=72) at
malloc.c:2750

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)

Comment 1 lok 1999-11-30 03:31:59 UTC
This may be because the machine was running with 64MB of memory with Netscape
and Java applets also running perhaps? :)

Anyway, a backtrace of the stack from the core dump follows.

(gdb) bt
#0  chunk_alloc (ar_ptr=0x405bf040, nb=72) at malloc.c:2750
#1  0x4052a40a in __libc_malloc (bytes=65) at malloc.c:2643
#2  0x404c1006 in __builtin_new (sz=65)
   from /usr/lib/libstdc++-libc6.1-1.so.2
#3  0x404c11dc in __builtin_vec_new (sz=65)
   from /usr/lib/libstdc++-libc6.1-1.so.2
#4  0x80560b3 in QCollection::newItem ()
#5  0x805ce9f in QCollection::newItem ()
#6  0x4013e8b4 in QObject::activate_signal ()
   from /usr/lib/qt-1.44/lib/libqt.so.1
#7  0x401e0baf in QTimer::timeout ()
   from /usr/lib/qt-1.44/lib/libqt.so.1
#8  0x4014d779 in QTimer::event ()
   from /usr/lib/qt-1.44/lib/libqt.so.1
#9  0x4011d0bb in QApplication::notify ()
   from /usr/lib/qt-1.44/lib/libqt.so.1
#10 0x401b7027 in qt_activate_timers ()
   from /usr/lib/qt-1.44/lib/libqt.so.1
#11 0x401b5982 in QApplication::processNextEvent ()
   from /usr/lib/qt-1.44/lib/libqt.so.1
#12 0x401b64be in QApplication::enter_loop ()
   from /usr/lib/qt-1.44/lib/libqt.so.1
#13 0x401b5731 in QApplication::exec ()
   from /usr/lib/qt-1.44/lib/libqt.so.1
#14 0x805283a in QCollection::newItem ()
#15 0x404ea1eb in __libc_start_main (
    main=0x80520f0 <QCollection::newItem(void *)+14636>, argc=1,
    argv=0xbffffd04, init=0x804d364 <_init>,
    fini=0x805e620 <_fini>, rtld_fini=0x4000a610 <_dl_fini>,
    stack_end=0xbffffcfc) at ../sysdeps/generic/libc-start.c:90

Comment 2 Bernhard Rosenkraenzer 1999-12-01 12:14:59 UTC
I've tried several times, it worked every time for me.
I don't have a solaris box though [Maybe the solaris termcap is messing this
up?].
Can you reproduce this by ftping a file from the linux box to the linux box or
something like that?
I doubt this is related to Netscape - under Linux, a program can't crash another
program (netscape itself can crash, but it can't take konsole or anything else
with it).

Comment 3 lok 1999-12-01 23:39:59 UTC
This problem appears to have been caused by a memory shortage -
the box has been upgraded from 64MB to 192MB, and there is no
problems anymore - logging in to solaris box and transferring
file as before works like a charm now.
The problem with netscape was it ate most of the 64MB, not leaving
enough for konsole apparently, but that's another story :)

I'm happy to close this off now.

Thanks,
Lachlan

Comment 4 lok 1999-12-13 01:12:59 UTC
This has happened again to me. This time, I was logged into a DEC box via SSH, I
was grepping for a string in a system log file, and my konsole window vanished,
leaving a core dump in my directory.
I have lots of free memory :

> free
             total       used       free     shared    buffers     cached
Mem:        192772     173076      19696      49140      26920      64748
-/+ buffers/cache:      81408     111364
Swap:       136512       1028     135484

Backtrace follows:

#0  0x4052aea4 in chunk_free (ar_ptr=0x405bf040, p=0x810ad60)
    at malloc.c:3036
3036    malloc.c: No such file or directory.
(gdb) bt
#0  0x4052aea4 in chunk_free (ar_ptr=0x405bf040, p=0x810ad60)
    at malloc.c:3036
#1  0x4052ad75 in __libc_free (mem=0x810ad68) at malloc.c:2959
#2  0x805cea5 in QCollection::newItem ()
#3  0x805cf10 in QCollection::newItem ()
#4  0x805cd5f in QCollection::newItem ()
#5  0x805d2b2 in QCollection::newItem ()
#6  0x805dcfe in QCollection::newItem ()
#7  0x4013eb97 in QObject::activate_signal ()
   from /usr/lib/qt-1.44/lib/libqt.so.1
#8  0x401e09d2 in QSocketNotifier::activated ()
   from /usr/lib/qt-1.44/lib/libqt.so.1
#9  0x4014d5fc in QSocketNotifier::event ()
   from /usr/lib/qt-1.44/lib/libqt.so.1
#10 0x4011d0bb in QApplication::notify ()
   from /usr/lib/qt-1.44/lib/libqt.so.1
#11 0x401b565d in sn_activate () from /usr/lib/qt-1.44/lib/libqt.so.1
#12 0x401b597a in QApplication::processNextEvent ()
   from /usr/lib/qt-1.44/lib/libqt.so.1
#13 0x401b64be in QApplication::enter_loop ()
   from /usr/lib/qt-1.44/lib/libqt.so.1
#14 0x401b5731 in QApplication::exec () from /usr/lib/qt-1.44/lib/libqt.so.1#15
0x805283a in QCollection::newItem ()
#16 0x404ea1eb in __libc_start_main (
    main=0x80520f0 <QCollection::newItem(void *)+14636>, argc=7,
    argv=0xbffffd34, init=0x804d364 <_init>, fini=0x805e620 <_fini>,
    rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbffffd2c)
    at ../sysdeps/generic/libc-start.c:90

I tried the same sequence of commands again, and could not reproduce the crash.
This is a out-of-the-box RedHat 6.1 system, upgraded from 6.0, running on an
AcerPower 4100.

Please let me know if you need any more info.

Thanks,
Lachlan

Comment 5 Preston Brown 2000-02-28 22:36:59 UTC
we'll continue to try and reproduce the issue here, but we haven't been
successful to date.

Comment 6 lok 2000-03-01 01:33:59 UTC
I have not observed a reoccurrance of this problem since my last report...