RFR(M): 8186072: dll_build_name returns true even if file is missing.
Thomas Stüfe
thomas.stuefe at gmail.com
Wed Aug 16 11:00:55 UTC 2017
Hi Goetz,
On Wed, Aug 16, 2017 at 12:22 PM, Lindenmaier, Goetz <
goetz.lindenmaier at sap.com> wrote:
> Hi,
>
> dll_build_name builds the proper path to a library given a list of paths
> seperated by
> path_seperator and a library name. It adds in the platform specific
> endings etc.
> It is documented to return whether the file exists, but only does so if a
> path_seperator
> exists in the path.
>
>
good catch!
> Especially if the path is empty, it just returns 'true'.
> Dll_build_name is usually used before calling dll_load. If dll_load does
> not get a full path it searches
> in well known unix/windows locations. This is intended in the two cases
> where dll_build_name
> is called with an empty path.
>
So, for both cases (thread.cpp, jvmtiExport.cpp),
before, we would call os::dll_build_name() with an empty string for the
path which, for relative paths, would result in feeding that path
unexpanded to dlopen(), which would use whatever the OS does in those cases
(LIBPATH, LD_LIBRARY_PATH, PATH on windows). Note that this does not
necessarily include searching the current directory.
With your change, we now use java.library.path, which is not necessarily
the same?
(BTW, I think the old comments in thread.cpp and jniExport.cpp were
wrong:"// Try the local directory" - if "local" means "current", this is
not what did happen).
> I added a second variant of dll_build_name without the path argument that
> adds the path
> from system property java.lang.path and use that in these two cases.
> I changed the original function to actually check file availability in all
> cases,
> and to check . if the path is empty.
>
>
I think that may be a bit confusing. We would then have three options:
- call os::dll_build_name with a real "<aa>;<bb>;.." PATH and get a file
name resolved from that path
- call os::dll_build_name with "" for the PATH and get OS dll resolution
- call your new overloaded version of os::dll_build_name(), which uses
-Djava.library.path.
> Please review this change. I please need a sponsor.
> http://cr.openjdk.java.net/~goetz/wr17/8186072-dllBuildName/webrev.01/
>
> Best regards,
> Goetz.
>
>
Kind Regards, Thomas
More information about the hotspot-runtime-dev
mailing list