[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(a)winehq.org Reporter: r.hayden(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=35176 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wine(a)martin.st --- Comment #1 from Anastasius Focht <focht(a)gmx.net> --- *** Bug 33546 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=35176 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |focht(a)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(a)gmx.net> --- Hello folks, refining summary. There is also bug 34869 which contains analysis of the same problem. Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=35176 --- Comment #3 from Martin Storsjö <wine(a)martin.st> --- Richard, can you share your workaround for loading c2.dll directly when loading cl.exe? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=35176 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=35176 --- Comment #4 from Martin Storsjö <wine(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=35176 --- Comment #5 from Richard Hayden <r.hayden(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=35176 --- Comment #6 from Martin Storsjö <wine(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=35176 --- Comment #7 from Austin English <austinenglish(a)gmail.com> --- Bug 34869 was fixed, please retest. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=35176 --- Comment #8 from Martin Storsjö <wine(a)martin.st> --- This does indeed work as it should now, so this bug can be closed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=35176 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |e54503f7085a5b62dfc373aaa6b | |98116bde784d4 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, this is fixed by commit http://source.winehq.org/git/wine.git/commitdiff/e54503f7085a5b62dfc373aaa6b... Thanks Alexandre. Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=35176 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #10 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 1.7.10. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org