SteveKing <steveking@gmx.ch> writes:
> kfogel@collab.net wrote:
>
>> SteveKing <steveking@gmx.ch> writes:
>>
>>> During the last two days, I received four crashreports from TSVN
>>> users. The crashreport showed a crash (EXCEPTION_ACCESS_VIOLATION) in
>>> libsvn_wc/status.c line 978. (Always referring to the 1.1.1 tag!)
>>>
>>> The lines in question:
>>> if (parent_status
>>> && (parent_status->text_status != svn_wc_status_unversioned)
>>> && (parent_status->text_status != svn_wc_status_deleted)
>>> && (parent_status->text_status != svn_wc_status_missing)
>>> && (parent_status->text_status != svn_wc_status_obstructed)
>>> && (parent_status->entry->kind == svn_node_dir)
>>> && (eb->descend || (! pb)))
>>> {
>>>
>>> Please check the second last line here:
>>> && (parent_status->entry->kind == svn_node_dir)
>>>
>>> Obviously, the
>>> parent_status->entry
>>> is NULL, which can be NULL for non-versioned items (AFAIR).
>>>
>>> I think this should be instead:
>>> if (parent_status
>>> && (parent_status->entry)
>>> && (parent_status->text_status != svn_wc_status_unversioned)
>>> && (parent_status->text_status != svn_wc_status_deleted)
>>> && (parent_status->text_status != svn_wc_status_missing)
>>> && (parent_status->text_status != svn_wc_status_obstructed)
>>> && (parent_status->entry->kind == svn_node_dir)
>>> && (eb->descend || (! pb)))
>>> {
>>
>>
>>
>> That sounds right, but can you supply a reproduction recipe so we can
>> test the fix (and even write a regression test)? That would be
>> sooooooo helpful...
>
> 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?
> >
> >All clients (subclipse, tortoise and svn-cmdline) crash!
> >
> >I think there might be a bug in the client-lib that causes the crash
> >when it can not get hold of the ".svn/tmp" directory! Please pass
> this >information on the the "correct" developers.
>
> I guess that some function before that part of code fails when the tmp
> dir is locked and then the the parent_status->entry is NULL (or
> pointing to an illegal address). Also note: the user reports that even
> the command line client crashes.
>
> 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"?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 23 03:08:45 2004