Anonymous | Login | Signup for a new account | 2025-06-14 14:59 UTC | ![]() |
My View | View Issues | Change Log | Roadmap | Doomseeker Issue Support Ranking | Rules | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0004431 | Doomseeker | [All Projects] Bug | public | 2024-10-22 18:27 | 2024-10-23 15:38 | ||||
Reporter | Blzut3 | ||||||||
Assigned To | Zalewa | ||||||||
Priority | normal | Severity | minor | Reproducibility | sometimes | ||||
Status | resolved | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 1.4.1 | ||||||||
Target Version | 1.5.0 | Fixed in Version | 1.5.0 | ||||||
Summary | 0004431: IP2C occasionally fails country lookup on startup | ||||||||
Description | Quoting the contents of relevant Blzut3 comments for 0004421: > Am I crazy or are there regressions with the IP2C handling? On 1.4.1 most servers are identified and Doomseeker starts querying instantly. With the latest git Doomseeker hangs completely unresponsive for several seconds at start up and then most servers appear to fail country lookup? > It does appear the IP2C issue is timing related. Making sure the IP2C parsing doesn't finish until after the query on startup is finished seems to make everything resolve correctly. Presumably something is going wrong if the IP2C parsing finishes mid refresh. > My working theory right now is that the sequence of events looks something like this: * Startup refresh triggers. * Master server responds, server queries begin. * IP2C finishes parsing. * Something in main thread happens here that causes the event queue to be flushed > The root cause of the IP2C issue. (Note line numbers in stack trace are probably nonsense given all the measurement code I added to trace this down in the first place.)
> The IP2CLoader::finished signal is emitted in multiple places, which connects to MainWindow::ip2cJobsFinished. Depending on the specific timing of queued slot execution, this can delete the IP2CLoader mid load and that causes the thread's signals to be disconnected. | ||||||||
Additional Information | Reported originally in comment 0004421:0024060 for 0004421 | ||||||||
Attached Files | |||||||||
![]() |
|
Zalewa (developer) 2024-10-22 19:11 |
Everytime I write multithreaded code it has to come up riddled with race conditions :( I identified one in how the "are we done" condition was checked: 'https://bitbucket.org/Doomseeker/doomseeker/commits/dbc82fb498450aaab1ccfde1cc42be2d47ddc285 [^]' Blzut, could you apply this and check if the '?' flag problem persists? |
Blzut3 (administrator) 2024-10-23 00:21 |
Seems to, and I think that logic change sounds right. I'm fairly sure you could also have just removed the isRunning check and used the parserThread pointer alone (you ultimately set the new flag to false in the same places you set parserThread to nullptr). So the effective change is you're waiting for the main event loop to acknowledge that the thread completed rather than checking the thread's status directly. On that note if it makes you feel better, the problem was less your multithreaded code had a data race, but rather just being async is enough in this case. (Which is to say the important part is that removing the parsingInProgress/isParsing() flag needs to occur atomically with handling the parsing results with how things are written currently. If other queued calls could happen in between you could have the same problem single threaded.) |
Zalewa (developer) 2024-10-23 15:38 |
Quote from Blzut3 Yeah, that's true. Anyway, I'm glad it was possible to fix this with a simple change. |
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. |
![]() |
|||
Date Modified | Username | Field | Change |
2024-10-22 18:27 | Zalewa | New Issue | |
2024-10-22 18:27 | Zalewa | Status | new => assigned |
2024-10-22 18:27 | Zalewa | Assigned To | => Zalewa |
2024-10-22 18:27 | Zalewa | Reporter | Zalewa => Blzut3 |
2024-10-22 19:11 | Zalewa | Note Added: 0024080 | |
2024-10-22 19:11 | Zalewa | Status | assigned => needs testing |
2024-10-23 00:21 | Blzut3 | Note Added: 0024081 | |
2024-10-23 15:38 | Zalewa | Note Added: 0024082 | |
2024-10-23 15:38 | Zalewa | Status | needs testing => resolved |
2024-10-23 15:38 | Zalewa | Fixed in Version | => 1.5.0 |
2024-10-23 15:38 | Zalewa | Resolution | open => fixed |
Copyright © 2000 - 2025 MantisBT Team |