Philip Martin wrote:
>>Heureka! (well, kind of ;) )
>>
>>I just received another crashreport, but this time the user actually
>>could provide additional information:
>> >Some additional notes on that matter:
>> >
>> >There was some process blocking the .svn/tmp directory!
>> >(The system refused to delete it as "it's in use")
>
>
> I don't know what that means. Could it happen if some process has a
> file open in .svn/tmp (the temporary file used to push data at neon
> perhaps)? Anyway, status doesn't try to delete .svn/tmp although it
> does create files there. Would "blocking" prevent file creation?
This kind of locked files/directories happens on windows a lot with
certain virus scanners. Some of those are really stupid and just open
files exclusively and therefore prevent the owner app from accessing its
own files.
>>Hope this helps to figure out why to check there for NULL (or do some
>>checks before).
>
>
> Status creates files in .svn/tmp directory to communicate over ra_dav,
> and when doing keyword/eol conversions. I don't see how failure to do
> either of these could causing the crash.
>
> Just had another thought: I wonder if this problem occurs when a
> Subversion thread/process is actively modifying the working copy while
> another thread/process runs status? Getting information from the
> users who experience the problem would help, but you said earlier that
> you gets lots of reports and yet we still don't know what the working
> copy looks like when it occurs. Should we give up attempting to
> understand the problem and apply the "fix"?
The problem with those crashreports is that they're automatically
generated by TSVN's crashrpt dll and then the user just has to press
"send" in their email client. They _could_ add a description of what
they were doing, but most of them don't (even though the crash report
dialog asks them to). And as I had to learn is that many of the users
who send in such reports don't use a real email address which I could
reply to and ask more questions. I guess they're afraid of SPAM...
About how often I get those crashreports: At least one a week, sometimes
two. But not more. Now, considering the user base of TSVN that might not
be a lot, but since that crash location is the reason for the report in
80% of all reports I get I'm kinda getting annoyed.
So yes, I'd like to have the 'fix' applied, or at least insert an
assert() there (the changes to the build generator do get merged back to
1.1.2, do they?). Even better: add the check to avoid the crash but
return an svn_error_t structure with an error text like "Please contact
the dev list that you're hitting a problem which isn't fully solved yet.
Be prepared for the devs to ask you many questions about that.
Contacting the dev list will help us improve Subversion. Problem number
xxxxx".
This kind of error could be used everywhere a crash occurs but it's not
fully understood why it happens.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 23 18:25:09 2004