Bug#871562: perl-base: Perl binary crashes with SIGSEGV when used for SVN access in "git svn" tests

2017-08-20 Thread Niko Tyni
Control: found -1 5.26.0-5

On Wed, Aug 09, 2017 at 05:31:24PM +0300, Niko Tyni wrote:
> On Wed, Aug 09, 2017 at 11:16:03AM +0200, Alex Riesen wrote:
> > Package: perl-base
> > Version: 5.24.1-3+deb9u1
> > Severity: normal
> 
> > when I run the test suite (Git (the VCS, master branch), the perl binary
> > sometimes crashes in one of its tests. I used the commands below to 
> > reproduce
> > the problem (just let it run, it'll crash eventually):

> Anyway, I'll see if I can reproduce this when I find the time.

It's reproducible and happens on 5.26 too, but is indeed
nondeterministic. It's not specific to any particular git-svn command.
I've been experimenting with a loop like

 while ~/tmp/git/git-svn branch -t tag-$i; do i=$(expr $i + 1); done

which seems to crash every few hundred runs or so on my system. That's
rare enough that distilling a minimized test case is very hard.

Running with /usr/bin/debugperl from perl-debug (which is not optimized
and has assertions and the like enabled), I got the backtrace below.
I also got at least once these messages:

 error closing pipe: Bad file descriptor at /home/niko/tmp/git/git-svn line 0.
 Attempt to free unreferenced scalar: SV 0x3fbc6949d0, Perl interpreter: 
0x3fbb4a4010 at /usr/share/perl5/Git.pm line 1108 during global destruction.

Valgrind doesn't help much, trace below too. I don't see any earlier
out of bound writes or anything like that. Running with strace shows
mainly that it crashes at the very end, but we knew that already.

It looks to me like this happens during global destruction cleanup
when file handles get closed, and it's probably triggered by a specific
order of the DESTROY method calls (which is undefined and random.)

The abovementioned Git.pm:1108 is the last line of
_close_cat_blob(). Running with debugperl -DD (log attached) shows that
it crashes when cleaning 'cat_blob_out' of a Git object. That makes
me think it should be possible to reproduce it somehow just by running
Git::cat_blob() or so, but I haven't managed that yet.

I'm running out of steam for now so I thought it best to document the
current state of the investigations. The main thing missing is a smaller
test case, and it still seems at least possible that the svn bindings
are doing something naughty on the C side that causes this.

gdb backtrace:
=
Core was generated by `/usr/bin/debugperl /home/niko/tmp/git/git-svn branch -t 
tag-8354'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00bb84712cd1 in Perl_PerlIO_error 
(my_perl=my_perl@entry=0xbb8599e010, f=0xbb86b90c38)
at perlio.c:1696
1696perlio.c: No such file or directory.
(gdb) bt
#0  0x00bb84712cd1 in Perl_PerlIO_error 
(my_perl=my_perl@entry=0xbb8599e010, f=0xbb86b90c38)
at perlio.c:1696
#1  0x00bb846cfe7b in Perl_io_close (my_perl=0xbb8599e010, 
io=io@entry=0xbb86caafd0, gv=gv@entry=0x0, 
not_implicit=not_implicit@entry=true, warn_on_fail=warn_on_fail@entry=false) at 
doio.c:1124
#2  0x00bb846d007d in Perl_do_close (my_perl=my_perl@entry=0xbb8599e010, 
gv=, 
gv@entry=0xbb86c506d8, not_implicit=not_implicit@entry=true) at doio.c:1083
#3  0x00bb846af1d9 in Perl_pp_close (my_perl=0xbb8599e010) at pp_sys.c:683
#4  0x00bb845dbc9a in Perl_runops_debug (my_perl=0xbb8599e010) at 
dump.c:2451
#5  0x00bb845383be in Perl_call_sv (my_perl=my_perl@entry=0xbb8599e010, 
sv=sv@entry=0xbb85f67a40, flags=flags@entry=45) at perl.c:2848
#6  0x00bb84629c1a in S_curse (my_perl=my_perl@entry=0xbb8599e010, 
sv=sv@entry=0xbb869b6388, check_refcnt=check_refcnt@entry=true) at sv.c:6972
#7  0x00bb8462a5ad in Perl_sv_clear (my_perl=my_perl@entry=0xbb8599e010, 
orig_sv=orig_sv@entry=0xbb869b6388)
at sv.c:6576
#8  0x00bb8462b695 in Perl_sv_free2 (my_perl=0xbb8599e010, sv=0xbb869b6388, 
rc=) at sv.c:7073
#9  0x00bb8462750b in S_visit (my_perl=0xbb8599e010, f=0xbb8462bd30 
, flags=2048, mask=2048)
at sv.c:476
#10 0x00bb8462c2a6 in Perl_sv_clean_objs 
(my_perl=my_perl@entry=0xbb8599e010) at sv.c:627
#11 0x00bb8453d10a in perl_destruct (my_perl=0xbb8599e010) at perl.c:856
#12 0x00bb84509fc5 in main (argc=, argv=, 
env=)
at perlmain.c:134
=

valgrind:
=
28055== Invalid read of size 8
==28055==at 0x33FCC9: Perl_PerlIO_error (perlio.c:1696)
==28055==by 0x2FCD86: Perl_io_close (doio.c:1115)
==28055==by 0x2FD07C: Perl_do_close (doio.c:1083)
==28055==by 0x2DC1D8: Perl_pp_close (pp_sys.c:683)
==28055==by 0x208C99: Perl_runops_debug (dump.c:2451)
==28055==by 0x1653BD: Perl_call_sv (perl.c:2848)
==28055==by 0x256C19: S_curse (sv.c:6972)
==28055==by 0x2575AC: Perl_sv_clear (sv.c:6576)
==28055==by 0x258694: Perl_sv_free2 (sv.c:7073)
==28055==by 0x25450A: S_visit (sv.c:476)
==28055==by 0x2592A5: Perl_

Bug#871562: perl-base: Perl binary crashes with SIGSEGV when used for SVN access in "git svn" tests

2017-08-09 Thread Niko Tyni
On Wed, Aug 09, 2017 at 11:16:03AM +0200, Alex Riesen wrote:
> Package: perl-base
> Version: 5.24.1-3+deb9u1
> Severity: normal

> when I run the test suite (Git (the VCS, master branch), the perl binary
> sometimes crashes in one of its tests. I used the commands below to reproduce
> the problem (just let it run, it'll crash eventually):

Thanks for the thorough report. For now, I'll just note that there's been
somewhat similar bugs in the past on the libsvn-perl (src:subversion)
side that git-svn uses, see at least #780246 and #534763. I don't see
the SVN bindings in your backtrace so it may be something else, but in
that case a test case without SVN in the mix would be good of course.

Anyway, I'll see if I can reproduce this when I find the time.

> I had to recompile the perl package locally to get the details backtrace: I
> failed to find the debug symbols of the perl package here:
> deb http://debug.mirrors.debian.org/debian-debug/ stretch-debug main non-free 
> contrib

They are in the perl-debug package in the main archive, mostly for
historical reasons.
-- 
Niko Tyni   nt...@debian.org



Bug#871562: perl-base: Perl binary crashes with SIGSEGV when used for SVN access in "git svn" tests

2017-08-09 Thread Alex Riesen
Package: perl-base
Version: 5.24.1-3+deb9u1
Severity: normal

Dear Maintainer,

when I run the test suite (Git (the VCS, master branch), the perl binary
sometimes crashes in one of its tests. I used the commands below to reproduce
the problem (just let it run, it'll crash eventually):

$ git clone git://git.kernel.org/pub/scm/git/git.git && cd git
$ make USE_LIBPCRE2=YesPlease   (requires curl-dev and openssl-dev, I think...)
$ cd t (the test suite)
$ ulimit -c unlimited
$ rm -rf 'trash directory.t9128-git-svn-cmd-branch'
$ while ./t9128-git-svn-cmd-branch.sh -d -i
do
  echo; echo
  rm -rf 'trash directory.t9128-git-svn-cmd-branch'
done
...
not ok 3 - git svn branch tests
#
#   git svn branch a &&
#   base=$(git rev-parse HEAD:) &&
#   test $base = $(git rev-parse remotes/origin/a:) &&
#   git svn branch -m "created branch b blah" b &&
#   test $base = $(git rev-parse remotes/origin/b:) &&
#   test_must_fail git branch -m "no branchname" &&
#   git svn branch -n c &&
#   test_must_fail git rev-parse remotes/origin/c &&
#   test_must_fail git svn branch a &&
#   git svn branch -t tag1 &&
#   test $base = $(git rev-parse remotes/origin/tags/tag1:) &&
#   git svn branch --tag tag2 &&
#   test $base = $(git rev-parse remotes/origin/tags/tag2:) &&
#   git svn tag tag3 &&
#   test $base = $(git rev-parse remotes/origin/tags/tag3:) &&
#   git svn tag -m "created tag4 foo" tag4 &&
#   test $base = $(git rev-parse remotes/origin/tags/tag4:) &&
#   test_must_fail git svn tag -m "no tagname" &&
#   git svn tag -n tag5 &&
#   test_must_fail git rev-parse remotes/origin/tags/tag5 &&
#   test_must_fail git svn tag tag1
#
$ gdb /usr/bin/perl './trash directory.t9128-git-svn-cmd-branch/core'
...
(gdb) bt full
#0  0x00b2ce983b10 in Perl_sv_clear (my_perl=my_perl@entry=0xb2cefdf010, 
orig_sv=orig_sv@entry=0xb2d00807e8) at sv.c:6582
stash = 
type = 9
sv_type_details = 
iter_sv = 0x0
next_sv = 0x0
sv = 0xb2d00807e8
hash_index = 0
#1  0x00b2ce983da0 in Perl_sv_free2 (my_perl=my_perl@entry=0xb2cefdf010, 
sv=sv@entry=0xb2d00807e8, rc=) at sv.c:6954
No locals.
#2  0x00b2ce8fd8a5 in S_SvREFCNT_dec (sv=0xb2d00807e8, 
my_perl=0xb2cefdf010) at inline.h:166
rc = 
#3  Perl_gp_free (my_perl=my_perl@entry=0xb2cefdf010, gv=gv@entry=0xb2d0080938) 
at gv.c:2568
file_hek = 
hv = 
io = 0xb2d00807e8
form = 0x0
sv = 
cv = 0x0
av = 0x0
gp = 
attempts = 100
#4  0x00b2ce983b74 in Perl_sv_clear (my_perl=my_perl@entry=0xb2cefdf010, 
orig_sv=orig_sv@entry=0xb2d00e92c0) at sv.c:6585
stash = 
type = 9
sv_type_details = 
iter_sv = 0x0
next_sv = 0x0
sv = 0xb2d0080938
hash_index = 0
#5  0x00b2ce983da0 in Perl_sv_free2 (my_perl=my_perl@entry=0xb2cefdf010, 
sv=0xb2d00e92c0, rc=) at sv.c:6954
No locals.
#6  0x00b2ce972ad2 in S_SvREFCNT_dec (sv=, 
my_perl=0xb2cefdf010) at inline.h:166
rc = 
#7  S_hv_delete_common (hash=, d_flags=68, k_flags=, klen=, key=, keysv=, 
hv=0xb2cefdf010, my_perl=0xb2d007db68) at hv.c:1279
xhv = 
first_entry = 
stash = 
entry = 0xb2d00e4828
keysv_hek = 
mro_changes = 
sv = 
oentry = 0xb2d007db68
is_utf8 = false
masked_flags = 
gv = 
#8  Perl_hv_common (my_perl=my_perl@entry=0xb2cefdf010, 
hv=hv@entry=0xb2cfff4e10, keysv=, key=, 
key@entry=0x0, klen=, klen@entry=0, flags=, 
flags@entry=0, action=68, val=0x0, hash=) at hv.c:397
xhv = 
entry = 
oentry = 
sv = 
is_utf8 = false
masked_flags = 
return_svp = 0
keysv_hek = 0x0
#9  0x00b2ce9aca1f in Perl_pp_delete (my_perl=0xb2cefdf010) at pp.c:5061
_p = 
sv = 
mark = 0xb2cf00fed8
origmark = 0
hv = 0xb2cfff4e10
hvtype = 
sp = 0xb2cf00fee0
gimme = 1 '\001'
discard = 4
#10 0x00b2ce976916 in Perl_runops_standard (my_perl=0xb2cefdf010) at 
run.c:41
op = 
#11 0x00b2ce8f4aee in Perl_call_sv (my_perl=my_perl@entry=0xb2cefdf010, 
sv=0xb2cf546fd0, flags=flags@entry=45) at perl.c:2812
myop = {
  op_next = 0x0,
  op_sibling = 0x0,
  op_ppaddr = 0x0,
  op_targ = 0,
  op_type = 0,
  op_opt = 0,
  op_slabbed = 0,
  op_savefree = 0,
  op_static = 0,
  op_folded = 0,
  op_moresib = 0,
  op_spare = 0,
  op_flags = 65 'A',
  op_private = 0 '\000',
  op_first = 0x0,
  op_other = 0x7fffe7a15bf0
}
method_op = {
  op_next = 0x7fffe7a15c78,
  o