stack trace for bug #755

[Lubomir I. Ivanov]

On 11 November 2014 15:45, Miika Turkia <miika.turkia at gmail.com> wrote:
> #0  strlen () at ../sysdeps/x86_64/strlen.S:106
> #1  0x00007ffff20b523e in __GI___strdup (s=0x0) at strdup.c:41
> #2  0x00000000004982e8 in MainTab::acceptChanges (this=this at entry=0x936320) at ../qt-ui/maintab.cpp:698

to me it looks like the stacktrace suggests displayedTrip.location is
NULL when it reaches strdup().

if (!same_string(displayedTrip.notes, currentTrip->notes)) {
currentTrip->notes = strdup(displayedTrip.notes);
mark_divelist_changed(true);
}
if (!same_string(displayedTrip.location, currentTrip->location)) {
currentTrip->location = strdup(displayedTrip.location);
mark_divelist_changed(true);
}

^ i don't think this code is reliable because same_string() -> false
would still pass even if one of the strings is NULL, but not sure if
that should ever happen.

but if does, entering the branches:
currentTrip->notes = strdup(displayedTrip.notes);
..
currentTrip->location = strdup(displayedTrip.location);

will surely SIGSEGV for most c libs.

> I do not have my trac password with me so I cannot comment on the actual bug
> report. But here is a stack trace from current master version of Subsurface
> (Ubuntu 14.10 as in the bug report).
>
>
> Reproduction steps:
> - start new divelog
> - import dives/test0.xml-test38.xml
> - select the trip on top of the divelist
> - edit notes
> - save

(current master, win32)

strangely the above doesn't produce a crash for me - editing both
location and notes, then saving:

but i think i found another one:
> - start new divelog
> - import dives/test0.xml-test38.xml
- select first dive in the trip
- select second dive in the trip (dive #35?)

it enters an infinite loop allocating 3MB per second while frozen.

lubomir
--