[Rpcemu] Crash

Peter Howkins rpcemu.howkins at marutan.net
Tue Jan 28 08:33:08 PST 2014


On Mon, Jan 27, 2014 at 10:57:01PM +0100, David Feugey wrote:
>    2014-01-27 Peter Howkins <[1]rpcemu.howkins at marutan.net>
> 
>      My recomendation is to update your graphics drivers, and to check your
>      windows event logs for clues. This seems like a host machine
>      hardware/driver issue.
> 
>    Graphic drivers: I have the latest one (old too). No issue with other
>    software.
>    Event log: nothing. Crash is to sudden.
>    Anyway, graphic problems can't explain slow performance in recompiler
>    mode.
>    Note that there is no crash in interpreter mode.
>    Recompiler works at 30 MIPS and more just a few seconds, then slow down to
>    2-3 MIPS, and a few seconds or minutes later, everything crash... even if
>    I leave the application before problems.

I can think of no issue that could cause a crash in this manner other than 
a hardware fault or faulty hardware driver *particulaly* if RPCEmu is not
even running at the time of the crash.

There are timing issues between recompiler and interpretter that I've seen 
affect display code, in particualar entering full-screen mode crashes 
RPCEmu (not the host system) in recompiler mode on accasion, for a reason 
not yet tracked down (running with gdb alters the timing enough that it's 
not shown).

RPCEmu, and the Allegro game library, call legitimate win32 public API in 
non-priviledged modes. Taking out the kernel to the point of not even 
getting a blue-screen is probably not possible without the assistance of 
buggy kernel mode (driver) level stuff.

>    As if the processor didn't manage to execute the generated instructions,
>    and just finished to stop after too many errors. Under VPC7, the problem
>    was the same, with an illegal instruction error (sometimes) and some
>    massive slow down (everytime).

The reason I've been ignoring this one is that it's not the issue here.

1) Windows programs executing unknown instructions fail in a different 
   manner, the issue would caught by the kernel and the individiual 
   program stopped with windows error box.
2) There is no x86 instruction in the code that would cause an issue, I 
   think we're using nothing more complex than 386 level of instructions.
3) I've used an Atom machine as a dev system for years and never 
   encountered this issue.
4) Other users have reported success with Atom systems too.

Peter

-- 
Peter Howkins
peter.howkins at marutan.net



More information about the Rpcemu mailing list