On 22/11/2014 23:01, Richard Heck wrote:
On 11/22/2014 03:19 AM, Abdelrazak Younes wrote:
On 20/11/2014 21:04, Georg Baum wrote:
I don't think so in this case. The crash happens because internal
std::basic_string members are corrupt, and it is almost always a string
created from Language::babel_. Furthermore, I was not able to
reproduce the
crash after changing
std::string const & babel() const { return babel_; }
to
std::string const babel() const { return babel_.c_str(); }
in Language.h (which circumvents copy-on-write).
Hum, well, maybe Language object is shared between the buffer clones?
In BufferParams.h:
///
Language const * language;
Ahah...
That could well explain the issue... babel_ is accessed at the same
time between 2 threads which creates a race condition.
So my solution would be to protect the Language object through a mutex.
If I am right then this crash is due to a flow in our design, not in
the STL string.
I'm not as well informed as you and others about these sorts of
issues. Why would
simply having two threads reading the babel_ string at the same time
cause this sort
of problem? We shouldn't have write access to the language object from
the Buffer.
This string might be modified by some class in main thread while being
read at the same time by a buffer clone in the export thread. If the
memory reserved by basic-string is big enough we should be fine but if
not basic_string will allocate another chunk of memory and delete
previously used one. So, if this is really the culprit, 2 choices:
1) easy one: reserve some memory for babel_ in Langage ctor
(basic_string::reserve() should exist).
2) protect babel_ with a mutex.
In any case, one should audit this Language class for thread safety.
Same thing for BufferParams if this is shared between buffers.
Abdel.
