Re: Debugging JNI shared libraries
From: Alf P. Steinbach (alfps_at_start.no)
Date: 10/07/03
- Next message: jAnO!: "[cURL] ommit headers"
- Previous message: Gerry Quinn: "Re: DOS, how long?"
- In reply to: Dave Neary: "Debugging JNI shared libraries"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 07 Oct 2003 10:01:02 GMT
On 07 Oct 2003 09:49:44 GMT, Dave Neary <real.addressinthesig@thisoneis.invalid> wrote:
>Hi all,
>
>I have been trying to get some JNI code working on Win32 (the code is
>libxmlj from the classpathx project). Compiles fine on Linux, and
>compiles OK on Win32 when I have teh requisite stuff installed and I'm
>using mingw, and I make a few changes (I really should learn how to use
>Visual Studio).
>
>I load my DLL/so via System.loadLibrary, and on Linux things go off
>without a hitch. On Win32, I get an access violation, attempt to
>reference object at address 0x00000... - looks like a null pointer
>dereference to me. So I compiled the Linux .so with efence (hoping to
>provoke a core dump in an environment that I know pretty well, and
>diagnose the problem), but I have not been able to replicate the problem
>at all.
>
>Which brings me to my question. How can I debug this kind of thing on
>Win32? Is there a way to load a DLL in a debugger, and (say) when
>DllMain gets called, attach to the dll?
You attach to the process/thread, not the DLL (which is just part of the
code as far as the debugger is concerned). Attach to the Java process
from the debugger, set a breakpoint in the DLL, let it run till the
breakpoint hits. However,
> How can I go about localising
>the problem? The best option available to me at the moment seems to be a
>bunch of printfs, which will perhaps help localise things.
I found trace output to be the cleanest solution when doing JNI stuff, but
that was years ago (1997?). Things to be aware of include, definitely, proper
exception handling (never let an exception escape up to the Java VM, it will
then go into panic mode), proper string conversion, and so on. I found it
best to build a small library of JNI wrappers and support classes. Also be
aware of threading. For an explicitly loaded DLL it's not safe to use the
Visual C++ support for thread local storage (if you use that compiler).
> It would be nice to get a core dump/stack trace though.
That's the Unix way; in Windows, use interactive debugging. MS Visual Studio,
which IMO is a really horrible piece of software (it insists on changing things,
like uppercase/lowercase, HTML entities, pictures added as resources (it actually
_mangles_ them!), and so on), has a very good, incredibly good, debugger.
>So - any Win32 people with good debugging tips for debugging shared
>objects?
They're not very different from non-shared.
- Next message: jAnO!: "[cURL] ommit headers"
- Previous message: Gerry Quinn: "Re: DOS, how long?"
- In reply to: Dave Neary: "Debugging JNI shared libraries"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
