You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Küng <to...@gmail.com> on 2009/03/26 18:14:03 UTC
another segfault during update
Hi,
In libsvn_wc\crop.c, line 294 (function svn_wc_crop_tree), the
target_entry pointer is NULL.
I already got four crash dumps from different people with this segfault.
I assume the pointer is NULL because the call in the previous line to
apr_hash_get can't find the entry.
Unfortunately, the crash dumps don't tell much. All I can see is that
the update is on a 'normal' local path (i.e., no UNC path, no non-ascii
chars in the path) and the update is done with externals included,
allowing unversioned obstruction, depth -1, sticky depth.
The url also doesn't seem special (https, no escaping needed since all
chars are plain ascii).
Maybe someone can find out why this happens?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1433245
Re: another segfault during update
Posted by Stefan Küng <to...@gmail.com>.
Yes, r36689 seems to fix the cause of the problem.
But: there will be a lot of corrupted working copies lying around, and
these will cause the same segfaults again.
How about adding a check for target_entry being NULL and if it is return
an error message telling the user to do a fresh checkout?
I really don't like segfaults if the root cause is known.
Stefan
Greg Stein wrote:
> I think that might be related to a bug I found right as 1.6.0 was
> going out the door. Take a look at r36686, and see if that fixes
> things for your users.
>
> (and r36689 for a test; these have been applied to 1.6.1 already, I believe)
>
> Cheers,
> -g
>
> On Thu, Mar 26, 2009 at 19:14, Stefan Küng <to...@gmail.com> wrote:
>> Hi,
>>
>> In libsvn_wc\crop.c, line 294 (function svn_wc_crop_tree), the
>> target_entry pointer is NULL.
>>
>> I already got four crash dumps from different people with this segfault.
>> I assume the pointer is NULL because the call in the previous line to
>> apr_hash_get can't find the entry.
>>
>> Unfortunately, the crash dumps don't tell much. All I can see is that
>> the update is on a 'normal' local path (i.e., no UNC path, no non-ascii
>> chars in the path) and the update is done with externals included,
>> allowing unversioned obstruction, depth -1, sticky depth.
>> The url also doesn't seem special (https, no escaping needed since all
>> chars are plain ascii).
>>
>>
>> Maybe someone can find out why this happens?
>>
>>
>> Stefan
>>
>> --
>> ___
>> oo // \\ "De Chelonian Mobile"
>> (_,\/ \_/ \ TortoiseSVN
>> \ \_/_\_/> The coolest Interface to (Sub)Version Control
>> /_/ \_\ http://tortoisesvn.net
>>
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1433245
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1434471
Re: another segfault during update
Posted by Greg Stein <gs...@gmail.com>.
I think that might be related to a bug I found right as 1.6.0 was
going out the door. Take a look at r36686, and see if that fixes
things for your users.
(and r36689 for a test; these have been applied to 1.6.1 already, I believe)
Cheers,
-g
On Thu, Mar 26, 2009 at 19:14, Stefan Küng <to...@gmail.com> wrote:
> Hi,
>
> In libsvn_wc\crop.c, line 294 (function svn_wc_crop_tree), the
> target_entry pointer is NULL.
>
> I already got four crash dumps from different people with this segfault.
> I assume the pointer is NULL because the call in the previous line to
> apr_hash_get can't find the entry.
>
> Unfortunately, the crash dumps don't tell much. All I can see is that
> the update is on a 'normal' local path (i.e., no UNC path, no non-ascii
> chars in the path) and the update is done with externals included,
> allowing unversioned obstruction, depth -1, sticky depth.
> The url also doesn't seem special (https, no escaping needed since all
> chars are plain ascii).
>
>
> Maybe someone can find out why this happens?
>
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1433245
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1433855