Bug 1317280
| Summary: | (perl) segfault when running ical2rem.pl | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tiger!P <redhat-tigerp> | ||||
| Component: | perl | Assignee: | Jitka Plesnikova <jplesnik> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 23 | CC: | cweyl, iarnell, jplesnik, kasal, perl-devel, ppisar, psabata, rc040203, tcallawa | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-03-14 17:33:53 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Could you show me more details? Like what iCal::Parser you use. What the input looks like. What arguments you pass to the script. And how back trace from the segfaulted program looks like. I tried to parse t/calendars/11complex.ics from iCal-Parser-1.20 sources with this command:
$ perl ical2rem.pl <11complex.ics
REM MSG Calendar ToDos:%"%"%
REM Nov 13 2004 +3 MSG %a todo 4%"%"%
REM Nov 14 2004 +5 MSG %a todo 3%"%"%
REM Nov 20 2004 +3 PRIORITY 1000 MSG %a todo 2%"%"%
REM MSG %"%"%
REM MSG Calendar Events:%"%"%
It works for me in Fedora 23.
I suspect you upgraded from old perl and you did not recompile your private XS modules against new perl. Because perl breaks binary compatibility between new releases, loading XS modules that were built against different perl can cause a segfault. You can check it with a strace tool like:
$ strace -e open perl ical2rem.pl <11complex.ics 2>&1 >/dev/null |grep \\.so
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libperl.so.5.22", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnsl.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libutil.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libfreebl3.so", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/perl5/vendor_perl/auto/List/Util/Util.so", O_RDONLY|O_CLOEXEC) = 9
open("/usr/lib64/perl5/vendor_perl/auto/Sub/Name/Name.so", O_RDONLY|O_CLOEXEC) = 11
open("/usr/lib64/perl5/vendor_perl/auto/Params/Validate/XS/XS.so", O_RDONLY|O_CLOEXEC) = 8
open("/usr/lib64/perl5/vendor_perl/auto/List/MoreUtils/MoreUtils.so", O_RDONLY|O_CLOEXEC) = 11
open("/usr/lib64/perl5/vendor_perl/auto/Cwd/Cwd.so", O_RDONLY|O_CLOEXEC) = 9
open("/usr/lib64/perl5/auto/Fcntl/Fcntl.so", O_RDONLY|O_CLOEXEC) = 8
open("/usr/lib64/perl5/auto/POSIX/POSIX.so", O_RDONLY|O_CLOEXEC) = 7
open("/usr/lib64/perl5/vendor_perl/auto/DateTime/DateTime.so", O_RDONLY|O_CLOEXEC) = 6
open("/usr/lib64/perl5/vendor_perl/auto/Data/Dumper/Dumper.so", O_RDONLY|O_CLOEXEC) = 11
open("/usr/lib64/perl5/auto/IO/IO.so", O_RDONLY|O_CLOEXEC) = 8
open("/usr/lib64/perl5/vendor_perl/auto/Encode/Encode.so", O_RDONLY|O_CLOEXEC) = 6
Here you can see none of the XS modules (the shared libraries) is loaded from /usr/local or similar private location.
I did upgrade from Fedora 21 to Fedora 23.
On the Fedora 21 system I installed iCal::Parser via `cpan -i iCal::Parser` and did this again on fedora 23, but this gives me the following output:
$ cpan -i iCal::Parser
Loading internal null logger. Install Log::Log4perl for logging messages
CPAN: Storable loaded ok (v2.53)
Reading '/root/.cpan/Metadata'
Database was generated on Sat, 12 Mar 2016 22:41:02 GMT
CPAN: Module::CoreList loaded ok (v5.20160121)
iCal::Parser is up to date (1.20).
$ strace -e open perl ical2rem.pl 2>&1 >/dev/null |grep \\.so
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libperl.so.5.22", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnsl.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libutil.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libfreebl3.so", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/perl5/vendor_perl/auto/List/Util/Util.so", O_RDONLY|O_CLOEXEC) = 9
open("/usr/lib64/perl5/vendor_perl/auto/Sub/Name/Name.so", O_RDONLY|O_CLOEXEC) = 11
open("/usr/local/lib64/perl5/auto/Params/Validate/XS/XS.so", O_RDONLY|O_CLOEXEC) = 8
It seems to me it uses an old XS.so.
How can I fix this?
The traceback from journal when running the strace above:
Mar 14 18:01:36 chiad systemd-coredump[15803]: Process 15798 (strace) of user 1001 dumped core.
Stack trace of thread 15798:
#0 0x00007f39e2acea98 raise (libc.so.6)
#1 0x00007f39e32e8586 main (strace)
#2 0x00007f39e2aba580 __libc_start_main (libc.so.6)
#3 0x00007f39e32e85f9 _start (strace)
Mar 14 18:01:40 chiad systemd-coredump[15802]: Process 15801 (perl) of user 1001 dumped core.
Stack trace of thread 15801:
#0 0x00007f43ecf8563e boot_Params__Validate__XS (XS.so)
#1 0x00007f43f570241a Perl_pp_entersub (libperl.so.5.22)
#2 0x00007f43f56fb156 Perl_runops_standard (libperl.so.5.22)
#3 0x00007f43f567fc76 Perl_call_sv (libperl.so.5.22)
#4 0x00007f43f5682303 Perl_call_list (libperl.so.5.22)
#5 0x00007f43f56616fb S_process_special_blocks (libperl.so.5.22)
#6 0x00007f43f567876c Perl_newATTRSUB_x (libperl.so.5.22)
#7 0x00007f43f567c2bc Perl_utilize (libperl.so.5.22)
#8 0x00007f43f56b06b7 Perl_yyparse (libperl.so.5.22)
#9 0x00007f43f5739da4 S_doeval (libperl.so.5.22)
#10 0x00007f43f5744e56 Perl_pp_require (libperl.so.5.22)
#11 0x00007f43f56fb156 Perl_runops_standard (libperl.so.5.22)
#12 0x00007f43f567fc76 Perl_call_sv (libperl.so.5.22)
#13 0x00007f43f5682303 Perl_call_list (libperl.so.5.22)
#14 0x00007f43f56616fb S_process_special_blocks (libperl.so.5.22)
#15 0x00007f43f567876c Perl_newATTRSUB_x (libperl.so.5.22)
#16 0x00007f43f567c2bc Perl_utilize (libperl.so.5.22)
#17 0x00007f43f56b06b7 Perl_yyparse (libperl.so.5.22)
#18 0x00007f43f5739da4 S_doeval (libperl.so.5.22)
#19 0x00007f43f5744e56 Perl_pp_require (libperl.so.5.22)
#20 0x00007f43f56fb156 Perl_runops_standard (libperl.so.5.22)
#21 0x00007f43f567fc76 Perl_call_sv (libperl.so.5.22)
#22 0x00007f43f5682303 Perl_call_list (libperl.so.5.22)
#23 0x00007f43f56616fb S_process_special_blocks (libperl.so.5.22)
#24 0x00007f43f567876c Perl_newATTRSUB_x (libperl.so.5.22)
#25 0x00007f43f567c2bc Perl_utilize (libperl.so.5.22)
#26 0x00007f43f56b06b7 Perl_yyparse (libperl.so.5.22)
#27 0x00007f43f5739da4 S_doeval (libperl.so.5.22)
#28 0x00007f43f5744e56 Perl_pp_require (libperl.so.5.22)
#29 0x00007f43f56fb156 Perl_runops_standard (libperl.so.5.22)
#30 0x00007f43f567fc76 Perl_call_sv (libperl.so.5.22)
#31 0x00007f43f5682303 Perl_call_list (libperl.so.5.22)
#32 0x00007f43f56616fb S_process_special_blocks (libperl.so.5.22)
#33 0x00007f43f567876c Perl_newATTRSUB_x (libperl.so.5.22)
#34 0x00007f43f567c2bc Perl_utilize (libperl.so.5.22)
#35 0x00007f43f56b06b7 Perl_yyparse (libperl.so.5.22)
#36 0x00007f43f5739da4 S_doeval (libperl.so.5.22)
#37 0x00007f43f5744e56 Perl_pp_require (libperl.so.5.22)
#38 0x00007f43f56fb156 Perl_runops_standard (libperl.so.5.22)
#39 0x00007f43f567fc76 Perl_call_sv (libperl.so.5.22)
#40 0x00007f43f5682303 Perl_call_list (libperl.so.5.22)
#41 0x00007f43f56616fb S_process_special_blocks (libperl.so.5.22)
#42 0x00007f43f567876c Perl_newATTRSUB_x (libperl.so.5.22)
#43 0x00007f43f567c2bc Perl_utilize (libperl.so.5.22)
#44 0x00007f43f56b06b7 Perl_yyparse (libperl.so.5.22)
#45 0x00007f43f5686951 perl_parse (libperl.so.5.22)
#46 0x0000000000400c8b main (perl)
#47 0x00007f43f42fb580 __libc_start_main (libc.so.6)
#48 0x0000000000400d69 _start (perl)
You probably have broken your perl installation by mixing Fedora perl packages with locally installed packages. At least /usr/local/lib64/perl5/auto/Params/Validate/XS/XS.so is not a path Fedora package would use. (In reply to Tiger!P from comment #3) > I did upgrade from Fedora 21 to Fedora 23. > > On the Fedora 21 system I installed iCal::Parser via `cpan -i iCal::Parser` > and did this again on fedora 23, but this gives me the following output: > > $ cpan -i iCal::Parser > Loading internal null logger. Install Log::Log4perl for logging messages > CPAN: Storable loaded ok (v2.53) > Reading '/root/.cpan/Metadata' > Database was generated on Sat, 12 Mar 2016 22:41:02 GMT > CPAN: Module::CoreList loaded ok (v5.20160121) > iCal::Parser is up to date (1.20). > The problem is not with iCal::Parser, but with one of its dependencies: > $ strace -e open perl ical2rem.pl 2>&1 >/dev/null |grep \\.so [...] > open("/usr/local/lib64/perl5/auto/Params/Validate/XS/XS.so", > O_RDONLY|O_CLOEXEC) = 8 > You have Params::Validate::XS built against the old perl. > How can I fix this? > Reinstall Params::Validate::XS. But that does not have to be the only old dependency. You should reinstall everything you have in /usr/local/lib64/perl5/auto/. Or better remove it and install it from Fedora repositories like "dnf install 'perl(Params::Validate::XS')". By the way, I packaged the iCal::Parser yesterday, so it will be available in Fedora repositories soon. > The traceback from journal when running the strace above: > > Mar 14 18:01:36 chiad systemd-coredump[15803]: Process 15798 (strace) of > user 1001 dumped core. > > Stack trace of thread 15798: > #0 0x00007f39e2acea98 raise > (libc.so.6) > #1 0x00007f39e32e8586 main > (strace) > #2 0x00007f39e2aba580 > __libc_start_main (libc.so.6) > #3 0x00007f39e32e85f9 _start > (strace) > Mar 14 18:01:40 chiad systemd-coredump[15802]: Process 15801 (perl) of user > 1001 dumped core. > > Stack trace of thread 15801: > #0 0x00007f43ecf8563e > boot_Params__Validate__XS (XS.so) There are no absolute path names. The backtrace cannot be used to decide where a module was loaded from. (In reply to Petr Pisar from comment #5) > (In reply to Tiger!P from comment #3) > > $ strace -e open perl ical2rem.pl 2>&1 >/dev/null |grep \\.so > [...] > > open("/usr/local/lib64/perl5/auto/Params/Validate/XS/XS.so", > > O_RDONLY|O_CLOEXEC) = 8 > > > You have Params::Validate::XS built against the old perl. > > > How can I fix this? > > > Reinstall Params::Validate::XS. But that does not have to be the only old > dependency. You should reinstall everything you have in > /usr/local/lib64/perl5/auto/. Or better remove it and install it from Fedora > repositories like "dnf install 'perl(Params::Validate::XS')". Thank you for the information. I removed /usr/local/lib64/perl5 and installed the iCal::Parser again. Now my script is working as expected :-)) > By the way, I packaged the iCal::Parser yesterday, so it will be available > in Fedora repositories soon. Thank you very much for that. Tiger!P |
Created attachment 1135950 [details] perl script ical2rem.pl Description of problem: perl program ical2rem.pl gives a segfault. Version-Release number of selected component (if applicable): perl-5.22.1-351.fc23.x86_64 How reproducible: Every time Steps to Reproduce: 1. Run the ical2rem.pl (see attachment) Actual results: Segmentation fault (core dumped) Expected results: no segfault, but a information how to use the program. Additional info: The program needs iCal::Parser to work, which I installed with `cpan -i iCal::Parser`. The program worked on Fedora 21, but no longer in Fedora 23.