RFR: 8220095: Assertion failure when symlink (with different name) is used for lib/modules file

[Jiangli Zhou]

Thanks for confirming!

Jiangli

On Thu, Mar 7, 2019 at 8:50 AM Harold Seigel <harold.seigel at oracle.com>
wrote:

> Hi Jiangli,
>
> The copyright for new test ModulesSymLink.java is correct.
>
> Harold
> On 3/7/2019 11:18 AM, Jiangli Zhou wrote:
>
> Hi Harold,
>
> Thank you so much for the review and checking on the copyright header!
> Will update the webrev to address your comment.
>
> Thanks and regards,
> Jiangli
>
> On Thu, Mar 7, 2019 at 8:13 AM Harold Seigel <harold.seigel at oracle.com>
> wrote:
>
>> Hi Jiangli,
>>
>> The change looks good.  Could you change the call to strdup() at line
>> 710 in classLoader.cpp to os::strdup() ?
>>
>> Also, I'm not sure about  the copyright for your new test.  I'll ask
>> internally if you are using the right one.
>>
>> Thanks! Harold
>>
>> On 3/6/2019 6:20 PM, Jiangli Zhou wrote:
>> > Please review the following fix for 8220095.
>> >
>> > webrev: http://cr.openjdk.java.net/~jiangli/8220095/webrev.00/
>> > bug: https://bugs.openjdk.java.net/browse/JDK-8220095
>> >
>> > Symbolic links may be used commonly in some cloud environments. The
>> target
>> > files might have different names than the linked names. The VM crashes
>> when
>> > 'lib/modules' links to a target file with a different name, for example,
>> > lib/modules -> lib/0.
>> >
>> > The usage of the hard-coded MODULES_IMAGE_NAME (used by
>> > ClassLoader::is_modules_image(const char*)) can become problematic in
>> this
>> > case and leads to assertion failures and crashes in this case. The
>> > is_modules_image()
>> > checks always fail even the actual file is the runtime image because the
>> > canonical paths (which might not end with 'modules') are passed in for
>> the
>> > check. The fix is to obtain the real name from the canonical path early
>> > during initialization and use that for the is_modules_image() check.
>> >
>> > Tested with submit repo testing, tier1, tier2, and hotspot runtime tests
>> > locally.
>> >
>> > Thanks!
>> > Jiangli
>>
>