RFR: 8220095: Assertion failure when symlink (with different name) is used for lib/modules file
jianglizhou at google.com
Thu Mar 7 16:18:57 UTC 2019
Thank you so much for the review and checking on the copyright header! Will
update the webrev to address your comment.
Thanks and regards,
On Thu, Mar 7, 2019 at 8:13 AM Harold Seigel <harold.seigel at oracle.com>
> 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
> > files might have different names than the linked names. The VM crashes
> > '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
> > 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
> > 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
More information about the hotspot-runtime-dev