MantisBT - Doomseeker
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003395Doomseeker[All Projects] Bugpublic2018-03-03 19:472020-01-30 12:58
ReporterWubTheCaptain 
Assigned ToZalewa 
PrioritylowSeveritycrashReproducibilityrandom
StatusclosedResolutionfixed 
Platformx86_64OSDebian GNU/LinuxOS Versionbuster/sid
Product Version1.1 
Target Version1.3.1Fixed in Version1.3.1 
Summary0003395: Possible crash at start after the configuration directory was removed
DescriptionStarting a second process of Doomseeker crashed on start (quit immediately) and on next start displayed an empty server list. The first process survived after the crash.

I couldn't reproduce this bug yet, but I'll try my best to explain what happened in case it can be reproduced again.

In my window manager workspace 5 (out of cursor focus), I had Doomseeker 1.1 running for a long time. Because there was no cursor focus, the server list was also showing as empty. This would of course list all the servers immediately on cursor focus.

While this was open and in this state or right before it, I removed the configuration folder $HOME/.doomseeker. (Note, I have $HOME/.config/doomseeker too and didn't touch it, however Doomseeker 1.1 has no awareness of it since it's a Doomseeker 1.2 thing.) Then, I executed Doomseeker 1.1 again in workspace 6.

The main window displayed for a brief moment without any servers and then crashed. No dialog for "first time run" was displayed.

The first process in workspace 5 was still out of focus, but working and got the servers again after focus. Starting the second process in workspace 6 again would display the empty server list, and again have no "first time run" dialog.
Steps To Reproduce
Additional InformationWhether any of these steps to reproduce are correct is unknown. I didn't have stdout or stderr open, unfortunately.

It could also be the "empty server list" is the master server throttling response.
TagsNo tags attached.
Relationships
related to 0003733new  Auto-updates may fire late after other buggy threads / functions have initiated and crashed the program 
Attached Fileslog 2018-09-22-crash.log (2,458) 2018-09-22 01:48
/tracker/file_download.php?file_id=2404&type=bug
log 2018-09-22-02-05-14-crash.log (2,134) 2018-09-22 02:12
/tracker/file_download.php?file_id=2405&type=bug
png 2020-01-19-125651_maim.png (29,579) 2020-01-19 12:57
/tracker/file_download.php?file_id=2514&type=bug
png

