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

[Will Hawkins]

On Thu, Dec 22, 2016 at 4:08 PM, Will Hawkins <whh8b at virginia.edu> 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 redhat.com> 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?

Thanks!
Will

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