Fine. At least we have the machinery in place for developers to
locally and easily get stack traces from failed assertions. I still
feel more comfortable with code that checks for specific error
conditions, not "did this thing give me any error?".
Though I do seem to recall somebody in IRC a few days ago stating that
we could replace the abort handler with something that returns an
error, so this idea isn't complete crazy.
-Hyrum
On Apr 17, 2009, at 2:00 PM, Greg Stein wrote:
> What?! There are a number of situations of "let's try <this>. oh,
> oops. okay... let's move on." Errors get cleared. Count the number of
> scn_error_clear() calls. Are you *sure* that your change will *tell
> me* when an assertion fails?
>
> I believe this change will chew up and throw out assertions that
> otherwise would have produced a core dump.
>
> Further, with that core dump in hand, I can go in and analyze the
> values which caused the assertion.
>
> And, lastly... the name of the function is
> svn_error_ABORT_on_malfunction(). [emphasis mine]
>
> Cheers,
> -g
>
> On Fri, Apr 17, 2009 at 20:55, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> I dunno. I'd prefer a nice stack trace, rather than having to get
>> the core
>> file, fire up the debugger, etc. Hopefully anybody that's catching
>> the
>> error is also checking the error code to make sure they propagate
>> unexpected
>> errors back up the stack. (And if you aren't: shame on you, you
>> get what
>> you asked for.)
>>
>> -Hyrum
>>
>> On Apr 17, 2009, at 1:51 PM, Greg Stein wrote:
>>
>>> Euh... this isn't gonna work. Somebody might catch the error. I'd
>>> prefer a core dump over a caught-and-cleared error.
>>>
>>> On Fri, Apr 17, 2009 at 20:33, Hyrum K. Wright <hyrum_at_hyrumwright.org
>>> >
>>> wrote:
>>>>
>>>> Author: hwright
>>>> Date: Fri Apr 17 11:33:41 2009
>>>> New Revision: 37336
>>>>
>>>> Log:
>>>> If we've enabled stack tracing, use it when we encounter an
>>>> abort().
>>>>
>>>> * subversion/libsvn_subr/error.c
>>>> (svn_error_abort_on_malfunction): If tracing is enabled, wrap and
>>>> return the error, so we can get a stack trace of the abort
>>>> failure.
>>>>
>>>> Modified:
>>>> trunk/subversion/libsvn_subr/error.c
>>>>
>>>> Modified: trunk/subversion/libsvn_subr/error.c
>>>> URL:
>>>> http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_subr/error.c?pathrev=37336&r1=37335&r2=37336
>>>>
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> ===================================================================
>>>> --- trunk/subversion/libsvn_subr/error.c Fri Apr 17
>>>> 11:31:36 2009
>>>> (r37335)
>>>> +++ trunk/subversion/libsvn_subr/error.c Fri Apr 17
>>>> 11:33:41 2009
>>>> (r37336)
>>>> @@ -541,11 +541,16 @@ svn_error_abort_on_malfunction(svn_boole
>>>> const char *file, int line,
>>>> const char *expr)
>>>> {
>>>> +#ifndef SVN_ERR__TRACING
>>>> svn_error_t *err = svn_error_raise_on_malfunction(TRUE, file,
>>>> line,
>>>> expr);
>>>>
>>>> svn_handle_error2(err, stderr, FALSE, "svn: ");
>>>> abort();
>>>> return err; /* Not reached. */
>>>> +#else
>>>> + return svn_error_return(svn_error_raise_on_malfunction(TRUE,
>>>> file,
>>>> + line,
>>>> expr));
>>>> +#endif
>>>> }
>>>>
>>>> /* The current handler for reporting malfunctions, and its default
>>>> setting. */
>>>>
>>>> ------------------------------------------------------
>>>>
>>>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=495&dsMessageId=1772419
>>>>
>>>
>>> ------------------------------------------------------
>>>
>>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1772710
>>
>>
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1772836
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1773278
Received on 2009-04-17 21:21:26 CEST