GetLastError() (with and without debugger)

[Manuel Bleichenbacher]

If it needs to be specified with command line arguments or similar, that's
perfectly ok.

While many Windows SDK functions have annotations, in particular on the
function parameters, it is not annotated if a function uses GetLastError().
So it would be almost impossible to make it fully automatic.


On Mon, Sep 12, 2022 at 2:57 PM Jorn Vernee <jorn.vernee at oracle.com> wrote:

> I don't think it's possible to do that automatically, since jextract can
> not detect whether a function sets the last error from the header file (as
> far as I know that fact is only documented).
>
> Though, I think we could add a new command line flag to list the functions
> that need the last error saved. Maybe the syntax of --include-function
> could be extended for that.
>
> Jorn
> On 10/09/2022 09:09, Manuel Bleichenbacher wrote:
>
> I'm happy to see that discussion about this issue continues. It's the only
> issue in project Panama that's really holding my work (
> https://github.com/manuelbl/JavaDoesUSB) back. For all other issues,
> there's a workaround.
>
> You are probably far more familiar with the internals of the Java VM than
> I am. But I can confirm that it's not a debugger only issue. The last error
> is overwritten more frequently while debugging, but it occurs without the
> debugger as well.
>
> I don't share the fear that more errno-like things will come along. The
> problem can only occur for errno-like things that are used by both the Java
> VM and by third-party software. It cannot occur for some random third-party
> library. So unless the Java VM starts using a new library with this ancient
> pattern, it's a non-issue.
>
> The proposed design looks good to me and aligned with the design
> principles I've seen so far. It would certainly work my USB library.
>
> The only open issue I see is with jextract. Would it be possible to
> instruct jextract to generate code this extra action, or would this only
> work with manually written binding code?
>
> On Sat, Sep 10, 2022 at 1:50 AM John Rose <john.r.rose at oracle.com> wrote:
>
>> On 12 Aug 2022, at 7:50, Maurizio Cimadamore wrote:
>>
>> On 12/08/2022 15:43, Pedro Lamarão wrote:
>>
>> … 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).
>>
>> So that it's clear - it's not that GetLastError fails in general. It
>> fails when a debugger is attached. As I explained, this could be due to
>> _which_ debugger is attached, or some existing issue (predating Panama) in
>> the way jdb/JPDA deal with some Windows system calls.
>>
>> Maurizio
>>
>> Besides debugger interactions, I would worry about the VM itself doing
>> some housekeeping functions between the two Panama calls. For example, if
>> the first call ends at a safepoint request, the thread can go into
>> safepoint-mode, and that is rather open-ended in its effects. If those
>> effect include something as simple as a storage allocation (malloc) then
>> the last-error in that thread might be reset. It’s hard to exclude such
>> things unless we design in a real transaction of some sort which excludes
>> all artifacts like safepoints or debugger operations.
>>
>> That’s why I nodded along when you, Maurizio, suggested a combinator for
>> bundling together two downcalls into a single region. I see Jorn’s
>> objection; it is in some sense a good design but it is very expensive to
>> maintain, as a general-purpose facility. Imagine writing the regression
>> tests…
>>
>> But, something like that transaction is clearly needed, though, for the
>> specific operation of getting the last error. (Somebody is eventually going
>> to come along with a second errno-like thing as well, which is a scary
>> thought…) So we need, at least, a bespoke transactional feature for
>> downcalls that saves the errno somewhere, no matter what. I like Vladimir’s
>> suggestion for poking it down an extra argument.
>>
>> Here’s a slightly-general design for such a thing that is slightly
>> future-proof, for the sake of brainstorming:
>>
>>    - Panama supplies a limited number of “extra actions” that can be
>>    attached to any downcall.
>>    - The only action defined initially gets a machine word which encodes
>>    some sort of error state visible after a downcall.
>>    - Adding more actions, and user control over them, is left for the
>>    future.
>>    - An extra action can have a return value. If you attach it to a
>>    downcall, you can capture that return value by adding a trailing (appendix)
>>    parameter, for a copy-out. Or, perhaps, you can route it directly,
>>    replacing the main return value of the downcall.
>>
>> This picks up on the suggestion that downcalls can be configured to
>> capture this extra information. And it generalizes the “save-error” feature.
>>
>> Finally, it makes the “ignore-error” feature unnecessary; that is a good
>> thing, since if you have to opt into ignoring errors, it means that
>> somebody is by default saving them for you. That is likely to turn into an
>> overhead on every call, regardless of whether the saved data is useful or
>> not.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220912/f1e0188b/attachment-0001.htm>