png 2020-01-19-125725_maim.png (29,222) 2020-01-19 12:57
/tracker/file_download.php?file_id=2515&type=bug
png
Issue History
Date ModifiedUsernameFieldChange
2018-03-03 19:47WubTheCaptainNew Issue
2018-03-03 19:47WubTheCaptainSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=11449#r11449
2018-03-03 19:49WubTheCaptainSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=11450#r11450
2018-03-03 19:50WubTheCaptainAdditional Information Updatedbug_revision_view_page.php?rev_id=11452#r11452
2018-03-03 19:54WubTheCaptainDescription Updatedbug_revision_view_page.php?rev_id=11454#r11454
2018-03-03 19:54WubTheCaptainSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=11455#r11455
2018-08-20 20:43WubTheCaptainNote Added: 0019351
2018-08-20 20:45WubTheCaptainNote Added: 0019352
2018-08-20 20:48WubTheCaptainNote Added: 0019353
2018-09-22 01:46WubTheCaptainNote Added: 0019609
2018-09-22 01:48WubTheCaptainFile Added: 2018-09-22-crash.log
2018-09-22 01:58WubTheCaptainNote Added: 0019611
2018-09-22 02:09WubTheCaptainNote Added: 0019612
2018-09-22 02:12WubTheCaptainFile Added: 2018-09-22-02-05-14-crash.log
2018-09-22 02:13WubTheCaptainNote Added: 0019613
2018-09-22 02:19WubTheCaptainNote Added: 0019614
2018-09-22 02:20WubTheCaptainNote Added: 0019615
2018-09-22 02:23WubTheCaptainNote Added: 0019616
2018-09-22 02:24WubTheCaptainNote Deleted: 0019614
2018-09-22 02:24WubTheCaptainNote Deleted: 0019615
2018-09-22 02:25WubTheCaptainNote Deleted: 0019616
2018-09-22 02:33WubTheCaptainNote Added: 0019617
2018-09-22 02:33WubTheCaptainStatusnew => acknowledged
2018-09-22 02:33WubTheCaptainNote Edited: 0019617bug_revision_view_page.php?bugnote_id=19617#r11888
2018-09-22 02:36WubTheCaptainNote Edited: 0019617bug_revision_view_page.php?bugnote_id=19617#r11889
2018-09-22 02:36WubTheCaptainNote Edited: 0019617bug_revision_view_page.php?bugnote_id=19617#r11890
2018-09-22 02:37WubTheCaptainPrioritylow => normal
2018-09-22 02:42WubTheCaptainNote Added: 0019618
2018-09-22 02:43WubTheCaptainNote Edited: 0019618bug_revision_view_page.php?bugnote_id=19618#r11892
2018-09-22 02:47WubTheCaptainNote Added: 0019619
2018-09-22 02:47WubTheCaptainNote Edited: 0019619bug_revision_view_page.php?bugnote_id=19619#r11894
2018-09-22 02:47WubTheCaptainNote Edited: 0019619bug_revision_view_page.php?bugnote_id=19619#r11895
2018-09-22 02:55WubTheCaptainNote Edited: 0019617bug_revision_view_page.php?bugnote_id=19617#r11896
2018-09-22 03:03WubTheCaptainNote Added: 0019620
2018-10-05 08:43WubTheCaptainPrioritynormal => low
2018-10-06 17:11ZalewaNote Added: 0019955
2018-12-17 05:06WubTheCaptainNote Added: 0020264
2018-12-17 05:06WubTheCaptainAssigned To => Zalewa
2018-12-17 05:18WubTheCaptainNote Edited: 0020264bug_revision_view_page.php?bugnote_id=20264#r12316
2020-01-18 03:03WubTheCaptainNote Added: 0021088
2020-01-18 03:03WubTheCaptainNote Edited: 0021088bug_revision_view_page.php?bugnote_id=21088#r12893
2020-01-18 03:14WubTheCaptainNote Edited: 0021088bug_revision_view_page.php?bugnote_id=21088#r12896
2020-01-18 23:45ZalewaNote Added: 0021089
2020-01-18 23:45ZalewaStatusacknowledged => assigned
2020-01-19 11:35ZalewaNote Added: 0021092
2020-01-19 11:35ZalewaStatusassigned => needs testing
2020-01-19 12:56WubTheCaptainNote Added: 0021095
2020-01-19 12:56WubTheCaptainStatusneeds testing => needs review
2020-01-19 12:56WubTheCaptainNote Edited: 0021095bug_revision_view_page.php?bugnote_id=21095#r12904
2020-01-19 12:57WubTheCaptainFile Added: 2020-01-19-125651_maim.png
2020-01-19 12:57WubTheCaptainFile Added: 2020-01-19-125725_maim.png
2020-01-19 12:58WubTheCaptainNote Added: 0021096
2020-01-19 13:08WubTheCaptainNote Edited: 0021095bug_revision_view_page.php?bugnote_id=21095#r12905
2020-01-19 13:28ZalewaNote Added: 0021097
2020-01-19 13:38WubTheCaptainNote Edited: 0021095bug_revision_view_page.php?bugnote_id=21095#r12906
2020-01-19 13:38WubTheCaptainNote Edited: 0021095bug_revision_view_page.php?bugnote_id=21095#r12907
2020-01-19 13:41WubTheCaptainNote Added: 0021099
2020-01-19 13:41WubTheCaptainStatusneeds review => needs testing
2020-01-19 14:25WubTheCaptainNote Added: 0021101
2020-01-19 14:25WubTheCaptainStatusneeds testing => resolved
2020-01-19 14:25WubTheCaptainFixed in Version => 1.3.3
2020-01-19 14:25WubTheCaptainResolutionopen => fixed
2020-01-19 14:27WubTheCaptainNote Edited: 0021101bug_revision_view_page.php?bugnote_id=21101#r12911
2020-01-19 14:28WubTheCaptainNote Edited: 0021095bug_revision_view_page.php?bugnote_id=21095#r12912
2020-01-19 14:28WubTheCaptainNote Edited: 0021095bug_revision_view_page.php?bugnote_id=21095#r12913
2020-01-19 14:29WubTheCaptainNote Edited: 0021095bug_revision_view_page.php?bugnote_id=21095#r12914
2020-01-19 14:33WubTheCaptainTarget Version => 1.3.3
2020-01-19 14:36WubTheCaptainNote Edited: 0021101bug_revision_view_page.php?bugnote_id=21101#r12915
2020-01-19 14:37WubTheCaptainNote Edited: 0021101bug_revision_view_page.php?bugnote_id=21101#r12916
2020-01-19 14:39WubTheCaptainNote Edited: 0021101bug_revision_view_page.php?bugnote_id=21101#r12917
2020-01-19 14:44WubTheCaptainNote Edited: 0021101bug_revision_view_page.php?bugnote_id=21101#r12918
2020-01-19 14:44WubTheCaptainNote Edited: 0021101bug_revision_view_page.php?bugnote_id=21101#r12919
2020-01-19 14:45WubTheCaptainNote Edited: 0021101bug_revision_view_page.php?bugnote_id=21101#r12920
2020-01-19 16:22WubTheCaptainRelationship addedrelated to 0003733
2020-01-27 20:34WubTheCaptainFixed in Version1.3.3 => 1.3.1
2020-01-27 20:34WubTheCaptainTarget Version1.3.3 => 1.3.1
2020-01-30 12:58WubTheCaptainStatusresolved => closed

