IRC discussion:

<caolan> https://dev-builds.libreoffice.org/crashtest/27e3ed0d25735603d2c82744e3a8f5f3e0a8d043/backtraces/task395-core.16181.backtrace.txt looks like some threading catastrophy
<vmiklos> caolan: 657413b5deea11a850970f23cba2cf34a5bdf8ea perhaps? but it's not new..
<IZBot> core - Refactor 3D renderer to use multithreading - http://cgit.freedesktop.org/libreoffice/core/commit/?id=657413b5deea11a850970f23cba2cf34a5bdf8ea
<noelgrandin> caolan, possibly somewhere in that stack is a o3tl::cow_wrapper that is not using thread-safe ref-counting
<caolan> hum, "typedef o3tl::cow_wrapper< Impl2DHomMatrix > ImplType;" while "typedef o3tl::cow_wrapper< Impl3DHomMatrix, o3tl::ThreadSafeRefCountingPolicy > ImplType;" most odd
<mst___> does 3d rendering use 2d matrices?
<thorsten> for putting pixel on the screen, not unlikely
<mst___> if we replace plain add instructions with locked add, is the multi-threaded code still faster :)
<noelgrandin> caolan, that isLastLineDefault method in ImplHomMatrixTemplate looks suspicious. Would be fairly easy there to end up working on freed memory
<caolan> sigh, dunno, not reproducing trivially
<noelgrandin> caolan, helgrind?
<noelgrandin> caolan, or rr --chaos, often good at triggering these kinds of timing issues
<caolan> never had any luck with helgrind and libreoffice
<noelgrandin> caolan, where do I get that file and what is that crash-test doing? some cloudon file?
<caolan> noelgrandin, I'll pass it on, it from cloudon's compatibility matrix collection, its just converting a .docx to .odt

Created attachment 152309 [details]
helgrind log

Created attachment 152310 [details]
backtrace

Noel's notes:

(*) Helgrind dumps lots of stuff - grep for the drawinglayer related stuff, and look for "This conflicts with " for the (IMO) more serious races. Straight read races I don't think are likely to cause crashes.

(*) the getNormal() related stuff looks benign, even if we get inconsistent data for a bit, it will get rebuilt correctly.

(*) Stuff like SdrLathePrimitive3D::get3DDecomposition is the problem - it locks before writing to the relevant fields, but not before reading, which means the read side can see inconsistent data.

(*) my command line for testing was
VALGRIND="helgrind --track-lockorders=no --gen-suppressions=all" instdir/program/soffice --convert-to odt filename.docx

Hi Noel,
Could you please attach the document to reproduce the crash ?

@X1sco the doc is private, I have forwarded the doc to thorsten - this bug is really just for thorsten

(In reply to Noel Grandin from comment #6)
> @X1sco the doc is private, I have forwarded the doc to thorsten - this bug
> is really just for thorsten

fair enough ;-)

Hi Noel, is this issue still reproducible in a master build ?

Can't find the emails relevant to this, suggest we just close it

(In reply to Noel Grandin from comment #9)
> Can't find the emails relevant to this, suggest we just close it

Let's close it then as WFM

If Thorsten or Noel think different then just reopen it. Thanks

Yeah, can't repro anymore here either