[Bug 35176] New: Thread-local storage not correctly initialised for explicitly-loaded DLLs
http://bugs.winehq.org/show_bug.cgi?id=35176
Bug ID: 35176 Summary: Thread-local storage not correctly initialised for explicitly-loaded DLLs Product: Wine Version: 1.7.6 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: r.hayden@gmail.com Classification: Unclassified
I came across this trying to get Microsoft Visual Studio 11.0 (2012)'s C/C++ compiler to work under wine (cl.exe). There is an already a bug report for this:
http://bugs.winehq.org/show_bug.cgi?id=33546
The symptom is that it page faults when trying to compile even the simplest of programs. Some investigation detailed in that bug report tracked it down to a particular memset causing a heap corruption.
I've investigated this further and discovered that it's due to wine not properly handling ".tls" sections in DLLs. My understanding is that this DLL section specifies initial values for thread-local variables and should be used to initialise these variables when new threads are created. One reason these come about is if the _declspec(thread) syntax is used to specify thread-local variables. It seems Wine has similar behaviour to Windows Server 2003 and Windows XP (see the paragraph near the bottom of http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175.aspx) in that these sections are not treated correctly for explictly-loaded DLLs, that is, loaded using LoadLibrary, but implicitly-loaded ones are fine.
I am able to work around my particular issues with cl.exe in Visual Studio 11.0 by hacking wine to inject the DLL with the .tls section, c2.dll, when it loads cl.exe, rather than letting it load it explicitly later on. Then it works fine in my fairly extensive testing (compiling a very large codebase).
http://bugs.winehq.org/show_bug.cgi?id=35176
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@martin.st
--- Comment #1 from Anastasius Focht focht@gmx.net --- *** Bug 33546 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=35176
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |focht@gmx.net Summary|Thread-local storage not |MSVC 2012 C compiler |correctly initialised for |'cl.exe' fails/crashes (TLS |explicitly-loaded DLLs |not correctly initialised | |for explicitly-loaded DLLs) Ever confirmed|0 |1
--- Comment #2 from Anastasius Focht focht@gmx.net --- Hello folks,
refining summary.
There is also bug 34869 which contains analysis of the same problem.
Regards
http://bugs.winehq.org/show_bug.cgi?id=35176
--- Comment #3 from Martin Storsjö wine@martin.st --- Richard, can you share your workaround for loading c2.dll directly when loading cl.exe?
http://bugs.winehq.org/show_bug.cgi?id=35176
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=35176
--- Comment #4 from Martin Storsjö wine@martin.st --- FWIW, I tried doing a similar workaround to what Richard mentioned, but I'm still running into crashes.
I've added this to the end of fixup_imports function in ntdll/loader.c:
// Any easier way to compare an UNICODE_STRING? if (wm->ldr.BaseDllName.Buffer[0] == 'c' && wm->ldr.BaseDllName.Buffer[1] == 'l' && wm->ldr.BaseDllName.Buffer[2] == '.' && wm->ldr.BaseDllName.Buffer[3] == 'e' && wm->ldr.BaseDllName.Buffer[4] == 'x' && wm->ldr.BaseDllName.Buffer[5] == 'e') { WINE_MODREF *extra = NULL; load_dll(load_path, L"c2.dll", 0, &extra); }
I've checked in alloc_thread_tls that tls_module_count is nonzero, but I'm still seeing crashes.
http://bugs.winehq.org/show_bug.cgi?id=35176
--- Comment #5 from Richard Hayden r.hayden@gmail.com --- Hi Martin, this is basically what I did.
However, I'd check the status coming back from load_dll; I'd hazard it's failing to load the DLL or some of its dependencies (not sure why tls_module_count > 0 though..). I think your problem here is that the other DLLs that c2.dll pulls in (e.g. mspdb110.dll) are not being found -- I don't think load_path = NtCurrentTeb()->Peb->ProcessParameters->DllPath.Buffer as passed to fixup_imports is sufficient here, you need to include %MSVSPATH%/Common7/IDE and maybe c:/windows/system32 too (semicolon delimited). At least that's what I had to do; I'm not sure where what is in your %PATH% comes into it, but I had to included these locations explicitly to get it work IIRC.
Hopefully I can post a patch for my exact workaround early next week.
http://bugs.winehq.org/show_bug.cgi?id=35176
--- Comment #6 from Martin Storsjö wine@martin.st --- Richard, I doubt that the culprit was the location of the DLLs, I had copied the necessary DLLs from Common7/IDE into VC/bin to simplify the setup already.
Anyway, it seems that this is fixed properly now by the last three commits at http://source.winehq.org/git/wine.git/shortlog/e54503f7085. Running the compiler still prints a lot of warnings about Rtl{Acquire,Release}SRWLockShared being stubs, but compiling simple programs at least seem to work now.
http://bugs.winehq.org/show_bug.cgi?id=35176
--- Comment #7 from Austin English austinenglish@gmail.com --- Bug 34869 was fixed, please retest.
http://bugs.winehq.org/show_bug.cgi?id=35176
--- Comment #8 from Martin Storsjö wine@martin.st --- This does indeed work as it should now, so this bug can be closed.
http://bugs.winehq.org/show_bug.cgi?id=35176
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |e54503f7085a5b62dfc373aaa6b | |98116bde784d4 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #9 from Anastasius Focht focht@gmx.net --- Hello folks,
this is fixed by commit http://source.winehq.org/git/wine.git/commitdiff/e54503f7085a5b62dfc373aaa6b...
Thanks Alexandre.
Regards
https://bugs.winehq.org/show_bug.cgi?id=35176
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.10.
-
wine-bugs＠winehq.org