abrt version: 1.1.13 architecture: i686 Attached file: backtrace cmdline: /usr/bin/perl /usr/sbin/bucardo_ctl --dbhost 192.168.1.68 show all component: bucardo executable: /usr/bin/perl kernel: 2.6.34.7-56.fc13.i686.PAE package: bucardo-4.4.0-2.fc13 rating: 3 reason: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) release: Fedora release 13 (Goddard) time: 1287004325 uid: 500
Created attachment 453670 [details] File: backtrace
What perl version are you using? Is it stable or testing?
1. perl -v This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi Copyright 1987-2009, Larry Wall 2. Stable
please report this bug against perl, seems to be a problem with perl
It does not have to be problem within perl. There is lot of XS modules (Pg, DBI) that can confuse perl as they manipulate with internal data structures by hand. Quick investigation shows mg_free() is called from Perl_sv_clear(). The mg_free() is macro expanded to Perl_mg_free() which is probably in-lined by compiler because it's not shown in the backtrace. The backtrace shows EIP out of mapped memmory. Thus the program has been killed by SIGSEGV. The EIP equals to EAX. It's computed indirect address clearly. I guess it's following code: Perl_mg_free(pTHX_ SV *sv) { MAGIC* mg; MAGIC* moremagic; PERL_ARGS_ASSERT_MG_FREE; for (mg = SvMAGIC(sv); mg; mg = moremagic) { const MGVTBL* const vtbl = mg->mg_virtual; moremagic = mg->mg_moremagic; if (vtbl && vtbl->svt_free) → CALL_FPTR(vtbl->svt_free)(aTHX_ sv, mg); More precisely, it could be the vtbl->svt_free pointer that is called as data structure destructor. However it points to invalid text memory (EIP=0x0a03bd58). Problem is nobody knows where the vtbl->svt_free is set. It can come from any DBI or Pg code, however gdb does not see Perl variables and perl debuger does not see C variables. Also reporter should note whether he can reproduce this bug or it was just a spurious event. Because without stable reproducer it's hard to debug it.