GetLastError() (with and without debugger)

[Jorn Vernee]

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/610ad902/attachment-0001.htm>