search

TASEmulators / mame-rr

MAME Rerecording is the rerecording version of MAME with many customized features designed to aid in recording movie input files. There's only a pre-alpha version at this time
http://tasvideos.org/EmulatorResources/Mamerr.html
21 stars 7 forks source link

bgaregga - crash on loading savestates while replaying/recording movie #7

Open xy2i opened 7 years ago

xy2i commented 7 years ago
  1. Open "bgaregga".
  2. Record or replay a movie file.
  3. Save a state, then wait a few frames/seconds.
  4. Load the state. Expected behavior: The state loads succesfully, and the replay/record continues. This is what happens on 0.139-rr. Actual behavior: Most of the time, mame-rr displays the "savestate loaded" message, then silently crashes after. For certain savestates (such as those in close proximity to the current frame) the savestate loads.
vadosnaprimer commented 7 years ago

Reproduced.

-----------------------------------------------------
Exception at EIP=013CDD24 (not found): ACCESS VIOLATION
While attempting to read memory at 00000D28
-----------------------------------------------------
EAX=00000D28 EBX=00321478 ECX=00321478 EDX=0810EC00
ESI=06DDE170 EDI=00000000 EBP=0022F950 ESP=0022F94C
-----------------------------------------------------
Stack crawl:
  0022F950: 013CDD24 (not found)
  0022F970: 013C6CD6 (not found)
  0022F9B0: 0130EA6A (not found)
  0022FA80: 0130F319 (not found)
  0022FAD0: 0136D285 (not found)
  0022FB60: 01369A6E (not found)
  0022FC20: 0134AAC4 (not found)
  0022FD60: 01500E3D (not found)
  0022FEF0: 00D28BB4 (not found)
  0022FF30: 01705BEE (not found)
  0022FFC0: 004013D1 (not found)
  0022FFF0: 7C817067 (RegisterWaitForInputIdle+0x0049)

And confirming it works on mz's 0.139.

xy2i commented 7 years ago

Same issue with cawing. Works fine on 0.139-rr.

-----------------------------------------------------
Exception at EIP=779643B0 (not found): ACCESS VIOLATION
While attempting to read memory at FB95FB99
-----------------------------------------------------
EAX=0BE32F58 EBX=0BE4A658 ECX=FB95FB95 EDX=FDE1FDE1
ESI=0BE32F50 EDI=05B50000 EBP=0028F8DC ESP=0028F8B4
-----------------------------------------------------
Stack crawl:
  0028F8DC: 779643B0 (RtlImageNtHeader+0x124c)
  0028F9D4: 77963587 (RtlImageNtHeader+0x0423)
  0028F9F4: 77963472 (RtlImageNtHeader+0x030e)
  0028FA08: 755C14DD (HeapFree+0x0014)
  0028FA28: 01705CF4 (not found)
  0028FA48: 01787A4F (not found)
  0028FA68: 0133BCA9 (not found)
  0028FA98: 0131B2DE (not found)
  0028FB28: 01369B05 (not found)
  0028FBE8: 0134AAC4 (not found)
  0028FD28: 01500E3D (not found)
  0028FEB8: 00D28BB4 (not found)
  0028FEF8: 01705BEE (not found)
  0028FF88: 004013D1 (not found)
  0028FF94: 755C33CA (BaseThreadInitThunk+0x0012)
  0028FFD4: 77969ED2 (RtlInitializeExceptionChain+0x0063)
  0028FFEC: 77969EA5 (RtlInitializeExceptionChain+0x0036)
vadosnaprimer commented 7 years ago

I investigated this, and now I know what the binary of 0.139 test2 was made from mame-rr revison 40, Aug 8, 2010. And the source under that same name (0.139 test2) was posted right before everything was removed, from revision 157, Nov 12, 2011. More than a year of commits! Most of them were dammit's.

The problem is, every mame-rr repo that was exported to github by various people only contains 2 commits, both are after everything about 0.139 is removed. And google.code killed all the repository histories. We can see the commit log, but not commit changes. So we well never know what commit broke garegga states.

All I can try is canceling changes of test2 source one by one compared to original mame's 0.139 and pray.

vadosnaprimer commented 7 years ago

A bit more investigation shows that it's also broken in original mame 0.139. And in rr 0.139 source. And not in rr 0.139 binary. And not in current mame. Bah.