Bug #78258 for File-Map: Undetected segfaults with any perl

Sat Jul 07 03:59:53 2012 ANDK [...] cpan.org - Ticket created

Subject:

Undetected segfaults with any perl

Since my Debian reports any segfault in /var/log/messages I discovered this weirdness. Running the test t/20-protect.t with any of my perls which currently go back to 5.14.1 gives a segfault. Nobody notices it, the program retruns true, passes all tests. I produced a ore file and this stacktrace: Core was generated by `/mnt/k75/homesand/src/perl/repoperls/installed-perls/p\ erl/v5.17.1-327-gee36fb6/'. Program terminated with signal 11, Segmentation fault. #0 0x00002b4ed699ec20 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00002b4ed699ec20 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00000000004ae40d in Perl_sv_setpvn (sv=sv@entry=0x2432ed0, ptr=ptr@entry=0x2b4ed7c3f000 "012345678:012345678:012345678:012345678:012\ 345678:012345678:012345678:012345678:012345678:012345678:", len=3) at sv.c:4516 #2 0x00000000004bcd10 in Perl_pp_substr () at pp.c:3042 #3 0x0000000000499833 in Perl_runops_standard () at run.c:41 #4 0x000000000043f076 in S_run_body (oldscope=<optimized out>) at perl.c:240\ 9 #5 perl_run (my_perl=<optimized out>) at perl.c:2332 #6 0x0000000000423a05 in main (argc=2, argv=0x7fff427689d8, env=0x7fff427689f0) at perlmain.c:120 Let me know if I can provide more information. Best,

Sat Jul 07 04:22:09 2012 LEONT [...] cpan.org - Correspondence added

On Sat Jul 07 03:59:53 2012, ANDK wrote: Show quoted text

> Since my Debian reports any segfault in /var/log/messages I discovered > this weirdness. Running the test t/20-protect.t with any of my perls > which currently go back to 5.14.1 gives a segfault. Nobody notices it, > the program retruns true, passes all tests. I produced a ore file and > this stacktrace: > > Core was generated by > `/mnt/k75/homesand/src/perl/repoperls/installed-perls/p\ > erl/v5.17.1-327-gee36fb6/'. > Program terminated with signal 11, Segmentation fault. > #0 0x00002b4ed699ec20 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > (gdb) bt > #0 0x00002b4ed699ec20 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x00000000004ae40d in Perl_sv_setpvn (sv=sv@entry=0x2432ed0, > ptr=ptr@entry=0x2b4ed7c3f000 > "012345678:012345678:012345678:012345678:012\ > 345678:012345678:012345678:012345678:012345678:012345678:", len=3) at > sv.c:4516 > #2 0x00000000004bcd10 in Perl_pp_substr () at pp.c:3042 > #3 0x0000000000499833 in Perl_runops_standard () at run.c:41 > #4 0x000000000043f076 in S_run_body (oldscope=<optimized out>) at > perl.c:240\ > 9 > #5 perl_run (my_perl=<optimized out>) at perl.c:2332 > #6 0x0000000000423a05 in main (argc=2, argv=0x7fff427689d8, > env=0x7fff427689f0) at perlmain.c:120 > > Let me know if I can provide more information.

This may sound unusual, but that segfault is actually intentional. I remove all permissions (including reading) from a piece of memory and then try to access it, which should trigger a segfault (though some systems erroneously give a busfault). This doen't crap out because I'm doing it in a fork and test for the wait status in the main process. Alternatively I could catch the signal in the main process and prevent it from dieing, not sure that'd really be preferable. Leon

Sat Jul 07 04:22:10 2012 The RT System itself - Status changed from 'new' to 'open'

Sat Jul 07 04:22:10 2012 LEONT [...] cpan.org - Status changed from 'open' to 'resolved'

Sat Jul 07 15:15:30 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Sat Jul 07 04:22:09 2012, LEONT wrote: Show quoted text

> This may sound unusual, but that segfault is actually intentional. I > remove all permissions (including reading) from a piece of memory and > then try to access it, which should trigger a segfault (though some > systems erroneously give a busfault).

So a SEGV is a read violation and a BUS is a write violation? I’ve always wondered what the difference was.

Sat Jul 07 15:15:51 2012 The RT System itself - Status changed from 'resolved' to 'open'

Sun Jul 08 16:02:27 2012 LEONT [...] cpan.org - Correspondence added

On Sat Jul 07 15:15:30 2012, SPROUT wrote: Show quoted text

> On Sat Jul 07 04:22:09 2012, LEONT wrote:

> > This may sound unusual, but that segfault is actually intentional. I > > remove all permissions (including reading) from a piece of memory

> and

> > then try to access it, which should trigger a segfault (though some > > systems erroneously give a busfault).

> > So a SEGV is a read violation and a BUS is a write violation? I’ve > always wondered what the > difference was.

A SIGSEGV is usually the memory equivalent of EACCES/EPERM, it's accessing memory you're not allowed to access. Most OSes map virtual memory that isn't allocated without permission, so accessing it gives a segfault. A SIGBUS is an invalid memory access. The easiest way to trigger it using File::Map (at least on Linux, and I think on Solaris too) is to map a file, truncate it and then access it: it's virtually defined but doesn't have a backing by anything anymore. On some architectures (like arm, but unlike x86) it can also mean a alignment issues. Hence it's rather uncommon in most code.. Leon

Sun Jul 08 16:02:28 2012 LEONT [...] cpan.org - Status changed from 'open' to 'resolved'