Bug 165465 - svn can segv on export of working copy
svn can segv on export of working copy
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: subversion (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-09 12:33 EDT by Nigel Metheringham
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: 1.2.3-2.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-07 04:01:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nigel Metheringham 2005-08-09 12:33:34 EDT
Description of problem:
  $ svn export . /tmp/eview
  Segmentation fault

Version: subversion-1.2.1-2.1


How reproducible:
  On this working copy (which has been in use for a few months), every time.
  If I check out the data again then it works OK.
  Differences between working copy and new checkout are some minor meta-data
  changes (ie prop-time & text-time changes).


This is likely to be a bit of a heisenbug.
I have the affected directory tree around in case there are some diagnostics you
wish to perform on it.
strace is giveing no clues I can see - last few lines are:-
 write(4, "#!/usr/bin/perl\n#\n#\t$Id: upload_"..., 1594) = 1594
 close(4)                                = 0
 rename("/tmp/eview/evlogana/bin/upload_queue.pl.tmp",
"/tmp/eview/evlogana/bin/upload_queue.pl") = 0
 stat64("/tmp/eview/evlogana/bin/upload_queue.pl", {st_mode=S_IFREG|0664,
st_size=1594, ...}) = 0
 chmod("/tmp/eview/evlogana/bin/upload_queue.pl", 0775) = 0 
 stat64("/tmp/eview/evlogana/bin/upload_queue.pl", {st_mode=S_IFREG|0775, 
st_size=1594, ...}) = 0
 utimes("/tmp/eview/evlogana/bin/upload_queue.pl", {1123604392, 0}) = 0
 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
 +++ killed by SIGSEGV +++
Comment 1 Joe Orton 2005-08-09 12:41:22 EDT
Can you get a backtrace from the crash?  (install subversion-debuginfo, gdb svn,
"run export . blah", "backtrace full"?)
Comment 2 Joe Orton 2005-08-09 12:49:09 EDT
Never mind, this is fixed upstream for 1.2.2.

------------------------------------------------------------------------
r15579 | dlr | 2005-08-03 23:20:13 +0100 (Wed, 03 Aug 2005) | 6 lines

Merge r15516 from trunk for the 1.2.2 release, fixing a 'svn export
wc_path' client SEGV.

Votes:
+1: philip, sussman, dlr
Comment 3 Joe Orton 2005-08-09 12:53:44 EDT
Can you confirm that there is a file in the "deleted" state (i.e. an uncommitted
'svn rm' or 'svn mv') in the working copy which triggers the crash?
Comment 4 Nigel Metheringham 2005-08-10 04:08:43 EDT
There are no uncommitted changes within the tree.  [This was showing up as part
of my checkout and build an rpm script, so does a ci, tags the repo, exports,
tars & rpmbuilds.  The working copy will be in a clean state].

Just to be really annoying I cannot reproduce this problem today - yesterday of
course I couldn't not reproduce it.

Suggest this be pushed into a quiescent state and I'll re-open if I manage to
reproduce it.  Unfortunately it came up just around the time I needed to leave
in the evening so I didn't have time to collect backtrace info.  I have seen a
similar heisenbug style segv with export in a different svn build.
Comment 5 Joe Orton 2005-08-30 06:54:38 EDT
The 1.2.3 updates in testing have the "svn export" fixes mentioned above; you
could try those.

  # yum --enablerepo=updates-testing update subversion
Comment 6 Fedora Update System 2005-09-06 01:38:04 EDT
From User-Agent: XML-RPC

subversion-1.2.3-2.1 has been pushed for FC4, which should resolve this issue.

If these issues are still present in this version, then please re-open this bug.
Comment 7 Nigel Metheringham 2005-09-06 06:22:40 EDT
Confirm subversion-1.2.3-2.1 appears to fix the problem for me.
Comment 8 Joe Orton 2005-09-07 04:01:28 EDT
Thanks.

Note You need to log in before you can comment on or make changes to this bug.