RFR (S) 8216308: StackTraceElement::fill_in can use injected Class source-file
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Mon Jan 14 13:23:12 UTC 2019
On 1/14/19 8:06 AM, David Holmes wrote:
> On 14/01/2019 10:32 pm, Aleksey Shipilev wrote:
>> On 1/12/19 1:43 AM, David Holmes wrote:
>>>>> I'm also very unclear about how the redefinition case is currently
>>>>> handled. It seems that we will
>>>>> normally intern NULL (and presumably get a NULL or empty-string
>>>>> oop?) unless ShowHiddenFrames is
>>>>> set, in which case we use the unknown_class_name() - regardless of
>>>>> whether the frame is actually
>>>>> hidden or not! This seems broken to me. (Separate bug to fix that
>>>>> is okay if it is indeed broken.)
>>>>
>>>> This looks like a bug, but I'm not sure what ShowHiddenFrames is
>>>> supposed to do here, or how it
>>>> got there. I think if Aleksey removed that with this patch it
>>>> would be fine with me.
>>>
>>> I think use of ShowHiddenFrames here is completely broken. But a
>>> seperate bug and some suitable
>>> archaeology is needed to fix it the right way.
>>
>> Okay, are we in agreement that current patch does not break anything
>> new? If so, let's push the
>
> Okay I agree it doesn't break anything new though I'd be happier if
> the Backtrace::get_line_number issue was fixed. Otherwise it needs a
> follow up bug too - I'm starting to think it makes no sense to allow
> redefinition to occur within a method like this! And this is a
> distinct issue from ShowHiddenFrames.
There's no practical way to disable redefinition here and it's not
something that happens. You can file a bug for it if you like, but it's
not something worth fixing.
thanks,
Coleen
>
> David
> -----
>
>
>> current patch in its current form, and then follow up on
>> ShowHiddenFrames in a separate issue. This
>> would also make current patch simply backportable to 11.
>>
>> Current patch (no changes since last time):
>> http://cr.openjdk.java.net/~shade/8216308/webrev.01/
>>
>> -Aleksey
>>
More information about the hotspot-dev
mailing list