Bug 1043568

Summary: [abrt] subversion-1.8.3-1.fc20: addentry: Process /usr/bin/svn was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Alan Schmidt <bucky>
Component: subversionAssignee: Joe Orton <jorton>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: bucky, jorton, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/f31ce4a2b9a2454cb6ba47afa396e5c4e2107c1e
Whiteboard: abrt_hash:c2d3ca154e45ecbf046baceb648e865f81cf20e9
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-29 13:33:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages
none
/etc/magic with customizations for KML and GPX none

Description Alan Schmidt 2013-12-16 16:32:07 UTC
Description of problem:
Eclipse quit twice trying to commit a change.

Dropped to the command line.

Doing "svn add" asked for an "svn cleanup" first, which I did.

Doing "svn add " + two files resulted in the segfault that produced this abrt dialog, with subversion adding the first, and bombing on the second, leaving a lock in place.

Doing "svn cleanup" and "svn add" on the second file succeeded.

I can't rule out that it was something to do with Eclipse that caused the problem in the first place.

Version-Release number of selected component:
subversion-1.8.3-1.fc20

Additional info:
reporter:       libreport-2.1.9
backtrace_rating: 4
cmdline:        svn add cmsadmin/functions/cnt_sitemap_store.cfc cmsadmin/graphtek-cms/CMSMenu.js
crash_function: addentry
executable:     /usr/bin/svn
kernel:         3.11.10-301.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 addentry at apprentice.c:916
 #1 load_1 at apprentice.c:993
 #2 apprentice_load at apprentice.c:1177
 #3 apprentice_1 at apprentice.c:424
 #4 file_apprentice at apprentice.c:582
 #5 magic_load at magic.c:254
 #6 svn_magic__init at subversion/libsvn_subr/magic.c:88
 #7 add at subversion/libsvn_client/add.c:844
 #8 svn_client_add5 at subversion/libsvn_client/add.c:1026
 #9 svn_cl__add at subversion/svn/add-cmd.c:77

Comment 1 Alan Schmidt 2013-12-16 16:32:11 UTC
Created attachment 837320 [details]
File: backtrace

Comment 2 Alan Schmidt 2013-12-16 16:32:13 UTC
Created attachment 837321 [details]
File: cgroup

Comment 3 Alan Schmidt 2013-12-16 16:32:15 UTC
Created attachment 837322 [details]
File: core_backtrace

Comment 4 Alan Schmidt 2013-12-16 16:32:17 UTC
Created attachment 837323 [details]
File: dso_list

Comment 5 Alan Schmidt 2013-12-16 16:32:19 UTC
Created attachment 837324 [details]
File: environ

Comment 6 Alan Schmidt 2013-12-16 16:32:20 UTC
Created attachment 837325 [details]
File: exploitable

Comment 7 Alan Schmidt 2013-12-16 16:32:22 UTC
Created attachment 837326 [details]
File: limits

Comment 8 Alan Schmidt 2013-12-16 16:32:23 UTC
Created attachment 837327 [details]
File: maps

Comment 9 Alan Schmidt 2013-12-16 16:32:29 UTC
Created attachment 837328 [details]
File: open_fds

Comment 10 Alan Schmidt 2013-12-16 16:32:31 UTC
Created attachment 837329 [details]
File: proc_pid_status

Comment 11 Alan Schmidt 2013-12-16 16:32:32 UTC
Created attachment 837330 [details]
File: var_log_messages

Comment 12 Alan Schmidt 2013-12-16 22:09:10 UTC
Got it to happen without any prior eclipse activity.

Also, this time it is with:

subversion-1.8.5-2.fc20.x86_64

...which at the time of this writing is still in updates-testing.

Comment 13 Joe Orton 2013-12-17 09:07:43 UTC
That's a curious backtrace - it seems to be failing when parsing your /etc/magic.

Can you attach that file so we can try to reproduce?  It looks like you possibly have some custom lines in there.

#1  0x00007fd1b80c1a8b in load_1 (ms=ms@entry=0x7fd1bb9c5430, action=action@entry=0, fn=fn@entry=0x7fd1bb9ce200 "/etc/magic", errs=errs@entry=0x7fff0c26870c, mentry=mentry@entry=0x7fff0c268720, mentrycount=mentrycount@entry=0x7fff0c268710) at apprentice.c:993
        lineno = 32
        llen = 120
        line = 0x7fd1bb9c5f10 "0 string PK\\003\\004"
        len = <optimized out>
        me = {mp = 0x7fd1bb9d71d0, cont_count = 8, max_count = 10}
        f = <optimized out>

Comment 14 Alan Schmidt 2013-12-17 15:37:06 UTC
Created attachment 837744 [details]
/etc/magic with customizations for KML and GPX

Egad! That's my doing all right.

Comment 15 Alan Schmidt 2013-12-18 22:21:07 UTC
It doesn't look like it's sensitive at all to the type of file being "svn add"-ded.

It DOES look like I can consistently make it segfault as long as I provide at least two file arguments to "svn add":

e.g.:
  svn add x.css y.jpg
  svn add x.css y.jpg z.html

...both produce a segfault.

One file argument at a time (so far) always works fine.

Comment 16 Alan Schmidt 2014-01-15 18:57:44 UTC
Just so I'm clear:

Is the problem that 

1) subversion bombs on BAD /etc/magic customizations, or
2) subversion just so happens to be sensitive to the customizations I've done

?

In the first case, my best workaround to avoid a crash is to FIX my darn /etc/magic customizations (and educate myself better on what file -c is telling me).

In the second case, my only workaround right now is to REMOVE my darn /etc/magic customizations.

(there are worse cases, too, like (3) the problem can't be reproduced even WITH my modified /etc/magic)

Comment 17 Fedora End Of Life 2015-05-29 10:00:26 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 18 Fedora End Of Life 2015-06-29 13:33:10 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.