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

[Coleen Phillmore]

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

True.   It would be a good change to add some dummy initialization to 
those also.
Coleen
>
> 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
>>>>>>>
>>>>>>
>>>>
>>