On 09/06/2012 12:46 PM, Stefan Teleman wrote:
On Thu, Sep 6, 2012 at 12:16 PM, Martin Sebor<[email protected]> wrote:
This locks a different mutex, one unrelated to __rw_facet::_C_mutex.
Let's debug this the good-ol' fashioned way: with fprintf(3C). Let's
print the addresses of the mutex being locked in various places, and
see what we get:
...
grouping: _RWSTD_MT_GUARD (__self->_C_mutex): 0xf774913c
_C_get_data: _RWSTD_MT_GUARD (&_C_mutex): 0xf774913c
[ ... deadlock ... ]
Looks like the same mutex to me ...
These two are the same. The one you pointed to before
(__rw_facet::_C_manage at line 366) is a different one.
Now that we know what's causing the deadlock (and that
we can't use the same mutex in the inline function),
let's see if we can fix it in __rw_get_numpunct()
(and __rw_get_moneypunct()).
Here's a thought: it's not pretty but how about having
the function initialize the facet? It already has a pointer
to the base class, so it could downcast it to std::numpunct
(or moneypunct, respectively), and assign the initial values
to the members. Would that work?
Martin
