You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Kumar Krishnamoorthy <rk...@seamlesscms.com> on 2014/10/08 09:02:13 UTC
Exception reporting
Just reporting it because by subversion client asked me to report it :-)
[cid:image001.png@01CFE321.FCC3F3C0]
Cheers,
Kumar Krishnamoorthy
Developer
Seamless | Leaders in Government WCM
Follow us on Twitter: @seamlesscms
Phone: +613 9913 0020
E-mail: rkrishnamoorthy@seamlesscms.com
www.seamlesscms.com<http://www.seamlesscms.com>
[cid:seamless_logo9d497f]
Re: Exception reporting
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Oct 9, 2014 at 2:34 PM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
> > -----Original Message-----
> > From: Stefan Sperling [mailto:stsp@elego.de]
> > Sent: donderdag 9 oktober 2014 12:05
> > To: Branko Čibej
> > Cc: Subversion Development
> > Subject: Re: Exception reporting
> >
> > On Thu, Oct 09, 2014 at 06:53:00AM +0200, Branko Čibej 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. 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.
> > >
> > > 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.
> > >
> > > -- Brane
> > >
> >
> > I agree. I've started to ignore all reports which provide no further
> > information than the naked crash report.
>
> It isn't even a crash. It is just the static message from an assertion
> text. Crashes at least have a dump, but in this case it is a message
> without any details how anything is called.
> (Anything... perhaps even including the commandline which was used to
> start tsvnproc would add more value)
>
After reading a bit of SVN and TSVN code, I found that the problem is
caused by passing TRUE in the 'can_return' parameter of the malfunction
handler. SVN_ERR_ASSERT_NO_RETURN() will create a crash report
with all the info you want, including command line info, SVN_ERR_ASSERT
does not.
I think TSvnProc should create a crash report even for 'can_return==TRUE',
e.g. by raising some arbitrary exception and then handling. The process
will soon exit anyway and the extra risk of the crash reporting messing up
the process state is certainly outweighed by fixing the corruption issue
triggering the assertion in the first place.
-- Stefan^2.
RE: Exception reporting
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: donderdag 9 oktober 2014 12:05
> To: Branko Čibej
> Cc: Subversion Development
> Subject: Re: Exception reporting
>
> On Thu, Oct 09, 2014 at 06:53:00AM +0200, Branko Čibej 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. 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.
> >
> > 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.
> >
> > -- Brane
> >
>
> I agree. I've started to ignore all reports which provide no further
> information than the naked crash report.
It isn't even a crash. It is just the static message from an assertion text. Crashes at least have a dump, but in this case it is a message without any details how anything is called.
(Anything... perhaps even including the commandline which was used to start tsvnproc would add more value)
Bert
Re: Exception reporting
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Oct 09, 2014 at 06:53:00AM +0200, Branko Čibej 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. 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.
>
> 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.
>
> -- Brane
>
I agree. I've started to ignore all reports which provide no further
information than the naked crash report.
Re: Exception reporting
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Oct 9, 2014 at 7:04 PM, Branko Čibej <br...@wandisco.com> wrote:
> On 09.10.2014 12:32, Stefan Fuhrmann wrote:
>
> On Thu, Oct 9, 2014 at 6:53 AM, Branko Čibej <br...@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:
>
> https://drdump.com/AppVersion.aspx?ClientID=tsvn&AppVersionID=452
>
> 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 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
-- Stefan^2.
Re: Exception reporting
Posted by Branko Čibej <br...@wandisco.com>.
On 09.10.2014 12:32, Stefan Fuhrmann wrote:
> On Thu, Oct 9, 2014 at 6:53 AM, Branko Čibej <brane@wandisco.com
> <ma...@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:
>
> https://drdump.com/AppVersion.aspx?ClientID=tsvn&AppVersionID=452
>
> Sorry for sounding harsh but I'm mildly pissed off right now.
Relax. 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.
-- Brane
Re: Exception reporting
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Oct 9, 2014 at 6:53 AM, Branko Čibej <br...@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:
https://drdump.com/AppVersion.aspx?ClientID=tsvn&AppVersionID=452
Sorry for sounding harsh but I'm mildly pissed off right now.
-- Stefan^2.
Re: Exception reporting
Posted by Branko Čibej <br...@wandisco.com>.
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. 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.
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.
-- Brane
RE: Exception reporting
Posted by John Maher <Jo...@rotair.com>.
I was supposed to do a reply all to keep the thread up to date and also let others see the issue.
If you're not sure if the issue is raised already you can always search. Search is your friend.
Did you follow the recommendation from the link you posted?
What happens if you get a new working copy?
JM
From: Kumar Krishnamoorthy [mailto:rkrishnamoorthy@seamlesscms.com]
Sent: Thursday, October 09, 2014 7:30 PM
To: John Maher
Subject: RE: Exception reporting
Oops. Sorry, I was in the middle of something when I got this error, so just skimmed through the message and took and screenshot and sent it. This time I really took the time to read the message and found that it's the same error reported here.
http://stackoverflow.com/questions/23991573/subversion-reported-a-malfunction-action-svn-wc-conflict-action-delete-on-l
Only difference I see is the version number in my message in 1.8.8
Not sure if it has an issue raised already.
I was trying to checkout spring-net from GitHub using Subversion url
https://github.com/spring-projects/spring-net
But the checkout operation completed with some error. I did a cleanup and did update and that's when I got this error.
I think the real problem was in the checkout process, which might have left my local copy in a stale state.
And I should not have done an update and instead just deleted the whole repo and checkout again.
But didn't bother with it and went with git for now.
Hope that's enough information. Let me know if you need any more details.
Thanks,
Kumar Krishnamoorthy
Developer
Seamless | Leaders in Government WCM
Follow us on Twitter: @seamlesscms
Phone: +613 9913 0020
E-mail: rkrishnamoorthy@seamlesscms.com<ma...@seamlesscms.com>
www.seamlesscms.com<http://www.seamlesscms.com>
[cid:image002.png@01CFE46F.1F1B9D80]
From: John Maher [mailto:JohnM@rotair.com]
Sent: Wednesday, 8 October 2014 10:49 PM
To: Kumar Krishnamoorthy
Subject: RE: Exception reporting
HI Kumar
Thanks for reporting, however this report is useless. Graphics files are not supported in this help system so many will not even see any exception. All they will see is "Just reporting it because by subversion client asked me to report it :-)" which doesn't tell them anything.
JM
From: Kumar Krishnamoorthy [mailto:rkrishnamoorthy@seamlesscms.com]
Sent: Wednesday, October 08, 2014 3:02 AM
To: users@subversion.apache.org<ma...@subversion.apache.org>
Subject: Exception reporting
Just reporting it because by subversion client asked me to report it :-)
[cid:image003.png@01CFE46F.1F1B9D80]
Cheers,
Kumar Krishnamoorthy
Developer
Seamless | Leaders in Government WCM
Follow us on Twitter: @seamlesscms
Phone: +613 9913 0020
E-mail: rkrishnamoorthy@seamlesscms.com<ma...@seamlesscms.com>
www.seamlesscms.com<http://www.seamlesscms.com>
[cid:image002.png@01CFE46F.1F1B9D80]