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?
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 also did tests with valgrind. memcheck reported an unrelated error in
LaTeX log file parsing which I fixed, and helgrind pointed at
std::basic_string (see log in trac). I am not 100% sure if the helgrind log
does not contain false positives, but it does at least not contain any hints
to other causes of the problem.
For me the fact that this is all related to the Latex exports means that
the latex export functions are not thread safe and we should work on that.
Why not compile with c++11 option? I guess basic_string won't do
copy-on-write if compiled this way?
Because the GNU libstdc++ is not conformant in this aspect: It uses copy-on-
write even with C++11.
Hum, I thought libstc++ was mostly about iostream and basic_stream is
coded all in template header?
Well, IIRC I developed buffer cloning and initial threaded export using
Linux :-)
Maybe Peter Kuemmel continued the work under Windows but I don't think
so...
Sorry, then my memory was wrong. I thought that Vincent developed this.
BTW, I would love to be proven wrong, because I find this issue rather
scary, but up to now I did not find any convincing argument, so please try
harder;-)
I tried ;-)
Abdel.