Notes
(0019351)
WubTheCaptain   
2018-08-20 20:43   
Reproduced this today while launching 1.1. I think I launched 1.2 with a first launch, closed it and launched 1.1 with a first launch. Not sure anymore.

Now my Doomseeker 1.1 doesn't list servers due to this fault or something else, heh. (Recreating the .doomseeker directory will probably fix this.)
(0019352)
WubTheCaptain   
2018-08-20 20:45   
Doomseeker 1.1 output from console:

$ doomseeker
[20:44:27] Starting Doomseeker. Hello World! :)
[20:44:27] Setting up data directories.
[20:44:27] Attempting to load plugins from directory: /home/wub/.doomseeker/engines
[20:44:27] Attempting to load plugins from directory: /usr/bin/engines
[20:44:27] Attempting to load plugins from directory: engines
[20:44:27] Attempting to load plugins from directory: /usr/share/doomseeker/engines
[20:44:27] Loaded plugin: "Zandronum"!
[20:44:27] Listening to Zandronum's LAN servers broadcasts on port 15101.
[20:44:27] Initializing configuration file.
[20:44:27] Setting INI file: /home/wub/.doomseeker/doomseeker.ini
[20:44:27] Loading translations definitions
[20:44:27] Loading translation "en_US".
[20:44:27] Translation 'qt_en_US' not found.
[20:44:27] Translation 'en_US' not found.
[20:44:27] Failed to load translation.
[20:44:27] Initializing IP2C database.
[20:44:27] Initializing passwords configuration file.
[20:44:27] Initializing configuration for plugins.
[20:44:27] Initializing IRC configuration file.
[20:44:27] Setting IRC INI file: /home/wub/.doomseeker/doomseeker-irc.ini
[20:44:27] Starting refreshing thread.
[20:44:27] Preparing GUI.
[20:44:27] Please wait. IP2C database is being read. This may take some time.
[20:44:27] Parsing IP2C database: :/IpToCountry.dat
[20:44:27] IP2C database read in 63 ms. Entries read: 119365
[20:44:27] Init finished.
================================
[20:44:27] IP2C parsing thread has finished.
[20:44:27] IP2C parsing finished.


