Red Hat Bugzilla – Bug 137610
Kdevelop crashes in FC3rc3. Looks like glibc related.
Last modified: 2007-11-30 17:10:53 EST
Kdevelop crashes when opening an existing project as a custom makefile
project where it imports all of the existing c source files. I've
debugged this for a while using gdb and the bt always starts with
memcpy. I can't find anything wrong with the code in kdevelop. It
looks to me like a memory leak or a pointer problem.
I'm hesitant to report this as a bug in glibc, but that is the feeling
I'm left with. The file importing makes heavy use of memcpy and other
C library functions.
Component version: glibc-2.3.3-73
a) download kdevelop3.1.1 source RPMs from www.kdevelop.org. Untar
them. Build it.
$ echo $QTDIR
$ echo $KDEDIR
$./configure --enable-debug=full --prefix=$KDEDIR
b) Test run kdevelop.
$ export KDEDIRS=/home/krlux/kdevelop-3.1.1/:$KDEDIRS &&
Note: if it is running correctly you'll get the splash screen and the
projects menu will have Import Existing Project. If not, check the
export step above.
c) download gdb-6.2 source rpm. Untar it.
d) run kdevelop either alone or in gdb.
Select Projects->Import Existing Project
Browse to the gdb-6.2-xxx directory
Give the project a name. I've been using numbers like 1,2,3,5, etc.
Don't reuse the same name in subsequent attepts.
A dialog box will appear asking if you want to import all the source
files below the project directory. Say Yes.
Things will progress fine until "UPdating..." appears in the Windows
status bar. On my computer, depending on which project I am
importing, the status gets to a certain percentage and then stalls.
At that point the operating system becomes unresponsive. If one waits
long enough the application terminates itself and the OS becomes
If one is quick and uses "ctrl c" in gdb when Updating first stalls,
you can interrupt the process and then get a backtrace. It always
yields something like this:
Program received signal SIGINT, Interrupt.
[Switching to Thread -152062272 (LWP 8640)]
0x007f74dc in memcpy () from /lib/tls/libc.so.6
#0 0x007f74dc in memcpy () from /lib/tls/libc.so.6
#1 0x02b8ab5e in QString::setLength () from /usr/lib/qt-3.3/lib/libqt-
#2 0x02b8af12 in QString::grow () from /usr/lib/qt-3.3/lib/libqt-
#3 0x02b8ea11 in QString::insert () from /usr/lib/qt-3.3/lib/libqt-
#4 0x02b8eaa1 in QString::insert () from /usr/lib/qt-3.3/lib/libqt-
#5 0xf66308ea in Lexer::nextToken ()
#6 0xf663a0a6 in Lexer::tokenize ()
#7 0xf663a2d0 in Lexer::setSource ()
#8 0xf66284c6 in Driver::parseFile ()
#9 0xf66cbd8e in CppSupportPart::slotParseFiles ()
#10 0xf66d3691 in CppSupportPart::qt_invoke ()
#11 0x028c33a0 in QObject::activate_signal ()
#12 0x02bf459d in QSignal::signal () from /usr/lib/qt-3.3/lib/libqt-
#13 0x028dc0dd in QSignal::activate () from /usr/lib/qt-3.3/lib/libqt-
#14 0x028e319b in QSingleShotTimer::event ()
---Type <return> to continue, or q <return> to quit---
#15 0x02864849 in QApplication::internalNotify ()
#16 0x028649da in QApplication::notify ()
#17 0x001b94e8 in KApplication::notify () from /usr/lib/libkdecore.so.4
#18 0x02858bbe in QEventLoop::activateTimers ()
#19 0x02814bde in QEventLoop::processEvents ()
#20 0x02879e75 in QEventLoop::enterLoop ()
#21 0x02879dce in QEventLoop::exec () from /usr/lib/qt-3.3/lib/libqt-
#22 0x02863a4b in QApplication::exec () from /usr/lib/qt-3.3/lib/libqt-
#23 0x0809db71 in main ()
$ cat maps
00775000-0078a000 r-xp 00000000 03:05 6193243 /lib/ld-2.3.3.so
0078a000-0078b000 r--p 00014000 03:05 6193243 /lib/ld-2.3.3.so
0078b000-0078c000 rw-p 00015000 03:05 6193243 /lib/ld-2.3.3.so
0078e000-008af000 r-xp 00000000 03:05 6258989 /lib/tls/libc-2.3.3.so
008af000-008b1000 r--p 00120000 03:05 6258989 /lib/tls/libc-2.3.3.so
008b1000-008b3000 rw-p 00122000 03:05 6258989 /lib/tls/libc-2.3.3.so
008b3000-008b5000 rw-p 008b3000 00:00 0
008dc000-008de000 r-xp 00000000 03:05 6193244 /lib/libdl-2.3.3.so
008de000-008df000 r--p 00001000 03:05 6193244 /lib/libdl-2.3.3.so
008df000-008e0000 rw-p 00002000 03:05 6193244 /lib/libdl-2.3.3.so
009cd000-009d0000 r-xp 00000000 03:05
009d0000-009d1000 rw-p 00002000 03:05
08047000-080d8000 r-xp 00000000 03:05 6045828 /bin/bash
080d8000-080de000 rw-p 00090000 03:05 6045828 /bin/bash
080de000-080e3000 rw-p 080de000 00:00 0
08caf000-08cf1000 rw-p 08caf000 00:00 0
f6dc9000-f6dd2000 r-xp 00000000 03:05
f6dd2000-f6dd3000 r--p 00008000 03:05
f6dd3000-f6dd4000 rw-p 00009000 03:05
f6de0000-f6de2000 rw-p f6de0000 00:00 0
f6de2000-f6de3000 r--p 002de000 03:05 2255274 /usr/lib/locale/locale-
f6de3000-f6de9000 r--s 00000000 03:05 2261896 /usr/lib/gconv/gconv-
f6de9000-f6fe9000 r--p 00000000 03:05 2255274 /usr/lib/locale/locale-
f6fe9000-f6feb000 rw-p f6fe9000 00:00 0
fef1d000-ff000000 rw-p fef1d000 00:00 0
ffffe000-fffff000 ---p 00000000 00:00 0
Reproducable: happens every time.
btw; I saw a glibc update message on fedora-tester-list about
glibc-2.3.3-27-1, but I don't know where to get it to use it. (I
don't have yum and update working on FC3rc3 yet.)
The chances of this being a glibc bug rather than KDE/Qt bug are really low,
as in, there is absolutely no indication from the above report that
would point to glibc.
It crashes at the same address in memcpy() every time.
I had a really obscure QT crash in FC3T3 when I first installed it. I
had the backtrace on it until a few hours ago. I deleted it. I left
the qt bt out because I didn't think it was relevant.
When you mean KDE to you mean as in kdebase or kdevelop ?
Do you think qt is giving memcpy and invalid pointer ?
I don't understand why it fails silently. What is killing the process
? Is it killing itself ?
I'm using kdebug-dialog --full and I'm not seeing any asserts going
off anywhere. Is there a debug version of kde, qt or glibc I should
be running to get more info ?
Look what I found:
Using host libthread_db library "/lib/tls/libthread_db.so.1".
#5 0x0676b207 in operator== () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#6 0x000001f4 in ?? () from /lib/libdl.so.2
#7 0x067686d1 in QString::operator+= ()
I've reported this to kdev's bugzilla. It is bug# 92560.
The root cause of this problem was found in kdevelop.
Although I was reassured that the problem was isolated to my use of
FC3, a kdev developer found a bug that had nothing to do with FC3.