Application that crashed: kile Version of the application: 2.0.83 KDE Version: 4.3.1 (KDE 4.3.1) "release 6" Qt Version: 4.5.3 Operating System: Linux 2.6.31.8-0.1-desktop i686 Distribution: "openSUSE 11.2 (i586)" What I was doing when the application crashed: I performed a full, fresh download, compile & install from SVN in a terminal. All terminal activity captured in transcript file using 'script.' Download, compile and install all OK. Other apps open: Firefox (Mozilla Firefox 3.5.7, Copyright (c) 1998 - 2009 mozilla.org). Ran Kile in same terminal. Performed system checks - OK (saved to file). Manually copied previously created document to testing area and opened in Kile. Compiled test document OK. Selected File -> Quit. GUI disappeared (as expected). Terminal from which Kile started not released for 6 minutes. Kile process still running during that time. KCrash appeared. Details filled out & submitted. Will post my transcript files ASAP. -- Backtrace: Application: Kile (kile), signal: Segmentation fault [KCrash Handler] #6 QStackedWidget::currentWidget (this=0x29) at widgets/qstackedwidget.cpp:229 #7 0xb60896d4 in QTabWidget::currentWidget (this=0x86750f0) at widgets/qtabwidget.cpp:613 #8 0x08300e82 in KileView::Manager::currentTextView() const () #9 0x0824ab92 in KileInfo::activeTextDocument() const () #10 0x082f02b3 in KileDocument::Manager::getInfo() const () #11 0x08301002 in KileView::Manager::updateStructure(bool, KileDocument::Info*) () #12 0x0830359f in KileView::Manager::qt_metacall(QMetaObject::Call, int, void**) () #13 0xb6600864 in QMetaObject::activate (sender=0x8519f98, from_signal_index=7, to_signal_index=7, argv=0xbfc44e84) at kernel/qobject.cpp:3113 #14 0xb6601585 in QMetaObject::activate (sender=0x8519f98, m=0x8405840, local_signal_index=3, argv=0xbfc44e84) at kernel/qobject.cpp:3187 #15 0x082f00e7 in KileDocument::Manager::updateStructure(bool, KileDocument::Info*) () #16 0x082f5780 in KileDocument::Manager::fileSaveAll(bool, bool) () #17 0x08117442 in Kile::autoSaveAll() () #18 0x0820be2e in Kile::qt_metacall(QMetaObject::Call, int, void**) () #19 0xb6600864 in QMetaObject::activate (sender=0x849a010, from_signal_index=4, to_signal_index=4, argv=0x0) at kernel/qobject.cpp:3113 #20 0xb6601585 in QMetaObject::activate (sender=0x849a010, m=0xb66dd904, local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3187 #21 0xb663c715 in QTimer::timeout (this=0x849a010) at .moc/release-shared/moc_qtimer.cpp:128 #22 0xb6606196 in QTimer::timerEvent (this=0x849a010, e=0xbfc45504) at kernel/qtimer.cpp:261 #23 0xb65fa51b in QObject::event (this=0x849a010, e=0xbfc45504) at kernel/qobject.cpp:1075 #24 0xb5c158fc in QApplicationPrivate::notify_helper (this=0x849c738, receiver=0x849a010, e=0xbfc45504) at kernel/qapplication.cpp:4065 #25 0xb5c1d34e in QApplication::notify (this=0xbfc45860, receiver=0x849a010, e=0xbfc45504) at kernel/qapplication.cpp:3605 #26 0xb6b92ce1 in KApplication::notify (this=0xbfc45860, receiver=0x849a010, event=0xbfc45504) at /usr/src/debug/kdelibs-4.3.1/kdeui/kernel/kapplication.cpp:302 #27 0xb65ea32e in QCoreApplication::notifyInternal (this=0xbfc45860, receiver=0x849a010, event=0xbfc45504) at kernel/qcoreapplication.cpp:610 #28 0xb6619356 in sendEvent (event=<value optimized out>, receiver=<value optimized out>) at kernel/qcoreapplication.h:213 #29 QTimerInfoList::activateTimers (event=<value optimized out>, receiver=<value optimized out>) at kernel/qeventdispatcher_unix.cpp:594 #30 0xb6616325 in timerSourceDispatch (source=0x849efb8) at kernel/qeventdispatcher_glib.cpp:184 #31 idleTimerSourceDispatch (source=0x849efb8) at kernel/qeventdispatcher_glib.cpp:231 #32 0xb50814c2 in g_main_dispatch (context=<value optimized out>) at gmain.c:1960 #33 IA__g_main_context_dispatch (context=<value optimized out>) at gmain.c:2513 #34 0xb5084d98 in g_main_context_iterate (context=0x849e890, block=<value optimized out>, dispatch=1, self=0x849c370) at gmain.c:2591 #35 0xb5084ebe in IA__g_main_context_iteration (context=0x849e890, may_block=1) at gmain.c:2654 #36 0xb6616011 in QEventDispatcherGlib::processEvents (this=0x847ef30, flags=...) at kernel/qeventdispatcher_glib.cpp:407 #37 0xb5cb729a in QGuiEventDispatcherGlib::processEvents (this=0x847ef30, flags=...) at kernel/qguieventdispatcher_glib.cpp:202 #38 0xb65e898d in QEventLoop::processEvents (this=0xbfc457b4, flags=) at kernel/qeventloop.cpp:149 #39 0xb65e8dd9 in QEventLoop::exec (this=0xbfc457b4, flags=...) at kernel/qeventloop.cpp:201 #40 0xb65eb270 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888 #41 0xb5c15774 in QApplication::exec () at kernel/qapplication.cpp:3525 #42 0x0820e103 in main () Reported using DrKonqi
Created attachment 40229 [details] Terminal transcript of complete Kile dowload and session. This is a transcript of ALL terminal input & output from initial download to running of latest SVN code.
Created attachment 40230 [details] Output of System Check post install. System check output.
Comment on attachment 40229 [details] Terminal transcript of complete Kile dowload and session. OK I'm a moron. At the end of this file, where I run Kile, I missed out the './'. Quite stupid. kile.transcript.2 is another script from the point of running Kile. Everything else has remained the same. Sorry!
(In reply to comment #3) > (From update of attachment 40229 [details]) > OK I'm a moron. At the end of this file, where I run Kile, I missed out the > './'. Quite stupid. kile.transcript.2 is another script from the point of > running Kile. Everything else has remained the same. Sorry! I don't think that 'kile.transcript.2' has been uploaded correctly... (could you maybe also choose a text mime type?) It would be interesting to see the output of Kile when it doesn't terminate correctly. Thanks.
Hi, RE: kile.transcript.2 - I'm still waiting for Kile to segfault - it hasn't released my terminal in over 15 minutes! As soon as it's completed I'll post it. In the meantime I'll change the mimetypes! ;)
Update: nearly ONE HOUR from quitting the Kile 2.0.84 GUI, the kile process as not terminated and released my terminal session. This is in stark contrast to version 2.0.83. I don't think 2.0.84 is going to quit at all... Output of ps aux at T + 50 minutes: kile-install/bin> ps aux | grep kile paul 18565 0.0 0.0 3068 708 pts/0 S+ 11:55 0:00 script kile.transcript.2 paul 18566 0.0 0.0 3072 436 pts/0 S+ 11:55 0:00 script kile.transcript.2 paul 18597 0.2 2.7 120584 56716 pts/1 Sl+ 11:55 0:04 ./kile paul 18625 0.0 0.2 36512 5696 ? S 11:55 0:00 kdeinit4: kio_file [kdeinit] file local:/tmp/ksocket-paul/klauncherT14323.slave-socket local:/tmp/ksocket-paul/kileZ18597.slave-socket kile-install/bin>
Created attachment 40233 [details] Terminal transcript of 2.0.84, gave up after over an hour! Not much in this one. The Kile process ran for well over an hour after quitting the GUI. In the end I had to send a HUP from another window to release the terminal. I didn't just hit CTRL-C since I wanted to see if sending a signal would make it do something (like crash). Normal CPU usage was not affected. I/O, swap, mem and net usage were all baseline. It was like the process was idle, waiting for something. It would seem that 2.0.84 is worse at quitting than 2.0.83 - the earlier version takes up to 15 minutes to quit (albeit ungracefully) but 2.0.84 hangs on until someone or something actively kills it. At least, these are my findings so far. PS output after HUP: kile-install/bin> ps aux | grep kile paul 18625 0.0 0.2 36892 5784 ? S 11:55 0:00 kdeinit4: kio_file [kdeinit] file local:/tmp/ksocket-paul/klauncherT14323.slave-socket local:/tmp/ksocket-paul/kileZ18597.slave-socket kile-install/bin> It would almost be worth a VNC session / movie to give a true representation of what's happening (or not)...
Can you maybe try it again without using "script", i.e. just in a terminal, and then paste the output here? (I assume that Kile was compiled in debug mode and that it prints something when it is executed) The last lines of output will probably be crucial for fixing this issue...
- Isn't this related to bug 220343 ? Regards
(In reply to comment #9) > - Isn't this related to bug 220343 ? Regards Yes, it's the same thing. I just wanted to get some more information here but I've got what I wanted now in 220343. *** This bug has been marked as a duplicate of bug 220343 ***