On Thu, Oct 9, 2014 at 7:04 PM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 09.10.2014 12:32, Stefan Fuhrmann wrote:
> On Thu, Oct 9, 2014 at 6:53 AM, Branko Čibej <brane_at_wandisco.com> wrote:
>> On 08.10.2014 09:02, Kumar Krishnamoorthy wrote:
>> Just reporting it because by subversion client asked me to report it :-)
>> I'm beginning to wonder if we should ask the TSVN devs to field these
>> crash reports.
> Maybe it would have been helpful to cite the actual error message.
> "It" has been an assert()ion in libsvn_wc/update_editor.c. Assuming
> the compiler did not break the code, this is *always* a library problem.
> So, right now you are standing in a group of 10 and you shout to
> the guy across the street: "Hey, I wonder if you could do our job?!"
>> It's confusing and not very productive for us to get reports of crashes
>> in Tortoise; I'm not saying these crashes "can't" have been caused by
>> Subversion bugs, but it's IMO more efficient to the TSVN devs to do the
>> initial triage and only forward actual bugs here.
> That is what is happening already. For many years, TSVN had to
> deal with generic SVN issues (server config etc.) as some kind
> of first level support. As a result, SVN internal issues now represent
> themselves to the user as SVN problems instead of generic "TSVN
> failed" messages.
>> Not to mention that it turns out that our Windows crash reporting hack
>> is moderately useless, because it doesn't give the report enough context to
>> do anything useful with the report.
> Too bad for SVN. You are probably aware that TSVN's crash reporting
> is excellent and provides the triage that you have been asking for.
> Here is are the 10,033 crashes reported for 1.8.8:
> Sorry for sounding harsh but I'm mildly pissed off right now.
I'm relaxed now ;)
> Jumping to the conclusion that I'm pissing on TSVN devs just because I
> said that these crash reports have zero value for us is rather a huge leap
> in the wrong direction.
And I strongly disagree about the "zero value" part. We use
assertions to detect situations that should never ever happen.
So, the least we can do is to document, e.g. in the code, that
a certain assertion has been observed failing "in the wild".
People then know that there is broken logic in the respective
functionality, probably caused by incomplete data verification
and triggered by e.g. a corrupted working copy. All of that is
useful information, IMO.
In the report at hand, the given information was enough to
actually identify the problem (not the cause, though).
I also strongly disagree with the part where you said that these
crashes *might* have been caused by a bug in SVN. They are
either caused by SVN_ERR_ASSERT being used where it
shouldn't, some API parameter not being sufficiently checked
or a plain internal logic error. All these are bugs in SVN. It is
almost the definition of malfunction that it is an internal problem
instead of something caused by external forces.
TSVN OTOH, should try to:
* include info like the command line parameters in the message box
* treat any malfunction as worthy of a crash dump
Received on 2014-10-11 13:09:59 CEST