John Maddock wrote:
David Yon wrote:
One more thought... where would be good places to put some good old-fashioned printfs in the regex code to detect when static initializer/destructors are being called? Would be interesting to see if I can catch the compiler in the act of destroying my static regexes *after* it has shut down the regex library code.
Hmm, actually the more I think about it, the less places I can think of that actually do anything at shutdown time. The best thing would be to get a decent stack trace and/or a test case.
Ok, sorry for the firedrill, but I'm now almost certain that Boost is the victim here rather than the culprit. As I said earlier, I'm using KDevelop with the AutoMake back-end for doing the actual build. The AutoMake back-end has a linker check-box that lets you statically link. Well, you do get an executable which doesn't have any shared lib dependencies, but for me, that executable is seriously broken. I apologize for this being somewhat off-topic, but I'm posting the rest of this note anyways in hopes the some poor schmoe in the future gets a more informative Google hit than did I this time around... So after going over to a Fedora Core 3 box with gcc 3.4, I was still running into problems. Only I was back to my original symptom of dying in c_regex_traits<char>::init() (which is called during static constructor initialization). It was dying on this line: #ifdef BOOST_HAS_THREADS re_detail::cs_guard g(*re_detail::p_re_lock); #endif Well actually, it was dying during InitializeCriticalSection(), which simply calls pthread_mutex_init(). Except in my case, the top of the backtrace was showing 0x00000000. Initially I attributed this to a side-effect of some wildly bad stack or something, but when you look at the disassembly, indeed the call to pthread_mutex_init() had been resolved to a null address!! (WTF?) Running "nm" on the executable shows that pthread_mutex_init is a "Weak Symbol", which means that it was legal for it not to resolve and therefore it resolved to zero. I'm not sure what problem the gcc folks were trying to solve with that somewhat oddball concept, or why the KDevelop "-all-static" checkbox causes this to happen. I do know that for C++, "-all-static" must be doing some serious voodoo, since normally it is not at all straightforward to get gcc to cleaning link C++ statically. For a very special flavor of pain, read the following thread on that topic: http://groups.google.com/group/gnu.gcc.help/browse_frm/thread/bfd688b5998856... At any rate, I've determined that there doesn't seem to be anything special about pthreads, because seemingly-inconsequential changes to the build will make the problem move around. I.e., when the problem is that I get a segv during exit(), obviously pthread_mutex_init() had been properly linked in that time. So I'm working on getting a static link "the hard way" without relying on the broken "-all-static" option. Hopefully that is the path to enlightenment. One good thing to come out of all this is that I discovered that including the Boost.regex source in my build is not the black magic I thought it would be. Thanks, John, for that suggestion---it will seriously simplify by build scripting. David Yon Tactical Software