Test Planner crash

Lubomir I. Ivanov neolit123 at gmail.com
Mon Jan 7 08:41:50 PST 2013


On 7 January 2013 18:07, Dirk Hohndel <dirk at hohndel.org> wrote:
> Henrik Brautaset Aronsen <subsurface at henrik.synth.no> writes:
>
>> Lubomir I. Ivanov wrote:
>>> On 7 January 2013 13:54, Henrik Brautaset Aronsen
>>> <subsurface at henrik.synth.no>  wrote:
>>>> If I start Subsurface with dives/*xml and select Test Planner, it freezes.
>>>> Some kind of eternal loop?
>>>>
>>>
>>> i can't reproduce the *.xml loop issue, but the other one is related
>>> to test code.
>>> it assumes that there are dives already, so that the plan dive is
>>> added after all of them.
>>> this shouldn't be a problem later on.
>>
>> Even with only dives/test0.xml loaded it loops around these lines, with
>> the same values over and over (according to gdb):
>

with only test0.xml imported and then doing is "test plan" i'm getting a:

0x0000000000442bfe in restore_deco_state (data=0x1 <Address 0x1 out of bounds>)
    at deco.c:254
254		memcpy(tissue_n2_sat, data, TISSUE_ARRAY_SZ);
(gdb) bt
#0  0x0000000000442bfe in restore_deco_state (
    data=0x1 <Address 0x1 out of bounds>) at deco.c:254
#1  0x0000000000443138 in tissue_at_end (dive=0x998c40,
    cached_datap=0x7fffffffcfa0) at planner.c:24
#2  0x0000000000443ade in plan (diveplan=0x7fffffffcf80,
    cached_datap=0x7fffffffcfa0, divep=0x7fffffffcf98) at planner.c:245
#3  0x0000000000443e4f in test_planner () at planner.c:291
#4  0x0000000000434afd in test_planner_cb (w=0x767180, data=0x0)
    at gtk-gui.c:1130

on ubuntu, which i think is due to using addresses of stack memory when calling:
plan(&diveplan, &cache_data, &dive);

where cache_data is declared as:
char *cache_data;

but stack frame may not exist after the test_planner() return.
x86 gdb & x64 windows 7 have no idea whats going on, as this is
technically undefined behavior and i get a infinite loop, but cannot
catch it well as it ends up in system libraries. :\

lubomir
--


More information about the subsurface mailing list