process corruption on windows

[vtjnash]

calling almost any external functions from DllInit or CONSTRUCTOR can lead to corruption of the libc state on windows. this manifested itself as a very odd bug on some machines where child processes are unable to initialize the networking stack

ref. JuliaLang/julia#5574
ref. http://msdn.microsoft.com/en-us/library/windows/desktop/dn633971(v=vs.85).aspx

proposed patch file: https://github.com/JuliaLang/julia/blob/master/deps/openblas-dllinit-safe.patch

alternatively, it appears that getenv may be the only call that touches the windows API in gotoblas_init, so a possible alternative is to use GetEnvironmentVariable instead of getenv, although this option has not yet been tested. any uses of malloc also must be avoided (although VirtualAlloc should be safe)

[wernsaar]

On 22.06.2014 05:42, Jameson Nash wrote:

calling almost any external functions from DllInit or CONSTRUCTOR can lead to corruption of the libc state on windows. this manifested itself as a very odd bug on some machines where child processes are unable to initialize the networking stack

ref. JuliaLang/julia#5574
ref. http://msdn.microsoft.com/en-us/library/windows/desktop/dn633971(v=vs.85).aspx

proposed patch file: https://github.com/JuliaLang/julia/blob/master/deps/openblas-dllinit-safe.patch

alternatively, it appears that getenv may be the only call that touches the windows API in gotoblas_init, so a possible alternative is to use GetEnvironmentVariable instead of getenv, although this option has not yet been tested. any uses of malloc also must be avoided (although VirtualAlloc should be safe)

---

Reply to this email directly or view it on GitHub:
#394
Hi,

I tried the proposed openblas-dllinit-safe.patch with BLAS-Tester on
linux with wine.
With the patch, multithreading does not work, because the program is waiting
( RtlpWaitForCriticalSection), without the patch there is no problem.
Maybe this
could be a bug in wine, but I don't have Windows for testing.

Best Regards
Werner

[vtjnash]

the patch defers initialization for the user to call gotoblas_init before using blas. i'm hoping to test whether replacing getenv with GetEnvironmentVariable will also seem to fix the issue, but I don't have direct access to a machine the exhibits symptoms of this bug for continuous testing.

[vtjnash]

I found the real issue was due to a leaked process handle, which was also being used to disable all process permissions. I have updated the gist above to correct that issue. After changing the call to getenv to GetEnvironmentVariable it should be safe to move this back into DllInit.