You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Brian Fallik <fa...@assurtech.com> on 2004/04/12 15:48:28 UTC
Assertion failed, core dumped
While running this command (YDL 2.3, svn 1.0.0):
svn switch svn://xxxx/path/to/branch
I got this message:
svn: subversion/libsvn_ra_svn/marshal.c:434: vwrite_tuple: Assertion `opt ||
cstr' failed.
Aborted (core dumped)
The command seemed to pretty far in the process. Is this a known bug? I
didn't see any references to this on the dev or user mailing lists.
I now have a 24 meg core dump that might be useful for debugging. Any
suggestion on how to proceed?
thanks,
brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Assertion failed, core dumped
Posted by Erik Huelsmann <e....@gmx.net>.
> While running this command (YDL 2.3, svn 1.0.0):
>
> svn switch svn://xxxx/path/to/branch
>
> I got this message:
>
> svn: subversion/libsvn_ra_svn/marshal.c:434: vwrite_tuple: Assertion `opt
> ||
> cstr' failed.
> Aborted (core dumped)
>
> The command seemed to pretty far in the process. Is this a known bug? I
> didn't see any references to this on the dev or user mailing lists.
Yes, it's fixed on trunk and nominated for backporting to 1.0.2. If you
built your svn yourself, you could apply the fix (r9293) to your local svn. The
problem is that you have an obstructed update going on.
>
> I now have a 24 meg core dump that might be useful for debugging. Any
> suggestion on how to proceed?
Delete it...
HTH,
Erik.
--
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/info
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svn working copy * not locked
Posted by Brian Fallik <fa...@assurtech.com>.
I will upgrade ASAP.
I had been using svn_load_dirs for these merges, so they originally came
from the same branch.
As for the 100% CPU utilization, it's hard to say. The size of the last
file svn completed processing was only 37k. The other files in that same
folder (whcih svn hadn't processed) are smallish (nothing over a meg).
Also, ctrl-C does not signal the svn client to terminate - I had to kill -9
the client in order to stop the process. Even if the client were waiting
for delivery of these files from the network, would that be a busy loop?
Svn should mostly wait on a select() in this situation, right?
brian
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Tuesday, April 13, 2004 10:40 AM
To: fallik@assurtech.com
Cc: users@subversion.tigris.org
Subject: RE: svn working copy * not locked
On Tue, 2004-04-13 at 09:33, Brian Fallik wrote:
> Sorry for the missing version information! D'oh. Clients are svn 1.0.0
on
> ydl 2.3, server is svn 1.0.1 (r1) on redhat 9.
Definitely use svn 1.0.1 client; it fixed a couple of merge bugs.
> As to your last point, that's exactly it. I'm trying to merge the changes
> from two versions of source code (think of them as vendor branches) into a
> third branch. It appears like this is going to require more effort than a
> simple merge. I'm now realising the usefulness of the --dry-run option.
Yah, this is why there's a whole section on vendor branches in chapter
7. If you simply imported two vendor releases into the repository (i.e.
the repository has no idea that the trees are supposed to be related)
then you might want to use the svn_load_dirs.pl script to help you
deduce changes.
As an alternative, you can also try running 'svn merge
--ignore-ancestry'. This will make the merge operation "more dumb" and
just do path-based comparisons, rather than comparisons based on
node-relatedness. It *might* help you out here.
>
> Another characteristic I'm noticing now is that during my dry-run merge,
the
> svn client uses 98% and about 10 mins of CPU time (from top) processing a
> single file.
Is it a huge file? 'svn diff' and 'svn merge' download fulltexts from
both trees that you're comparing. Perhaps you were just waiting for the
CPU to download the file from each tree.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svn working copy * not locked
Posted by Ben Collins-Sussman <su...@collab.net>.
On Tue, 2004-04-13 at 09:33, Brian Fallik wrote:
> Sorry for the missing version information! D'oh. Clients are svn 1.0.0 on
> ydl 2.3, server is svn 1.0.1 (r1) on redhat 9.
Definitely use svn 1.0.1 client; it fixed a couple of merge bugs.
> As to your last point, that's exactly it. I'm trying to merge the changes
> from two versions of source code (think of them as vendor branches) into a
> third branch. It appears like this is going to require more effort than a
> simple merge. I'm now realising the usefulness of the --dry-run option.
Yah, this is why there's a whole section on vendor branches in chapter
7. If you simply imported two vendor releases into the repository (i.e.
the repository has no idea that the trees are supposed to be related)
then you might want to use the svn_load_dirs.pl script to help you
deduce changes.
As an alternative, you can also try running 'svn merge
--ignore-ancestry'. This will make the merge operation "more dumb" and
just do path-based comparisons, rather than comparisons based on
node-relatedness. It *might* help you out here.
>
> Another characteristic I'm noticing now is that during my dry-run merge, the
> svn client uses 98% and about 10 mins of CPU time (from top) processing a
> single file.
Is it a huge file? 'svn diff' and 'svn merge' download fulltexts from
both trees that you're comparing. Perhaps you were just waiting for the
CPU to download the file from each tree.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svn working copy * not locked
Posted by Brian Fallik <fa...@assurtech.com>.
Sorry for the missing version information! D'oh. Clients are svn 1.0.0 on
ydl 2.3, server is svn 1.0.1 (r1) on redhat 9.
Here is the output leading up to the problem:
D devices/gps/source/product/EGRMsgCounter.h
D devices/gps/source/product/Tipy.h
D devices/gps/source/product/TimeOutAlarms.h
C devices/gps/interface/GPS_impl.h
D devices/gps/interface/StdAfx.h
D devices/gps/interface/StdAfx.cpp
Skipped missing target:
'devices/HomingLogicalIndicator/build/visualc/product/HomingLogicalIndicator
Server/HomingLogicalIndicatorServer.plg'
Skipped missing target:
'devices/HomingLogicalIndicator/build/visualc/product/HomingLogicalIndicator
Server/HomingLogicalIndicatorServer.dsp'
svn: Working copy
'devices/HomingLogicalIndicator/build/visualc/product/HomingLogicalIndicator
Server' not locked
I see many "skipped missing target" messages, which i understood to be
missing in my working copy (and it's not critical that they are there
anyway).
Inconsistent state meant (to me) that the merge is partially completed and
so I don't match a specific revision anymore. Thanks for the tip to get get
back to a single revision.
As to your last point, that's exactly it. I'm trying to merge the changes
from two versions of source code (think of them as vendor branches) into a
third branch. It appears like this is going to require more effort than a
simple merge. I'm now realising the usefulness of the --dry-run option.
Another characteristic I'm noticing now is that during my dry-run merge, the
svn client uses 98% and about 10 mins of CPU time (from top) processing a
single file. I thought the process had hung, but it actually makes it past
this after 10 or so minutes. Memory usage does not go up during this
time. No other file uses nearly this much CPU. Is this a known bug?
brian
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Tuesday, April 13, 2004 10:16 AM
To: fallik@assurtech.com
Cc: users@subversion.tigris.org
Subject: Re: svn working copy * not locked
On Tue, 2004-04-13 at 08:56, Brian Fallik wrote:
> I'm trying to complete a large merge. The command I'm using is :
>
> svn merge svn://path/to/branch/temp_windows_baselines/20031215
> svn://path/to/branch/temp_windows_baselines/20040406 .
>
> where my CWD is the root of a working copy of another branch.
>
>
> First, Subversion fails after only partially completing the merge with the
> message:
>
> svn: Working copy 'devices/Component/build/visualc/product/blah' not
locked
>
What client OS? What server OS? What client version? What server
version?
We need more information. What's 'svn merge' trying to do in that
directory? Can you show us an actual transcript of the merge operation?
> The one thing I notice is that "Component" is lower case in both of the
> merge paths.
Then why is it upper-case in the working copy? That might very well be
the problem.
> This error message is very cryptic, shouldn't subversion
> handle it somewhat cleaner?
Typically that error message means: "you asked me to change something
in a path that doesn't exist in the WC."
> Also it leaves my working copy in an
> inconsistent state since the merge was only partially completed.
What does 'inconsistent state' mean? If 'svn status' shows (L)ocked
directories, just run 'svn cleanup'. If you have only half a merge
applied, then just 'svn revert -R' the local mods, delete any
unversioned stuff left behind, and try the merge again.
One last side question: it looks like you're comparing the latest
version of two different branches. Are you sure that's what you really
mean to do? Typically a merge operation compares two different
revisions of the *same* branch (i.e. beginning and HEAD). Comparing the
HEAD of two different branches often results in a patch that doesn't
apply cleanly.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn working copy * not locked
Posted by Ben Collins-Sussman <su...@collab.net>.
On Tue, 2004-04-13 at 08:56, Brian Fallik wrote:
> I'm trying to complete a large merge. The command I'm using is :
>
> svn merge svn://path/to/branch/temp_windows_baselines/20031215
> svn://path/to/branch/temp_windows_baselines/20040406 .
>
> where my CWD is the root of a working copy of another branch.
>
>
> First, Subversion fails after only partially completing the merge with the
> message:
>
> svn: Working copy 'devices/Component/build/visualc/product/blah' not locked
>
What client OS? What server OS? What client version? What server
version?
We need more information. What's 'svn merge' trying to do in that
directory? Can you show us an actual transcript of the merge operation?
> The one thing I notice is that "Component" is lower case in both of the
> merge paths.
Then why is it upper-case in the working copy? That might very well be
the problem.
> This error message is very cryptic, shouldn't subversion
> handle it somewhat cleaner?
Typically that error message means: "you asked me to change something
in a path that doesn't exist in the WC."
> Also it leaves my working copy in an
> inconsistent state since the merge was only partially completed.
What does 'inconsistent state' mean? If 'svn status' shows (L)ocked
directories, just run 'svn cleanup'. If you have only half a merge
applied, then just 'svn revert -R' the local mods, delete any
unversioned stuff left behind, and try the merge again.
One last side question: it looks like you're comparing the latest
version of two different branches. Are you sure that's what you really
mean to do? Typically a merge operation compares two different
revisions of the *same* branch (i.e. beginning and HEAD). Comparing the
HEAD of two different branches often results in a patch that doesn't
apply cleanly.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Argh - frustration level high
Posted by McClain Looney <m...@loonsoft.com>.
On Tuesday 13 April 2004 03:11 pm, Ben Collins-Sussman wrote:
> subversion/libsvn_wc/adm_files.c:939: (apr_err=155000)
> svn: URL
> 'svn://server/repo/blah/branches/linux/temp_windows_baselines/20040406/modem
> /source/release' doesn't match existing URL
> 'svn://server/repo/blah/branches/linux/old_main/modem/source/release' in
> 'modem/source/release'
>
I ran into this exact problem last week, i think a new error message would
help the user dramatically, since the current message gives no indication to
the user of what to do to resolve the problem (or really even what the
problem is).
--
McClain Looney
LoonSoft LLC
m@loonsoft.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Argh - frustration level high
Posted by Brian Fallik <fa...@assurtech.com>.
Thanks. With some minor tweaking that worked.
brian
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Tuesday, April 13, 2004 4:11 PM
To: fallik@assurtech.com
Cc: users@subversion.tigris.org
Subject: Re: Argh - frustration level high
On Tue, 2004-04-13 at 14:21, Brian Fallik wrote:
> I'm trying to complete - what I believe should be - a very simple task. I
> simply want to merge two branches into a third. I can test this using
> the --dry-run parameter to svn merge, but it seems that whenever I try to
do
> the real deal, I get the following error.
>
> subversion/libsvn_wc/adm_files.c:939: (apr_err=155000)
> svn: URL
>
'svn://server/repo/blah/branches/linux/temp_windows_baselines/20040406/modem
> /source/release' doesn't match existing URL
> 'svn://server/repo/blah/branches/linux/old_main/modem/source/release' in
> 'modem/source/release'
>
> I "resolved" the bug initially by deleting the problem directory in the
> working copy and the merge made it past the original failure point. I
quote
> the word resolved because that doesnt' resolve anything, it just helps the
> svn client get a little farther before it fails.
>
> What does this error message mean? Any help would be welcome. This is
svn
> 1.0.1 on ydl 2.3.
'svn merge' compares two trees, and by default, it assumes they are
*related* to each other. In other words, that either you're looking at
two versions of the same tree at different points in time, or that one
tree is a branch of the other (created by copying.)
This "ancestry sensitivity" means that the merge operation will do
clever things. For example, if tree A and tree B both contain foo.c,
but tree B's file is completely new (it was created by deleting foo.c
and re-adding a "new" foo.c), then the merge operation will actually try
to delete and then re-add foo.c in your working copy. The same behavior
happens when merge encounters unrelated directories with identical
names: delete the old directory, re-add the "new" directory. The fact
that they have the same name is irrelevant; the repository objects are
different, and that's all that matters.
You can turn off this ancestry sensitivity (--ignore-ancestry), making
merge "dumber". In this mode, it doesn't care that the two trees have
unrelated foo.c files; it just dumbly compares the two files anyway and
applies the diff to your own foo.c. The same goes for unrelated
same-named directories: rather than try to delete and re-add whole
directories, it just mindlessly recurses into the directory as long as
the name is the same.
('svn diff URL1 URL2', incidentally, is dumb by default. You can make
it ancestry sensitive with the --notice-ancestry flag.)
So the main problem here is that you're comparing two unrelated trees.
I'm guessing that 'svn merge' is trying to delete and re-add whole
subtrees, and getting deeply annoyed the the URLs in your working copy
seem to have nothing to do with the objects it's trying to put in your
working copy. By passing '--ignore-ancestry', it will chill out and
only care about matching paths, nothing else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Argh - frustration level high
Posted by Ben Collins-Sussman <su...@collab.net>.
On Tue, 2004-04-13 at 14:21, Brian Fallik wrote:
> I'm trying to complete - what I believe should be - a very simple task. I
> simply want to merge two branches into a third. I can test this using
> the --dry-run parameter to svn merge, but it seems that whenever I try to do
> the real deal, I get the following error.
>
> subversion/libsvn_wc/adm_files.c:939: (apr_err=155000)
> svn: URL
> 'svn://server/repo/blah/branches/linux/temp_windows_baselines/20040406/modem
> /source/release' doesn't match existing URL
> 'svn://server/repo/blah/branches/linux/old_main/modem/source/release' in
> 'modem/source/release'
>
> I "resolved" the bug initially by deleting the problem directory in the
> working copy and the merge made it past the original failure point. I quote
> the word resolved because that doesnt' resolve anything, it just helps the
> svn client get a little farther before it fails.
>
> What does this error message mean? Any help would be welcome. This is svn
> 1.0.1 on ydl 2.3.
'svn merge' compares two trees, and by default, it assumes they are
*related* to each other. In other words, that either you're looking at
two versions of the same tree at different points in time, or that one
tree is a branch of the other (created by copying.)
This "ancestry sensitivity" means that the merge operation will do
clever things. For example, if tree A and tree B both contain foo.c,
but tree B's file is completely new (it was created by deleting foo.c
and re-adding a "new" foo.c), then the merge operation will actually try
to delete and then re-add foo.c in your working copy. The same behavior
happens when merge encounters unrelated directories with identical
names: delete the old directory, re-add the "new" directory. The fact
that they have the same name is irrelevant; the repository objects are
different, and that's all that matters.
You can turn off this ancestry sensitivity (--ignore-ancestry), making
merge "dumber". In this mode, it doesn't care that the two trees have
unrelated foo.c files; it just dumbly compares the two files anyway and
applies the diff to your own foo.c. The same goes for unrelated
same-named directories: rather than try to delete and re-add whole
directories, it just mindlessly recurses into the directory as long as
the name is the same.
('svn diff URL1 URL2', incidentally, is dumb by default. You can make
it ancestry sensitive with the --notice-ancestry flag.)
So the main problem here is that you're comparing two unrelated trees.
I'm guessing that 'svn merge' is trying to delete and re-add whole
subtrees, and getting deeply annoyed the the URLs in your working copy
seem to have nothing to do with the objects it's trying to put in your
working copy. By passing '--ignore-ancestry', it will chill out and
only care about matching paths, nothing else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Argh - frustration level high
Posted by Brian Fallik <fa...@assurtech.com>.
I'm trying to complete - what I believe should be - a very simple task. I
simply want to merge two branches into a third. I can test this using
the --dry-run parameter to svn merge, but it seems that whenever I try to do
the real deal, I get the following error.
subversion/libsvn_wc/adm_files.c:939: (apr_err=155000)
svn: URL
'svn://server/repo/blah/branches/linux/temp_windows_baselines/20040406/modem
/source/release' doesn't match existing URL
'svn://server/repo/blah/branches/linux/old_main/modem/source/release' in
'modem/source/release'
I "resolved" the bug initially by deleting the problem directory in the
working copy and the merge made it past the original failure point. I quote
the word resolved because that doesnt' resolve anything, it just helps the
svn client get a little farther before it fails.
What does this error message mean? Any help would be welcome. This is svn
1.0.1 on ydl 2.3.
Thanks,
brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
svn working copy * not locked
Posted by Brian Fallik <fa...@assurtech.com>.
I'm trying to complete a large merge. The command I'm using is :
svn merge svn://path/to/branch/temp_windows_baselines/20031215
svn://path/to/branch/temp_windows_baselines/20040406 .
where my CWD is the root of a working copy of another branch.
First, Subversion fails after only partially completing the merge with the
message:
svn: Working copy 'devices/Component/build/visualc/product/blah' not locked
The one thing I notice is that "Component" is lower case in both of the
merge paths. This error message is very cryptic, shouldn't subversion
handle it somewhat cleaner? Also it leaves my working copy in an
inconsistent state since the merge was only partially completed. Is this a
known bug?
If I svn mv to correct the case naming above, a second (or similar) problem
occurs when I try a --dry-run of the same command. This fails with the
following message:
svn: 'path/to/another/component/mchms.dll' is not under version control
mchms.dll does not exist in the working copy or the from merge branch, but
does exist in the to merge branch. Shouldn't this file be added? Is there
a problem because it is a dll, or am I missing something else?
Thanks for your help,
brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org