Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 7404 - konsole dumps core
Summary: konsole dumps core
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kdebase
Version: 6.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-11-29 05:56 UTC by lok
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-02-28 22:36:49 UTC


Attachments (Terms of Use)

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@its.adelaide.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...


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