From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2006-04-07 05:46:33
On 4/7/06, Roland Schwarz <roland.schwarz_at_[hidden]> wrote:
> Felipe Magno de Almeida wrote:
> > I'm using an AMD64 X2 and sometimes the program fails with the
> > debugger showing me this call stack:
> [ snip ]
> Unfortunately at the moment none of the developers seems to have access
> to a 64 bit machine. I will try to improve on this situation, but have
> to ask for patience until we have access.
I forgot to mention! I'm compiling to x86.
It seems the problem is due to boost::thread_specific_ptr<ptr_t> being
a local static variable in get_definition on grammar.ipp in spirit
line: 224 in grammar.ipp
# ifdef BOOST_SPIRIT_THREADSAFE
static boost::thread_specific_ptr<ptr_t> tld_helper;
ptr_t &helper = *tld_helper;
The .get member function is called before the tld_helper is fully
constructed (and, as a consequence, the tss_data in tss.cpp isnt
So in line 114 - tss.cpp - ::get_slots
slots = static_cast<tss_slots*>(
tss_data isnt initialized yet.
I think the only relevance is that it is a dual core. Which makes two
parse's functions being called concurrently on a local static.
The pretty bad workaround I made was adding
as the first line to get_slots.
But the real problem is that local statics arent thread safe, and a
member-function is being called before the object being fully
Unfortunately I dont have more time to invest coding any better
solution right now. Nor understanding boost.thread/boost.spirit
internals. It seems to me that thread_specific_ptr has a broken
interface and documentation, since it doesnt address the local static
thread-safety issue. Which leads users to use it erroneously.
I dont know now if I should move the thread to spirit, as a spirit
thread-safety bug. What do you think?
-- Felipe Magno de Almeida
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk