On 6/13/08, steveking <tortoisesvn_at_gmail.com> wrote:
> David Glasser wrote:
>
> > I do think that there is value in having a way of assert/aborting from
> > anywhere in the code (not just svn_error_t-returning functions) which
> > can't be ignored accidentally by forgetting to write SVN_ERR and
> > friends. Additionally, assert/abort generally gives good stack traces
> > when run in gdb, whereas it's trickier to track down the source of our
> > error objects.
> >
>
> I don't know how gdb works. I'm just wondering why an assert/abort helps in
> getting a better stacktrace?
> In windows, if an application causes a segfault, the default windows error
> report dialog shows up and if a debugger is installed on the system, it
> gives you the choice to attach the segfaulting process to that debugger. An
> assert (or worse, an abort) doesn't cause a segfault but only shows a
> messagebox with some pretty useless text (something like "the application
> caused the runtime to close unexpectedly") and no chance of attaching a
> debugger.
On *nix, with gdb, both a segfault and an abort() look very much alike
and both have the effect of ending up in the debugger as you describe.
If you have core dumping turned on, you can even -post-mortem- get a
stack trace to the point of the abort()/assert.
> So for me, the much better way is still to just segfault instead of
> aborting. Of course, even better: returning an error indicating what exactly
> is wrong.
Wouldn't it be more usefull for you to - on Windows - force a segfault
when we in fact really meant an abort/assert()?
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-13 20:33:13 CEST