This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Patch: catch_errors() cleanup chain restore


Elena Zannoni wrote:
> 
> Andrew Cagney writes:
>
>  > A subsequent call to quit() would land GDB in the middle of (3) a popped
>  > stack :-(
>  >
>  > Can anyone confirm this?
>  >
> 
> It seems right. That's a bug.

Ok.  So something needs to be done to catch_errors() +
return_to_top_level() so that they correctly unwind the stack.  I can
(just) live with GDB occasionally leaking memory, I'm not so keen on GDB
jumping into no where :-)

This makes me think that the catch_errors() and return_to_top_level()'s
current unhealthy obsession with those error_return and quit_return
buffers should be cured.  I think all that catch_errors needs to do is:

	o	save the old jumpbuf *ONCE*

	o	if (setjmp (globalbuf) == 0)
		   call func()

	o	restore old state

	o	if failure
		  and not caught here, rethrow

I think this would fix both unwind bugs (bad jmpbuf and cleanups).

BTW, as far as I can tell the FIXME comment I made is still true -
fixing the problem involves examining every catch_errors call :-(


--

Elena wrote:
> I would prefer if this patch wasn't applied as is, we can solve Nick's
> immediate problem by adding another catch_errors(..RETURN_MASK_QUIT)
> call on top of the original catch_errors(..RETURN_MASK_ALL) where the
> problem occurred, and do something meaningful with the return values.

True, but it might be better addressed with a better interface into
catch_errors() one that returns exactly what happened.

> [BTW, for the curious, this is in a (the?) call to
> print_only_stack_frame_stub()]

Hm, yes.  Hmm, that function returns ``0'' :-(

Nick, do you need to differentiate between error and quit or just an
exception and success?


--


One thing to consider (to drag out an old bug bear of mine) I think a
second interface into the catch errors mechanism should be considered. 
Something like (random guess)

	enum new_catch_rc { RC_CATCH_OK = 1, RC_CATCH_ERROR, RC_CATCH_QUIT,
RC_CATCH_INTERNAL };
	typedef void catch_ftype (void *args
	enum new_catch_rc new_catch (catch_ftype *func, void*args, ....);

the things I'm trying to address being:

	o	the catch function returns an indication of what
		was caught.

	o	the function being wrapped can't return anything
		(except via the args buffer).  The current
		problem of both func() and catch errors() returning
		zero can be avoided.

I'm suggesting this as, while doing some of the MI code, I found the
constant need to identify exactly what class of error had occured.

--



	Andrew

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]