Re: thoughts about unwind_protect

[Jaroslav Hajek]

On Thu, Jan 7, 2010 at 3:39 PM, Marco Atzeri <address@hidden> wrote:
> --- Gio 7/1/10, Jaroslav Hajek ha scritto:
>
>> On Thu, Jan 7, 2010 at 1:59 PM,
>> Jaroslav Hajek <address@hidden>
>> wrote:
>> > On Thu, Jan 7, 2010 at 11:07 AM, Marco Atzeri <address@hidden>
>> wrote:
>> >> --- Gio 7/1/10, Jaroslav Hajek  ha scritto:
>> >>
>> >>>
>> >>> Can you clarify a little? You have Octave
>> built
>> >>> --without-framework-opengl and it crashes on
>> exit? Or the
>> >>> other way
>> >>> around?
>> >>
>> >> It is configured without opengl and without fltk.
>> >> Octave crash on exit; just only the command exit
>> is
>> >> enough for the segfault.
>> >> All the other functionality seems to work.
>> >> "Make check" pass all the tests.
>> >>
>> >> ../octave/configure --libexecdir=/usr/lib
>> --without-framework-opengl F77=gfortran-4 CXX=g++-4
>> CPP=cpp-4 CC=gcc-4 LDFLAGS=-no-undefined FLIBS=-lgfortran
>> lt_cv_deplibs_check_method=pass_all
>> >>
>> >> In the past there was a flag to disable the fltk,
>> but it seems not anymore available. However the absence is
>> detected,
>> >> and I have no fltk libs in the system to avoid
>> false detection.
>> >>
>> >
>> > Why do you think FLTK has anything to do with this?
>> Does the problem
>> > vanish if you build with FLTK?
>
> Fltk is not working on cygwin, so I am skipping it.
> Before the automake change there was a switch to disable it
> and today is not available , if I am not wrong.
>
> I don't know if fltk is involved at all, but there was a
> similar fault reported and corrected about it
> https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-December/014256.html
>

This was because __remove_fltk__ was not properly registered, I think.
I don't see how FLTK could be involved here, because you don't even
start the backend.

> Eventually there is a similar problem with another module,
> but which one ?
>
>>
>> I just tried to build without FLTK, but can't reproduce the
>> crash.
>> Valgrind doesn't show anything. I'm afraid you'll have to
>> make
>> discover the source.
>
> I already identified the changeset, it starts to SIGSEV from
> changeset 9981  692ab4eaf965
>
> "clean up top-level variables when exiting Octave"
>
> before that I have no SIGSEV.
>

OK.

>
> Any idea how to further investigate ?
>

First rule out any package involvement (I suppose you already did).
Try ./run-octave -f. Then, if nothing works,
go to symbol_table::cleanup and start commenting out *from backwards*
the individual cleanup actions, until the problem vanishes.

hth
-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz