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