From: David Yon (yon_at_[hidden])
Date: 2006-05-24 08:36:01
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/bfd688b59988567c
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