[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: thoughts about unwind_protect
From: |
Marco Atzeri |
Subject: |
Re: thoughts about unwind_protect |
Date: |
Thu, 7 Jan 2010 20:37:22 +0000 (GMT) |
--- Gio 7/1/10, Jaroslav Hajek <address@hidden> ha scritto:
> 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
unfortunately removing fcn_table.clear () alone
doesn't work also. so it seems an interaction between
fcn_table.clear and the following actions.
I will need some time to follow your suggestion.
Marco
- Re: thoughts about unwind_protect, (continued)
- Re: thoughts about unwind_protect, Marco Atzeri, 2010/01/07
- Re: thoughts about unwind_protect, Jaroslav Hajek, 2010/01/07
- Re: thoughts about unwind_protect, Marco Atzeri, 2010/01/07
- Re: thoughts about unwind_protect, Jaroslav Hajek, 2010/01/07
- Re: thoughts about unwind_protect, Jaroslav Hajek, 2010/01/07
- Re: thoughts about unwind_protect, Marco Atzeri, 2010/01/07
- Re: thoughts about unwind_protect, Jaroslav Hajek, 2010/01/07
- Re: thoughts about unwind_protect, Marco Atzeri, 2010/01/07
- Re: thoughts about unwind_protect, John W. Eaton, 2010/01/07
- Re: thoughts about unwind_protect, Jaroslav Hajek, 2010/01/07
- Re: thoughts about unwind_protect,
Marco Atzeri <=
- Re: thoughts about unwind_protect, John W. Eaton, 2010/01/21
- Re: thoughts about unwind_protect, Jaroslav Hajek, 2010/01/22