RFR: 8157490: null stream->source() no longer causes error with -Xlog:class+load
max.ockner at oracle.com
Tue May 31 17:39:57 UTC 2016
I like this suggestion and I have updated my fix with it.
On 5/26/2016 3:12 PM, Lois Foltan wrote:
> On 5/26/2016 2:07 PM, Max Ockner wrote:
>> Please review this very small fix for class+load logging with modules.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8157490
>> Webrev: http://cr.openjdk.java.net/~mockner/8157490/
>> Summary: The JCK test
>> vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1 hit a SIGSEGV in
>> the logging section at the end of
>> ClassFileParser::fill_instance_klass(). With the addition of modules,
>> this logging section now uses
>> to compute some of the module related parameters that it needs. This
>> SIGSEGV originated from the above line being executed with a null
>> stream source.
> Hi Max,
> I think you change is correct, but I would like to suggest changing
> the code even further. Currently the code between line #5352-5360
> does a complicated check to see if the module's name is part of the
> java runtime image file and only sets the local variable "module_name"
> if it is. So, only module names that are defined within the java
> runtime image file are printed out in the logging. We should print out
> all modules' names, not just the ones in the jimage file. So please
> try removing lines #5352-5360 and set the local variable to:
> const char* module_name = (module_entry->name() == NULL) ?
> UNNAMED_MODULE : module_entry->name()->as_C_string();
> The local variable "module_entry" is already checked at line #5310 to
> make sure it is set to a non-NULL value.
>> Tested with vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1
More information about the hotspot-dev