EVALEXCEPTION c0000005!

[deimos]

I'm getting this semi-randomly, but frequently, when I'm calling the motorola ffp library fpa code.

I don't know what to do apart from uploading the dmp and log files here.

I don't know how to debug code that causes the emulator to crash.

[paraj]

Try without JIT and/or try the 32-bit version of WinUAE. Code that crashes the Amiga can crash WinUAE as well in JIT mode in pathological cases (e.g. when it happens in supervisor mode). 32-bit versions seems to at least in some cases handle it better. Without JIT it shouldn't crash and you'll probably see it in some kind of HALT state.

[Toni Wilen]

Exe is not official winuae.exe which makes dump file useless.
Does it happen without JIT?

[Thomas Richter]

This is a division by zero exception, which happens if you, err, divide by zero. The later versions of mathffp does not create this exception anymore, but return the largest possible value. Note that IEEE math never returns exceptions, it just returns INF in this case. Unfortunately, the mathFFP model does not define INFs.

FFP should really not be used anymore. It is, as far as numerics are concerned, a pretty bad format and not very robust.

[Toni Wilen]

No, lets not confuse PC and Amiga exceptions.

Cause is read from 0xFFFFFFFFFFFFFFFF, seems to be caused by CPU jumping to that address. Which usually means JIT is getting confused, possibly caused by stack overrun.

[deimos]

Originally Posted by Toni Wilen

No, lets not confuse PC and Amiga exceptions.

Cause is read from 0xFFFFFFFFFFFFFFFF, seems to be caused by CPU jumping to that address. Which usually means JIT is getting confused, possibly caused by stack overrun.

I am using the Bartman VS Code extension, so it is a non-official binary, but it has to be that way.

I will try and get my code out to run it in a more approved environment, and following the advice from paraj above, but as the code that seems to be triggering the problem is part of my logging/debugging to the VS Code integration I don't know whether the bug will be reproducible, as it's semi-random as it is.

[deimos]

I now have a clean install of WinUAE 4.9.1 and have created an A500 configuration, adding a directory backed hard drive (so I can copy my executable over) and enabling the log file. And I can see my logging appearing in the log file too, which is nice.

But I don't understand how to disable the JIT. All those options under CPU are greyed out for me.

[paraj]

Originally Posted by deimos

I now have a clean install of WinUAE 4.9.1 and have created an A500 configuration, adding a directory backed hard drive (so I can copy my executable over) and enabling the log file. And I can see my logging appearing in the log file too, which is nice.

But I don't understand how to disable the JIT. All those options under CPU are greyed out for me.

Sorry misread the logs, I now noticed that JIT wasn't enabled. Anyway, run your code in normal WinUAE (with the same configuration) and see if you can reproduce the crash. If you can't it's an issue with the modified build and you can report it to the VS code people.

I don't know how you output the debug information, but if it isn't compatible you probably want to NOP out the fewest possible instructions (i.e. if it involves some detection code, skip that and just don't do the final "debug output" call).

[deimos]

Originally Posted by paraj

Sorry misread the logs, I now noticed that JIT wasn't enabled. Anyway, run your code in normal WinUAE (with the same configuration) and see if you can reproduce the crash. If you can't it's an issue with the modified build and you can report it to the VS code people.

I don't know how you output the debug information, but if it isn't compatible you probably want to NOP out the fewest possible instructions (i.e. if it involves some detection code, skip that and just don't do the final "debug output" call).

Working on it...

I can reproduce the crash, but its frequency seems to depend on things outside of my view, even back in the environment where it was crashing often. This morning it was crashing within seconds, after leaving the house for a couple of hours the code suddenly became almost stable. All with no code changes.

I do have one very questionable bit of code that I'm looking into rewriting (pushing my assembly skills though), to do with copying the results that the fpa function returns on the stack into a permanent location. I think (know, or suspect, depending on my frame of mind) that this whole returning things on the stack just won't work in supervisor mode, which my code is running in, for better or worse, or if I use this function from within an interrupt, is the same, same thing.

But, if I'm not using an experimental JIT mode, and I can write code that crashes the emulator, then I'd love to help find the information needed to fix it. Or, conversely, I'd love to find a way to make code running on my real Amigas exit to a fill Windows 10 desktop.

[Toni Wilen]

Do you mean your config is plain 68000?

Then make sure "more compatible" is ticked because otherwise memory accesses are "more direct" and bad accesses are not always detected (prefers speed than accuracy)

Does this "fix" the crash? (and now emulated Amiga most likely crashes)

Do you see "program did something stupid" or other log messages before the crash? (keep log window open by running winuae with -log command line parameter)

[deimos]

Originally Posted by Toni Wilen

Do you mean your config is plain 68000?

I've tried not to fiddle.

Originally Posted by Toni Wilen

Then make sure "more compatible" is ticked because otherwise memory accesses are "more direct" and bad accesses are not always detected (prefers speed than accuracy)

It's ticked, see attached for all the ticks. I'm struggling to understand the JIT enabling, I don't seem to be able to be able to enable it even if you asked me to.

Originally Posted by Toni Wilen

Does this "fix" the crash? (and now emulated Amiga most likely crashes)

The crash is so inconsistent (at the moment) that I can't give a good answer to that.

Originally Posted by Toni Wilen

Do you see "program did something stupid" or other log messages before the crash? (keep log window open by running winuae with -log command line parameter)

I will look into running winuae like that, at the moment I'm looking at the log after the fact. But no, I don't see anything that looks like useful information in the logs.

Are programs not allowed to do stupid things?

[aros-sg]

Originally Posted by deimos

this whole returning things on the stack

Don't store stuff at negative offset from stackpointer. Otherwise for example preemptive task switches bite you.

[meynaf]

Originally Posted by deimos

I'm struggling to understand the JIT enabling, I don't seem to be able to be able to enable it even if you asked me to.

JIT does not work with 68000. To activate it you need at least 68020.

[deimos]

Originally Posted by meynaf

JIT does not work with 68000. To activate it you need at least 68020.

Thank you.

[deimos]

Originally Posted by aros-sg

Don't store stuff at negative offset from stackpointer. Otherwise for example preemptive task switches bite you.

It's more subtle than that. The code returns stuff on the stack correctly, leaving you to fix the stack pointer to remove it. However, the compiled C code that calls it has its destination variables also on the stack, so the SP is wrong to refer to them. Making the SP correct for them leaves the return value on the wrong side of the SP, which I believe is at least one of my problems.

I have multiple options to fix this. Yesterday I tried to go all in and fix the assembly code to write the return value into a buffer pointed to by A0 rather than on the stack, which would be the nicest solution. That code currently doesn't work, but I will try again before giving up and going for one of my other options.