Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|03374||DIP/Input||Minor||Always||Aug 4, 2009, 09:35||Oct 4, 2009, 14:03|
|Tester||Haze||View Status||Public||Platform||MAME (Self-compiled)|
|Version||0.133u1||Fixed in Version||0.134u2||Build||Normal|
|Fixed in Git Commit||Github Pull Request #|
|Summary||03374: Crash with Xbox 360 Wireless Controller for Windows resulting in corrupted cfg files|
This bug only occurs the first time the machine / MAME are booted. Subsequent times it doesn't happen.
I'm using the latest official drivers etc. on a fully up to date machine.
Basically I have my controller setup, and custom pad inputs in default.cfg, however, if after booting the machine the following procedure is followed those config files will be wiped / corrupted.
1) Boot Machine
2) Load up MAME (puzzle bobble was my test case)
3) Turn on the PAD (press a few buttons to observe that it doesn't work because it wasn't on when MAME was loaded, as expected)
4) Exit MAME (notice, exit isn't clean, there is a crash message)
5) Look at invalid (0 size) cfg files.
6) Reload MAME, note custom mappings have been lost.
If I subsequently take out the battery and attempt to reproduce a 2nd time it doesn't happen, only the first time after booting the machine.
I'm guessing MAME had some kind of issue with new controllers / devices changing at runtime, which only occurs the first time you turn on the pad, and it initializes the wireless receiver?
If I can get any kind of backtrace I'll post it.
|Steps To Reproduce|
|Affected Sets / Systems|
|There are no relationship linked to this issue.|
Sep 4, 2009, 12:04
Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c90120f in ntdll!DbgUiConnectToDbg () from D:\WINDOWS\system32\ntdll.dll
#0 0x7c90120f in ntdll!DbgUiConnectToDbg ()
#1 0x014bca53 in osd_break_into_debugger (
message=0x47d8350 "assert: src/emu/input.c:1326: devcode != NULL")
Backtrace stopped: frame did not save the PC
is what I get when exiting under GDB in this case.
Sep 4, 2009, 12:48
|(which makes sense, because a debug build does give that assert)|
Oct 4, 2009, 11:52
|should be fixed in 134u2|