JVM crashes when adding more than 2 methods to java.lang.Object
Daniel D. Daugherty
daniel.daugherty at oracle.com
Fri May 21 13:11:03 PDT 2010
Sorry that I'm really late to this e-mail thread. We don't support
using the RedefineClasses() API to add a public method. This testing
assertion is verified by an internal test (redefclass020) and I just
verified that the test does pass.
In Guillaume's scenarios, the Object.class bits are being replaced at
ClassFileLoadHook time or by providing the modified Object class using
the -Xbootclasspath/p parameter. (That info was provided in another
e-mail.) In neither of those cases is the RedefineClasses() API being
called so the error check I mention above isn't being made.
It more be worth adding a sanity check of some sort to the early
bring up/boot strapping logic to verify that the Object class that
we're about to load has the expected number of virtual methods. This
will allow us to get a cleaner error message for now.
Dan
On 4/28/2010 12:09 PM, Tom Rodriguez wrote:
> I didn't think we supporting redefining Object and adding public methods after JVM bootstrap. Adding methods to classes which are already loaded with subclasses means that you have to generate new vtables for all subclasses and as far as I know we don't do that. You might get more answer over on serviceability-dev.
>
> tom
>
> On Apr 24, 2010, at 1:30 PM, Guillaume Pothier wrote:
>
>
>> Hi,
>> First of all I hope it is appropriate to ask this kind of question in
>> this list, otherwise what would be the correct forum?
>> Here is my problem: I'm adding public, non-native methods to the
>> Object class through instrumentation, and it seems that adding more
>> than 2 such methods causes the JVM to crash. I get different kinds of
>> crashes depending on the number of methods I add. With 3 and 4 methods
>> I get a SIGSEGV; with more methods I get an NPE during VM
>> initialization (in String.charAt). For testing purposes, all added
>> methods take no arguments and return void, and have an empty body
>> (only the RETURN bytecode).
>> Is that expected behavior? Is there something I can do about it?
>> Kind regards,
>> Guillaume Pothier
>> PhD student, University of Chile
>>
>
>
>
More information about the serviceability-dev
mailing list