Abdelrazak Younes wrote:
> Hi Georg,
>
> Warning: I haven't read LyX source code for a long long time :-)
This is no problem, I think the main point can be understood quite well
without code details.
> I am not questioning your reasoning but I think STL thread safety
> limitation has limited impact in our case. AFAIR, the Buffer is cloned
> in in the current and main thread so we have no race condition here.
> After that the cloned buffer shares nothing with the original Buffer and
> can thus be used safely in another thread.
Yes, this is true if you look at the involved data structures from the
outside. If you look at the internal std::basic string members in gdb after
the crash then you see that two instances which where both originally
created from the document language Language::babel_ use the same pointer to
the string data internally. This is of course no surprise if you know that
copy-on-write is used, but it also means that the two buffers are _not_
completely independant from each other. BTW, I am pretty sure that the
cloning itself works very reliably.
> I believe that there could be many reasons that could cause a crash
> before incriminating the stl string, etc:
> * Gui elements (message passing?)
> * Graphics preview elements
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).
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.
> 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.
> 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;-)
Georg
