GetLastError() (with and without debugger)

[Pedro Lamarão]

Em sex., 12 de ago. de 2022 às 12:13, Thomas Stüfe <thomas.stuefe at gmail.com>
escreveu:

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

JNR seems to have special support here:
https://github.com/jnr/jnr-ffi/blob/master/src/main/java/jnr/ffi/LastError.java



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