MantisBT - Doomseeker |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0003268 | Doomseeker | [All Projects] Bug | public | 2017-09-20 17:39 | 2018-10-27 22:55 |
|
| Reporter | WubTheCaptain | |
| Assigned To | Zalewa | |
| Priority | normal | Severity | crash | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | |
| Platform | x86_64 | OS | Debian GNU/Linux | OS Version | buster/sid |
| Product Version | 1.1 | |
| Target Version | 1.2 | Fixed in Version | 1.2 | |
|
| Summary | 0003268: Doomseeker crashes when attempting to cancel joining a server while WADs are downloading and awaiting URLs |
| Description | Doomseeker crashed when I pressed "cancel" to the following textbox:
Quote
You don't have all the files required by this server and an instance of Wadseeker is already running.
Press 'Ignore' to join anyway.
This is dependent on active downloads in Wadseeker, and I've managed to crash this somewhat consistently. |
| Steps To Reproduce | I attempted to join a server. I had missing WADs. I was asked to download WADs.
(This is probably irrelevant, but making a mention anyway: The server also had an optional WAD, which I first clicked to "ignore". I then unchecked the optional WAD and clicked continue.)
Now I had three WADs in the queue: One downloading from host #1, second one downloading from host 0000002, and third one "Awaiting URLs".
Quickly while the two WADs are downloading, I right clicked "refresh" on the same server with missing WADs. (Whether this step is needed or not I've not tried.) I then attempted to join the server.
Doomseeker presented a dialog in the description. Clicking "cancel" crashes Doomseeker if the third WAD is still awaiting URLs? |
| Additional Information | No core dump anywhere I can see.
I was almost going to tag this "unable to reproduce", but gladly found a way to reproduce it. |
| Tags | No tags attached. |
| Relationships | |
| Attached Files |  doomseeker-debug.log (11,057) 2017-09-20 18:18
https://zandronum.com/tracker/file_download.php?file_id=2207&type=bug
doomseeker-stdout.log (2,198) 2017-09-20 18:24
https://zandronum.com/tracker/file_download.php?file_id=2208&type=bug
dmesg.log (1,683) 2017-09-20 18:31
https://zandronum.com/tracker/file_download.php?file_id=2209&type=bug
gdb.txt (59,371) 2017-09-20 19:03
https://zandronum.com/tracker/file_download.php?file_id=2210&type=bug
gdb.1.txt (9,990) 2017-09-20 19:11
https://zandronum.com/tracker/file_download.php?file_id=2211&type=bug
gdb.2.txt (5,746) 2017-09-20 19:15
https://zandronum.com/tracker/file_download.php?file_id=2212&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2017-09-20 17:39 | WubTheCaptain | New Issue | |
| 2017-09-20 17:46 | WubTheCaptain | Note Added: 0018345 | |
| 2017-09-20 17:47 | WubTheCaptain | Note Edited: 0018345 | bug_revision_view_page.php?bugnote_id=18345#r10976 |
| 2017-09-20 17:59 | WubTheCaptain | Note Added: 0018346 | |
| 2017-09-20 18:01 | WubTheCaptain | Note Edited: 0018346 | bug_revision_view_page.php?bugnote_id=18346#r10978 |
| 2017-09-20 18:18 | WubTheCaptain | File Added: doomseeker-debug.log | |
| 2017-09-20 18:19 | WubTheCaptain | Note Added: 0018347 | |
| 2017-09-20 18:24 | WubTheCaptain | File Added: doomseeker-stdout.log | |
| 2017-09-20 18:25 | WubTheCaptain | Note Edited: 0018347 | bug_revision_view_page.php?bugnote_id=18347#r10980 |
| 2017-09-20 18:31 | WubTheCaptain | File Added: dmesg.log | |
| 2017-09-20 18:38 | WubTheCaptain | Note Added: 0018348 | |
| 2017-09-20 19:03 | WubTheCaptain | File Added: gdb.txt | |
| 2017-09-20 19:11 | WubTheCaptain | File Added: gdb.1.txt | |
| 2017-09-20 19:15 | WubTheCaptain | File Added: gdb.2.txt | |
| 2017-09-20 19:18 | WubTheCaptain | Note Added: 0018349 | |
| 2017-09-20 20:12 | WubTheCaptain | Note Added: 0018350 | |
| 2017-09-20 20:28 | WubTheCaptain | Note Added: 0018351 | |
| 2017-09-20 20:54 | WubTheCaptain | Note Edited: 0018351 | bug_revision_view_page.php?bugnote_id=18351#r10982 |
| 2017-09-23 17:52 | Zalewa | Assigned To | => Zalewa |
| 2017-09-23 17:52 | Zalewa | Status | new => assigned |
| 2017-09-23 20:53 | Zalewa | Note Added: 0018362 | |
| 2017-09-23 20:53 | Zalewa | Status | assigned => needs testing |
| 2017-09-23 20:53 | Zalewa | Note Edited: 0018362 | bug_revision_view_page.php?bugnote_id=18362#r10993 |
| 2017-09-23 20:54 | Zalewa | Note Edited: 0018362 | bug_revision_view_page.php?bugnote_id=18362#r10994 |
| 2017-09-24 02:16 | WubTheCaptain | Note Added: 0018363 | |
| 2017-09-24 07:52 | Zalewa | Status | needs testing => resolved |
| 2017-09-24 07:52 | Zalewa | Fixed in Version | => 1.2 |
| 2017-09-24 07:52 | Zalewa | Resolution | open => fixed |
| 2018-09-27 03:15 | WubTheCaptain | Target Version | => 1.2 |
| 2018-10-27 22:55 | WubTheCaptain | Status | resolved => closed |
|
Notes |
|
|
(0018345)
|
|
WubTheCaptain
|
2017-09-20 17:46
(edited on: 2017-09-20 17:47) |
|
For clarification, I did attempt to do this without awaiting URLs in the Wadseeker queue and it did not crash.
Wadseeker also crashes because the parent process(?) (Doomseeker) crashes.
|
|
|
|
(0018346)
|
|
WubTheCaptain
|
2017-09-20 17:59
(edited on: 2017-09-20 18:01) |
|
This is a bit random to reproduce. Sometimes it crashes, sometimes it gives the following error: QIODevice::read (QNetworkReplyHttpImpl): device not open. Sometimes it doesn't crash or error at all.
Still trying to debug.
|
|
|
|
(0018347)
|
|
WubTheCaptain
|
2017-09-20 18:19
(edited on: 2017-09-20 18:25) |
|
I reproduced doomseeker-debug.log, but this time I had no awaiting URLs. It's some kind of race condition.
I recorded doomseeker-debug.log with "./doomseeker > /tmp/doomseeker-debug.log 2>&1", but it doesn't look the same as in my terminal stdout. I attached partial doomseeker-stdout.log for you to see how I saw it in the terminal.
|
|
|
|
|
I have a coredump now, but it's 12 MB even gzipped and can't be uploaded to the tracker.
Reading symbols from ./doomseeker...done.
[New LWP 8377]
[New LWP 8381]
[New LWP 8386]
[New LWP 8378]
[New LWP 8404]
[New LWP 8387]
[New LWP 8402]
[New LWP 8395]
[New LWP 8382]
[New LWP 8384]
[New LWP 8385]
[New LWP 8388]
[New LWP 8389]
[New LWP 8390]
[New LWP 8391]
[New LWP 8392]
[New LWP 8393]
[New LWP 8394]
[New LWP 8396]
[New LWP 8397]
[New LWP 8398]
[New LWP 8399]
[New LWP 8403]
[New LWP 8780]
[New LWP 8781]
[New LWP 8379]
[New LWP 8380]
[New LWP 8821]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./doomseeker'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fc98c73002e in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
[Current thread is 1 (Thread 0x7fc98ed1b600 (LWP 8377))]
(gdb) list
582
583 // On the other hand we could just ignore the fact that this array is left
584 // hanging in the memory because Windows will clean it up for us...
585 for (int i = 0; i < argc; ++i)
586 {
587 delete [] argv[i];
588 }
589 delete [] argv;
590
591 return returnValue;
(gdb) bt
#0 0x00007fc98c73002e in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1 0x00007fc98c6250e1 in QIODevice::channelReadyRead(int) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
0000002 0x00007fc98d644644 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
0000003 0x00007fc98d656d21 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
0000004 0x00007fc98dd5a46c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
0000005 0x00007fc98dd61d34 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
0000006 0x00007fc98c701d68 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
0000007 0x00007fc98c75b05d in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
0000008 0x00007fc989d72f67 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000009 0x00007fc989d731a0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000010 0x00007fc989d7322c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000011 0x00007fc98c75a3ff in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
0000012 0x00007fc98c6ffdba in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
0000013 0x00007fc98c708d24 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
0000014 0x000056485973314e in Main::run (this=0x56485ab0d210) at /home/wub/.local/src/doomseeker/doomseeker-hg/src/core/main.cpp:219
0000015 0x0000564859734ddc in main (argc=1, argv=0x7ffda05f9b68) at /home/wub/.local/src/doomseeker/doomseeker-hg/src/core/main.cpp:597 |
|
|
|
|
|
Output with debug symbols and "bt full" in attachments. |
|
|
|
|
|
Qt 5.9.1, for what little it's worth. |
|
|
|
(0018351)
|
|
WubTheCaptain
|
2017-09-20 20:28
(edited on: 2017-09-20 20:54) |
|
I've also noticed something odd, following the steps to reproduce. Sometimes Doomseeker presents the 'Ignore' dialog when I refresh the server manually from right click menu. Sometimes it doesn't until I attempt to actually join it (double click).
Why is it trying to "join" the server on server refresh anyway?
|
|
|
|
(0018362)
|
|
Zalewa
|
2017-09-23 20:53
(edited on: 2017-09-23 20:54) |
|
I have noticed that nesting loops in Qt by calling QDialog::exec() or with an explicit QEventLoop can have a strange effect on the signal/slot system. Sometimes the same slot will be called twice, even when there was only one signal. In this case it resulted in a crash that was untraceable - the stack trace was garbage. I managed to reproduce this in Visual Studio and the debugger there was also very unhelpful.
Nevertheless, this should fix it:'https://bitbucket.org/Doomseeker/doomseeker/commits/362d3f5c361a1522fdb57e1df78b34cdae3683d5#Lsrc/core/connectionhandler.cppT92 [^]'
Quote from "WubTheCaptain"
I've also noticed something odd, following the steps to reproduce. Sometimes Doomseeker presents the 'Ignore' dialog when I refresh the server manually from right click menu. Sometimes it doesn't until I attempt to actually join it (double click).
Why is it trying to "join" the server on server refresh anyway?
This issue should also be fixed now.
|
|
|
|
|
I tested this few times and couldn't reproduce a crash any longer with the latest build (362d3f5c361a). The "Refresh before launch" operation in ConnectionHandler and configuration also seems to have been fixed as committed.
Color me impressed. |
|