SIGSEGV/SIGBUS when accessing after end of mmapped file; why it differs with GCC?

[Ryan Stone]

On Wed, Feb 13, 2013 at 11:18 AM, <natris at centrum.cz> wrote:

> Hello,
> I am porting an application which maps files into the memory and works
> directly with the memory. When doing this, it can happen that when someone
> resizes the file so that part of the previously mapped region is no longer
> backed by the file, synchronous signal is sent to the process which needs
> to be handled.
>
> On all other platforms than FreeBSD I have tested (Solaris, Linux, Darwin,
> HP-UX) the signal in question is SIGBUS. However on FreeBSD, depending on
> the >>compiler<< used, it is either SIGBUS or SIGSEGV. When I compile the
> binary with "gcc version 4.2.1 20070831 patched [FreeBSD], amd64", the
> signal is SIGBUS, when i use "gcc version 4.7.3 20121103 (prerelease)
> (FreeBSD Ports Collection)", the signal is SIGSEGV. Please note that one of
> the versions of gcc between 4.2 and 4.7 also caused SIGSEFV to be sent but
> this did not matter for me as I did not need to use that version; I however
> need gcc 4.7 to work because of c++11 stuff that my project has recently
> started to use.
>
> Unfortunately registering signal handler on SIGSEGV is very inconvenient
> for me; I would prefer to somehow switch the behavior to be sane.
>
> Please anyone has an idea whether or how this could be achieved? I have
> tried to find out why, on single machine, just because of different gcc
> version, kernel sends different signal but I have never worked with fbsd
> kernel before and so my search did not succeed so far.
>
> Machine in question runs amd64 FreeBSD 9.1-RC2, but this has also happened
> to me with older version of FreeBSD.
>
>
> gcc 4.2 (same happens also with libstdc++ and co. from gcc 4.2):
> Program received signal SIGBUS, Bus error.
> (gdb) i shared
> From                To                  Syms Read   Shared Object Library
> 0x0000000800f2ef70  0x0000000800f3ee68  Yes (*)     /libexec/ld-elf.so.1
> 0x000000080114d710  0x0000000801159748  Yes (*)     /lib/libthr.so.3
> 0x00000008013c2d30  0x000000080142c656  Yes
> /usr/local/lib/gcc47/libstdc++.so.6
> 0x00000008016737c0  0x00000008016891b8  Yes (*)     /lib/libm.so.5
> 0x0000000801893930  0x00000008018a3088  Yes
> /usr/local/lib/gcc47/libgcc_s.so.1
> 0x0000000801ad71d0  0x0000000801ba9358  Yes (*)     /lib/libc.so.7
>
> gcc 4.7:
> Program received signal SIGSEGV, Segmentation fault.
> (gdb) i shared
> From                To                  Syms Read   Shared Object Library
> 0x0000000800f5ef70  0x0000000800f6ee68  Yes (*)     /libexec/ld-elf.so.1
> 0x000000080117d710  0x0000000801189748  Yes (*)     /lib/libthr.so.3
> 0x00000008013f2d30  0x000000080145c656  Yes
> /usr/local/lib/gcc47/libstdc++.so.6
> 0x00000008016a37c0  0x00000008016b91b8  Yes (*)     /lib/libm.so.5
> 0x00000008018c3930  0x00000008018d3088  Yes
> /usr/local/lib/gcc47/libgcc_s.so.1
> 0x0000000801b071d0  0x0000000801bd9358  Yes (*)     /lib/libc.so.7
>
>
> I would be glad for any hint or information.
> Kind Regards,
> Ondrej Kolacek
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"



I think that setting sysctl machdep.prot_fault_translation=1 would do what
you want.