> On Aug 14, 2020, at 12:20 PM, Salvador Cuñat <[email protected]> wrote:
>> That's frustrating and shouldn't happen. But the meta data on the cloud
>> server
>> show me that Manfred successfully stored data in the cloud from a Windows
>> machine earlier today - so I'm not sure that statement is correct, either.
>>
> I've finally been able to sync Manfred's cloud log in my laptop and
> reproduce the segfault.
> This is the backtrace I'm getting:
>
> Thread 1 "subsurface" received signal SIGSEGV, Segmentation fault.
> event_renumber (mapping=0x5555592a3400, ev=0x55555906a9b0) at
> /home/boret/src/subsurface/core/dive.c:2139
> 2139 ev->gas.index = mapping[ev->gas.index];
> (gdb) bt
>
> #0 event_renumber (mapping=0x5555592a3400, ev=0x55555906a9b0) at
> /home/boret/src/subsurface/core/dive.c:2139
> #1 event_renumber (mapping=0x5555592a3400, ev=0x55555906a9b0) at
> /home/boret/src/subsurface/core/dive.c:2133
So we are merging dives and are renumbering cylinders, and then things go
kaboom here:
static void event_renumber(struct event *ev, const int mapping[])
{
if (!event_is_gaschange(ev))
return;
if (ev->gas.index < 0)
return;
ev->gas.index = mapping[ev->gas.index];
}
Line 2139 is that last assignment.
Since you are compiling from source, Salvador, could you insert an fprintf
there that prints out the value of and ev->gas.index ?
My guess is that that's a bogus value and we are accessing memory we should
access here.
Linus, any other guesses?
/D_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
