GetLastError() (with and without debugger)

[Pedro Lamarão]

Em seg., 15 de ago. de 2022 às 05:05, David Holmes <david.holmes at oracle.com>
escreveu:


> 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.
>

I think this is the correct general solution.


> 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 this code:

write(...)
call-into-some-library-function(...)
log(last-error())

This is not the generally correct way to observe the status of write.
It is not, generally, a library's responsibility to preserve last-error.

The generally correct way is to observe the last-error immediately.
What matters is that the code below observes the status of write.

write(...)
log(last-error())

If there is some code running somewhere with the power of affecting
last-error on this thread, that code must be very careful to preserve it.
It has been supposed that the OP's debugger is doing I/O from inside the
application's thread;
if that is the case, then this debugger must do something like
PreserveLastError.

--
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220815/b1ac5ddc/attachment.htm>