03849: MAME hangs after the register dump with GCC compile in case of an exception

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
03849	Crash/Freeze	Major	Always	May 11, 2010, 22:13	Sep 1, 2010, 23:01

Tester	Firewave	View Status	Public	Platform	MAME (Self-compiled)
Assigned To		Resolution	Fixed	OS
Status [?]	Resolved			Driver
Version	0.137u4	Fixed in Version		Build	Debug
		Fixed in Git Commit		Github Pull Request #

Summary	03849: MAME hangs after the register dump with GCC compile in case of an exception
Description	Robbbert complained about it in the past and now I also experienced the freeze when MAME encounters an exception. With the tomcat set MAME hangs after dumping the registers. The first assumption was an incompatible version of dbghelp.dll, but since MAME is looking for the function SymInitializeW in dbghelp.dll, which doesn't exist, the stack walk code is never executed. So neither the stack walk or the DLL is at fault. My new assumption is now, that it's a bug in the mingw64 (or maybe MinGW itself) build with the unhandled exception filter MAME is setting since it is working fine with a Visual Studio 2010 compile. I know there were issues with exceptions in earlier versions MinGW.
Steps To Reproduce
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems

Attached Files

No.06089 Firewave Senior Tester May 11, 2010, 22:34	There appears to be a similar issue, that happened in the past with GCC: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9539 I tried running the sample, but it doesn't hang anymore, but sounds similar to our case. I created a sample with the MAME exception filter, but it doesn't hang either. I had to disable some parts of it though. I will investigate further.
No.06100 Firewave Senior Tester May 12, 2010, 14:29	Here's the traces of threads in a hanging instance: (gdb) info threads * 2 Thread 3056.0x1c0 0x7d61002e in strchr () from C:\WINDOWS\system32\ntdll.dll 1 Thread 3056.0x17c 0x7d61f1a9 in ntdll!RtlAppendPathElement () from C:\WINDOWS\system32\ntdll.dll (gdb) thread 1 [Switching to thread 1 (Thread 3056.0x17c)]#0 0x7d61f1a9 in ntdll!RtlAppendPathElement () from C:\WINDOWS\system32\ntdll.dll (gdb) bt #0 0x7d61f1a9 in ntdll!RtlAppendPathElement () from C:\WINDOWS\system32\ntdll.dll #1 0x00000000 in ?? () (gdb) thread 2 [Switching to thread 2 (Thread 3056.0x1c0)]#0 0x7d61002e in strchr () from C:\WINDOWS\system32\ntdll.dll (gdb) bt #0 0x7d61002e in strchr () from C:\WINDOWS\system32\ntdll.dll #1 0x7d666ea1 in ntdll!RtlCopyUnicodeString () from C:\WINDOWS\system32\ntdll.dll #2 0x00000000 in ?? ()
No.06101 Firewave Senior Tester May 12, 2010, 16:08	Updating mingw64 to "gcc version 4.4.4 20100421 (prerelease) [svn/rev.158621 - mingw-w64/oz] (GCC)" (mingw64 mingw-w32-bin_i686-mingw_20100428_sezero.zip) didn't help. Robbbert found some incorrect function declarations, but fixing those didn't helped as well.