Re: JNI calls from inside UNIX signal handler

Discussion in 'Java' started by Joseph Millar, Jul 9, 2003.

  1. On Tue, 08 Jul 2003 15:48:53 -0600, Marc Rochkind <> wrote:
    [snip!]
    > Has anyone had success with this particular use of JNI? I'm especially
    > looking for first hand experience with this. The conventional opinion would
    > be, of course, "No way!!!!"
    >
    > (It's on an Intel Solaris box running Java 1.3.)

    [snip!]

    In general, I have to agree, it's not such a good idea, for several
    reasons. First and foremost, if your native code is setting signal
    handlers, it's likely overwriting the signal handers that the JVM
    has installed and which it needs in order to behave properly.
    Secondly, your signal handling code is calling JNI routines which may
    themselves generate signals, thus resulting in a recursion loop or
    confusion at best. If you ask me, you're asking for big trouble.
    But if you're careful and keep what you need to do at a minimum it
    should work, but you will need libjsig.so to make it work properly
    in all cases.

    Prior to 1.4, libjsig.so was only available at special request from
    Sun. Starting in 1.4, it's part of the core. What it does is basically
    front end the sigaction() and like api's and protects and chains the
    JVM's signal handers from overwriting. What you do is link your native
    code with libjsig (or LD_PRELOAD it), and whenever you call sigaction
    or one of it's cousins, libjsig will act as traffic cop and allow
    your handlers to coexist with the JVM's. It's not a perfect solution,
    but then signal handlers aren't either. I would recommend going to
    to JDK 1.4.2 on Solaris if you can. If you have to stay on 1.3.1,
    my understanding is the libjsig in 1.4 will still work, but I have
    never verified that. See the libjsig documentation in the JDK docs
    for more info.

    Good luck.

    --Joe
    Joseph Millar, Jul 9, 2003
    #1
    1. Advertising

  2. On Wed, 09 Jul 2003 00:10:23 GMT, Joseph Millar
    <> wrote:

    > On Tue, 08 Jul 2003 15:48:53 -0600, Marc Rochkind <>
    > wrote:
    > [snip!]
    >> Has anyone had success with this particular use of JNI? I'm especially
    >> looking for first hand experience with this. The conventional opinion
    >> would be, of course, "No way!!!!"
    >>
    >> (It's on an Intel Solaris box running Java 1.3.)

    > [snip!]
    >
    > In general, I have to agree, it's not such a good idea, for several
    > reasons. First and foremost, if your native code is setting signal
    > handlers, it's likely overwriting the signal handers that the JVM
    > has installed and which it needs in order to behave properly.


    It's easy to generate a list (from JNI code) of signals that the JVM has
    neither arranged to catch or ignore. I'm sticking with those for my tests.
    (Like, say, SIGRTMIN.)

    > Secondly, your signal handling code is calling JNI routines which may
    > themselves generate signals, thus resulting in a recursion loop or
    > confusion at best. If you ask me, you're asking for big trouble.


    Must be... or else I have received it wihtout asking! ;-) But, seriously,
    trouble is what I want. I'm exploring the JNI environment.

    > But if you're careful and keep what you need to do at a minimum it
    > should work, but you will need libjsig.so to make it work properly
    > in all cases.


    Thanks a million for this! I never would have otherwise come across it.
    Nothing you've said implies that this library helps me with my lost-class
    problem, but we shall see... I'm hopeful!

    [snip]

    --Marc
    Marc Rochkind, Jul 9, 2003
    #2
    1. Advertising

  3. On Tue, 08 Jul 2003 18:35:33 -0600, Marc Rochkind <> wrote:
    > Must be... or else I have received it wihtout asking! ;-) But, seriously,
    > trouble is what I want. I'm exploring the JNI environment.


    You want trouble? Steal SIGSEGV and try anything in that
    would normally generate a NullPointerException.


    > Thanks a million for this! I never would have otherwise come across it.
    > Nothing you've said implies that this library helps me with my lost-class
    > problem, but we shall see... I'm hopeful!


    Not sure what the issue is there, but if you use libjsig,
    the problem just might disappear if the issue is signal
    based. Try it and let us know.

    --Joe
    Joseph Millar, Jul 9, 2003
    #3
  4. On Wed, 09 Jul 2003 02:33:33 GMT, Joseph Millar
    <> wrote:

    > On Tue, 08 Jul 2003 18:35:33 -0600, Marc Rochkind <>
    > wrote:
    >> Must be... or else I have received it wihtout asking! ;-) But,
    >> seriously, trouble is what I want. I'm exploring the JNI environment.

    >
    > You want trouble? Steal SIGSEGV and try anything in that
    > would normally generate a NullPointerException.
    >
    >
    >> Thanks a million for this! I never would have otherwise come across it.
    >> Nothing you've said implies that this library helps me with my lost-
    >> class problem, but we shall see... I'm hopeful!

    >
    > Not sure what the issue is there, but if you use libjsig,
    > the problem just might disappear if the issue is signal
    > based. Try it and let us know.
    >
    > --Joe
    >


    Went to 1.4.2 and the immediate problem (not finding the class) went away
    and stayed away, without doing anything with libjsig, as I don't think this
    was a signal-chaining issue.
    I went ahead and added libjsig anyway.

    I have other weirdnesses, which I don't think have any solution, when I
    call NewObject from within the signal handler. It seems to work, but then
    later (much later) the program exhibits other strange behavior. This is
    probaly because NewObject (and many other calls I'm making) aren't async
    signal safe. I suspected this, but wanted to see what would happen.

    --Marc
    Marc Rochkind, Jul 9, 2003
    #4
  5. Marc Rochkind <> wrote in message news:<>...
    > On Wed, 09 Jul 2003 02:33:33 GMT, Joseph Millar
    > <> wrote:
    >
    > > On Tue, 08 Jul 2003 18:35:33 -0600, Marc Rochkind <>
    > > wrote:
    > >> Must be... or else I have received it wihtout asking! ;-) But,
    > >> seriously, trouble is what I want. I'm exploring the JNI environment.

    > >
    > > You want trouble? Steal SIGSEGV and try anything in that
    > > would normally generate a NullPointerException.
    > >
    > >
    > >> Thanks a million for this! I never would have otherwise come across it.
    > >> Nothing you've said implies that this library helps me with my lost-
    > >> class problem, but we shall see... I'm hopeful!

    > >
    > > Not sure what the issue is there, but if you use libjsig,
    > > the problem just might disappear if the issue is signal
    > > based. Try it and let us know.
    > >
    > > --Joe
    > >

    >
    > Went to 1.4.2 and the immediate problem (not finding the class) went away
    > and stayed away, without doing anything with libjsig, as I don't think this
    > was a signal-chaining issue.
    > I went ahead and added libjsig anyway.
    >
    > I have other weirdnesses, which I don't think have any solution, when I
    > call NewObject from within the signal handler. It seems to work, but then
    > later (much later) the program exhibits other strange behavior. This is
    > probaly because NewObject (and many other calls I'm making) aren't async
    > signal safe. I suspected this, but wanted to see what would happen.
    >


    Instead of trying to execute java code in a signal handler
    could you get a similar effect by marking signals as having occured
    with C code, and then using a thread (mostly java) that monitors
    the signal marking and calls back some other java object (from a thread,
    not a signal handler)?

    > --Marc
    Bryan Castillo, Jul 10, 2003
    #5
  6. On 10 Jul 2003 00:35:34 -0700, Bryan Castillo <> wrote:


    [snip]

    >
    > Instead of trying to execute java code in a signal handler
    > could you get a similar effect by marking signals as having occured
    > with C code, and then using a thread (mostly java) that monitors
    > the signal marking and calls back some other java object (from a thread,
    > not a signal handler)?
    >


    I would love to...

    But, there are cases -- a signal caused by the arrival of a message on a
    POSIX message queue, for example -- where information in a siginfo_t
    structure is passed to the signal handler. This information needs to be
    captured somehow and passed, eventually, to the Java program.

    Less generally, what I'm trying to do is construct a package that allows
    students learning POSIX/SUS to write programs in Java, Jython, or, perhaps,
    even BeanShell. Alas, is seems that signals will have to be omitted from
    the lab, although it seems that most everything else in POSIX/SUS is
    working well (even shared memory).

    --Marc
    Marc Rochkind, Jul 10, 2003
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Marc Rochkind
    Replies:
    0
    Views:
    426
    Marc Rochkind
    Jul 9, 2003
  2. Replies:
    12
    Views:
    1,638
    Dave Thompson
    Jan 10, 2005
  3. Michael Pronath
    Replies:
    1
    Views:
    1,166
    Diez B. Roggisch
    Jan 3, 2005
  4. Replies:
    18
    Views:
    619
    Dave Thompson
    Jan 10, 2005
  5. Replies:
    6
    Views:
    1,313
    James Kanze
    Jun 10, 2008
Loading...

Share This Page