Zandronum plugin is definitely loaded, reports servers on the list, but the GUI tells there are none even with cursor focus on the window.
(0019353)
WubTheCaptain   
2018-08-20 20:48   
Quote
Zandronum plugin is definitely loaded, reports servers on the list, but the GUI tells there are none even with cursor focus on the window.


Wrong paste, but definitely said to have found some 629 servers with the GUI empty.
(0019609)
WubTheCaptain   
2018-09-22 01:46   
Removed $HOME/.doomseeker/doomseeker.ini on 1.2~beta (!) built with Qt4 and crashed on OpenBSD with this:

[01:34:50] Parsing IP2C database: /home/doomseeker/.local/share/data/doomseeker/
IpToCountry.dat
Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

terminating with uncaught exception of type std::bad_alloc: std::bad_alloc
Abort trap (core dumped)


Backtracing the core dump with gdb isn't so helpful, because of abort trap.

(gdb) bt       
#0  thrkill () at -:3
#1  0x000002c607f9655e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
Die: DW_TAG_unspecified_type (abbrev = 4, offset = 251222)
        has children: FALSE
        attributes:
                DW_AT_name (DW_FORM_strp) string: "decltype(nullptr)"
Dwarf Error: Cannot find type of die [in module /usr/lib/libc++abi.so.0.1]


Something to note, $HOME/.config/doomseeker/doomseeker.ini exists. I've been switching between 1.1, 1.2, Qt4 and Qt5 versions.

Something very special to note too, just before the crash every checkbox in Doomseeker settings for this 1.2~beta-1 build (latest) was unchecked through no action of mine. (But I think it may have been like that ever since Qt5 was found to be broken; 0003494.)

Hopefully someone can reproduce soon, or at least finally find a cause.
(0019611)
WubTheCaptain   
2018-09-22 01:58   
Quote from WubTheCaptain
Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.


