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

Will Hawkins whh8b at
Thu Dec 22 21:10:59 UTC 2016

On Thu, Dec 22, 2016 at 4:08 PM, Will Hawkins <whh8b at> wrote:
> Andrews,
> Thank you SO much for your quick and incredibly thorough responses!
> This is going to make my debugging that much easier. Now, when I
> actually fix the problem, I will tell you a) why I am debugging
> java/javac and b) thank you again for your help!
> I hope that you have a great afternoon and great rest of the week!
> Will
> On Thu, Dec 22, 2016 at 4:01 PM, Andrew Dinn <adinn at> wrote:
>> 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.

Sorry to respond to my own email, but I was rereading this and thought
of a related question:

When I am compiling IcedTea, is there a way to "force" this alternate
behavior? In other words, could I ./configure with a flag that does
this proactive testing rather than responsive handling?


>> 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