Re: Thread problems with std::basic_string and GNU libstdc++
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.
Re: Thread problems with std::basic_string and GNU libstdc++
On Fri, Nov 21, 2014 at 11:27:55PM +0100, Georg Baum wrote:
Richard Heck wrote:
Yes, I understand that. But it's hard to see what relevant difference
there might be
between the document set that is causing this crash---which Georg says
in the bug
report he can produce reliably---and other large documents sets that
other people
have used frequently without producing any crash.
I think I found the relevant difference: The LaTeX preview panel needs to be
open for current paragraph with automatic update on. Otherwise it does not
crash. I uploaded a reduced, anonymized test case to trac, so I would be
curios whether anybody can reproduce the crash. If yes, I'd also like to
know the gcc version and linux distribution which was used.
I tried hard but was not able to reproduce the crash on debian wheezy
(gcc 4.7.2), cygwin (gcc 4.8.3) and solaris (gcc 4.9.0).
BTW, the test case did not compile without errors and I had to add the
following lines to the preable:
\def\citep#1{}
\def\citet#1{}
\def\citealt#1{}
--
Enrico
Re: Thread problems with std::basic_string and GNU libstdc++
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;
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.
Richard
Re: Thread problems with std::basic_string and GNU libstdc++
On 11/22/2014 10:24 AM, Enrico Forestieri wrote: On Fri, Nov 21, 2014 at 11:27:55PM +0100, Georg Baum wrote: Richard Heck wrote: Yes, I understand that. But it's hard to see what relevant difference there might be between the document set that is causing this crash---which Georg says in the bug report he can produce reliably---and other large documents sets that other people have used frequently without producing any crash. I think I found the relevant difference: The LaTeX preview panel needs to be open for current paragraph with automatic update on. Otherwise it does not crash. I uploaded a reduced, anonymized test case to trac, so I would be curios whether anybody can reproduce the crash. If yes, I'd also like to know the gcc version and linux distribution which was used. I tried hard but was not able to reproduce the crash on debian wheezy (gcc 4.7.2), cygwin (gcc 4.8.3) and solaris (gcc 4.9.0). Couldn't do it here, either, on Fedora 20. But this is a very fast machine. Richard
Re: Thread problems with std::basic_string and GNU libstdc++
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.
Re: Thread problems with std::basic_string and GNU libstdc++
On Fri, Nov 21, 2014 at 11:27:55PM +0100, Georg Baum wrote:
> Richard Heck wrote:
>
> > Yes, I understand that. But it's hard to see what relevant difference
> > there might be
> > between the document set that is causing this crash---which Georg says
> > in the bug
> > report he can produce "reliably"---and other large documents sets that
> > other people
> > have used frequently without producing any crash.
>
> I think I found the relevant difference: The LaTeX preview panel needs to be
> open for current paragraph with automatic update on. Otherwise it does not
> crash. I uploaded a reduced, anonymized test case to trac, so I would be
> curios whether anybody can reproduce the crash. If yes, I'd also like to
> know the gcc version and linux distribution which was used.
I tried hard but was not able to reproduce the crash on debian wheezy
(gcc 4.7.2), cygwin (gcc 4.8.3) and solaris (gcc 4.9.0).
BTW, the test case did not compile without errors and I had to add the
following lines to the preable:
\def\citep#1{}
\def\citet#1{}
\def\citealt#1{}
--
Enrico
Re: Thread problems with std::basic_string and GNU libstdc++
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;
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.
Richard
Re: Thread problems with std::basic_string and GNU libstdc++
On 11/22/2014 10:24 AM, Enrico Forestieri wrote: On Fri, Nov 21, 2014 at 11:27:55PM +0100, Georg Baum wrote: Richard Heck wrote: Yes, I understand that. But it's hard to see what relevant difference there might be between the document set that is causing this crash---which Georg says in the bug report he can produce "reliably"---and other large documents sets that other people have used frequently without producing any crash. I think I found the relevant difference: The LaTeX preview panel needs to be open for current paragraph with automatic update on. Otherwise it does not crash. I uploaded a reduced, anonymized test case to trac, so I would be curios whether anybody can reproduce the crash. If yes, I'd also like to know the gcc version and linux distribution which was used. I tried hard but was not able to reproduce the crash on debian wheezy (gcc 4.7.2), cygwin (gcc 4.8.3) and solaris (gcc 4.9.0). Couldn't do it here, either, on Fedora 20. But this is a very fast machine. Richard
