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

[Vladimir Kozlov]

On 3/12/13 4:27 PM, Coleen Phillmore wrote:
>
> Metachunk::initialize() sets the pattern to 0xf7f7f7f7.
> thanks,
> Coleen

Yes, but I am talking about regular Chunk. C2 use Arenas and it may not 
initialized as we expect.

Vladimir

>
> On 3/12/2013 7:16 PM, Vladimir Kozlov wrote:
>> 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
>>>>>>
>>>>>
>>>
>