GetLastError() (with and without debugger)

[David Holmes]

Hi Maurizio,

On 13/08/2022 2:05 am, Maurizio Cimadamore wrote:
> If this is a problem with the debugger accidentally overwriting 
> LastError on some platforms, I think it would be perhaps better to fix 
> it at that level (given that our JVM has some code to defend against 
> similar accidental overwrites, I'm assuming that it is possible for the 
> JVM code/debugger code to act in a "transparent" fashion).

PreserveLastError is just a helper for logging, so that the I/O from the 
logging doesn't overwrite any error from the real native operation.

Fixing this in general would require that we define the required 
thread-local state to be preserved, and then save that after each native 
method invocation and restore it before the next. But that in itself 
would limit the effectiveness as it can't distinguish between 
application level native methods and library level (including things 
triggered from the VM). Consider the JNI case. The scenario is we have 
two JNI methods:

doSomeNativeAPIStuff();
// <what can go here?>
getLastErrorFromDoSomeNativeAPIStuff();

and we expect the VM to preserve the error state from the first call, 
and then make it available again to the second call, regardless of what 
is in between? I can imagine some kind of source/bytecode transformation 
so that we effectively get:

doSomeNativeAPIStuff();
saveState();
// <what can go here?>
restoreState()
getLastErrorFromDoSomeNativeAPIStuff();

but I don't see how the VM can do it when hitting an invokestatic, for 
example, that happens to bind to a native method. And I imagine Panama's 
call mechanism would make it even harder to manage.

The JNI scenario above is just not realistic (as you alluded). We only 
have things like GetlastError and errno because system API's are not 
well designed when it comes to error reporting, but you have to use them 
immediately after the API call of interest for them to work as intended. 
If the programmer, or panama, is going to break them up by reifying them 
as different Java methods, then that is not going to work. The API call 
and its error handling has to be handled "atomically" somehow.

Cheers,
David

> Maurizio
> 
> 
>>
>> -- 
>> Pedro Lamarão