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/05/21 08:22:29 UTC
segfault when deleting folders in 1.6.2
Hi,
In the file libsvn_wc/adm_ops.c, function
svn_wc_remove_from_revision_control(), line 2628:
dir_entry = apr_hash_get(parent_entries, base_name,
APR_HASH_KEY_STRING);
if (dir_entry->depth != svn_depth_exclude)
{
svn_wc__entry_remove(parent_entries, base_name);
SVN_ERR(svn_wc__entries_write(parent_entries, parent_access, pool));
}
the 'dir_entry' is NULL, and accessing it in the if-clause causes a
segfault.
Re: segfault when deleting folders in 1.6.2
Posted by CC <cr...@gmail.com>.
Regardless of what's causing the issue, I would say that there should
be a check for dir_entry being NULL to avoid segfaulting.
CC
On Thu, May 21, 2009 at 1:22 AM, Stefan Küng <to...@gmail.com> wrote:
> Hi,
>
> In the file libsvn_wc/adm_ops.c, function
> svn_wc_remove_from_revision_control(), line 2628:
>
> dir_entry = apr_hash_get(parent_entries, base_name,
> APR_HASH_KEY_STRING);
> if (dir_entry->depth != svn_depth_exclude)
> {
> svn_wc__entry_remove(parent_entries, base_name);
> SVN_ERR(svn_wc__entries_write(parent_entries, parent_access, pool));
>
> }
>
> the 'dir_entry' is NULL, and accessing it in the if-clause causes a
> segfault.
> From the crash dump I got, I can't see anything special about the path
> (it was F:\dev\svn\name\name), so no root path, no UNC path or anything
> else special I can think of.
>
> But the delete was called with --keep-local, so maybe that has something
> to do with it?
>
> 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=2343506
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2353070
Re: segfault when deleting folders in 1.6.2
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Stefan Küng wrote:
> Neels J Hofmeyr wrote:
>> Stefan Küng wrote:
>>> On Thu, May 21, 2009 at 10:22, Stefan Küng <to...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> In the file libsvn_wc/adm_ops.c, function
>>>> svn_wc_remove_from_revision_control(), line 2628:
>>>>
>>>> dir_entry = apr_hash_get(parent_entries, base_name,
>>>> APR_HASH_KEY_STRING);
>>>> if (dir_entry->depth != svn_depth_exclude)
>>>> {
>>>> svn_wc__entry_remove(parent_entries, base_name);
>>>> SVN_ERR(svn_wc__entries_write(parent_entries, parent_access, pool));
>>>>
>>>> }
>>>>
>>>> the 'dir_entry' is NULL, and accessing it in the if-clause causes a
>>>> segfault.
>>>> From the crash dump I got, I can't see anything special about the path
>>>> (it was F:\dev\svn\name\name), so no root path, no UNC path or anything
>>>> else special I can think of.
>>>>
>>>> But the delete was called with --keep-local, so maybe that has something
>>>> to do with it?
>>> Some more information:
>>> the folder which should be deleted is tree-conflicted (deleted in
>>> repository, still present locally).
>>>
>>> Stefan
>> Actually, are you saying that when you got the error, some folder was
>> already tree-conflicted, or are you saying that deleting with --keep-local
>> per se results in a tree-conflicted situation?
>>
>> The latter results in an obstructed path, as I pointed out just now in a
>> different mail, just a "potential tree-conflict", nothing to worry about.
>>
>> If it's the former, could you please clarify? Maybe it's worth
>> investigating, TC wise. But so far I'd guess it's not related.
>
> I didn't reproduce this myself. The information I got was from a crash
> dump file sent for TSVN and what the user told me. So I don't know
> whether the --keep-local is the reason for the crash. But as the user
> said, there was a tree conflict on that folder and he tried to remove
> the folder to get rid of the tree conflict. So the folder already was
> marked as conflicted.
>
> Stefan
In any case, there's a directory that is in version control in the WC, but
not (anymore) in the repos. When svn deletes, it won't schedule them for
deletion, but currently will mark keep_local anyway.
I'm still thinking my fix suggestion from earlier today is sufficient
(haven't tested though). If TC victims still pose a problem after that,
that'd be a similar, yet unrelated, fix.
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2359229
Re: segfault when deleting folders in 1.6.2
Posted by Stefan Küng <to...@gmail.com>.
Neels J Hofmeyr wrote:
> Stefan Küng wrote:
>> On Thu, May 21, 2009 at 10:22, Stefan Küng <to...@gmail.com> wrote:
>>> Hi,
>>>
>>> In the file libsvn_wc/adm_ops.c, function
>>> svn_wc_remove_from_revision_control(), line 2628:
>>>
>>> dir_entry = apr_hash_get(parent_entries, base_name,
>>> APR_HASH_KEY_STRING);
>>> if (dir_entry->depth != svn_depth_exclude)
>>> {
>>> svn_wc__entry_remove(parent_entries, base_name);
>>> SVN_ERR(svn_wc__entries_write(parent_entries, parent_access, pool));
>>>
>>> }
>>>
>>> the 'dir_entry' is NULL, and accessing it in the if-clause causes a
>>> segfault.
>>> From the crash dump I got, I can't see anything special about the path
>>> (it was F:\dev\svn\name\name), so no root path, no UNC path or anything
>>> else special I can think of.
>>>
>>> But the delete was called with --keep-local, so maybe that has something
>>> to do with it?
>> Some more information:
>> the folder which should be deleted is tree-conflicted (deleted in
>> repository, still present locally).
>>
>> Stefan
>
> Actually, are you saying that when you got the error, some folder was
> already tree-conflicted, or are you saying that deleting with --keep-local
> per se results in a tree-conflicted situation?
>
> The latter results in an obstructed path, as I pointed out just now in a
> different mail, just a "potential tree-conflict", nothing to worry about.
>
> If it's the former, could you please clarify? Maybe it's worth
> investigating, TC wise. But so far I'd guess it's not related.
I didn't reproduce this myself. The information I got was from a crash
dump file sent for TSVN and what the user told me. So I don't know
whether the --keep-local is the reason for the crash. But as the user
said, there was a tree conflict on that folder and he tried to remove
the folder to get rid of the tree conflict. So the folder already was
marked as conflicted.
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=2359116
Re: segfault when deleting folders in 1.6.2
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Stefan Küng wrote:
> On Thu, May 21, 2009 at 10:22, Stefan Küng <to...@gmail.com> wrote:
>> Hi,
>>
>> In the file libsvn_wc/adm_ops.c, function
>> svn_wc_remove_from_revision_control(), line 2628:
>>
>> dir_entry = apr_hash_get(parent_entries, base_name,
>> APR_HASH_KEY_STRING);
>> if (dir_entry->depth != svn_depth_exclude)
>> {
>> svn_wc__entry_remove(parent_entries, base_name);
>> SVN_ERR(svn_wc__entries_write(parent_entries, parent_access, pool));
>>
>> }
>>
>> the 'dir_entry' is NULL, and accessing it in the if-clause causes a
>> segfault.
>> From the crash dump I got, I can't see anything special about the path
>> (it was F:\dev\svn\name\name), so no root path, no UNC path or anything
>> else special I can think of.
>>
>> But the delete was called with --keep-local, so maybe that has something
>> to do with it?
>
> Some more information:
> the folder which should be deleted is tree-conflicted (deleted in
> repository, still present locally).
>
> Stefan
Actually, are you saying that when you got the error, some folder was
already tree-conflicted, or are you saying that deleting with --keep-local
per se results in a tree-conflicted situation?
The latter results in an obstructed path, as I pointed out just now in a
different mail, just a "potential tree-conflict", nothing to worry about.
If it's the former, could you please clarify? Maybe it's worth
investigating, TC wise. But so far I'd guess it's not related.
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2358945
Re: segfault when deleting folders in 1.6.2
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Neels Janosch Hofmeyr wrote:
> The entry, say A/C, is scheduled for addition. It isn't actually added yet.
Sorry, that's supposed to be A/C/D.
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2358941
Re: segfault when deleting folders in 1.6.2
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Jun 2, 2009 at 8:13 PM, Neels J Hofmeyr<ne...@elego.de> wrote:
> Paul Burba wrote:
>> On Sun, May 31, 2009 at 7:35 AM, Stefan Küng <to...@gmail.com> wrote:
>>> On Thu, May 21, 2009 at 10:22, Stefan Küng <to...@gmail.com> wrote:
>> I'm going to hold off on committing though for two reasons:
>>
>> First, while this fixes the problem for 1.6.x, when running this new
>> test on trunk it triggers an assert on line 2051 in
>> entries.c:write_entry():
>>
>> 2048 if (entry->keep_local)
>> 2049 {
>> 2050 SVN_ERR_ASSERT(working_node != NULL);
>> 2051 SVN_ERR_ASSERT(entry->schedule == svn_wc_schedule_delete);
>> 2052 working_node->keep_local = TRUE;
>> 2053 }
>
> <rant>Whoa, a simple NULL check affects an assert like this??
> It implies that previously, the "if" condition that you change in the patch
> evaluated a NULL pointer and did ugly stuff, if I'm following correctly.
Neels,
I should have been clearer, I meant that the assert is triggered when
running the *test* from my patch on trunk. It doesn't matter if the
change to adm_ops.c is made or not, the assert happens first.
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2359777
Re: segfault when deleting folders in 1.6.2
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Paul Burba wrote:
> On Sun, May 31, 2009 at 7:35 AM, Stefan Küng <to...@gmail.com> wrote:
>> On Thu, May 21, 2009 at 10:22, Stefan Küng <to...@gmail.com> wrote:
>>> Hi,
>>>
>>> In the file libsvn_wc/adm_ops.c, function
>>> svn_wc_remove_from_revision_control(), line 2628:
>>>
>>> dir_entry = apr_hash_get(parent_entries, base_name,
>>> APR_HASH_KEY_STRING);
>>> if (dir_entry->depth != svn_depth_exclude)
>>> {
>>> svn_wc__entry_remove(parent_entries, base_name);
>>> SVN_ERR(svn_wc__entries_write(parent_entries, parent_access, pool));
>>>
>>> }
>>>
>>> the 'dir_entry' is NULL, and accessing it in the if-clause causes a
>>> segfault.
>>> From the crash dump I got, I can't see anything special about the path
>>> (it was F:\dev\svn\name\name), so no root path, no UNC path or anything
>>> else special I can think of.
>>>
>>> But the delete was called with --keep-local, so maybe that has something
>>> to do with it?
>> Some more information:
>> the folder which should be deleted is tree-conflicted (deleted in
>> repository, still present locally).
>>
>> Stefan
Actually, it's only an obstructed path. It's not like it was deleted in the
repos vs. edited in the WC. No, the deleted subtree is now out of version
control, they are "some other files lying around", edits don't matter as far
as Subversion is concerned. This will only become a tree-conflict if the
user tries to subsequently do an update or merge that involves this path,
i.e. add a new file/dir with the same name (sbutler,stsp: other cases??).
>
> Attached is a patch that adds a new update test to replicate this
> segfault, along with the very simple fix to address it.
>
> I'm going to hold off on committing though for two reasons:
>
> First, while this fixes the problem for 1.6.x, when running this new
> test on trunk it triggers an assert on line 2051 in
> entries.c:write_entry():
>
> 2048 if (entry->keep_local)
> 2049 {
> 2050 SVN_ERR_ASSERT(working_node != NULL);
> 2051 SVN_ERR_ASSERT(entry->schedule == svn_wc_schedule_delete);
> 2052 working_node->keep_local = TRUE;
> 2053 }
<rant>Whoa, a simple NULL check affects an assert like this??
It implies that previously, the "if" condition that you change in the patch
evaluated a NULL pointer and did ugly stuff, if I'm following correctly.
So it's probably the first time that this part of the code gets proper input
for this particular situation. So, hopefully the assert is wrong. Otherwise,
it sounds like a rat's tail "missing feature".</rant>
>
> This assert was added in r36105, but I can't figure out what its
> purpose is.
quoting include/svn_wc.h svn_entry_t
[[[
/** Whether a local copy of this entry should be kept in the working copy
* after a deletion has been committed, Only valid for the this-dir entry
* when it is scheduled for deletion.
*
* @since New in 1.5. */
svn_boolean_t keep_local;
]]]
So, the assert is verifying that keep_local is only set on an entry that is
also scheduled for deletion; So that every keep_local that is set is in fact
carried out and doesn't linger past the next commit, I think.
> Putting aside tree conflicts for a moment we can trigger
> this assert by simply deleting a path with a locally added subtree,
> e.g.:
>
> trunk@37912>svn st -v
> 1 1 jrandom .
> 1 1 jrandom A
> 1 1 jrandom A\mu
> 1 1 jrandom A\B
> 1 1 jrandom A\B\lambda
> 1 1 jrandom A\B\E
> 1 1 jrandom A\B\E\alpha
> 1 1 jrandom A\B\E\beta
> 1 1 jrandom A\B\F
> 1 1 jrandom A\C
> 1 1 jrandom A\D
> 1 1 jrandom A\D\gamma
> 1 1 jrandom A\D\G
> 1 1 jrandom A\D\G\rho
> 1 1 jrandom A\D\G\pi
> 1 1 jrandom A\D\G\tau
> 1 1 jrandom A\D\H
> 1 1 jrandom A\D\H\chi
> 1 1 jrandom A\D\H\omega
> 1 1 jrandom A\D\H\psi
> 1 1 jrandom iota
>
> trunk@37912>svn copy A\D A\C
> A A\C\D
>
> trunk@37912>svn delete A\C --keep-local
> D A\C\D\gamma
> D A\C\D\G\rho
> D A\C\D\G\pi
> D A\C\D\G\tau
> D A\C\D\G
> D A\C\D\H\chi
> D A\C\D\H\omega
> D A\C\D\H\psi
> D A\C\D\H
> ..\..\..\subversion\libsvn_wc\wc_db.c:2240: (apr_err=235000)
> svn: In file '..\..\..\subversion\libsvn_wc\entries.c' line 2051:
> assertion failed (entry->schedule == svn_wc_schedule_delete)
What with the backslashes ;)
Hm, would be nice to know on which entry this assertion fails.
But I'm already getting a notion that the cause is this:
The entry, say A/C, is scheduled for addition. It isn't actually added yet.
Then we go on deleting it, before it's a real repository entry. That's more
like a revert, not a delete, right? However, --keep-local sets keep_local on
it anyways (my guess). The result is a directory node that is *not*
scheduled for deletion but still has keep_local set. Probably just another
special case in an if statement somewhere.
Hey, I'm right, this says it all:
libsvn_wc/adm_ops.c:923 (mark_tree)
[[[
/* Uncommitted directories (schedule add) that are to be scheduled for
deletion are a special case, they don't need to be changed as they
will be removed from their parent's entry list. */
if (! (entry->schedule == svn_wc_schedule_add
&& schedule == svn_wc_schedule_delete))
{
if (modify_flags & SVN_WC__ENTRY_MODIFY_SCHEDULE)
{
tmp_entry.schedule = schedule;
this_dir_flags |= SVN_WC__ENTRY_MODIFY_SCHEDULE;
}
if (modify_flags & SVN_WC__ENTRY_MODIFY_COPIED)
{
tmp_entry.copied = copied;
this_dir_flags |= SVN_WC__ENTRY_MODIFY_COPIED;
}
}
/* Set keep_local on the "this dir", if requested. */
if (modify_flags & SVN_WC__ENTRY_MODIFY_KEEP_LOCAL)
{
tmp_entry.keep_local = keep_local;
this_dir_flags |= SVN_WC__ENTRY_MODIFY_KEEP_LOCAL;
}
]]]
I think all that needs to happen is that the keep_local part has to move
into the "if(! (..._add && ..._delete)){" scope.
>
> Hyrum, I'm ccing you in the hope you can explain the purpose of this
> assert (apologies if I'm being dense!).
:)
> ~~~~~
>
> Second, I'm wondering what additional limitations we should consider
> putting on operations on a tree conflicted directory before that TC is
> resolved or reverted. Obviously we can't commit a tree conflicted WC,
> but should we allow other operations, copies, moves, deletes, etc., of
> WC paths which are either a subtree of a tree conflicted directory or
> have a subtree that is tree conflicted. Or should all this be allowed
> and should it "work" (however that might be defined)? I'm CCing you
> TC guys in the hopes of prying some wisdom from your brains on this
> ;-)
This fix is not really that closely related to tree-conflicts, as pointed
out above. What operations are or are not allowed on tree-conflicted entries
is a matter of resolve strategies ... which we haven't really mapped out
completely yet, AFAIR. We should have some document on what operations do
what, I guess. So far, I only know of some TC resolving examples.
(beware, slightly outdated)
http://svn.collab.net/viewvc/svn/trunk/notes/tree-conflicts/use-cases-resolution.txt
Anyway. Don't worry. :)
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2358939
Re: segfault when deleting folders in 1.6.2
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
See r37953.
~Neels
Paul Burba wrote:
> On Sun, May 31, 2009 at 7:35 AM, Stefan Küng <to...@gmail.com> wrote:
>> On Thu, May 21, 2009 at 10:22, Stefan Küng <to...@gmail.com> wrote:
>>> Hi,
>>>
>>> In the file libsvn_wc/adm_ops.c, function
>>> svn_wc_remove_from_revision_control(), line 2628:
>>>
>>> dir_entry = apr_hash_get(parent_entries, base_name,
>>> APR_HASH_KEY_STRING);
>>> if (dir_entry->depth != svn_depth_exclude)
>>> {
>>> svn_wc__entry_remove(parent_entries, base_name);
>>> SVN_ERR(svn_wc__entries_write(parent_entries, parent_access, pool));
>>>
>>> }
>>>
>>> the 'dir_entry' is NULL, and accessing it in the if-clause causes a
>>> segfault.
>>> From the crash dump I got, I can't see anything special about the path
>>> (it was F:\dev\svn\name\name), so no root path, no UNC path or anything
>>> else special I can think of.
>>>
>>> But the delete was called with --keep-local, so maybe that has something
>>> to do with it?
>> Some more information:
>> the folder which should be deleted is tree-conflicted (deleted in
>> repository, still present locally).
>>
>> Stefan
>
> Attached is a patch that adds a new update test to replicate this
> segfault, along with the very simple fix to address it.
>
> I'm going to hold off on committing though for two reasons:
>
> First, while this fixes the problem for 1.6.x, when running this new
> test on trunk it triggers an assert on line 2051 in
> entries.c:write_entry():
>
> 2048 if (entry->keep_local)
> 2049 {
> 2050 SVN_ERR_ASSERT(working_node != NULL);
> 2051 SVN_ERR_ASSERT(entry->schedule == svn_wc_schedule_delete);
> 2052 working_node->keep_local = TRUE;
> 2053 }
>
> This assert was added in r36105, but I can't figure out what its
> purpose is. Putting aside tree conflicts for a moment we can trigger
> this assert by simply deleting a path with a locally added subtree,
> e.g.:
>
> trunk@37912>svn st -v
> 1 1 jrandom .
> 1 1 jrandom A
> 1 1 jrandom A\mu
> 1 1 jrandom A\B
> 1 1 jrandom A\B\lambda
> 1 1 jrandom A\B\E
> 1 1 jrandom A\B\E\alpha
> 1 1 jrandom A\B\E\beta
> 1 1 jrandom A\B\F
> 1 1 jrandom A\C
> 1 1 jrandom A\D
> 1 1 jrandom A\D\gamma
> 1 1 jrandom A\D\G
> 1 1 jrandom A\D\G\rho
> 1 1 jrandom A\D\G\pi
> 1 1 jrandom A\D\G\tau
> 1 1 jrandom A\D\H
> 1 1 jrandom A\D\H\chi
> 1 1 jrandom A\D\H\omega
> 1 1 jrandom A\D\H\psi
> 1 1 jrandom iota
>
> trunk@37912>svn copy A\D A\C
> A A\C\D
>
> trunk@37912>svn delete A\C --keep-local
> D A\C\D\gamma
> D A\C\D\G\rho
> D A\C\D\G\pi
> D A\C\D\G\tau
> D A\C\D\G
> D A\C\D\H\chi
> D A\C\D\H\omega
> D A\C\D\H\psi
> D A\C\D\H
> ..\..\..\subversion\libsvn_wc\wc_db.c:2240: (apr_err=235000)
> svn: In file '..\..\..\subversion\libsvn_wc\entries.c' line 2051:
> assertion failed (entry->schedule == svn_wc_schedule_delete)
>
> Hyrum, I'm ccing you in the hope you can explain the purpose of this
> assert (apologies if I'm being dense!).
>
> ~~~~~
>
> Second, I'm wondering what additional limitations we should consider
> putting on operations on a tree conflicted directory before that TC is
> resolved or reverted. Obviously we can't commit a tree conflicted WC,
> but should we allow other operations, copies, moves, deletes, etc., of
> WC paths which are either a subtree of a tree conflicted directory or
> have a subtree that is tree conflicted. Or should all this be allowed
> and should it "work" (however that might be defined)? I'm CCing you
> TC guys in the hopes of prying some wisdom from your brains on this
> ;-)
>
> Paul
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2358905
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2360289
Re: segfault when deleting folders in 1.6.2
Posted by Paul Burba <pt...@gmail.com>.
On Sun, May 31, 2009 at 7:35 AM, Stefan Küng <to...@gmail.com> wrote:
> On Thu, May 21, 2009 at 10:22, Stefan Küng <to...@gmail.com> wrote:
>> Hi,
>>
>> In the file libsvn_wc/adm_ops.c, function
>> svn_wc_remove_from_revision_control(), line 2628:
>>
>> dir_entry = apr_hash_get(parent_entries, base_name,
>> APR_HASH_KEY_STRING);
>> if (dir_entry->depth != svn_depth_exclude)
>> {
>> svn_wc__entry_remove(parent_entries, base_name);
>> SVN_ERR(svn_wc__entries_write(parent_entries, parent_access, pool));
>>
>> }
>>
>> the 'dir_entry' is NULL, and accessing it in the if-clause causes a
>> segfault.
>> From the crash dump I got, I can't see anything special about the path
>> (it was F:\dev\svn\name\name), so no root path, no UNC path or anything
>> else special I can think of.
>>
>> But the delete was called with --keep-local, so maybe that has something
>> to do with it?
>
> Some more information:
> the folder which should be deleted is tree-conflicted (deleted in
> repository, still present locally).
>
> Stefan
Attached is a patch that adds a new update test to replicate this
segfault, along with the very simple fix to address it.
I'm going to hold off on committing though for two reasons:
First, while this fixes the problem for 1.6.x, when running this new
test on trunk it triggers an assert on line 2051 in
entries.c:write_entry():
2048 if (entry->keep_local)
2049 {
2050 SVN_ERR_ASSERT(working_node != NULL);
2051 SVN_ERR_ASSERT(entry->schedule == svn_wc_schedule_delete);
2052 working_node->keep_local = TRUE;
2053 }
This assert was added in r36105, but I can't figure out what its
purpose is. Putting aside tree conflicts for a moment we can trigger
this assert by simply deleting a path with a locally added subtree,
e.g.:
trunk@37912>svn st -v
1 1 jrandom .
1 1 jrandom A
1 1 jrandom A\mu
1 1 jrandom A\B
1 1 jrandom A\B\lambda
1 1 jrandom A\B\E
1 1 jrandom A\B\E\alpha
1 1 jrandom A\B\E\beta
1 1 jrandom A\B\F
1 1 jrandom A\C
1 1 jrandom A\D
1 1 jrandom A\D\gamma
1 1 jrandom A\D\G
1 1 jrandom A\D\G\rho
1 1 jrandom A\D\G\pi
1 1 jrandom A\D\G\tau
1 1 jrandom A\D\H
1 1 jrandom A\D\H\chi
1 1 jrandom A\D\H\omega
1 1 jrandom A\D\H\psi
1 1 jrandom iota
trunk@37912>svn copy A\D A\C
A A\C\D
trunk@37912>svn delete A\C --keep-local
D A\C\D\gamma
D A\C\D\G\rho
D A\C\D\G\pi
D A\C\D\G\tau
D A\C\D\G
D A\C\D\H\chi
D A\C\D\H\omega
D A\C\D\H\psi
D A\C\D\H
..\..\..\subversion\libsvn_wc\wc_db.c:2240: (apr_err=235000)
svn: In file '..\..\..\subversion\libsvn_wc\entries.c' line 2051:
assertion failed (entry->schedule == svn_wc_schedule_delete)
Hyrum, I'm ccing you in the hope you can explain the purpose of this
assert (apologies if I'm being dense!).
~~~~~
Second, I'm wondering what additional limitations we should consider
putting on operations on a tree conflicted directory before that TC is
resolved or reverted. Obviously we can't commit a tree conflicted WC,
but should we allow other operations, copies, moves, deletes, etc., of
WC paths which are either a subtree of a tree conflicted directory or
have a subtree that is tree conflicted. Or should all this be allowed
and should it "work" (however that might be defined)? I'm CCing you
TC guys in the hopes of prying some wisdom from your brains on this
;-)
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2358905
Re: segfault when deleting folders in 1.6.2
Posted by Stefan Küng <to...@gmail.com>.
On Thu, May 21, 2009 at 10:22, Stefan Küng <to...@gmail.com> wrote:
> Hi,
>
> In the file libsvn_wc/adm_ops.c, function
> svn_wc_remove_from_revision_control(), line 2628:
>
> dir_entry = apr_hash_get(parent_entries, base_name,
> APR_HASH_KEY_STRING);
> if (dir_entry->depth != svn_depth_exclude)
> {
> svn_wc__entry_remove(parent_entries, base_name);
> SVN_ERR(svn_wc__entries_write(parent_entries, parent_access, pool));
>
> }
>
> the 'dir_entry' is NULL, and accessing it in the if-clause causes a
> segfault.
> From the crash dump I got, I can't see anything special about the path
> (it was F:\dev\svn\name\name), so no root path, no UNC path or anything
> else special I can think of.
>
> But the delete was called with --keep-local, so maybe that has something
> to do with it?
Some more information:
the folder which should be deleted is tree-conflicted (deleted in
repository, still present locally).
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=2357262