WineHQ Bugzilla – Bug 35176 – MSVC 2012 C compiler 'cl.exe' fails/crashes (TLS not correctly initialised for explicitly-loaded DLLs)

Bugzilla

Last modified: 2014-01-03 13:10:00 UTC

MSVC 2012 C compiler 'cl.exe' fails/crashes (TLS not correctly initialised for explicitly-loaded DLLs)

Bug 35176 - MSVC 2012 C compiler 'cl.exe' fails/crashes (TLS not correctly initialised for explicitly-loaded DLLs)


Summary:	MSVC 2012 C compiler 'cl.exe' fails/crashes (TLS not correctly initialised fo...

Status:	CLOSED FIXED

AppDB:	Show Apps affected by this bug
Product:	Wine
Classification:	Unclassified
Component:	ntdll
Version:	1.7.6
Hardware:	x86 Linux

Importance:	P2 normal
Target Milestone:	---
Assigned To:	Mr. Bugs

URL:
Keywords:

Duplicates:	33546 (view as bug list)
Depends on:
Blocks:
	Show dependency tree

Reported:	2013-12-19 11:43 UTC by Richard Hayden
Modified:	2014-01-03 13:10 UTC (History)
CC List:	3 users (show)

See Also:
Regression SHA1:
Fixed by SHA1:	e54503f7085a5b62dfc373aaa6b98116bde784d4
Distribution:	---
Staged patchset:

Attachments
Add an attachment (back traces, logs, proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Richard Hayden 2013-12-19 11:43:54 UTC

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).

Comment 1 Anastasius Focht 2013-12-19 12:28:51 UTC

*** Bug 33546 has been marked as a duplicate of this bug. ***

Comment 2 Anastasius Focht 2013-12-19 12:30:22 UTC

Hello folks,

refining summary.

There is also bug 34869 which contains analysis of the same problem.

Regards

Comment 3 Martin Storsjö 2013-12-19 13:09:30 UTC

Richard, can you share your workaround for loading c2.dll directly when loading cl.exe?

Comment 4 Martin Storsjö 2013-12-21 15:16:53 UTC

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.

Comment 5 Richard Hayden 2013-12-22 07:38:42 UTC

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.

Comment 6 Martin Storsjö 2013-12-23 14:31:04 UTC

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.

Comment 7 Austin English 2013-12-26 17:59:53 UTC

Bug 34869 was fixed, please retest.

Comment 8 Martin Storsjö 2013-12-27 06:41:00 UTC

This does indeed work as it should now, so this bug can be closed.

Comment 9 Anastasius Focht 2013-12-27 08:43:32 UTC

Hello folks,

this is fixed by commit http://source.winehq.org/git/wine.git/commitdiff/e54503f7085a5b62dfc373aaa6b98116bde784d4

Thanks Alexandre.

Regards

Comment 10 Alexandre Julliard 2014-01-03 13:10:00 UTC

Closing bugs fixed in 1.7.10.