Should I be able to run java(c) in gdb?

Andrew Dinn adinn at redhat.com
Thu Dec 22 21:01:22 UTC 2016


On 22/12/16 20:44, Andrew Haley wrote:
> On 22/12/16 20:14, Will Hawkins wrote:
> 
>> I am attempting to run java/javac under gdb. Everything works a-okay
>> when I run those binaries from the command line. It works okay under
>> strace, too. When I run them under gdb, though, I get a segfault every
>> time. Is there a reason this happens? Is there some set of flags that
>> I should be passing to java/javac when I want to run it under gdb?
> 
> Type:
> 
>   handle 11 nostop noprint
> 
> and all will be well.

11 . . . also known as SIGSEGV i.e. the signal sent when a segmentation
violation (access to an unmapped virtual memory address) occurs. The
above command tells gdb not to stop if that happens and let the running
program deal with it.

You are probably wondering why the JVM would ever try to access an
unmapped memory address. Well, this sometimes without it actually being
an error.

Internally the JVM can choose to represent the Java value null with an
address with an unmapped address (typically 0). When a program tries to
access an object field and it turns out that the object reference it is
trying to read from is null then this results in a SEGV signal being
raised. The JVM catches it with a registered handler, checks that the
cause was actually a null reference and raises a NullPointerException,
unwinding the stack back to a catch block handler or aborting the thread
if it is not caught.

A JVM doesn't have to this but -- it could just check every object
reference before trying to access an object. However for almost all
programs omitting the check and catching an exception when the access
fails gives better performance.

Also, note that the JVM knows when it is performing an object access so
it only ever patches up a SEGV signal when the access is to the address
which represents null. If it catches a SEGV signal in any other
circumstance it bails out, writing an error log and dumping a core file.

regards,


Andrew Dinn
-----------
(Yeah, that other Andrew)


More information about the distro-pkg-dev mailing list