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.

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

fix shutdown crash on Windows #19410

Merged
merged 1 commit into from
Aug 24, 2024
Merged

fix shutdown crash on Windows #19410

merged 1 commit into from
Aug 24, 2024

Conversation

oltolm
Copy link
Contributor

@oltolm oltolm commented Aug 23, 2024

When I shutdown ppsspp I get a crash:

Exception 0xc0000005 encountered at address 0x7ff8f7eb49f6: Access violation writing location 0x00000024

RtlWaitOnAddress (Unknown Source:0)
RtlEnterCriticalSection (Unknown Source:0)
RtlEnterCriticalSection (Unknown Source:0)
std::__1::__libcpp_recursive_mutex_lock(void* (*) [5]) (Unknown Source:0)
std::__1::recursive_mutex::lock() (Unknown Source:0)
std::__1::lock_guard<std::__1::recursive_mutex>::lock_guard[abi:se180100](std::__1::recursive_mutex&) (c:\msys64\clang64\include\c++\v1\__mutex\lock_guard.h:35)
MIPSState::Shutdown() (c:\src\ppsspp\Core\MIPS\MIPS.cpp:165)
MIPSState::~MIPSState() (c:\src\ppsspp\Core\MIPS\MIPS.cpp:161)
::__dtor_mipsr4k() (Unknown Source:0)
_execute_onexit_table (Unknown Source:0)
_execute_onexit_table (Unknown Source:0)
_execute_onexit_table (Unknown Source:0)
exit (Unknown Source:0)
exit (Unknown Source:0)
exit (Unknown Source:0)
__tmainCRTStartup (c:\M\B\src\mingw-w64\mingw-w64-crt\crt\crtexe.c:260)
WinMainCRTStartup (c:\M\B\src\mingw-w64\mingw-w64-crt\crt\crtexe.c:148)
BaseThreadInitThunk (Unknown Source:0)
RtlUserThreadStart (Unknown Source:0)

I fixed it. Not sure if it is correct, but it works.

@anr2me
Copy link
Collaborator

anr2me commented Aug 24, 2024

May be try to use debug build and see which thread hold the lock, or may be the thread that hold the lock already exited?
Oops sorry, since it's a crash while trying to lock, may be the lock (MIPSComp::jitLock) was already destroyed? may be checked whether MIPSComp is null or not? (i kinda forgot whether a destroyed object will become null or not tho)

@oltolm
Copy link
Contributor Author

oltolm commented Aug 24, 2024

It's not possible to check if the lock was destroyed, but I noticed that my fix can be simplified. I skipped the call to Shutdown from the destructor, but it is simpler to just remove the call.

@hrydgard
Copy link
Owner

I guess this is alright.

I want to someday get around to redesigning the whole startup / shutdown process, it's kind of grown into a multiplatform mess...

@hrydgard hrydgard merged commit 6f5374b into hrydgard:master Aug 24, 2024
18 checks passed
@oltolm oltolm deleted the shutdown_fix branch August 24, 2024 23:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants