Sigsegv from XS_DBI_dispatch during destruction
oschwald opened this issue · comments
#0 0x00007fe4614dc9e6 in XS_DBI_dispatch ()
from /home/greg/perl5/perlbrew/perls/perl-5.26.0/lib/site_perl/5.26.0/x86_64-linux/auto/DBI/DBI.so
#1 0x0000562e6b08be78 in Perl_pp_entersub ()
#2 0x0000562e6b009566 in Perl_call_sv ()
#3 0x0000562e6b090766 in S_curse ()
#4 0x0000562e6b09114d in Perl_sv_clear ()
#5 0x0000562e6b09144e in Perl_sv_free2 ()
#6 0x0000562e6b08f5f7 in S_visit ()
#7 0x0000562e6b0917ae in Perl_sv_clean_objs ()
#8 0x0000562e6b00bdb6 in perl_destruct ()
#9 0x0000562e6afeb4be in main ()
Unfortunately, I don't have a small test case for this. This is with 1.636.
Tested on Perl 5.26.0 and 5.24.0.
It would be a big help to get at least a line number.
This happens on Perl 5.26.2 and DBI 1.641.
Backtrace with line numbers:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f925d9159a3 in XS_DBI_dispatch (cv=0x8b32e48) at DBI.xs:3372
3372 DBI.xs: No such file or directory.
(gdb) bt
#0 0x00007f925d9159a3 in XS_DBI_dispatch (cv=0x8b32e48) at DBI.xs:3372
#1 0x000000000051286d in Perl_pp_entersub () at pp_hot.c:4228
#2 0x000000000044a666 in Perl_call_sv (sv=sv@entry=0x8b32e48, flags=<optimized out>, flags@entry=45) at perl.c:2856
#3 0x000000000051968d in S_curse (sv=sv@entry=0x2ae70b88, check_refcnt=check_refcnt@entry=true) at sv.c:6972
#4 0x0000000000519edc in Perl_sv_clear (orig_sv=orig_sv@entry=0x2ae70b88) at sv.c:6576
#5 0x000000000051ae5e in Perl_sv_free2 (sv=0x2ae70b88, rc=<optimized out>) at sv.c:7073
#6 0x00000000005172d2 in S_visit (f=0x51aff0 <do_clean_objs>, flags=2048, mask=2048) at sv.c:476
#7 0x000000000051b40c in Perl_sv_clean_objs () at sv.c:627
#8 0x000000000044e499 in perl_destruct (my_perl=<optimized out>) at perl.c:864
#9 0x00000000004224c4 in main (argc=3, argv=0x7fffc11651f8, env=0x7fffc1165218) at perlmain.c:134
I think the best advise I have is to try to manually clean up as much as possible before perl's internal global destruction gets started tearing the world apart semi-randomly. END { ... } blocks can be useful for that.
I don't think this issue is limited to global destruction. I frequently see the issue when the application is not otherwise exiting.