Home Dashboard Directory Help

application crashed when include fstream in mixed (Cli/native) c++ project by Victor Sukharev


 as Fixed Help for as Fixed

Sign in
to vote
Type: Bug
ID: 664827
Opened: 4/26/2011 12:19:59 AM
Access Restriction: Public
User(s) can reproduce this bug


If create WinForm application (C++ Project), then switch compilef from /clr:pure to /clr,
and add cpp file to project and remove /clr for it. We get crash after lunch application if try to create fstream object. You can see sample below:

// test_fstr.cpp
#ifdef _MANAGED
#pragma unmanaged

#include <fstream>
#include <iostream>

int f1(void)
    std::ofstream of;
    return 0;

When application crash we recive next call stack
*1         msvcr100d.dll!_msize_dbg(void * pUserData=0xc071e859, int nBlockUse=2)
2         msvcr100d.dll!_dllonexit_nolock(int (void)* func=0xc03197f9, void (void)* * * pbegin=0x0013e930, void (void)* * * pend=0x0013e928)
3         msvcr100d.dll!__dllonexit(int (void)* func=0xc03197f9, void (void)* * * pbegin=0x0013e930, void (void)* * * pend=0x0013e928)
4         test.exe!_onexit(int (void)* func=0x00407fa0)
5         test.exe!atexit(void (void)* func=0x00407fa0)
6         test.exe!std::`dynamic initializer for '_Fac_tidy_reg''()
7         [Внешний код]
8         test.exe!_initterm(void** pfbegin = 0x004081BC, void pfend = )
9         test.exe!<CrtImplementationDetails>::LanguageSupport::InitializeNative()
10         test.exe!<CrtImplementationDetails>::LanguageSupport::_Initialize()
11         test.exe!<CrtImplementationDetails>::LanguageSupport::Initialize()
12         test.exe!?.cctor@@$$FYMXXZ()
13         mscoreei.dll!603b55ab()
14         [Указанные ниже фреймы могут быть неверны и (или) отсутствовать, символы для mscoreei.dll не загружены]
15         mscoree.dll!79007f16()
16         mscoree.dll!79004de3()
17         kernel32.dll!7c817067()
6         test.exe!std::`dynamic initializer for '_Fac_tidy_reg''() ->


struct _Fac_tidy_reg_t { ~_Fac_tidy_reg_t() { ::_Fac_tidy(); } };
_AGLOBAL const _Fac_tidy_reg_t _Fac_tidy_reg;
Problem with initialize Struct _Fac_tidy_reg (CLI/Native)

If come back /clr for it file then all OK.

It test under vc9 toolset and .Net 3.5 is OK.
Sign in to post a comment.
Posted by Microsoft on 4/29/2014 at 12:17 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 SergeLalonde1 on 5/14/2013 at 8:10 AM
Is a hotfix for this problem available for VS2010 SP1?
The workaround is not practical when using third party libraries for which we don't control their source code.
Posted by adam_sdgm on 7/25/2012 at 1:40 AM
This is marked as closed - but you do not specify for what version - can we expect a hotfix/SP, or will this wait for the next edition of VS?
Posted by Microsoft on 4/28/2011 at 12:20 AM
Thank you for quick response. Your issue has been routed to the appropriate VS development team for review. We will contact you if we require any additional information.
Posted by Victor Sukharev on 4/27/2011 at 10:13 AM
I attached file with sample solution. It tuning for crash.
Posted by Microsoft on 4/27/2011 at 12:52 AM
Thank you for reporting this issue.
But we were not able to reproduce it with the steps you provided. Could you please attach a demo project to help us reproduce this issue?
Posted by Microsoft on 4/26/2011 at 1:13 AM
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)
Sign in to post a workaround.
Posted by CodeMercenary on 7/12/2011 at 12:27 AM
The cause of the crash is that there is a global variable introduced in locale0.cpp called "_AGLOBAL const _Fac_tidy_reg_t _Fac_tidy_reg;" and the corresponding destructor has a non-trivial delete. This causes the runtime to attempt to invoke _onexit in order to register the dtor, which in CRT implementations will incorrectly invoke __dllonexit for non-DLL applications.

The workaround is to wrap any functionality you have which needs to make use of fstream in a .dll which is then dynamically linked (rather than statically linked) to the corresponding application.
File Name Submitted By Submitted On File Size  
test1.zip 4/27/2011 9 KB