Zandronum Chat on our Discord Server Get the latest version: 3.2
Source Code
My View | View Issues | Change Log | Roadmap | Doomseeker Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003268Doomseeker[All Projects] Bugpublic2017-09-20 17:392018-10-27 22:55
ReporterWubTheCaptain 
Assigned ToZalewa 
PrioritynormalSeveritycrashReproducibilitysometimes
StatusclosedResolutionfixed 
Platformx86_64OSDebian GNU/LinuxOS Versionbuster/sid
Product Version1.1 
Target Version1.2Fixed in Version1.2 
Summary0003268: Doomseeker crashes when attempting to cancel joining a server while WADs are downloading and awaiting URLs
DescriptionDoomseeker 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 ReproduceI 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 InformationNo core dump anywhere I can see.

I was almost going to tag this "unable to reproduce", but gladly found a way to reproduce it.
Attached Fileslog file icon doomseeker-debug.log [^] (11,057 bytes) 2017-09-20 18:18
log file icon doomseeker-stdout.log [^] (2,198 bytes) 2017-09-20 18:24
log file icon dmesg.log [^] (1,683 bytes) 2017-09-20 18:31
txt file icon gdb.txt [^] (59,371 bytes) 2017-09-20 19:03 [Show Content]
txt file icon gdb.1.txt [^] (9,990 bytes) 2017-09-20 19:11 [Show Content]
txt file icon gdb.2.txt [^] (5,746 bytes) 2017-09-20 19:15 [Show Content]

- Relationships

-  Notes
User avatar (0018345)
WubTheCaptain (reporter)
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.
User avatar (0018346)
WubTheCaptain (reporter)
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.
User avatar (0018347)
WubTheCaptain (reporter)
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.
User avatar (0018348)
WubTheCaptain (reporter)
2017-09-20 18:38

 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
User avatar (0018349)
WubTheCaptain (reporter)
2017-09-20 19:18

 Output with debug symbols and "bt full" in attachments.
User avatar (0018350)
WubTheCaptain (reporter)
2017-09-20 20:12

 Qt 5.9.1, for what little it's worth.
User avatar (0018351)
WubTheCaptain (reporter)
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?
User avatar (0018362)
Zalewa (developer)
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.
User avatar (0018363)
WubTheCaptain (reporter)
2017-09-24 02:16

 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.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- 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 View Revisions
2017-09-20 17:59 WubTheCaptain Note Added: 0018346
2017-09-20 18:01 WubTheCaptain Note Edited: 0018346 View Revisions
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 View Revisions
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 View Revisions
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 View Revisions
2017-09-23 20:54 Zalewa Note Edited: 0018362 View Revisions
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




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker