Crash when loading Killer Instinct (Arcade)

I know it's an experimental core but the only CHD games that won't open are Killer Instincts
SF3 + Naomi, OK

5804ff0

Best regards,

[nattthebear]

What error message are you getting?

none, the emulator closes
yesterday I was doing some tests and I saw that other "Ultra/Nintendo 64" games don't open either, Cruis'n USA/World/Exotica, Off Road Challenge, but The Grid* opens.

• • https://system16.com/hardware.php?id=617

crusnusa
crusnwld
crusnexo
offroadc

[CasualPokePlayer]

Keep in mind our MAME core is Arcade only, if you shove non-Arcade crap in it it will reject it.

Considering there's some silent emulator crash I suspect it's the same issue with other games I've noted which have some crash due to some getpid() call somewhere (and that crashing since the syscall for that is unimplemented, although the places where it possibly gets used would likely just crash later on so implementing pid syscalls probably won't fix anything)

[nattthebear]

We can easily stub out syscalls like getpid to return some constant dummy value, but from what I've seen in the past it's not useful because there's nothing meaningful the guest application can do with it. Usually syscalls like that are the first step in some high level call that we can't possibly support, such as abort(). The real fix is to figure out what the guest is trying to do and fix it.

I could see improving our own abort situation here, though. When the guest crashes internally we might be able to at least recover back to the host, although that guest would be permanently spoiled. We do have recovery of this sort already when we throw inside a callback to managed that was passed to the guest.

[YoshiRulz]

Would that be useful without a multi-instance-capable host?

[nattthebear]

One goal is to simply give better error reporting and/or host error recovery. Pop a reasonable error dialog, save the movie, etc.

An unimplemented syscall in the guest in principle shouldn't cause any direct problem for Bizhawk. We can safely tear down the guest without knowing too much about its internal state.

[CasualPokePlayer]

For MAME specifically it could potentially be more tricky, as emulation runs in a separate cothread. Other libco cores could have similar complexities.

[CasualPokePlayer]

For the getpid() case here, it seems to be in some XML bullshit code, and is just used as a "random" value and works fine if you stub it to whatever value. Perhaps we could just implement it for cores which use it as a "random" value. (Can probably also just make it avoid getpid() in the first place and give it 0, but doing it in host probably helps against weird future cases).

[nattthebear]

Makes sense, I'll stub in getpid.

[CasualPokePlayer]

Should be fixed enough now.