test\addons\load-long-path\test.js - windows 32 bit failures

[mhdawson]

I'm seeing failures in our internal builds for test\addons\load-long-path\test.js for windows 32 bit.

I know it was validated that it worked for 32 bit as part of #2965 but I can't see what I'm doing wrong.

I looked in the CI to see if I could find this test running, but I don't think its runs for Windows.

I checked out the latest from the 4.2.2. branch built and ran the test. In addition, I had to build the module for the test with:

E:\test2\node>Release\node deps\npm\node_modules\node-gyp\bin\node-gyp rebuild --directory=e:\test2\node\test\addons\load-long-path --nodedir=e:\test2\node

The failure I see is the same as in our build environment:

#module.js:460
#  return process.dlopen(module, path._makeLong(filename));
#                 ^
#
#Error: The data area passed to a system call is too small.
#\\?\E:\test2\node\test\tmp.0\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\xxxxxxxxxxxxxxxxxxx
xxxxxxxxxxx\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\xxxxxx
xxxxxxxxxxxxxxxxxxxxxxxx\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\xxxxxxxxxxxxxxxxxxxxxxxx
xxxxxx\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\xxxxxxxxxxx
xxxxxxxxxxxxxxxxxxx\binding.node
#    at Error (native)
#    at Object.Module._extensions..node (module.js:460:18)
#    at Module.load (module.js:356:32)
#    at Function.Module._load (module.js:311:12)
#    at Module.require (module.js:366:17)
#    at require (module.js:385:17)
#    at Object. (E:\test2\node\test\addons\load-long-path\test.js:27:
13)
#    at Module._compile (module.js:435:26)
#    at Object.Module._extensions..js (module.js:442:10)
#    at Module.load (module.js:356:32)
  ---
  duration_ms: 1.144
  ...
not ok 8 test.js

Can anybody spot what I'm doing wrong or point me to somewhere in the CI were the test is run so that I can see if its doing anything I'm not ?

In both my local test and the build environment its running on Windows 7 SP1 64 bit with MSVC 2013 installed.

[mhdawson]

@orangemocha any input on this ?

[orangemocha]

I can reproduce on my Windows 7 machine, with a 32-bit build but not with a 64-bit one.

On 32-bit, LoadLibraryExW returns ERROR_INSUFFICIENT_BUFFER for long paths, in spite of the long path syntax. This is consistent with some user reports on MSDN (eg https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx).

I am reaching out to the owners of the API to find out more.

[mhdawson]

Thanks for the update

[mhdawson]

Any upadate on this ?

[orangemocha]

It is a confirmed bug on Wow64 only (meaning 32-bit Node on 64-bit Windows). I reported to the Windows team. It will be fixed in future updates but it's unlikely to be backported.

Next of my todo list is to try the following workarounds in Node:

1. Make a symbolic link in the temp folder and load from there
2. Use relative syntax

[mhdawson]

@orangemocha did you have any luck with the work arounds ?

[orangemocha]

Relative syntax is a no-go, as it would require setting the current directory or dll search path, which both have global side effects.

However, I could make it load through a symbolic link. I could submit a patch to libuv (uv_dlopen) or make it node-specific.

The patch creates a symbolic link in the user temp folder, calls LoadLibrary on it, then deletes the sym link.

@saghul would the above patch be desirable in libuv?

[orangemocha]

The workaround might not work in 100% of scenarios. For example, I think it might break usage of GetModuleHandle

cc @nodejs/platform-windows

[saghul]

@orangemocha IMHO such a workaround belongs in Node, rather than libuv.

[orangemocha]

It looks like this won't be easy to implement in Node, because we use uv_dlopen and uv_dlopen doesn't return the original error code (it formats it into a string messages and returns success/failure). @saghul , would this workaround be acceptable in libuv?

[gibfahn]

@orangemocha should this be closed as "no good way to fix"? I'm assuming what you said in your libuv comment applies here too.