Return-Path: X-Original-To: apmail-subversion-dev-archive@minotaur.apache.org Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BBB5C176F5 for ; Sat, 11 Oct 2014 11:09:57 +0000 (UTC) Received: (qmail 13892 invoked by uid 500); 11 Oct 2014 11:09:57 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 13840 invoked by uid 500); 11 Oct 2014 11:09:57 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 13824 invoked by uid 99); 11 Oct 2014 11:09:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Oct 2014 11:09:57 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of stefan.fuhrmann@wandisco.com designates 209.85.213.180 as permitted sender) Received: from [209.85.213.180] (HELO mail-ig0-f180.google.com) (209.85.213.180) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Oct 2014 11:09:52 +0000 Received: by mail-ig0-f180.google.com with SMTP id uq10so5630487igb.13 for ; Sat, 11 Oct 2014 04:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wandisco.com; s=gapps; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d8nJ31Qoc/OLBSGa0I7/QZpZRStXdcLXNUHCiuJamKo=; b=oEA8CpgzyHD89lLktEj9muqahtn9k3vYvJxU6/SUSOsmGIZrupdDmgsBCyXTehXbh4 f7KPX+KUn+JYz77z33SWEWfMSMLebx4yfj+p68AWK64ttdK5jo4mTOSNOpnYiTYRxr8K up2Pas1VyALcWfh+kP6v8MTRcbOt3+W9dShiQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d8nJ31Qoc/OLBSGa0I7/QZpZRStXdcLXNUHCiuJamKo=; b=UnosNUFieVPxn8QwtvLnqv2VO5SwO4EVe70ylP7JN2rIP6asicGwscXhPQIk2A9XlX okEEp3Ek7rloK4fG5RMGsHtVULJti9sU/bOBVkmRgfuRkVwn9AdgL7tG1jgVRrDBu0u4 iodpEEPt88kQBaDIo82lZozCaKeF6HrxIm/tnfIaYxvDGgN8n+F5MqD/2O8d86UANZ7l 9h2BkKc2x9PsYe+zda4vip3gGBIG0kz1GupjZspBl2jiwxRzB7buvYkRp/Dd4dSAu9Wk nNFNONcGg5TjW0cHj+2aSwF7LMKYpFcQcFRMtCt9O2e7QT6mBr4jJKmRjgAOnysk8rUg Pg5w== X-Gm-Message-State: ALoCoQnZ+gtZFXr6/VL1mH80wKTpFQqHhgdYfRhm04KOjl7CNP49ok4NkpNuIYBXFj6ERlpCys5L MIME-Version: 1.0 X-Received: by 10.51.17.66 with SMTP id gc2mr14795917igd.40.1413025770418; Sat, 11 Oct 2014 04:09:30 -0700 (PDT) Received: by 10.50.214.101 with HTTP; Sat, 11 Oct 2014 04:09:30 -0700 (PDT) In-Reply-To: <5436C007.2090607@wandisco.com> References: <864EF393C7D75842833B30FA560DE13D1F2AA0C8@SEMAIL.seamless.local> <543614AC.2020100@wandisco.com> <5436C007.2090607@wandisco.com> Date: Sat, 11 Oct 2014 13:09:30 +0200 Message-ID: Subject: Re: Exception reporting From: Stefan Fuhrmann To: =?UTF-8?Q?Branko_=C4=8Cibej?= Cc: Subversion Development Content-Type: multipart/alternative; boundary=001a1135f3a41afb0e050523b396 X-Virus-Checked: Checked by ClamAV on apache.org --001a1135f3a41afb0e050523b396 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 9, 2014 at 7:04 PM, Branko =C4=8Cibej wrot= e: > On 09.10.2014 12:32, Stefan Fuhrmann wrote: > > On Thu, Oct 9, 2014 at 6:53 AM, Branko =C4=8Cibej w= rote: > >> 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: > > https://drdump.com/AppVersion.aspx?ClientID=3Dtsvn&AppVersionID=3D452 > > Sorry for sounding harsh but I'm mildly pissed off right now. > > > > Relax. > 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 lea= p > 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 -- Stefan^2. --001a1135f3a41afb0e050523b396 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Oct 9, 2014 at 7:04 PM, Branko =C4=8Cibej <brane@wandisco.com>= wrote:
=20 =20 =20
On 09.10.2014 12:32, Stefan Fuhrmann wrote:
On Thu, Oct 9, 2014 at 6:53 AM, Branko =C4=8Cibej <brane@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 d= o our job?!"
=C2=A0
It's confusing= and not very productive for us to get reports of crashes in Tortoise; I'm not saying these crashes "can't&= quot; 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.
=C2=A0
Not to mention tha= t 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:

https://drdump.com/AppVersion.aspx?C= lientID=3Dtsvn&AppVersionID=3D452

Sorry for sounding harsh but I'm mil= dly pissed off right now.


Relax.

I'm relaxed now ;)
=
=C2=A0
Jumping to the conclusion that I'm pissing on TSV= N 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 useassertions to detect situations that should never ever happen.
<= div class=3D"gmail_extra">So, the least we can do is to document, e.g. in t= he code, that
a certain assertion has b= een 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 th= e 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=C2=A0caused b= y SVN_ERR_ASSERT being used where it
shouldn't, some API parameter n= ot being sufficiently checked
or a plain internal logic error. All these= are bugs in SVN. It is
almost the defi= nition of malfunction that it is an internal problem
instead of something caused by external forces.

TSVN OTOH, shou= ld try to:

* include info like the = command line parameters in the message box
* treat any malfunction as worthy of a crash dump

-- Stefan^2.
--001a1135f3a41afb0e050523b396--