RFR (urgent, S): 8009836: nsk/regression/b4222717 fails with empty stack trace (new, still urgent!)

Rickard Bäckman rickard.backman at oracle.com
Wed Mar 13 06:12:33 PDT 2013


Coleen,

this looks good to me.

/R

On Mar 13, 2013, at 1:14 PM, Coleen Phillmore wrote:

> Summary: Some zeroing was missed for bug 8003553, causing empty stack traces and Xcomp crashes, add back zeroing to metablock
> 
> I'll file a new bug to take more time and work on the missing zeroing.
> 
> http://cr.openjdk.java.net/~coleenp/8009836_2/
> 
> JPRT found this and so did runThese -Xcomp product which is a configuration that in retrospect, I should have tested.   Good thing we have hotspot-rt repository because this would have wreaked havoc in the compiler baseline.
> 
> Thanks,
> Coleen
> 
> On 3/12/2013 2:04 PM, Coleen Phillimore wrote:
>> 
>> Thank you for the code review, Dan.
>> 
>> On 03/12/2013 11:00 AM, Daniel D. Daugherty wrote:
>>> On 3/12/13 7:52 AM, Coleen Phillimore wrote:
>>>> Summary: zero bit fields missed in Method* and ConstMethod*
>>>> 
>>>> Tested with JPRT and failed test.   The other tests didn't find this omission.
>>>> This bug might be causing JPRT c1 tests to get SEGV with stack overflows too on the hotspot-rt baseline.
>>>> 
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8009836/
>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8009836
>>> 
>>> src/share/vm/oops/constMethod.cpp
>>>    No comments.
>>> 
>>> src/share/vm/oops/method.cpp
>>>    No comments.
>>> 
>>> Maybe I'm being dense, but I don't see the connection between
>>> these code changes and the failure mode we're seeing. Can you
>>> explain the connection between these changes and the missing
>>> stack traces?
>>> 
>> 
>> In javaClasses.cpp at line 1560, the method was marked as hidden randomly on solaris sparc probably because of the endianness.
>> 
>>    if (method->is_hidden()) {
>>      if (skip_hidden)  continue;
>>    }
>>    bt.push(method, bci, CHECK);
>>    total_count++;
>> 
>>> I'm going to guess that the fields that were not explicitly
>>> zero were randomly non-zero on some of the Solaris SPARC configs
>>> and that caused some confusion.
>> 
>> yes.  I have a feeling that setting flags dont_inline and force_inline could also cause confusion but the confusion there was more subtle.
>>> 
>>> 
>>> How do we know whether all the fields have been properly
>>> initialized?
>> 
>> I had some temporary code that checked for the pattern 0xf1 from p = this to p< header_size() and manually checked the exceptions. We have a lot of gaps in instanceKlass so I couldn't leave the debugging code in.  So I checked them manually, unfortunately.
>> 
>> thanks,
>> Coleen
>>> 
>>> 
>>> Dan
>>> 
>>>> 
>>>> 
>>>> Thanks,
>>>> Coleen
>>> 
>> 
> 



More information about the hotspot-runtime-dev mailing list