Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8369838

Likely invalid assert or function call in jimage.cpp

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: P4 P4
    • None
    • None
    • tools

      In src/java.base/share/native/libjimage/jimage.cpp there is a commented out assert marked:

      // TBD: assert(module_name_len > 0 && "module name must be non-empty");

      This guards the module name from being empty when trying to look up a resource.

      Since jimage entries for resources all live inside the '/modname/...' namespace, an empty module name will result in the string concatenation code:

          index = 0;
          fullpath[index++] = '/';
          memcpy(&fullpath[index], module_name, moduleNameLen);
          index += moduleNameLen;
          fullpath[index++] = '/';
          memcpy(&fullpath[index], name, nameLen);
          index += nameLen;
          fullpath[index++] = '\0';

      producing a fullpath that starts with '//'.

      This isn't an error per se, but no such resource can ever exist in jimage (as far as the normal jimage creation code is concerned).

      This would imply that the assertion should be conceptually valid and could be (re)instated, but we also see src/hotspot/share/classfile/classLoader.cpp:

      ClassFileStream* ClassPathImageEntry::open_stream_for_loader(...) {
        jlong size;
        JImageLocationRef location = (*JImageFindResource)(jimage_non_null(), "", get_jimage_version_string(), name, &size);

        if (location == 0) {
          ...
        }

      where "" above is an emtpy module name.

      I suspect that the following is true:
      1. The call to JImageFindResource with an empty module name never succeeds.
      2. That call and the if-guard can be removed.
      3. The non-empty module name assert can be enabled.

      But I could be wrong.

      Alternative explanations involve non standard jimage files where (some) paths can start with '//' (is this a pre-module system hangover?).

      Right now there's no obvious issue with running the code that always fails to find the resource in ClassPathImageEntry::open_stream_for_loader() other than its ability to confuse maintainers.

            Unassigned Unassigned
            dbeaumont David Beaumont
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: