Opened 10 years ago
Closed 10 years ago
#7499 closed Bugs (fixed)
call_once doesn't call even once
Reported by: | 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 , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Version: | Boost 1.52.0 → Boost 1.51.0 |
comment:2 by , 10 years ago
comment:3 by , 10 years ago
Milestone: | To Be Determined → Boost 1.52.0 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Committed revision [80985].
Committed in trunk revision [80966].