Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Games freezes at start-up if -n command line option is used. #6619

Closed
DorpsGek opened this issue Sep 5, 2017 · 6 comments
Closed

Games freezes at start-up if -n command line option is used. #6619

DorpsGek opened this issue Sep 5, 2017 · 6 comments
Labels
bug Something isn't working flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

DorpsGek commented Sep 5, 2017

sincx opened the ticket and wrote:

Games freezes at start-up if -n command line option to connect to a specific server is used.

On 1.6.0, using the command line option "openttd -n [server ip]" works fine.
On 1.7.1 or 1.7.0, using the same command line to connect to the exact same server (after adjusting the version of the game running on the server to match) results in a freeze at the Scanning NewGRFs screen.

Reported version: 1.7.1
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/6619
@DorpsGek
Copy link
Member Author

DorpsGek commented Sep 5, 2017

james1101 wrote:

Able to reproduce on Win 7 Ultimate.
Ram: 4 GB, CPU: 2 cores, 2 GHz

Task Manager says CPU usage of client is on average, near 0.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6619#comment14759

@DorpsGek
Copy link
Member Author

gpsoft wrote:

I can also reproduce it on Windows 8.1
It seems it's a deadlock on mutexes.
1.6.1 is still fine, 1.7.0 locks up.
Will try to debug more and check where it was broken exactly.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6619#comment14810

@DorpsGek
Copy link
Member Author

gpsoft wrote:

The problem is since revision 27775 (doesn't happen in revision 27774):
introducing AcquireBlitterLock() and ReleaseBlitterLock() interface which seems it locks (enters into critical section) it with a _draw_mutex object.
In the same time PaintWindowThread is also in the _draw_mutex critical section so two threads are in dead-lock here. It is possible there is another interaction with a _modal_progress_paint_mutex and _modal_progress_work_mutex but I am not sure about it, possibly just a _draw_mutex is dead-locked.
I included the stack trace in a deadlocked state. It is running with a source code of version 1.7.0 (revision 27840).
Author of the modification was frosch, the message on revision 27775 is:
-Fix [#6510]: Insufficient thread synchronisation when switching blitters. (JGR)

Attachments

This comment was imported from FlySpray: https://bugs.openttd.org/task/6619#comment14811

@DorpsGek
Copy link
Member Author

gpsoft wrote:

It seems the difference in other cases is the AcquireBlitterLock() is called from the main thread.
The patch seems to fix this problem (although there might be another reason to run that particular code from new thread named "ottd:newgrf-scan"). In this patch I am running it from main thread and it doesn't get locked up.

Attachments

This comment was imported from FlySpray: https://bugs.openttd.org/task/6619#comment14812

@DorpsGek
Copy link
Member Author

frosch wrote:

This disables the 'Cancel scanning' button, doesn't it?

This comment was imported from FlySpray: https://bugs.openttd.org/task/6619#comment14868

@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) labels Apr 7, 2018
@frosch123 frosch123 removed the Core label Apr 14, 2018
@andythenorth andythenorth added the stale Stale issues label Jan 5, 2019
@andythenorth andythenorth removed the stale Stale issues label Jan 24, 2019
@nielsmh nielsmh mentioned this issue Feb 11, 2019
Closed
@glx22 glx22 closed this as completed Feb 11, 2019
@glx22
Copy link
Contributor

glx22 commented Feb 11, 2019

Fixed with e76fd99

Sorry, something went wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@TrueBrain @andythenorth @glx22 @DorpsGek @frosch123