Opened 11 years ago
Last modified 8 years ago
#5638 assigned Bugs
greg_month::get_month_map_ptr is not thread safe
| Reported by: | Owned by: | az_sw_dude | |
|---|---|---|---|
| Milestone: | To Be Determined | Component: | date_time |
| Version: | Boost 1.46.1 | Severity: | Showstopper |
| Keywords: | Cc: |
Description
We recently have found a crash issue related to this function in greg_month.cpp.
the block from line 39 is not thread safe. If multiple threads call this function simultaneously, it will lead to a crash. As one thread is populating the map while the other thread may start using the map, or even worse two threads populate the map at the same time.
Change History (8)
comment:1 by , 11 years ago
| Component: | None → date_time |
|---|---|
| Owner: | set to |
comment:2 by , 11 years ago
comment:3 by , 11 years ago
It's neem 5 months... has this been fixed, because this is happening to me 100% of the time, two threads trying to populate the map!... is there anyway we can put a wait in somewhere, or force it to run on 1 thread?
comment:4 by , 10 years ago
Sorry, please realize that if you want fast support you need to either modify the code yourself or pay someone. Sorry, but just because I wrote the library doesn't mean it's my highest priority to maintain it.
My suggestion would be to ignore the library and use the all inline i/o as represented in the facet i/o -- then this map is never needed at all. This will eventually be fixed by removing the map altogether and making the entire library inline once and for all.
comment:5 by , 10 years ago
| Status: | new → assigned |
|---|
Solution is to remove support for legacy i/o solution that makes there actually be a library as part of date-time.
comment:6 by , 10 years ago
An alternate solution would be to, in your startup code call greg_month::get_month_map_ptr yourself.
This would populate the map, and then you never have to worry about it getting changed again.
It's been six weeks. is anyone looking at this?