Why doesn't Visual Studio catch fatal exception in JNI callbacks?

Discussion in 'Java' started by Steve, Aug 2, 2009.

  1. Steve

    Steve Guest

    I'm working in Visual Studio 2008 on Windows XP. I've got a 32-bit
    environment at work and a 64-bit environment at home, and both exhibit
    this mystery.

    I'm working on a project that consists of a C++ main program with an
    embedded JVM. The C++ code calls java bytecode via JNI and that
    bytecode can call back into the C++ code via JNI native methods.

    This all works great...except when it doesn't. I'm finding it very
    difficult to debug problems in my native callback methods because
    whenever a fatal exception (say a null pointer reference, for example)
    occurs, the program just exits rather than dropping into the debugger
    like I would expect.

    To be clear...I'm running my C++ app in the debugger. I can step
    around, and if I dereference a null pointer, I get the familiar
    "something bad happened, do you want to debug?" dialog. But if my
    code enters the JVM and then calls back into my C++ code via a JNI
    native method, a null pointer deref leads to my app just exiting
    without me getting any kind of look at what caused the exit.

    Can anyone tell me why this occurs? Better still, is there some way I
    can change this behavior so that fatal problems in native methods are
    caught by the Visual Studio debugger?

    TIA for any help, which will be greatly appreciated.

    Steve
    Steve, Aug 2, 2009
    #1
    1. Advertising

  2. Steve

    Roedy Green Guest

    On Sat, 1 Aug 2009 20:19:24 -0700 (PDT), Steve <>
    wrote, quoted or indirectly quoted someone who said :

    >
    >TIA for any help, which will be greatly appreciated.


    One technique is to try to test the C++ and Java portions separately
    by writing test drivers in the same language. When you have the code
    working solidly, then glue them together with the JNI.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "Patriotism is fierce as a fever, pitiless as the grave, blind as a stone, and as irrational as a headless hen."
    ~ Ambrose Bierce (born: 1842-06-24 died: 1914 at age: 71)
    Roedy Green, Aug 2, 2009
    #2
    1. Advertising

  3. Steve

    Tom Anderson Guest

    Re: Why doesn't Visual Studio catch fatal exception in JNIcallbacks?

    On Sat, 1 Aug 2009, Steve wrote:

    > I'm working in Visual Studio 2008 on Windows XP. I've got a 32-bit
    > environment at work and a 64-bit environment at home, and both exhibit
    > this mystery.
    >
    > I'm working on a project that consists of a C++ main program with an
    > embedded JVM. The C++ code calls java bytecode via JNI and that
    > bytecode can call back into the C++ code via JNI native methods.
    >
    > This all works great...except when it doesn't. I'm finding it very
    > difficult to debug problems in my native callback methods because
    > whenever a fatal exception (say a null pointer reference, for example)
    > occurs, the program just exits rather than dropping into the debugger
    > like I would expect.
    >
    > To be clear...I'm running my C++ app in the debugger. I can step
    > around, and if I dereference a null pointer, I get the familiar
    > "something bad happened, do you want to debug?" dialog. But if my
    > code enters the JVM and then calls back into my C++ code via a JNI
    > native method, a null pointer deref leads to my app just exiting
    > without me getting any kind of look at what caused the exit.
    >
    > Can anyone tell me why this occurs? Better still, is there some way I
    > can change this behavior so that fatal problems in native methods are
    > caught by the Visual Studio debugger?


    Pure speculation follows.

    My guess would be that it's to do with signal handling, or whatever
    Windows's equivalent of that is. When a thread does something illegal, it
    is suspended, and a signal is delivered to the owning process. In a normal
    app, the handler for this would usually terminate the app, or at least the
    thread. In an app running under the debugger, the debugger installs its
    own signal handler which triggers debugging instead. But i suspect the JVM
    also installs its own handler, so that it can manage errors its way, by
    throwing Errors in java or whatever or whatever. It will install that
    handler when you call into it, and it remove it before it returns.

    However, if java makes a callback into C, then that still happens with the
    JVM's signal handler in place, and so the JVM does the handling, rather
    than the debugger - and in this case, it just exits (which surprises me a
    little, but is believable).

    As for solutions, you need to get the debugger to put its signal handler
    in place again on reentry into C. I have no idea how you'd do that.

    The best i can suggest for forward progress would be some informed
    googling or asking on stackoverflow.com!

    tom

    --
    Argumentative and pedantic, oh, yes. Although it's properly called
    "correct" -- Huge
    Tom Anderson, Aug 2, 2009
    #3
  4. Steve

    Steve Guest

    Thanks guys for your help. I did some googling and found this, which
    seems to explain pretty well what the JVM is doing:

    http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/signals.html

    Section 6.2 explains the exception handlers (the equivalent of Unix
    signals for Windows) that the JVM installs, and also explains how to
    insert your own handlers in the chain. I still don't see how to get
    the behavior I really want, which is to not have ANY exception
    handlers, but this should give me a solution by letting me catch
    exceptions in my own code while I still have a stack trace to see what
    went wrong.

    This link is a hot find in general...a Java troubleshooting guide from
    Sun...isn't that special.

    Be well all!

    Steve
    Steve, Aug 4, 2009
    #4
    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. wh
    Replies:
    2
    Views:
    509
    Cowboy \(Gregory A. Beamer\)
    Jan 16, 2004
  2. John Black
    Replies:
    8
    Views:
    4,152
    Xenos
    Aug 20, 2004
  3. aBs0lut30
    Replies:
    0
    Views:
    299
    aBs0lut30
    Aug 10, 2006
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,840
    Smokey Grindel
    Dec 2, 2006
  5. Marteno Rodia

    catch doesn't catch a thrown exception

    Marteno Rodia, Aug 3, 2009, in forum: Java
    Replies:
    5
    Views:
    564
    Daniel Pitts
    Aug 5, 2009
Loading...

Share This Page