| Summary: | crash after stop build pressed | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Lukasz Michalski <l.michalski> |
| Component: | general | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | crash | ||
| Priority: | NOR | ||
| Version: | 3.0.4 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | gdb stderr log and backtrace | ||
|
Description
Lukasz Michalski
2004-08-09 13:26:42 UTC
Created attachment 7048 [details]
gdb stderr log and backtrace
Forgot to metion: this bug still exists in kdevelop 3.0.95 (compiled from sources) Please reconfigure/rebuild with --enable-debug=full and see if you can get a better backtrace. AFAIK, you're the only one who has managed to trigger this and unless there is something concrete to go on I'm most inclined to write this off as flakey hardware. Some questions: 1. Are you running KDevelop from within KDE? Is it started from the K-menu? 2. Does the same problem appear if you run KDevelop from konsole? I recompiled with debug symbols 3.0.95 and tried my another project: EPORT=\"\" -DPACKAGE=\"common\" -DVERSION=\"0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I/home/users/zork/sources/common/common -O0 -g3 -MT tm.o -MD -MP -MF ".deps/tm.Tpo" -c -o tm.o /home/users/zork/sources/common/common/tm.cpp; \ kdevelop (output views): Directory filter line then mv -f ".deps/tm.Tpo" ".deps/tm.Po"; else rm -f ".deps/tm.Tpo"; exit 1; fi kdevelop (output views): Found: compiling tm.cpp(g++) kdevelop (output views): Directory filter line if g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"common\" -DVERSION=\"0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I/home/users/zork/sources/common/common -O0 -g3 -MT sem.o -MD -MP -MF ".deps/sem.Tpo" -c -o sem.o /home/users/zork/sources/common/common/sem.cpp; \ kdevelop (output views): Directory filter line then mv -f ".deps/sem.Tpo" ".deps/sem.Po"; else rm -f ".deps/sem.Tpo"; exit 1; fi kdevelop (output views): Found: compiling sem.cpp(g++) kdevelop (output views): Directory filter line if g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"common\" -DVERSION=\"0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I/home/users/zork/sources/common/common -O0 -g3 -MT staticspace.o -MD -MP -MF ".deps/staticspace.Tpo" -c -o staticspace.o /home/users/zork/sources/common/common/staticspace.cpp; \ kdevelop (output views): Directory filter line then mv -f ".deps/staticspace.Tpo" ".deps/staticspace.Po"; else rm -f ".deps/staticspace.Tpo"; exit 1; fi kdevelop (output views): Found: compiling staticspace.cpp(g++) kdevelop (output views): Directory filter line if g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"common\" -DVERSION=\"0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I/home/users/zork/sources/common/common -O0 -g3 -MT treeutils.o -MD -MP -MF ".deps/treeutils.Tpo" -c -o treeutils.o /home/users/zork/sources/common/common/treeutils.cpp; \ kdevelop (output views): Directory filter line then mv -f ".deps/treeutils.Tpo" ".deps/treeutils.Po"; else rm -f ".deps/treeutils.Tpo"; exit 1; fi kdevelop (output views): Found: compiling treeutils.cpp(g++) kdevelop (output views): Directory filter line rm -f libcommon.a kdevelop (output views): Directory filter line ar cru libcommon.a pointers.o conversion.o exception.o bitmask.o autoincrementedmap.o observer.o membertree.o tm.o sem.o staticspace.o treeutils.o kdevelop (output views): Directory filter line ranlib libcommon.a kdevelop (output views): Directory filter line make[1]: Leaving directory `/home/users/zork/sources/common/debug/common' kdevelop (output views): Directory filter line make[1]: Entering directory `/home/users/zork/sources/common/debug' kdevelop (output views): Directory filter line make[1]: Nothing to be done for `all-am'. kdevelop (output views): Directory filter line make[1]: Leaving directory `/home/users/zork/sources/common/debug' Program received signal SIGTERM, Terminated. 0x418f9a31 in select () from /lib/libc.so.6 (gdb) bt #0 0x418f9a31 in select () from /lib/libc.so.6 #1 0x415e07d4 in ?? () from /usr/lib/libqt-mt.so.3 #2 0x00000015 in ?? () #3 0x4116d908 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3 #4 0x4116d7b8 in QEventLoop::exec () from /usr/lib/libqt-mt.so.3 #5 0x4115c4c1 in QApplication::exec () from /usr/lib/libqt-mt.so.3 #6 0x080c5a32 in main (argc=1, argv=0xbffff9d4) at main.cpp:132 (gdb) quit The program is running. Exit anyway? (y or n) y Now I am trying to recompile qt using specs from my distribution. I got this behaviour on two identical machines with two identical linuxes (PLD 2.0 beta) installed. On both "stop" button is useless. Answers:. 1. I am using kdevelop from within KDE. If it is started from K-menu then "stop" terminates my X-Server. I have no other problems with any KDE-app installed in my system. 2. If kdevelop is started from console then it just prints "terminated" after "stop" button is used. QT rebuild didn't help :( What else can I do? I tried to debug kevelop 3.0.92 but I am little bit lost in the sources..... There is still no one else who has reproduced this problem. I have never heard of "PLD Linux" but maybe they enforce some non-standard process policy or something... There has been a slight change in the relevant code in HEAD recently, unless that happens to help, I can't see that we can do anything about this. Closing as WONTFIX. Problem disappeared between 3.1.2 and 3.2.0 Regards, Łukasz |