# git svn 2.26.0 segfault on fetch 2 messages from 2020-03-27 to 2020-03-27. Participants: Szőts Ákos, brian m. carlson. Thread: https://gitlist.dev/t/53114 ## Szőts Ákos, 2020-03-27 16:36 Subject: git svn 2.26.0 segfault on fetch Message-ID: URL: https://gitlist.dev/e/CAAr69zbzX%3DihOQLZRELWHaC42vs%3DXtNGkuJ%2BWhzeWaokPNcfAA%40mail.gmail.com ``` Dear list, When I use a "git svn fetch" on my git-SVN repository it dies with "error: git-svn died of signal 11". I tried to get a coredump or attach GDB to it but as I see in strace there are signal handlers attached to INT, HUP, TERM, QUIT, and PIPE and possibly because of them no coredumps are generated even with unlimited "-c" and also possibly because of this GDB doesn't stop on SIGSEGV. What I could do still with turned off ASLR is to run Valgrind with children tracking. It gave the following results: Warning: invalid file descriptor -1 in syscall close() Invalid read of size 4 at 0x9B1A82C: UnknownInlinedFun (atomic_base.h:419) by 0x9B1A82C: UnknownInlinedFun (qatomic_cxx11.h:239) by 0x9B1A82C: UnknownInlinedFun (qbasicatomic.h:107) by 0x9B1A82C: UnknownInlinedFun (qrefcount.h:66) by 0x9B1A82C: UnknownInlinedFun (qstring.h:1263) by 0x9B1A82C: UnknownInlinedFun (kaboutdata.cpp:460) by 0x9B1A82C: KAboutData::~KAboutData() (kaboutdata.cpp:583) by 0x9B1AADC: (anonymous namespace)::Q_QGS_s_registry::innerFunction()::Holder::~Holder() (kaboutdata.cpp:1041) by 0x4A63706: __run_exit_handlers (exit.c:108) by 0x4A638BB: exit (exit.c:139) by 0x154465: main (perlmain.c:171) Address 0x80cf1c0 is not stack'd, malloc'd or (recently) free'd Process terminating with default action of signal 11 (SIGSEGV): dumping core Access not within mapped region at address 0x80CF1C0 at 0x9B1A82C: UnknownInlinedFun (atomic_base.h:419) by 0x9B1A82C: UnknownInlinedFun (qatomic_cxx11.h:239) by 0x9B1A82C: UnknownInlinedFun (qbasicatomic.h:107) by 0x9B1A82C: UnknownInlinedFun (qrefcount.h:66) by 0x9B1A82C: UnknownInlinedFun (qstring.h:1263) by 0x9B1A82C: UnknownInlinedFun (kaboutdata.cpp:460) by 0x9B1A82C: KAboutData::~KAboutData() (kaboutdata.cpp:583) by 0x9B1AADC: (anonymous namespace)::Q_QGS_s_registry::innerFunction()::Holder::~Holder() (kaboutdata.cpp:1041) by 0x4A63706: __run_exit_handlers (exit.c:108) by 0x4A638BB: exit (exit.c:139) by 0x154465: main (perlmain.c:171) If you believe this happened as a result of a stack overflow in your program's main thread (unlikely but possible), you can try to increase the size of the main thread stack using the --main-stacksize= flag. The main thread stack size used in this run was 8388608. During stracing I found this line around the SIGSEGV: close(-1) = -1 EBADF If you could tell me how it's possible to attach GDB onto it, I'd be glad to provide you some backtraces as well. Version: 2.26.0. All the best, Ákos ``` ## brian m. carlson, 2020-03-27 21:26 Subject: Re: git svn 2.26.0 segfault on fetch Message-ID: <20200327212656.GM6499@camp.crustytoothpaste.net> URL: https://gitlist.dev/e/20200327212656.GM6499%40camp.crustytoothpaste.net In-Reply-To: ``` On 2020-03-27 at 16:36:56, Szőts Ákos wrote: > Dear list, > > When I use a "git svn fetch" on my git-SVN repository it dies with > "error: git-svn died of signal 11". > > I tried to get a coredump or attach GDB to it but as I see in strace > there are signal handlers attached to INT, HUP, TERM, QUIT, and PIPE > and possibly because of them no coredumps are generated even with > unlimited "-c" and also possibly because of this GDB doesn't stop on > SIGSEGV. Git uses the Subversion Perl bindings and git-svn is written entirely in Perl. While it's possible we've broken something, it's probably a little more likely that the Subversion Perl bindings on your system are a little broken and that's what's causing the issue. What operating system are you using? > What I could do still with turned off ASLR is to run Valgrind with > children tracking. It gave the following results: > > Warning: invalid file descriptor -1 in syscall close() > Invalid read of size 4 > at 0x9B1A82C: UnknownInlinedFun (atomic_base.h:419) > by 0x9B1A82C: UnknownInlinedFun (qatomic_cxx11.h:239) > by 0x9B1A82C: UnknownInlinedFun (qbasicatomic.h:107) > by 0x9B1A82C: UnknownInlinedFun (qrefcount.h:66) > by 0x9B1A82C: UnknownInlinedFun (qstring.h:1263) > by 0x9B1A82C: UnknownInlinedFun (kaboutdata.cpp:460) > by 0x9B1A82C: KAboutData::~KAboutData() (kaboutdata.cpp:583) > by 0x9B1AADC: (anonymous > namespace)::Q_QGS_s_registry::innerFunction()::Holder::~Holder() > (kaboutdata.cpp:1041) > by 0x4A63706: __run_exit_handlers (exit.c:108) > by 0x4A638BB: exit (exit.c:139) > by 0x154465: main (perlmain.c:171) > Address 0x80cf1c0 is not stack'd, malloc'd or (recently) free'd This looks like you're loading something with Qt. Are you using the Subversion KWallet integration? Does disabling it make things work? > Process terminating with default action of signal 11 (SIGSEGV): dumping core > Access not within mapped region at address 0x80CF1C0 > at 0x9B1A82C: UnknownInlinedFun (atomic_base.h:419) > by 0x9B1A82C: UnknownInlinedFun (qatomic_cxx11.h:239) > by 0x9B1A82C: UnknownInlinedFun (qbasicatomic.h:107) > by 0x9B1A82C: UnknownInlinedFun (qrefcount.h:66) > by 0x9B1A82C: UnknownInlinedFun (qstring.h:1263) > by 0x9B1A82C: UnknownInlinedFun (kaboutdata.cpp:460) > by 0x9B1A82C: KAboutData::~KAboutData() (kaboutdata.cpp:583) > by 0x9B1AADC: (anonymous > namespace)::Q_QGS_s_registry::innerFunction()::Holder::~Holder() > (kaboutdata.cpp:1041) > by 0x4A63706: __run_exit_handlers (exit.c:108) > by 0x4A638BB: exit (exit.c:139) > by 0x154465: main (perlmain.c:171) > If you believe this happened as a result of a stack > overflow in your program's main thread (unlikely but > possible), you can try to increase the size of the > main thread stack using the --main-stacksize= flag. > The main thread stack size used in this run was 8388608. > > During stracing I found this line around the SIGSEGV: > close(-1) = -1 EBADF > > If you could tell me how it's possible to attach GDB onto it, I'd be > glad to provide you some backtraces as well. You'd need to run something like the following: gdb --args /usr/bin/perl /usr/lib/git-core/git-svn Note that I don't use git-svn and remember next to nothing about using Subversion, so hopefully any information you provide makes sense to someone more familiar with git-svn than I. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 ```