You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Gustavo Chaves <gu...@gnustavo.com> on 2016/06/14 22:57:39 UTC
Segmentation fault in "svn resolve"
I got a "segmentation fault" while performing a "svn resolve" to resolve a
conflict in a file with the svn:mime-type property set to
application/octet-stream. I got the same error using the WANdisco packages
for svn-1.9.4 at RHEL and using Ubuntu 16.04 native package for svn-1.9.3.
I was able to reproduce the problem in a small scale following the steps
below, in my Ubuntu 16.04 machine.
Should I open an issue?
--
Gustavo.
Script started on Tue Jun 14 19:26:20 2016
$ type svn
svn is /usr/bin/svn
$ dpkg -S /usr/bin/svn
subversion: /usr/bin/svn
$ dpkg -l subversion | tail -1
ii subversion 1.9.3-2ubuntu1 amd64 Advanced version control system
$ ulimit -c unlimited
$ svnadmin create repo
$ svn mkdir file://$PWD/repo/{trunk,branches,tags} -m'start'
Committing transaction...
Committed revision 1.
$ svn co file://$PWD/repo/trunk wc
Checked out revision 1.
$ cd wc
/home/gustavo/tmp/svn/bug/wc
$ echo asdf >file
$ svn add file
A file
$ svn ps svn:mime-type application/octet-stream file
svn: warning: 'application/octet-stream' is a binary mime-type but file
'/home/gustavo/tmp/svn/bug/wc/file' looks like text; diff, merge, blame,
and other operations will stop working on this file
property 'svn:mime-type' set on 'file'
$ svn ci -m'add file'
Adding (bin) file
Transmitting file data .done
Committing transaction...
Committed revision 2.
$ svn cp ^/trunk ^/branches/b -m'create branch'
Committing transaction...
Committed revision 3.
$ echo trunk >>file
$ svn ci -m'add line in trunk'
Sending file
Transmitting file data .done
Committing transaction...
Committed revision 4.
$ svn switch ^/branches/b
U file
Updated to revision 4.
$ echo branch >>file
$ svn ci -m'add line in branch'
Sending file
Transmitting file data .done
Committing transaction...
Committed revision 5.
$ svn up
Updating '.':
At revision 5.
$ svn merge ^/trunk
--- Merging r3 through r5 into '.':
C file
--- Recording mergeinfo for merge of r3 through r5 into '.':
U .
Summary of conflicts:
Text conflicts: 1
$ svn status
M .
C file
? file.merge-left.r2
? file.merge-right.r5
Summary of conflicts:
Text conflicts: 1
$ svn resolve --accept mine-conflict file
Segmentation fault (core dumped)
$ ls -l
total 3604
-rw------- 1 gustavo gustavo 3678208 Jun 14 19:31 core
-rw-rw-r-- 1 gustavo gustavo 12 Jun 14 19:29 file
-rw------- 1 gustavo gustavo 5 Jun 14 19:30 file.merge-left.r2
-rw------- 1 gustavo gustavo 11 Jun 14 19:30 file.merge-right.r5
$ gdb /usr/lib/debug/usr/bin/svn core
GNU gdb (Ubuntu 7.11-0ubuntu1) 7.11
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/debug/usr/bin/svn...done.
[New LWP 25527]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `svn resolve --accept mine-conflict file'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1 0x00007faf2a27066d in check_cstring_utf8 (data=data@entry=0x0,
pool=pool@entry=0x7faf2b241028) at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_subr/utf.c:676
#2 0x00007faf2a270c3c in svn_utf_cstring_from_utf8
(dest=dest@entry=0x7ffcb44752f0,
src=src@entry=0x0, pool=pool@entry=0x7faf2b241028)
at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_subr/utf.c:901
#3 0x00007faf2a25cbe6 in svn_path_cstring_from_utf8
(path_apr=path_apr@entry=0x7ffcb44752f0, path_utf8=path_utf8@entry=0x0,
pool=pool@entry=0x7faf2b241028)
at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_subr/path.c:1141
#4 0x00007faf2a24dfa8 in cstring_from_utf8 (pool=0x7faf2b241028,
path_utf8=0x0, path_apr=0x7ffcb44752f0) at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_subr/io.c:221
#5 svn_io_file_open (new_file=new_file@entry=0x7ffcb44759f8, fname=0x0,
flag=flag@entry=1, perm=perm@entry=4095, pool=0x7faf2b241028)
at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_subr/io.c:3654
#6 0x00007faf2a525cd6 in datasources_open (baton=0x7ffcb44759a0,
prefix_lines=0x7ffcb44758d0, suffix_lines=0x7ffcb44758d8,
datasources=0x7ffcb44758e0, datasources_len=3)
at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_diff/diff_file.c:797
#7 0x00007faf2a523470 in svn_diff_diff3_2 (diff=diff@entry=0x7ffcb4475b70,
diff_baton=diff_baton@entry=0x7ffcb44759a0, vtable=vtable@entry=0x7faf2a732b00
<svn_diff.file_vtable>, pool=pool@entry=0x7faf2b247028)
at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_diff/diff3.c:276
#8 0x00007faf2a527212 in svn_diff_file_diff3_2
(diff=diff@entry=0x7ffcb4475b70,
original=original@entry=0x7faf2b2470e8
"/home/gustavo/tmp/svn/bug/wc/file.merge-left.r2", modified=modified@entry
=0x0,
latest=latest@entry=0x7faf2b247160
"/home/gustavo/tmp/svn/bug/wc/file.merge-right.r5",
options=options@entry=0x7faf2b247198,
pool=pool@entry=0x7faf2b247028)
at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_diff/diff_file.c:1349
#9 0x00007faf2ab70c49 in merge_showing_conflicts
(delete_when=svn_io_file_del_none, scratch_pool=0x7faf2b247028,
result_pool=0x7faf2b247028, cancel_baton=0x0, cancel_func=0x41c0d0
<svn_cl__check_cancel>,
right_abspath=0x7faf2b247160
"/home/gustavo/tmp/svn/bug/wc/file.merge-right.r5",
detranslated_target=0x0, left_abspath=0x7faf2b2470e8
"/home/gustavo/tmp/svn/bug/wc/file.merge-left.r2", merge_options=0x0,
style=svn_diff_conflict_display_modified, wri_abspath=0x7faf2b24b180
"/home/gustavo/tmp/svn/bug/wc/file", db=0x7faf2b24dd18,
chosen_abspath=0x7ffcb4475b58)
at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_wc/conflicts.c:1450
#10 build_text_conflict_resolve_items
(work_items=work_items@entry=0x7ffcb4475c50,
found_artifact=found_artifact@entry=0x7ffcb4475c34, db=db@entry
=0x7faf2b24dd18,
local_abspath=local_abspath@entry=0x7faf2b24b180
"/home/gustavo/tmp/svn/bug/wc/file", conflict=<optimized out>,
choice=choice@entry=svn_wc_conflict_choose_mine_conflict, merged_file=0x0,
save_merged=0,
merge_options=0x0, cancel_func=0x41c0d0 <svn_cl__check_cancel>,
cancel_baton=0x0, result_pool=0x7faf2b247028, scratch_pool=0x7faf2b247028)
at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_wc/conflicts.c:1636
#11 0x00007faf2ab72bf3 in conflict_status_walker
(baton=baton@entry=0x7ffcb4475fe0,
local_abspath=local_abspath@entry=0x7faf2b24b180
"/home/gustavo/tmp/svn/bug/wc/file", status=<optimized out>,
scratch_pool=scratch_pool@entry=0x7faf2b24b028) at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_wc/conflicts.c:3036
#12 0x00007faf2ab99260 in send_status_structure (wb=wb@entry=0x7ffcb4475ed0,
local_abspath=local_abspath@entry=0x7faf2b24b180
"/home/gustavo/tmp/svn/bug/wc/file",
parent_repos_root_url=parent_repos_root_url@entry=0x7faf2b24bd90
"file:///home/gustavo/tmp/svn/bug/repo",
parent_repos_relpath=parent_repos_relpath@entry=0x7faf2b24bd80
"branches/b",
parent_repos_uuid=parent_repos_uuid@entry=0x7faf2b24bdb8
"894f1137-aff6-42e5-98a3-d85ac20a33eb", info=info@entry=0x7faf2b24b7a0,
dirent=0x7faf2b24bc28, get_all=0,
status_func=0x7faf2ab72970 <conflict_status_walker>,
status_baton=0x7ffcb4475fe0, scratch_pool=0x7faf2b24b028) at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_wc/status.c:834
#13 0x00007faf2ab9a083 in one_child_status (wb=wb@entry=0x7ffcb4475ed0,
local_abspath=local_abspath@entry=0x7faf2b24b180
"/home/gustavo/tmp/svn/bug/wc/file",
parent_abspath=parent_abspath@entry=0x7faf2b24bc40
"/home/gustavo/tmp/svn/bug/wc", info=info@entry=0x7faf2b24b7a0,
dirent=dirent@entry=0x7faf2b24bc28,
dir_repos_root_url=0x7faf2b24bd90
"file:///home/gustavo/tmp/svn/bug/repo", dir_repos_relpath=0x7faf2b24bd80
"branches/b", dir_repos_uuid=0x7faf2b24bdb8
"894f1137-aff6-42e5-98a3-d85ac20a33eb",
unversioned_tree_conflicted=<optimized out>,
collected_ignore_patterns=0x7ffcb4475ec8, ignore_patterns=0x7faf2b24b558,
depth=svn_depth_empty, get_all=0, no_ignore=1,
status_func=0x7faf2ab72970 <conflict_status_walker>,
status_baton=0x7ffcb4475fe0, cancel_func=0x41c0d0 <svn_cl__check_cancel>,
cancel_baton=0x0, result_pool=0x7faf2b24b028, scratch_pool=0x7faf2b24b028)
at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_wc/status.c:1111
#14 0x00007faf2ab9ba7b in get_child_status (scratch_pool=0x7faf2b24b028,
cancel_baton=0x0, cancel_func=0x41c0d0 <svn_cl__check_cancel>,
status_baton=0x7ffcb4475fe0,
status_func=0x7faf2ab72970 <conflict_status_walker>, get_all=0,
ignore_patterns=0x7faf2b24b558, dirent=0x7faf2b24bc28, info=<optimized
out>, local_abspath=0x7faf2b24b180 "/home/gustavo/tmp/svn/bug/wc/file",
wb=0x7ffcb4475ed0) at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_wc/status.c:1443
#15 svn_wc__internal_walk_status (db=<optimized out>,
local_abspath=local_abspath@entry=0x7faf2b24b180
"/home/gustavo/tmp/svn/bug/wc/file", depth=depth@entry=svn_depth_empty,
get_all=get_all@entry=0,
no_ignore=no_ignore@entry=0, ignore_text_mods=ignore_text_mods@entry=1,
ignore_patterns=0x7faf2b24b558, status_func=0x7faf2ab72970
<conflict_status_walker>, status_baton=0x7ffcb4475fe0,
cancel_func=0x41c0d0 <svn_cl__check_cancel>, cancel_baton=0x0,
scratch_pool=0x7faf2b24b028) at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_wc/status.c:2706
#16 0x00007faf2ab9baf8 in svn_wc_walk_status
(wc_ctx=wc_ctx@entry=0x7faf2b24dd00,
local_abspath=local_abspath@entry=0x7faf2b24b180
"/home/gustavo/tmp/svn/bug/wc/file", depth=depth@entry=svn_depth_empty,
get_all=get_all@entry=0, no_ignore=no_ignore@entry=0,
ignore_text_mods=ignore_text_mods@entry=1, ignore_patterns=0x0,
status_func=0x7faf2ab72970 <conflict_status_walker>,
status_baton=0x7ffcb4475fe0,
cancel_func=0x41c0d0 <svn_cl__check_cancel>, cancel_baton=0x0,
scratch_pool=0x7faf2b24b028) at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_wc/status.c:2746
#17 0x00007faf2ab73da7 in svn_wc__resolve_conflicts (wc_ctx=0x7faf2b24dd00,
local_abspath=0x7faf2b24b180 "/home/gustavo/tmp/svn/bug/wc/file",
depth=<optimized out>, depth@entry=svn_depth_empty,
resolve_text=resolve_text@entry=1,
resolve_prop=resolve_prop@entry=0x7faf2ae61f1f
"", resolve_tree=resolve_tree@entry=1,
conflict_choice=svn_wc_conflict_choose_mine_conflict,
conflict_func=0x40c7c0 <svn_cl__conflict_func_interactive>,
conflict_baton=0x7faf2b24ebb0, cancel_func=0x41c0d0 <svn_cl__check_cancel>,
cancel_baton=0x0, notify_func=0x415590 <notify>,
notify_baton=0x7faf2b24de40, scratch_pool=0x7faf2b24b028) at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_wc/conflicts.c:3166
#18 0x00007faf2ae59153 in svn_client_resolve (path=path@entry=0x7faf2b24ee20
"file", depth=svn_depth_empty, conflict_choice=conflict_choice@entry
=svn_wc_conflict_choose_mine_conflict,
ctx=ctx@entry=0x7faf2b24dc30, pool=pool@entry=0x7faf2b24b028) at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_client/resolved.c:128
#19 0x000000000041a00e in svn_cl__resolve (os=<optimized out>,
baton=<optimized out>, scratch_pool=<optimized out>) at
/build/subversion-yttRtj/subversion-1.9.3/subversion/svn/resolve-cmd.c:112
#20 0x000000000041c0d0 in ?? () at
/build/subversion-yttRtj/subversion-1.9.3/subversion/svn/svn.c:1795
#21 0x000000002b2890a0 in ?? ()
#22 0x00007faf2b24ee28 in ?? ()
#23 0xb26b2ae63a795000 in ?? ()
#24 0x00000000004123b0 in ?? () at
/build/subversion-yttRtj/subversion-1.9.3/subversion/svn/lock-cmd.c:102
#25 0x00007faf2b289028 in ?? ()
#26 0x00000000004123b0 in ?? () at
/build/subversion-yttRtj/subversion-1.9.3/subversion/svn/lock-cmd.c:102
---Type <return> to continue, or q <return> to quit---
#27 0x00007faf2b28a9e0 in ?? ()
#28 0x0000000000643878 in svn_cl.cmd_table ()
#29 0x00007ffcb4476250 in ?? ()
#30 0x0000000000000000 in ?? ()
(gdb) q
$ exit
Script done on Tue Jun 14 19:32:21 2016
Re: Segmentation fault in "svn resolve"
Posted by Stefan Hett <st...@egosoft.com>.
On 6/15/2016 10:26 AM, Stefan Sperling wrote:
> On Wed, Jun 15, 2016 at 10:13:08AM +0200, Stefan wrote:
>> This sounds utterly familiar to me:
>>
>> See this mail on the dev list: "[PATCH] error handling for
>> build_text_conflict_resolve_items" from 02/01/16:
>> http://mail-archives.apache.org/mod_mbox/subversion-dev/201602.mbox/%3C56AEA607.7030209%40posteo.de%3E
>>
>> The position you add the check seems to differ slightly (I added the
>> mine_abspath check above the line which determines the conflict style,
>> but I'd be +1 (non-binding) with any of the two patches.
>>
>> Regards,
>> Stefan
> Ah, I had missed that. Thanks!
>
> Too bad this fell through the cracks back in February. Please try to
> ping your own patches if you don't get a reply. We have a patch manager
> role in the community who regularly pings every patch posted, but our
> last patch manager has gone AWOL.
> http://subversion.apache.org/docs/community-guide/roles.html#patch-manager
I kept it on my backlog, but since I got no replies, I thought best to
get a repro case demonstrating the issue and verifying the proposed fix
really solves the issue (so it's verifiable).
Unfortunately, I simply didn't get to that yet. So glad, you picked it
up. :-)
> One problem with your version of this fix is that it creates a case
> where we run code before a variable declaration in the same block.
> We can't do that because we remain compatible with old compilers.
Oh right. Completely overlooked that C89 violation in my patch. Nice spot.
--
Regards,
Stefan Hett, Developer/Administrator
EGOSOFT GmbH, Heidestrasse 4, 52146 Wrselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschftsfhrer: Bernd Lehahn, Handelsregister Aachen HRB 13473
Re: Segmentation fault in "svn resolve"
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jun 15, 2016 at 10:13:08AM +0200, Stefan wrote:
> This sounds utterly familiar to me:
>
> See this mail on the dev list: "[PATCH] error handling for
> build_text_conflict_resolve_items" from 02/01/16:
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201602.mbox/%3C56AEA607.7030209%40posteo.de%3E
>
> The position you add the check seems to differ slightly (I added the
> mine_abspath check above the line which determines the conflict style,
> but I'd be +1 (non-binding) with any of the two patches.
>
> Regards,
> Stefan
Ah, I had missed that. Thanks!
Too bad this fell through the cracks back in February. Please try to
ping your own patches if you don't get a reply. We have a patch manager
role in the community who regularly pings every patch posted, but our
last patch manager has gone AWOL.
http://subversion.apache.org/docs/community-guide/roles.html#patch-manager
One problem with your version of this fix is that it creates a case
where we run code before a variable declaration in the same block.
We can't do that because we remain compatible with old compilers.
Re: Segmentation fault in "svn resolve"
Posted by Stefan <lu...@posteo.de>.
On 6/15/2016 09:55, Stefan Sperling wrote:
> On Wed, Jun 15, 2016 at 09:33:52AM +0200, Stefan Sperling wrote:
>> On Tue, Jun 14, 2016 at 07:57:39PM -0300, Gustavo Chaves wrote:
>>> I got a "segmentation fault" while performing a "svn resolve" to resolve a
>>> conflict in a file with the svn:mime-type property set to
>>> application/octet-stream. I got the same error using the WANdisco packages
>>> for svn-1.9.4 at RHEL and using Ubuntu 16.04 native package for svn-1.9.3.
>>>
>>> I was able to reproduce the problem in a small scale following the steps
>>> below, in my Ubuntu 16.04 machine.
>>>
>>> Should I open an issue?
>> I can reproduce this problem. I will fix it. Thanks for your report!
> The problem here is that the working copy code wrongly assumes it can
> create a merged version of the file.
>
> I think we should fix it like this. Does this make sense?
>
> $ svn resolve --accept mc file
> svn: warning: apr_err=SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE
> svn: warning: W155027: Conflict on '/tmp/svn-sandbox/branch/file' cannot be resolved to 'theirs-conflict' or 'mine-conflict' because a merged version of the file cannot be created.
>
> Index: subversion/libsvn_wc/conflicts.c
> ===================================================================
> --- subversion/libsvn_wc/conflicts.c (revision 1748508)
> +++ subversion/libsvn_wc/conflicts.c (working copy)
> @@ -1633,6 +1633,15 @@ build_text_conflict_resolve_items(svn_skel_t **wor
> ? svn_diff_conflict_display_latest
> : svn_diff_conflict_display_modified;
>
> + if (mine_abspath == NULL)
> + return svn_error_createf(SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE, NULL,
> + _("Conflict on '%s' cannot be resolved to "
> + "'theirs-conflict' or 'mine-conflict' "
> + "because a merged version of the file "
> + "cannot be created."),
> + svn_dirent_local_style(local_abspath,
> + scratch_pool));
> +
> SVN_ERR(merge_showing_conflicts(&install_from_abspath,
> db, local_abspath,
> style, merge_options,
This sounds utterly familiar to me:
See this mail on the dev list: "[PATCH] error handling for
build_text_conflict_resolve_items" from 02/01/16:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201602.mbox/%3C56AEA607.7030209%40posteo.de%3E
The position you add the check seems to differ slightly (I added the
mine_abspath check above the line which determines the conflict style,
but I'd be +1 (non-binding) with any of the two patches.
Regards,
Stefan
Re: Segmentation fault in "svn resolve"
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jun 15, 2016 at 09:33:52AM +0200, Stefan Sperling wrote:
> On Tue, Jun 14, 2016 at 07:57:39PM -0300, Gustavo Chaves wrote:
> > I got a "segmentation fault" while performing a "svn resolve" to resolve a
> > conflict in a file with the svn:mime-type property set to
> > application/octet-stream. I got the same error using the WANdisco packages
> > for svn-1.9.4 at RHEL and using Ubuntu 16.04 native package for svn-1.9.3.
> >
> > I was able to reproduce the problem in a small scale following the steps
> > below, in my Ubuntu 16.04 machine.
> >
> > Should I open an issue?
>
> I can reproduce this problem. I will fix it. Thanks for your report!
The problem here is that the working copy code wrongly assumes it can
create a merged version of the file.
I think we should fix it like this. Does this make sense?
$ svn resolve --accept mc file
svn: warning: apr_err=SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE
svn: warning: W155027: Conflict on '/tmp/svn-sandbox/branch/file' cannot be resolved to 'theirs-conflict' or 'mine-conflict' because a merged version of the file cannot be created.
Index: subversion/libsvn_wc/conflicts.c
===================================================================
--- subversion/libsvn_wc/conflicts.c (revision 1748508)
+++ subversion/libsvn_wc/conflicts.c (working copy)
@@ -1633,6 +1633,15 @@ build_text_conflict_resolve_items(svn_skel_t **wor
? svn_diff_conflict_display_latest
: svn_diff_conflict_display_modified;
+ if (mine_abspath == NULL)
+ return svn_error_createf(SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE, NULL,
+ _("Conflict on '%s' cannot be resolved to "
+ "'theirs-conflict' or 'mine-conflict' "
+ "because a merged version of the file "
+ "cannot be created."),
+ svn_dirent_local_style(local_abspath,
+ scratch_pool));
+
SVN_ERR(merge_showing_conflicts(&install_from_abspath,
db, local_abspath,
style, merge_options,
Re: Segmentation fault in "svn resolve"
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Jun 14, 2016 at 07:57:39PM -0300, Gustavo Chaves wrote:
> I got a "segmentation fault" while performing a "svn resolve" to resolve a
> conflict in a file with the svn:mime-type property set to
> application/octet-stream. I got the same error using the WANdisco packages
> for svn-1.9.4 at RHEL and using Ubuntu 16.04 native package for svn-1.9.3.
>
> I was able to reproduce the problem in a small scale following the steps
> below, in my Ubuntu 16.04 machine.
>
> Should I open an issue?
I can reproduce this problem. I will fix it. Thanks for your report!