Re: svn log xml hangs and produces too many logentry closing tags
Den lör 17 juli 2021 kl 15:02 skrev Attila : > On 14 Jul 2021, at 21:42, Nathan Hartman wrote: > > > On Tue, Jul 13, 2021 at 5:49 PM Attila wrote: > > > Hi > > I have a problem getting the svn log in a branch after sync-merging a > commit from trunk. > This commit in trunk is a merge of an old and complex branch with many > commits. > > The client accessing the repository over svn:// url. > (paths and text is redacted) > The head revision is: 10801 > > When I run the following command on the client (in the working copy), it > prints a long partial xml-log output, then hangs. > /usr/bin/svn log --xml -g -v -r 10701:HEAD /path/to/branch-wc > > When observing in "top", the command uses no visible CPU resources on > hang. (I waited ca. 2 minutes) > The hanging command does mot exits on CTRL-c, it does not exits on "kill > -TERM pid", I have to send "kill -KILL pid" to terminate it. > > When I run the command with strace it hangs at read(4, > ...SNIP... > read(4, " ( ) ( 4:file true false ) ) ( 1"..., 16384) = 16384 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x7f63f1d83000 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x7f63f1d81000 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x7f63f1d7f000 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x7f63f1d7d000 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x7f63f1d7b000 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x7f63f1d79000 > read(4, "***/-***_redacted_*_"..., 16384) = 14773 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x7f63f1d77000 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x7f63f1d75000 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x7f63f1d73000 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x7f63f1d71000 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x7f63f1d6f000 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x7f63f1d6d000 > read(4, > > When I observe the server, there is a CPU activity at the begin, but when > the client hangs, the server seems to be in idle. > Just a corresponding svnserve process is there with no visible cpu usage. > In svnserve.log is nothing relevant to see. > > The svnserve command is: > svnserve -d -r /path/to/repositories \ > --log-file=/var/log/svnserve.log \ > --memory-cache-size 1024 \ > --cache-txdeltas yes \ > --cache-fulltexts yes > > When I try to get the xml-log on the server with the corresponding file:// > repository URL: > /usr/bin/svn log --xml -g -v -r 10701:HEAD > file://path/to/local/repositories/project/branch > The command finishes in ca 5-10 seconds and I get the xml output, but the > output has a way too many lines. > > There are 1217 occurrences of the string “ of the string "" in the output xml. > There are several thousand lines of in a row in many places in > repeated blocks. > > Details: > Client and Server OS: > Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1+deb10u1 (2020-04-27) x86_64 > GNU/Linux > > The repository is ca. 4 GB. > Running "svnadmin verify" on the server founds no errors. > I have no other problems with the server, checkout and commit works normal. > > svn --version > svn, version 1.10.4 (r1850624) > compiled Feb 10 2021, 20:15:45 on x86_64-pc-linux-gnu > > Copyright (C) 2019 The Apache Software Foundation. > This software consists of contributions made by many people; > see the NOTICE file for more information. > Subversion is open source software, see http://subversion.apache.org/ > > The following repository access (RA) modules are available: > > * ra_svn : Module for accessing a repository using the svn network > protocol. > - with Cyrus SASL authentication > - handles 'svn' scheme > * ra_local : Module for accessing a repository on local disk. > - handles 'file' scheme > * ra_serf : Module for accessing a repository via WebDAV protocol using > serf. > - using serf 1.3.9 (compiled with 1.3.9) > - handles 'http' scheme > - handles 'https' scheme > > The following authentication credential caches are available: > > * Plaintext cache in /home/username/.subversion > * Gnome Keyring > * GPG-Agent > * KWallet (KDE) > > > > Hello Attila, > > Thanks for this detailed explanation. There are quite a few important > clues here. > > To help narrow down the search for the culprit: Are you able to run > the same 'svn log' command against the same working copy, but without > the '--xml', and get a correct output in a reasonable amount of time? > > > Hi Nathan > > thanks for the suggestions. > > The command without the --xml parameter hangs on the client and works on > the server. > The text output on the server seems be ok. > This suggests that the hang and the closing xml tags are t
Re: Segfault in libsvn_client/conflicts.c
The shell script is easy. I run resolve on my codebase :-). The trick will be recreating the repo history that reproduces this problem, and that has always been gnarly to me. I could use some advice for this. Basically, what I will try to do is create a folder with files. create a branch at this point, move a file in the branch, cherry pick this commit with the move into trunk, and then try a top level merge of the branch into trunk. Those are the things I did to the repo, I'm not sure if others mucked with it. If that doesn't work, I'll have to sleuth my repo and I'll need help to do that On 8/8/21 16:38, Stefan Sperling wrote: On Sun, Aug 08, 2021 at 10:26:43AM +0200, Daniel Sahlberg wrote: On 2021-08-07 17:14, Joshua Kordani wrote: Yes it does appear to fix the issue. Thank you! Hi Joshua (and list), I've been trying to reproduce your issue both to have test case for backporting the fix and possibly also adding to the test suite. However I can't reproduce it, possibly I misunderstand some of your steps. Do you know the exact steps to reproduce (when running without the patch, obviously)? Kind regards, Daniel Sahlberg I have committed my patch in https://svn.apache.org/r1892118 I agree that having a test case would be nice to prevent this issue from resurfacing accidentally. It could also help us to identify other similar scenarios that don't work right. If we had a shell script which reproduced the crash I could write a corresponding C test for the resolver. What we lack is the sequence of changes and merges which trigger the issue. Joshua, do you think you would be able to provide this sequence of steps, ideally as a self-contained shell script? We offer a suitable shell script template here: https://subversion.apache.org/docs/community-guide/repro-template.sh Regards, Stefan -- Joshua Kordani Senior Engineer Robotic Research, LLC jkord...@roboticresearch.com CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: Segfault in libsvn_client/conflicts.c
So unfortunately that simple case didn't reproduce the problem. So I need help investigating the state of things... On 8/9/21 14:09, Joshua Kordani wrote: The shell script is easy. I run resolve on my codebase :-). The trick will be recreating the repo history that reproduces this problem, and that has always been gnarly to me. I could use some advice for this. Basically, what I will try to do is create a folder with files. create a branch at this point, move a file in the branch, cherry pick this commit with the move into trunk, and then try a top level merge of the branch into trunk. Those are the things I did to the repo, I'm not sure if others mucked with it. If that doesn't work, I'll have to sleuth my repo and I'll need help to do that On 8/8/21 16:38, Stefan Sperling wrote: On Sun, Aug 08, 2021 at 10:26:43AM +0200, Daniel Sahlberg wrote: On 2021-08-07 17:14, Joshua Kordani wrote: Yes it does appear to fix the issue. Thank you! Hi Joshua (and list), I've been trying to reproduce your issue both to have test case for backporting the fix and possibly also adding to the test suite. However I can't reproduce it, possibly I misunderstand some of your steps. Do you know the exact steps to reproduce (when running without the patch, obviously)? Kind regards, Daniel Sahlberg I have committed my patch in https://svn.apache.org/r1892118 I agree that having a test case would be nice to prevent this issue from resurfacing accidentally. It could also help us to identify other similar scenarios that don't work right. If we had a shell script which reproduced the crash I could write a corresponding C test for the resolver. What we lack is the sequence of changes and merges which trigger the issue. Joshua, do you think you would be able to provide this sequence of steps, ideally as a self-contained shell script? We offer a suitable shell script template here: https://subversion.apache.org/docs/community-guide/repro-template.sh Regards, Stefan -- Joshua Kordani Senior Engineer Robotic Research, LLC jkord...@roboticresearch.com CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: Segfault in libsvn_client/conflicts.c
Actually I was able to trace more of what happened in the repo, and I found a new crash ;-) I will try to script up these steps. So, I created trunk, a feature branch, and a test branch. On the test branch I created a file. I merged the test with the feature. On the feature, I moved the file to a new folder. Then I cherry pick merged that last revision onto trunk. Automatic merge resolution core dumped on that file. I run the final command with the version of svn with the patch not applied. --- Merging r12 into '.': C module1/m1file3new A module2/m1file3new --- Recording mergeinfo for merge of r12 into '.': G . --- Recording mergeinfo for merge of r12 into 'module1': U module1 Summary of conflicts: Tree conflicts: 1 Searching tree conflict details for 'module1/m1file3new' in repository: Checking r7...subversion/libsvn_subr/token.c:40: (apr_err=SVN_ERR_ASSERTION_FAIL) svn: E235000: In file 'subversion/libsvn_subr/token.c' line 40: internal malfunction Aborted (core dumped) On 8/9/21 14:38, Joshua Kordani wrote: So unfortunately that simple case didn't reproduce the problem. So I need help investigating the state of things... On 8/9/21 14:09, Joshua Kordani wrote: The shell script is easy. I run resolve on my codebase :-). The trick will be recreating the repo history that reproduces this problem, and that has always been gnarly to me. I could use some advice for this. Basically, what I will try to do is create a folder with files. create a branch at this point, move a file in the branch, cherry pick this commit with the move into trunk, and then try a top level merge of the branch into trunk. Those are the things I did to the repo, I'm not sure if others mucked with it. If that doesn't work, I'll have to sleuth my repo and I'll need help to do that On 8/8/21 16:38, Stefan Sperling wrote: On Sun, Aug 08, 2021 at 10:26:43AM +0200, Daniel Sahlberg wrote: On 2021-08-07 17:14, Joshua Kordani wrote: Yes it does appear to fix the issue. Thank you! Hi Joshua (and list), I've been trying to reproduce your issue both to have test case for backporting the fix and possibly also adding to the test suite. However I can't reproduce it, possibly I misunderstand some of your steps. Do you know the exact steps to reproduce (when running without the patch, obviously)? Kind regards, Daniel Sahlberg I have committed my patch in https://svn.apache.org/r1892118 I agree that having a test case would be nice to prevent this issue from resurfacing accidentally. It could also help us to identify other similar scenarios that don't work right. If we had a shell script which reproduced the crash I could write a corresponding C test for the resolver. What we lack is the sequence of changes and merges which trigger the issue. Joshua, do you think you would be able to provide this sequence of steps, ideally as a self-contained shell script? We offer a suitable shell script template here: https://subversion.apache.org/docs/community-guide/repro-template.sh Regards, Stefan -- Joshua Kordani Senior Engineer Robotic Research, LLC jkord...@roboticresearch.com CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: Segfault in libsvn_client/conflicts.c
On Mon, Aug 09, 2021 at 02:09:40PM -0400, Joshua Kordani wrote: > The shell script is easy. I run resolve on my codebase :-). The trick will > be recreating the repo history that reproduces this problem, and that has > always been gnarly to me. I could use some advice for this. > > Basically, what I will try to do is create a folder with files. create a > branch at this point, move a file in the branch, cherry pick this commit > with the move into trunk, and then try a top level merge of the branch into > trunk. Those are the things I did to the repo, I'm not sure if others > mucked with it. If that doesn't work, I'll have to sleuth my repo and I'll > need help to do that svn log -v can help you figure out what copies and deletions have occurred. I suspect you have a case where some parent directory of the affected file has also been deleted or replaced somewhere along the line. Otherwise we should not get a NULL result when looking for the deleted node in the parent directory's history.
Crash in token.c after incomplete cherry pick merges in 1.15
Attached is a script to reproduce the error.
I also have a packed rr debugger session that I can provide (I highly
recommend the rr reversible debugger). Its ~30meg
--
Joshua Kordani
Senior Engineer
Robotic Research, LLC
jkord...@roboticresearch.com
CONFIDENTIALITY NOTICE: This communication may contain private, confidential
and privileged material for the sole use of the intended recipient. If you are
not the intended recipient, please delete this e-mail and any attachments
permanently.
#!/bin/bash
repo=$(mktemp -d)
wc=$(mktemp -d)
pushd /tmp/
svnadmin create $repo
svn co file:///$repo $wc
cd $wc
mkdir -p {trunk,branches/feature}/module{1,2}/
touch trunk/module1/m1file{1,2}
touch trunk/module2/m2file{1,2}
svn add trunk branches
svn commit -m "initial state"
svn copy -m "created feature" ^/trunk ^/branches/feature1
svn up
cd branches/feature1/module1
svn move m1file1 ../module2/m1file1-from-module1
cd ../
svn commit -m "Moved file to other module"
cd ../../trunk/
cd module1
svn up
svn merge -c3 ^/branches/feature1/module1 .
svn commit -m "cherry picked deletion into module folder"
touch mfile3
rm mfile3
touch m1file3
svn add m1file3
svn revert m1file3
rm m1file3
cd ../../branches/feature1/module1
touch m1file3
svn add m1file3
svn commit -m "created a new file in module1 of feature branch"
svn copy -m "made test branch of feature" ^/branches/feature{1,2}
svn up
cd ../../feature2
cd ../../feature2/
svn up
cd ../../
svn up
cd feature2
cd module1
touch m1file4
svn add m1file4
svn commit -m "meant to do this in the accidental branch I created called
feature (not feature1)"
echo meaningless1>m1file2
svn add m1file2
svn st
svn commit -m "meaningless change to module1 in test branch"
echo meaningless2 > m1file2
svn commit -m "meaningless change to module1 in test branch"
cd ../../feature1
svn merge ^/branches/feature2 .
svn commit -m "merged test into feature1 after file was created on test"
cd module1
svn move m1file4 m1file4new
svn commit -m "moved file4 in feature1 branch"
svn move m1file4new ../module2/
cd ../
svn commit -m "moved file4 from module1 to module2 in feature"
ls module1
ls module2
cd ../../
ls
cd branches/
cd ../trunk/
svn merge -c12 ^/branches/feature1/ .
svn up
svn merge -c12 ^/branches/feature1/ .
popd
#output below
# jkordani@host:~/Code/svncrash$ svnadmin create repo-1
# jkordani@host:~/Code/svncrash$ svn co file:///$(pwd)/repo-1 wc1.2
# Checked out revision 0.
# jkordani@host:~/Code/svncrash$ cd wc1.2
# jkordani@host:~/Code/svncrash/wc1.2$ mkdir -p
{trunk,branches/feature}/module{1,2}/
# jkordani@host:~/Code/svncrash/wc1.2$ touch trunk/module1/m1file{1,2}
# jkordani@host:~/Code/svncrash/wc1.2$ touch trunk/module2/m2file{1,2}
# jkordani@host:~/Code/svncrash/wc1.2$ svn add trunk branches
# A trunk
# A trunk/module1
# A trunk/module1/m1file1
# A trunk/module1/m1file2
# A trunk/module2
# A trunk/module2/m2file1
# A trunk/module2/m2file2
# A branches
# A branches/feature
# A branches/feature/module1
# A branches/feature/module2
# jkordani@host:~/Code/svncrash/wc1.2$ svn commit -m "initial state"
# Adding branches
# Adding branches/feature
# Adding branches/feature/module1
# Adding branches/feature/module2
# Adding trunk
# Adding trunk/module1
# Adding trunk/module1/m1file1
# Adding trunk/module1/m1file2
# Adding trunk/module2
# Adding trunk/module2/m2file1
# Adding trunk/module2/m2file2
# Transmitting file data done
# Committing transaction...
# Committed revision 1.
# jkordani@host:~/Code/svncrash/wc1.2$ svn copy ^/trunk ^/branches/feature1
# Waiting for Emacs...
# Log message unchanged or not specified
# (a)bort, (c)ontinue, (e)dit:
# a
# jkordani@host:~/Code/svncrash/wc1.2$ svn copy -m "created feature" ^/trunk
^/branches/feature1
# Committing transaction...
# Committed revision 2.
# jkordani@host:~/Code/svncrash/wc1.2$ svn up
# Updating '.':
# Abranches/feature1
# Abranches/feature1/module1
# Abranches/feature1/module1/m1file1
# Abranches/feature1/module1/m1file2
# Abranches/feature1/module2
# Abranches/feature1/module2/m2file1
# Abranches/feature1/module2/m2file2
# Updated to revision 2.
# jkordani@host:~/Code/svncrash/wc1.2$ cd branches/feature1/module1
# jkordani@host:~/Code/svncrash/wc1.2/branches/feature1/module1$ svn move
m1file1 ../module2/m1file1-from-module1
# A
/home/jkordani/Code/svncrash/wc1.2/branches/feature1/module2/m1file1-from-module1
# D m1file1
# jkordani@host:~/Code/svncrash/wc1.2/branches/feature1/module1$ #svn commit -m
"Moved file to other module"
# jkordani@host:~/Code/svncrash/wc1.2/branches/feature1/module1$ cd ../
# jkordani@host:~/Code/svncrash/wc1.2/branches/feature1$ svn commit -m "Moved
file to other module"
# Deleting module1/m1file1
# Adding module2/m1file1-from-module1
# Committing transaction..
Re: Segfault in libsvn_client/conflicts.c
So I've traced what happened to the path that causes a segfault, but I can't reproduce it with a simple example. I created develop branch, then a test branch from it. On the test branch I added a file, and merged the toplevel of the test branch back into devel I made a release branch from devel. On devel, I deleted the file I cherrypick merged this deletion at the top level of release I merged the toplevel of release back into devel On my work repo, this causes the crash. In a small repo where I have repeated these steps, it does not. On my work repo, svn can't figure out that the deletions on each side are the same, even though I've outlined the steps here. On my simple repo, the deletion is not performed, or else recognized to be related changes somehow. When I try to use the --ignore-ancestry merge on my test repo, I get the tree conflict but the resolution doesn't cause the crash. I'm not sure what else I can do at this point. I'd love to know why svn can't detect that these deletions are the same in my work repo... This kind of problem plagues us On 8/9/21 16:10, Stefan Sperling wrote: On Mon, Aug 09, 2021 at 02:09:40PM -0400, Joshua Kordani wrote: The shell script is easy. I run resolve on my codebase :-). The trick will be recreating the repo history that reproduces this problem, and that has always been gnarly to me. I could use some advice for this. Basically, what I will try to do is create a folder with files. create a branch at this point, move a file in the branch, cherry pick this commit with the move into trunk, and then try a top level merge of the branch into trunk. Those are the things I did to the repo, I'm not sure if others mucked with it. If that doesn't work, I'll have to sleuth my repo and I'll need help to do that svn log -v can help you figure out what copies and deletions have occurred. I suspect you have a case where some parent directory of the affected file has also been deleted or replaced somewhere along the line. Otherwise we should not get a NULL result when looking for the deleted node in the parent directory's history. -- Joshua Kordani Senior Engineer Robotic Research, LLC jkord...@roboticresearch.com CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
