From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-07 04:55:14
From: "William Kempf" <williamkempf_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
> >condition.cpp does not compile when the macro NOMINMAX is not defined.
> I'll add the macro before the includes.
> >This program:
> >sometimes prints 1, 2, ..., 7 (note absence of 0) and sometimes locks up
> >machine. (I'm using MSVC.) This happens only in Release builds, not in
> >Debug; I suspect that 0 is not printed because the catch(...) handler in
> >thread.cpp eats the access violation. The problem is probably in
> What access violation?
The access violation. Weird, I know. It happens somewhere in
boost::call_once(init_cleanup_key, once) in tss.cpp, AFAICS, but I may be
wrong. It's very difficult to debug on 9x since you never know whether it'll
be Big Red Button time.
> I also don't see any use of call_once in the above?
thread_specific_ptr<> uses call_once internally to initialize its cleanup
handler std::set. (Why isn't it a std::map, BTW? Looks like you are 'faking'
a map with a set?)
> This is very similar to code used in the test harness, which passes for me
> in both Debug and Release (the one difference being the use of
> which I don't suspect as a problem). This perplexes me. I'll have to try
> it out myself later and see if I can diagnose any errors.
Perplexed me, too.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk