<div dir="ltr">Interesting re the constexpr point.  That makes sense now why GCC/Clang don't have this issue.  I've definitely had to work around a few constexpr issues already as MSVC really doesn't support it.  At least vc12 doesn't, vc14 might but I can't use that in anger yet as MS have seriously updated their CRT which is causing me headaches.<div><br></div><div>I'll have to make some sort of patch on my own code.  I'll try to see if there's a clean way to do it which would make it acceptable for submission, in case I can get this stuff back into the code base.  Advise on doing that would be welcomed btw.</div><div><br></div><div>Swithing to console made no difference Matthew.  Which I'm sort of glad of TBH because I'd have needed to figure out the knock on effects of making that switch for us! :)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 9, 2015 at 12:42 AM, <a href="mailto:mfaithfull@btopenworld.com">mfaithfull@btopenworld.com</a> <span dir="ltr"><<a href="mailto:mfaithfull@btopenworld.com" target="_blank">mfaithfull@btopenworld.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:'Calibri','sans-serif'"><div dir="ltr">
<div dir="ltr">I am in a very similar position, having done very similar work to get libc++ working under MSVC so I appreciate the difficulty of providing a reproduction. </div><div dir="ltr">However I think Howard is almost certainly right and a lack of constexpr is at the root of the problem. </div><div dir="ltr">MSVC runtime does not attempt to initialize stdin stdout and therefore cin cout until they are used in a Windows application. One thing to try may be changing your build to target the Console. No promises but it does change the related static init.</div><div dir="ltr"><br></div>

</div><br><div><span class="">----- Reply message -----<br>From: "Andrew Parker" <<a href="mailto:andrew.j.c.parker@gmail.com" target="_blank">andrew.j.c.parker@gmail.com</a>><br></span><span class="">To: "<a href="mailto:mfaithfull@btopenworld.com" target="_blank">mfaithfull@btopenworld.com</a>" <<a href="mailto:mfaithfull@btopenworld.com" target="_blank">mfaithfull@btopenworld.com</a>><br>Cc: <<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a>><br>Subject: [cfe-dev] libc++: Race condition in facets initialization?<br></span><div><div class="h5">Date: Wed, Jul 8, 2015 12:32</div></div></div></div><div><div class="h5"><br><div dir="ltr">It's difficult for me to give you a repo because the whole thing relies on our custom runtime.  I'll give you a brief description of what I have though.<div><br></div><div>I'm just creating a dll and linking against the static windows CRT.  I rely on the MSVC _CRT_INIT function to call static ctrs so I basically get whatever MSVC gives me.  The offending code is as simple as:</div><div><br></div><div>std::cout << std::endl;<br></div><div><br></div><div>in a "main" function.  main being the first (significant) thing I call after _CRT_INIT has returned.  </div><div><br></div><div>Obviously no guarantees you'd be able to repro given we both probably have changed the source and likely have quite different runtimes.</div><div><br></div><div>Re generally porting to msvc.  I've spent some fairly painful time getting as far as I have.  Many of the issues I've faced relate to working around MS's poor compiler support for MSVC.  There are numerous changes that I think would be beneficial to the code base.  I haven't made any progress with trying to submit them because:</div><div><br></div><div>a) I'm too busy.</div><div>b) I'm not familiar with the submission process.</div><div>c) I don't know whether changes would be readily accepted based on me saying "this fixes X with MSVC".  Is there any automated testing for MSVC?  Would moderators accept code on the basis that "it doesn't break anything else and trust me it makes Windows better"?</div><div><br></div><div>Roughly the changes I've made fall into 3 categories:</div><div><br></div><div>- Workarounds for poor compiler support.</div><div>- Fixes to libc++ fallbacks when certain features aren't available.  For example, when _LIBCPP_HAS_NO_VARIADICS is defined the fallbacks for certain code don't actually work.</div><div>- Minor bug fixes to libcpp (there are very few in this category and mostly innocuous).</div><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Jul 8, 2015 at 6:29 PM, <a href="mailto:mfaithfull@btopenworld.com" target="_blank">mfaithfull@btopenworld.com</a> <span dir="ltr"><<a href="mailto:mfaithfull@btopenworld.com" target="_blank">mfaithfull@btopenworld.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div style="font-family:'Calibri','sans-serif'"><div dir="ltr">
<div dir="ltr">I don't have a solution for you but I am very interested to stay in the loop on this one. I already have a 'working' port of libc++ to MSVC . It is highly operational but by no means thoroughly tested and 6 months out of date in terms of libc++ updates. I may have the same initialization order issue or I may not. I have implemented custom static initialization across this and several other libraries that operate together.</div><div dir="ltr">Do you have a code example that triggers the bug?</div><div dir="ltr"><br></div><div dir="ltr">Matthew Faithfull.</div>

</div><span><br><div>----- Reply message -----<br>From: "Andrew Parker" <<a href="mailto:andrew.j.c.parker@gmail.com" target="_blank">andrew.j.c.parker@gmail.com</a>><br>To: <<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a>><br>Subject: [cfe-dev] libc++: Race condition in facets initialization?<br>Date: Wed, Jul 8, 2015 10:32</div></span></div><span><br><div dir="ltr">And excuse the misleading title.  It's not a race condtion.  I just have other stuff on the brain!  Should probably read:<div><br></div><div>libc++: Order of static initialization issue with facets ?<br></div></div></span></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Jul 8, 2015 at 5:26 PM, Andrew Parker <span dir="ltr"><<a href="mailto:andrew.j.c.parker@gmail.com" target="_blank">andrew.j..c.parker@gmail.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div>I'm currently porting libc++ to work with MSVC.  I'm seeing a crash when I call the insertion operator on std::err.  I've traced the problem down to static initialization order of the static locale::id member of the ctype<char> facet.<br></div><div><br></div><div>I've looked over the code several times and am convinced that there's a genuine issue here.  It's entirely possible that the changes I've made for MSVC (or just the use of MSVC itself) may be causing unexpected problems.  Hence the need for a second opinion.</div><div><br></div><div>Here's a rough overview of the chain of events:</div><div><br></div><div>- static constructors for my binary are called.</div><div>- ios_base::Init::Init() called to initialize std::cout, std::cerr etc..</div><div>- const locale& locale::__imp::make_classic() called during initialization of first basic_streambuf.</div><div>- Enter locale::__imp::__imp(size_t refs) to start constructing and installing facets into the locale.</div><div><br></div><div>The cause of my particular crash is when we install ctype<char>, i.e. install(&make<_VSTD::ctype<char> >(nullptr, false, 1u));</div><div><br></div><div>The install member of locale::__imp looks like:</div><div><br></div><div>template <class F> void install(F* f) {install(f, f->id.__get());}<br></div><div><br></div><div>The thing to note here is that the id member of *f is actually a static member of ctype<char> (the template param F is resolving to ctype<char> here). The call to get() looks at the once flag member of ctype<char>::id, which is zero as the id variable is static an zero initialized.  This means the member __id_ of id is set to the next available id (__next_id) and installed at that index in the locale.</div><div><br></div><div>Things go wrong later when the static ctr for locale::id ctype<char>::id is called.  This effectively zero initializes the id again.  Later on when use_facet is called (during my call to the std::cerr insertion operator) the id gets set again (to __next_id).  This index is invalid and causes a crash when looked up in the locale.</div><div><br></div><div>It seems to me that this issue would affect all of the static id members of the various facets.  Any thoughts anyone?  How could this have never been seen before?  Is it possible GCC/clang somehow skirt around this bug?</div><div><br></div><div>I want to be sure it's not me stuffing things up before I start writing patches.</div><div><br></div></span><div>Thanks</div><div><br></div></div>
</blockquote></div><br></div>

</div></div></blockquote></div><br></div>

</blockquote></div><br></div>