UDDF crash

Miika Turkia miika.turkia at gmail.com
Mon Nov 2 20:24:07 PST 2015


On Tue, Nov 3, 2015 at 5:53 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Mon, Nov 02, 2015 at 06:14:16PM -0800, Linus Torvalds wrote:
>> On Mon, Nov 2, 2015 at 6:03 PM, Linus Torvalds
>> <torvalds at linux-foundation.org> wrote:
>> >
>> > So something like the attached might be the right thing.  Not tested.
>>
>> Tested and seems to work.
>>
>> It looks like none of the dives actually have more than one cylinder,
>> but being UDDF, we know that the developers are insane (it's basically
>> a requirement to touch UDDF), and we have beauties like liks:
>>
>>     <mix id="gas_33">
>>       <name>33</name>
>>       <o2>0.21</o2>
>>       <n2>0.79</n2>
>>       <maximumpo2>1.4</maximumpo2>
>>     </mix>
>>
>> which is obviously just air, and all the *other* gases are the same
>> thing too (so gas_2 .. gas_289 are all air).
>
> Gas Two Hundred Eighty Nine ???

The XSLT grabs all the gases for all the dives, so we end up with
quite a few cylinders in total.

> But no, it's not ALL of them air. There are beauties like this hidden in
> there as well:
>
>     <mix id="gas_87">
>       <name>87</name>
>       <o2>0.34</o2>
>       <n2>0.659999967</n2>
>       <maximumpo2>1.6</maximumpo2>
>     </mix>
>
> Which is a rather useful way of defining EAN34 I guess.

It looks like there are a couple of ways used to define cylinders in
different sources of UDDF files. And when I added support for Xdeep,
we ended up with the massive amount of cylinders for something else...

>> Christ. I didn't look at what actually triggered the "lots of gases
>> for a single dive" though. There's only so long I can stand staring at
>> UDDF.
>>
>> Let me re-iterate my undying love for UDDF one more time.
>
> A shared feeling. Having talked to Nick about the amazing beauty that is
> the DAN format I understand that there is another circle of hell beyond
> where UDDF itself can take us...
>
>> Looking (carefully - wouldn't want to go blind) at the UDDF, I see things like
>>
>>           <waypoint>
>>             <depth>0</depth>
>>             <divetime>0</divetime>
>>             <switchmix ref="gas_25" />
>>             <temperature>296.05</temperature>
>>           </waypoint>
>>
>> but there seems to be only one per dive (the divetime is always zero).
>> So I'm not quite sure what makes us overflow the cylinder thing. The
>> xslt translation from uddf to the native subsurface format may be
>> doing something odd.
>
> Always a possibility. But this sounds like it's just picking the starting
> gas. Using grep (much safer than actually opening the file in an editor)
> it appears that not a single dive has an actual gas switch in it. So we
> should never have run out of cylinders.
>
> So yes, I think there's a bug in our uddf parsing. Miika?

Patch attached. I just didn't send it out yesterday, as there was
still something wrong with importing directly to Subsurface. (I
probably run out of memory.) But if the cylinder index is already
fixed, I suppose this issue should be pretty much covered when
attached patch is included.

>> So I think that xml parsing patch is worth applying regardless, but I
>> also get the feeling that there might be something else going on in
>> addition to this.

I would not be surprised, if there was still something more lurking around...

miika
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Grab-all-gas-mixes-only-when-no-tank-data-is-given.patch
Type: text/x-patch
Size: 1316 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20151103/3f8bc25a/attachment-0001.bin>


More information about the subsurface mailing list