UDDF crash

[Dirk Hohndel]

On Tue, Nov 03, 2015 at 12:38:01AM +0200, Lubomir I. Ivanov wrote:
> On 2 November 2015 at 15:54, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> > a user has posted a UDDF file that crashes subsurface:
> > http://trac.subsurface-divelog.org/ticket/958#comment:4
> >
> > i'm getting high ram and CPU usage, possibly due to an infinite loop
> > on both Windows (latest 4.5.1) and Ubuntu (4.5.0 appImage).
> >
> 
> small report there,
> 
> so this is a nasty one...and the debugging it is difficult because of
> the massive file size.
> 
> the crash is kind of different every time which suggests memory corruption.
> the XSLT stage passes and produces a 10MB XML ouput out of the 25MB
> UDDF input that the user provided.
> 
> but then it either:
> - loads fine but then hangs if i do Renumber for some reason??
> - faults in parse-xml.c:traverse() after short parsing near a
> "cylinder" entry (there are a lot of those)
> - faults quickly in parse-xml.c:sample_start() with a SIGSEGV because
> prepare_sample() returns NULL.
> 
> observations:
> - i do see some <sample time="" depth="NaN m"/> entries in the output
> XML, but those doesn't seem to matter much for the crashes if i remove
> them.
> - there are some weird "Mylinder" tags in the XML. those can't be right...
> - if it loads fine and i do a "Save", the file is now valid and loads each time
> 
> overall, this seems like a bug in our code - e.g. a corner case is not
> handled somewhere.
> 
> i'm CCing Miika, so that he can check if the input has something which
> we don't handle in the XSLT transform.

That screams like something valgrind could help with.
IIRC valgrind becomes semi useful if you disable most of the optional
parts of Subsurface (FB, User Manual, Printing, Marble, I seem to
remember). And none of those should have anything to do with the crash /
memory corruption.

Have you considered that? And yes, I realize it's past midnight for you,
so I'm mostly sending this out as a starting point for tomorrow, unless I
find time to work on this with looks not all that likely.

/D