Eric Gillespie wrote:
> "David Glasser" <glasser_at_davidglasser.net> writes:
>
>
>> On Tue, Jun 17, 2008 at 2:38 PM, Eric Gillespie <epg_at_pretzelnet.org> wrote:
>>
>>> "David Glasser" <glasser_at_davidglasser.net> writes:
>>>
>>>
>>>> I still do agree with Stefan that we should make it easy for people
>>>> providing binaries of Subversion integrated into something like the
>>>> Windows Explorer to re-bind assert/abort to something more
>>>> appropriate.
>>>>
>>> Don't forget bindings. And having one svn installation for
>>> svn(1) and one for bindings is a no-go. It's sad enough you have
>>> to do that on Windows.
>>>
>> I've appreciated having the right breakpoint for gdb in bindings as well.
>>
>
> But "the right breakpoint" is the line of Python where you
> mis-call svn.wc.adm_retrieve, not in C (or gdb) at all.
>
> Anyway, it should not be too difficult to expand svn_error_t to
> have an apr_array to which SVN_ERR appends __FILE__ and __LINE__.
> And the svn_error_ calls that wrap an svn_error_t can easily copy
> that field over. I tried to entice Hyrum to implement this some
> time last year, but of course he's as busy as (or busier than :)
> so... :)
>
> Then, in C, you could have a traceback, and in Python the
> traceback can include both C and Python code.
>
Hmm. This array idea is not the same as a stack trace, since you can
practically never guarantee that it's complete. The right way to do
this, imho, is to add crash handlers and/or use debuggers.
But there is another option: we can have an svn_error_* function that
you can call (in single threaded mode) at application startup that sets
a write-once flag; then svn_error_assert can check that flag and, if
it's set, trap to a system-specific debug breakpoint. The command-line
client could, for example, have a runtime option to turn on debug traps.
On second though, this flag wouldn't even have to be write-once; it
wouldn't really hurt to change it even in a multi-threaded client,
because the probability of one threads hitting that line of code in
svn_error_assert at the same time as another is changing the flag's
value is too remote to be a real concern.
In the end, of course, it would always be nicer to do everything in
Python, where you can catch an AssertionError ...
-- Brane
---------------------------------------------------------------------
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-18 01:55:01 CEST