Opened 10 years ago

Closed 10 years ago

#7499 closed Bugs (fixed)

call_once doesn't call even once

Reported by: kab@… Owned by: viboes
Milestone: Boost 1.52.0 Component: thread
Version: Boost 1.51.0 Severity: Showstopper
Keywords: Cc:

Description

In boost 1.52.0 beta1

In boost/thread/pthread/once.hpp, near the head of the file, is the following conditional snippet:

#ifdef SIG_ATOMIC_MAX

typedef sig_atomic_t uintmax_atomic_t; ...

#else

...

#endif

Well, sig_atomic_t may be a signed type, and in fact on the Linux system I'm testing on it is a typedef for int [suse12.1, but I suspect it doesn't really matter.] POSIX says "Possibly volatile-qualified integer type ...".

This led to boost::call_once never calling the function, because there is a comparison in call_once

(epoch<this_thread_epoch)

where I'm seeing values of 0 and -2 respectively for those variables, that doesn't go in the expected direction when uintmax_atomic_t is a signed type rather than the expected unsigned type. I bet there are other places that get confused by this being an unexpectedly signed type.

I'm working around this to continue my testing of 1.52beta1 by commenting out the offending conditional code and just using the code in the #else clause.

The relevant code is new code, introduced since boost 1.51. This is a serious regression that should be a blocker for the 1.52 release.

Change History (3)

comment:1 by viboes, 10 years ago

Owner: changed from Anthony Williams to viboes
Status: newassigned
Version: Boost 1.52.0Boost 1.51.0

comment:2 by viboes, 10 years ago

Committed in trunk revision [80966].

comment:3 by viboes, 10 years ago

Milestone: To Be DeterminedBoost 1.52.0
Resolution: fixed
Status: assignedclosed

Committed revision [80985].

Note: See TracTickets for help on using tickets.