octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: thoughts about unwind_protect


From: Jaroslav Hajek
Subject: Re: thoughts about unwind_protect
Date: Thu, 7 Jan 2010 21:07:39 +0100

On Thu, Jan 7, 2010 at 7:03 PM, Marco Atzeri <address@hidden> wrote:
> --- Gio 7/1/10, Jaroslav Hajek  ha scritto:
>
>>
>> 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.
>
>
>
> It vanishes on fcn_table.clear .
> Starting from the bottom I almost hit the top ;-(
>
> void symbol_table::cleanup (void)
> {
>  // Clear variables in top scope.
>  all_instances[xtop_scope]->clear_variables ();
>
> /* DISABLED
>  // Clear function table. This is a hard clear, ignoring mlocked functions.
>  fcn_table.clear ();
>
>  // Clear variables in global scope.
>  // FIXME: are there any?
>  all_instances[xglobal_scope]->clear_variables ();
>
>  // Clear global variables.
>  global_table.clear ();
>
>  // Delete all possibly remaining scopes.
>  for (all_instances_iterator iter = all_instances.begin ();
>       iter != all_instances.end (); iter++)
>    {
>      scope_id scope = iter->first;
>      if (scope != xglobal_scope && scope != xtop_scope)
>        scope_id_cache::free (scope);
>
>      // First zero the table entry to avoid possible duplicate delete.
>      symbol_table *inst = iter->second;
>      iter->second = 0;
>
>      // Now delete the scope. Note that there may be side effects, such as
>      // deleting other scopes.
>      delete inst;
>    }
> */
> }
>
>
>> hth
>> --
>> RNDr. Jaroslav Hajek, PhD
>>
>
> next step ?
> Marco
>

Besides John's suggestion, you should also try whether the
fcn_table.clear () itself crashes or if the crash occurs later, by
putting some debug print statements after it, like:

fcn_table.clear ();
std::cerr << "got to line " << __LINE << '\n';


or use a debugger, but those can often spoil the crash. In the former
case, the way forward is clear; substitute the clear() with a loop
that will clear one element at a time, along with printing its name,
to discover which function triggers the crash when cleared.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]