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

[Vladimir Kozlov]

On 3/12/13 3:46 PM, Coleen Phillmore wrote:
>
> On 3/12/2013 6:40 PM, Vladimir Kozlov wrote:
>> Coleen,
>>
>> Each allocation in Metaspace (Method is Metadata) is zeroed by calling
>> Metablock::initialize() in Metaspace::allocate(). So why these fields
>> can have random numbers?
>
> With my last checkin, I took out this zero initialization and changed it
> to 0xf1f1f1f1 in debug mode.

Okay. It would be nice to do the same for Chunks allocatino which do not 
zero at all.

Vladimir

> Coleen
>
>>
>> Thanks,
>> Vladimir
>>
>> On 3/12/13 11:04 AM, 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
>>>>
>>>
>