But it's odd, because I can't find any try{...}catch{...} in Doomseeker's source code (specifically Qt) with a grep search.
(0019612)
WubTheCaptain   
2018-09-22 02:09   
Yep, okay, Doomseeker 1.1 also crashed on OpenBSD shortly after deleting ~/.config/doomseeker/* – but there was no doomseeker.ini, only doomseeker-irc.ini and the other .ini file. Same backtrace.

But uh, 1.1 is not even supposed to use that directory. In fact, XDG basedir support is broken on OpenBSD. I wonder how sometimes my files got into $HOME/.config/doomseeker/, sometimes to legacy $HOME/.doomseeker/ path.

[02:05:13] Setting IRC INI file: /home/doomseeker/.doomseeker/doomseeker-irc.ini
[02:05:13] Starting refreshing thread.
[02:05:13] Preparing GUI.
[02:05:13] Please wait. IP2C database is being read. This may take some time.
[02:05:13] Parsing IP2C database: /home/doomseeker/.doomseeker/IpToCountry.dat
[02:05:13] Init finished.
================================
[02:05:13] Total refresh process initialized!
[02:05:14] IP2C database read in 340 ms. Entries read: 175445
[02:05:14] IP2C parsing thread has finished.
[02:05:14] IP2C parsing finished.
LookupHostConsumerThread: 0x10c6777b8c40
terminating with uncaught exception of type std::bad_alloc: std::bad_alloc
Abort trap (core dumped)
(0019613)
WubTheCaptain   
2018-09-22 02:13   
Okay, and now it's reproducible on 1.1 all the time on my machine.
(0019617)
WubTheCaptain   
2018-09-22 02:33   
(edited on: 2018-09-22 02:55)
I'd take a guess it's the IP2C autoupdater behind this.

src/core/ip2c/ip2cupdater.cpp calls lots to abort(); and there's no line for IP2C remote/local comparison. When the config directory is removed, settings get reset on the next launch of Doomseeker; That is, IP2C autoupdate gets enabled again by default.

Then, something with IP2C autoupdate fails on OpenBSD. Code calls abort, abort trap, do this few times until the settings file gets corrupt with no checkboxes enabled by default (disables IP2C updating), and the issue doesn't exist anymore.

This is very reproducible with 1.1-0 (note: didn't try 1.1-p1) built with Qt4 on OpenBSD (using QEMU KVM virtual machine).

That doesn't explain bad_alloc easily, though...
(0019618)
WubTheCaptain   
2018-09-22 02:42   
(edited on: 2018-09-22 02:43)
Quote from WubTheCaptain
Now my Doomseeker 1.1 doesn't list servers due to this fault or something else, heh. (Recreating the .doomseeker directory will probably fix this.)


Omg, it totally makes sense now. Yes!

The most likely answer in retrospect is that in this scenario too, the config checkbox for "refresh servers on startup" (Configuration → Query) got unchecked due to config file corruption (probably an abnormal quit during a critical process), so that's why I saw no servers at all! And of course, re-creating .doomseeker directory reset that setting and things worked again for a while.

This same symptom, no servers on startup, is part of what I experience on OpenBSD with reproducible results, for the same reasons.
(0019619)
WubTheCaptain   
2018-09-22 02:47   
And fyi, a likely reason this has gone unseen for so long is that I typically disable IP2C autoupdate on my machine (Debian GNU/Linux) in Doomseeker settings.
(0019620)
WubTheCaptain   
2018-09-22 03:03   
Oh, and std::bad_alloc in most cases with OpenBSD means memory exhaustion. If it was that (seems a bit unlikely), two plausible explanations:

  1. 4 GB RAM in a virtual machine is not enough to run X with fvwm and Doomseeker (untrue); or
  2. /etc/login.conf memory limits on users limit the maximum available memory to programs.


Dunno?
(0019955)
Zalewa   
2018-10-06 17:11   
The std::bad_alloc may be caused by some "size()" function returning a negative value and then this negative value being passed to malloc() without checking. As malloc() takes the size as the unsigned size_t type, the negative value is interpreted as a really huge number and thus std::bad_alloc happens.

Let's return to this when we go forth with 0003541 and see if it still happens.
(0020264)
WubTheCaptain   
2018-12-17 05:06   
(edited on: 2018-12-17 05:18)
Quote from Zalewa
Let's return to this when we go forth with 0003541 and see if it still happens.


0003541 was closed as "denied".
(0021088)
WubTheCaptain   
2020-01-18 03:03   
(edited on: 2020-01-18 03:14)
Enabling IP2C updates caused a segmentation fault (no abort trap) on my system again on Debian GNU/Linux, more details in a note at 0003728:0021087. Qt5 and Doomseeker 1.3.
(0021089)
Zalewa   
2020-01-18 23:45   
I'll fix this.
(0021092)
Zalewa   
2020-01-19 11:35   
I mitigated a potential race condition in the IP2C parser:'https://bitbucket.org/Doomseeker/doomseeker/commits/22abfcaa00800c2f90352d54434ae6a5d99f1b3e [^]'

Please see if it helped.
(0021095)
WubTheCaptain   
2020-01-19 12:56   
(edited on: 2020-01-19 14:29)
Removing *pTargetDatabase will probably remove support for reading from /usr/share/doomseeker/IpToCountry.dat. Doomseeker packages on Debian/Ubuntu GNU/Linux may be affected. This is silly, because distros now rely on the users to acquire a binary IP2C blob (via IP2C autoupdate) and can't distribute IpToCountry.dat as an useful package system-wide.

Quote from 1.3, no ~/.local/share/IpToCountry.dat
[12:41:40] Preparing GUI.
[12:41:40] Checking if IP2C database at '/usr/share/doomseeker/IpToCountry.dat' needs updating.
[12:41:40] Please wait. IP2C database is being read. This may take some time.
[12:41:40] Parsing IP2C database: /usr/share/doomseeker/IpToCountry.dat
[12:41:40] Init finished.
================================
[12:41:40] IP2C database read in 99 ms. Entries read: 196041
[12:41:40] Total refresh initialized!
[12:41:40] IP2C parsing thread has finished.
[12:41:40] IP2C parsing finished.
[12:41:41] Comparing IP2C hashes: local = aeca013c6eb838531099b9727f2187a0, remote = aeca013c6eb838531099b9727f2187a0

[12:41:41] IP2C update not needed.
[12:41:44] Finished refreshing. Servers on the list: 512 (+2 custom, +0 LAN). Players: 51.


ok

Quote from 1.3, manually updated to acquire ~/.local/share/IpToCountry.dat
[12:43:42] Preparing GUI.
[12:43:42] Checking if IP2C database at '/home/wub/.local/share/doomseeker/IpToCountry.dat' needs updating.

[12:43:42] Please wait. IP2C database is being read. This may take some time.
[12:43:42] Parsing IP2C database: /home/wub/.local/share/doomseeker/IpToCountry.dat
[12:43:42] Init finished.
================================
[12:43:42] IP2C database read in 100 ms. Entries read: 196041
[12:43:42] Total refresh initialized!
[12:43:42] IP2C parsing thread has finished.
[12:43:42] IP2C parsing finished.
[12:43:42] Comparing IP2C hashes: local = aeca013c6eb838531099b9727f2187a0, remote = aeca013c6eb838531099b9727f2187a0

[12:43:42] IP2C update not needed.
[12:43:45] Finished refreshing. Servers on the list: 513 (+2 custom, +0 LAN). Players: 53.


ok

Quote from 1.3 + patch, no ~/.local/share/IpToCountry.dat, with IP2C autoupdate
[12:44:53] Preparing GUI.
[12:44:53] Starting IP2C update.
[12:44:53] Init finished.
================================
[12:44:53] Total refresh initialized!
[12:44:55] IP2C database finished downloading.
[12:44:55] Please wait. IP2C database is being read. This may take some time.
[12:44:55] Parsing IP2C database: /home/wub/.local/share/doomseeker/IpToCountry.dat
[12:44:55] IP2C database read in 220 ms. Entries read: 196041
[12:44:55] IP2C parsing thread has finished.
[12:44:55] IP2C parsing finished.
[12:44:57] Finished refreshing. Servers on the list: 665 (+2 custom, +0 LAN). Players: 341.


Notice reading /usr/share/doomseeker/IpToCountry.dat was skipped, so IP2C autoupdate downloaded a database to /home/wub/.local/share/doomseeker/IpToCountry.dat.

Quote from 1.3 + patch, no ~/.local/share/IpToCountry.dat, IP2C autoupdate disabled
[13:34:27] Initializing IP2C database.
[13:34:27] Initializing passwords configuration file.
[13:34:27] Initializing configuration for plugins.
[13:34:27] Initializing IRC configuration file.
[13:34:27] Setting IRC INI file: /home/wub/.config/doomseeker/doomseeker-irc.ini
[13:34:27] Starting refreshing thread.
[13:34:27] Preparing GUI.
[13:34:27] Did not find any IP2C database. IP2C functionality will be disabled.
[13:34:27] You may install an IP2C database from the "File" menu.
[13:34:27] Init finished.
================================
[13:34:27] Total refresh initialized!
[13:34:31] Finished refreshing. Servers on the list: 652 (+2 custom, +0 LAN). Players: 249


Ditto, /usr/share/doomseeker/IpToCountry.dat was skipped. Server country flags won't be displayed unless the user makes a updates IP2C manually or enables IP2C autoupdates.

Quote from 1.3 + patch, ~/.local/share/IpToCountry.dat exists
[12:46:57] Preparing GUI.
[12:46:57] Checking if IP2C database at '/home/wub/.local/share/doomseeker/IpToCountry.dat' needs updating.

[12:46:57] Please wait. IP2C database is being read. This may take some time.
[12:46:57] Parsing IP2C database: /home/wub/.local/share/doomseeker/IpToCountry.dat
[12:46:57] Init finished.
================================
[12:46:57] Total refresh initialized!
[12:46:58] IP2C database read in 228 ms. Entries read: 196041
[12:46:58] IP2C parsing thread has finished.
[12:46:58] IP2C parsing finished.
[12:46:58] Comparing IP2C hashes: local = aeca013c6eb838531099b9727f2187a0, remote = aeca013c6eb838531099b9727f2187a0

[12:46:58] IP2C update not needed.
[12:47:01] Finished refreshing. Servers on the list: 666 (+2 custom, +0 LAN). Players: 339.


Works equally like 1.3.
(0021096)
WubTheCaptain   
2020-01-19 12:58   
  • 2020-01-19-125651_maim.png is from 1.3+patch
  • 2020-01-19-125725_maim.png is from 1.3
(0021097)
Zalewa   
2020-01-19 13:28   
Your observation is unrelated to the patch. In the official release "/usr" is the CMAKE_INSTALL_PREFIX path which is #defined as INSTALL_PREFIX which is prepended to "/share/doomseeker/" (in main.cpp initDataDirectories()) which is added to the paths where IpToCountry.dat is looked for (in doomseekerfilepaths.cpp ip2cDatabaseAny()). When you compile Doomseeker on your own, you probably have a different CMAKE_INSTALL_PREFIX.
(0021099)
WubTheCaptain   
2020-01-19 13:41   
I see, that makes sense Zalewa.
(0021101)
WubTheCaptain   
2020-01-19 14:25   
(edited on: 2020-01-19 14:45)
I found a (mostly reliable) way to reproduce the racing condition (as Zalewa found out) in 1.3 on my system, which often didn't trigger with the typical Doomseeker configuration I use.
  1. Have an up-to-date /usr/share/doomseeker/IpToCountry.dat (as in official release; adapt to CMAKE_INSTALL_PREFIX with source builds, which may be /usr/local/share/doomseeker/IpToCountry.dat)
  2. Install all game plugins (sudo apt install doomseeker-*)
  3. Set (or assume) IP2CAutoUpdate=0 in doomseeker.ini (~/.config/doomseeker/doomseeker.ini)
  4. Start Doomseeker.
  5. Enable querying all five servers. ("Query" top navigation menu. I used to usually query Zandronum only.)
  6. Enable IP2C auto update: Options → Configure (F5) → Auto Updates → IP2C auto update
  7. Enable refresher on startup: Options → Configure (F5) → Query → Refresh servers on startup
  8. Click "OK" to save the configuration changes.
  9. Close Doomseeker.
  10. Build an outdated IpToCountry.dat blob from source (I used 28eeb49) and copy the outdated IpToCountry.dat to local user directory (~/.local/share/doomseeker/IpToCountry.dat)
  11. Start Doomseeker and hope to crash.

As Doomseeker is started with this state (with Internet connectivity), two threads run simultaneously: IP2C thread and refresher thread. An auto update will occur: IP2C database will be overwritten while the refresher thread is still busy reading from the database (hopefully), which may result in the refresher thread reading empty or garbage data and segfaulting.
The race condition didn't trigger with my usual configuration, when I querying only Zandronum's master server: It had enough time to read the old IP2C database & refresh every server before the IP2C was updated. "Slowing down" the refresher thread by giving it more work to do triggered the race condition.
As new Doomseeker releases were shipped, the Debian packages shipped with an up-to-date /usr/share/doomseeker/IpToCountry.dat; thus, this problem would "go away" for a while unnoticed until a different remote IP2C database was made available again.
The attached patch fixes the issue indeed, I no longer crashed.