GetLastError() (with and without debugger)

[Thomas Stüfe]

On Fri, Aug 12, 2022 at 5:02 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> On 12/08/2022 15:55, Pedro Lamarão wrote:
>
> Em sex., 12 de ago. de 2022 às 11:50, Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> escreveu:
>
>>
>> On 12/08/2022 15:43, Pedro Lamarão wrote:
>>
>>
>> This is incorrect. WriteFile() indicates an error, but GetLastError()
>>> returns 0 (= NO_ERROR). Could it be that the debugger calls another Windows
>>> API function between those two functions, resetting the last error?
>>>
>>> In my project that's a major issue. Since the software behaves
>>> incorrectly with the debugger, the software can no longer be debugged. This
>>> doesn't just affect it when debugging this particular piece of code but
>>> anytime this code is run in a debugging session.
>>>
>>
>>
>> This would be a blocker for all applications of Windows API functions via
>> panama.
>> Windows Sockets has a similar mechanism called WSAGetLastError.
>>
>> And JNI - I doubt there's anything Panama specific here (unless proven
>> otherwise).
>>
>
> Of course, this would disturb any interaction with Windows API, however it
> was activated.
> For some reason, such a debugger has been working with software for some
> time, and I presume it works with software that calls the system via JNI.
> Is there perhaps some kind of special "locking" when calling into JNI
> which the debugger might have learned to respect?
>
> I think what we need at this point is some more testing.
>
> E.g. can we reproduce the same issue with JNI? E.g. assume we have a JNI
> binding for Windows API we want to call and a _different_ JNI binding for
> checking LastError. Does that show the same problem?
>
Stupid question, since those calls are embedded into java code, can this
really be prevented? E.g. thread allocates object -> causes heap to expand
-> needs commit -> calls VirtualAlloc?

I would have thought that you need to treat GetLastError special. JNA seems
to do this:
https://github.com/java-native-access/jna/blob/999c60a1fa0ab1154b07edffa3748ce46d8d3b89/src/com/sun/jna/NativeLibrary.java#L130

Cheers, Thomas

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220812/b142b85b/attachment.htm>