On Thu, Oct 9, 2014 at 2:34 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
> > -----Original Message-----
> > From: Stefan Sperling [mailto:stsp_at_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.
Received on 2014-10-09 16:00:09 CEST