Segfault

[Dirk Hohndel]

Jef Driesen <jefdriesen at telenet.be> writes:
>>>
>>> In the first case (bt1.log), I created a new file, and downloaded data
>>> from a dive computer. Right after the download finishes, I hit the
>>> segfault. For the second case (bt2.log), I started subsurface with the
>>> command "./subsurface dives/*.xml". When selecting some dives in the
>>> treeview, a segfault again.
>>>
>>> I can reproduce these segfaults every time.
>>>
>>> Jef#0  __strlen_sse2_pminub () at ../sysdeps/x86_64/multiarch/strlen-sse2-pminub.S:39
>>> #1  0x00007ffff61422d2 in g_strdup () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
>>
>> Since the code in set_one_cylinder explicitly tests that we don't pass
>> in a NULL for description and that's the only string involved here, my
>> only guess would be that you are passing in a completely bogus but
>> non-NULL pointer.
>>
>> I just don't see how that could happen...
>>
>> Can you set a breakpoint in set_one_cylinder and take a look at what's
>> in cyl ?
>
> The description field contains a bogus pointer (0x2300000006e). Smells like 
> memory corruption. I have the impression the dive pointer might have been freed 
> already, because also other pointers are out of bounds:
>
> (gdb) p dive->suit
> $8 = 0xbb00000000 <Address 0xbb00000000 out of bounds>
> (gdb) p dive->dc.model
> $9 = 0x54ed0001013a <Address 0x54ed0001013a out of bounds>

Beautiful. Do you have Valgrind installed? That's usually the best to
catch issues like this.

Or do you have a way to reproduce this that does NOT require a
divecomputer download? Then I can look into this here. I tried what you
described in the text above for the second case and wasn't able to get
it to SIGSEGV...

/D