dllcrt0.c corrupts heap - by Orin Eman(laplink)

Status : 


Sign in
to vote
ID 773459 Comments
Status Closed Workarounds
Type Bug Repros 2
Opened 12/4/2012 2:29:29 PM
Access Restriction Public


All memory allocated by the C runtime in a dll is freed too early by __freeCrtMemory().

_ioterm() and  _mtterm() which are called after __freeCrtMemory() both access and/or free memory that was allocated by the C runtime.  See below:

                    /* Free allocated CRT memory */

#ifndef _DEBUG
                    /* If dwReason is DLL_PROCESS_DETACH, lpreserved is NULL
                     * if FreeLibrary has been called or the DLL load failed
                     * and non-NULL if the process is terminating.
                    if ( lpreserved == NULL )
#endif  /* _DEBUG */
                         * The process is NOT terminating so we must clean up...
                        /* Shut down lowio */

                        /* This should be the last thing the C run-time does */
                        _heap_term();   /* heap is now invalid! */
#ifndef _DEBUG
#endif  /* _DEBUG */

The fix is simple.   __freeCrtMemory() should be after _mtterm().
Sign in to post a comment.
Posted by Deon [MSFT] on 4/29/2014 at 12:31 PM
Thank you for reporting this issue. This issue has been fixed in Visual Studio 2013. You can install a trial version of Visual Studio 2013 with the fix from: http://go.microsoft.com/?linkid=9832436
Posted by chksr on 8/21/2013 at 2:32 AM
Still happening:

Microsoft Visual Studio Premium 2012
Version 11.0.60610.01 Update 3


Posted by Aaron Wishnick on 7/26/2013 at 2:20 PM
If it's helpful, here's my call stack:

    ntdll.dll!NtWaitForKeyedEvent()    Unknown
    ntdll.dll!RtlAcquireSRWLockExclusive()    Unknown
    ntdll.dll!RtlFlsFree()    Unknown
    KernelBase.dll!FlsFree()    Unknown
>    MyProject.dll!__crtFlsFree(unsigned long dwFlsIndex) Line 377    C
    MyProject.dll!_mtterm() Line 169    C
    MyProject.dll!_CRT_INIT$fin$0() Line 205    C
    MyProject.dll!__C_specific_handler(_EXCEPTION_RECORD * ExceptionRecord, void * EstablisherFrame, _CONTEXT * ContextRecord, _DISPATCHER_CONTEXT * DispatcherContext) Line 283    C
    ntdll.dll!RtlpExecuteHandlerForUnwind()    Unknown
    ntdll.dll!RtlUnwindEx()    Unknown
    ntdll.dll!__C_specific_handler()    Unknown
    ntdll.dll!RtlpExecuteHandlerForException()    Unknown
    ntdll.dll!RtlDispatchException()    Unknown
    ntdll.dll!KiUserExceptionDispatch()    Unknown
    MyProject.dll!_freefls(void * data) Line 410    C
    ntdll.dll!RtlFlsFree()    Unknown
    KernelBase.dll!FlsFree()    Unknown
    MyProject.dll!__crtFlsFree(unsigned long dwFlsIndex) Line 377    C
    MyProject.dll!_mtterm() Line 169    C
    MyProject.dll!_CRT_INIT(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 187    C
    MyProject.dll!__DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 390    C
    MyProject.dll!_DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 332    C
    ntdll.dll!LdrpUnloadDll()    Unknown
    ntdll.dll!LdrUnloadDll()    Unknown
    KernelBase.dll!FreeLibrary()    Unknown
Posted by Aaron Wishnick on 7/26/2013 at 2:14 PM
This bug is impacting me by causing a deadlock when calling FreeLibrary(), and does not appear to have been fixed in either VS2012 Update 3, or the VS2013 preview. The deadlock appears to be because _mtterm() calls __crtFlsFree(), which calls RtlFlsFree(). RtlFlsFree() holds a lock by calling RtlAcquireSRWLockExclusive(). Then, while holding that lock, RtlFlsFree() calls _freefls(), which triggers an access violation because the heap has been destroyed. That access violation ends up being caught in the __finally block, back in _CRT_INIT(), which calls _mtterm() re-entrantly on line 205. That once again ends up in RtlFlsFree(), which attempts to acquire that same lock with RtlAcquireSRWLockExclusive(), which causes the deadlock.

Is there any workaround you can suggest in the meantime? And is there any chance of some sort of patch to VS2012 that could resolve this issue? Thank you very much.
Posted by James [MSFT] on 2/17/2013 at 11:29 PM

Thank you for reporting this issue! We have fixed this bug and the fix will be available in the next release of our Visual C++ libraries.

Note: Connect doesn't notify me about comments. If you have any further questions, please feel free to e-mail me.

James McNellis
Visual C++ Libraries
Posted by Macy [MSFT] on 12/4/2012 at 7:40 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Macy [MSFT] on 12/4/2012 at 2:51 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)