Date: Wed, 13 Feb 2013 21:12:08 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: natris@centrum.cz Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Ryan Stone <rysto32@gmail.com> Subject: Re: SIGSEGV/SIGBUS when accessing after end of mmapped file; why it differs with GCC? Message-ID: <20130213191208.GR2522@kib.kiev.ua> In-Reply-To: <CAFMmRNxkYKy_-GVSGAwM7Zjikwtezj1cR3mmzDjC1sqkv2Btog@mail.gmail.com> References: <20130213171825.76D3A9DC@centrum.cz> <CAFMmRNxkYKy_-GVSGAwM7Zjikwtezj1cR3mmzDjC1sqkv2Btog@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--ms/uB3aZsWYC/mdj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2013 at 12:13:58PM -0500, Ryan Stone wrote: > On Wed, Feb 13, 2013 at 11:18 AM, <natris@centrum.cz> wrote: >=20 > > 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 some= one > > resizes the file so that part of the previously mapped region is no lon= ger > > backed by the file, synchronous signal is sent to the process which nee= ds > > to be handled. > > > > On all other platforms than FreeBSD I have tested (Solaris, Linux, Darw= in, > > 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 t= he > > 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 on= e 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 how= ever > > 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 happe= ned > > 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 Libra= ry > > 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 Libra= ry > > 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@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 >=20 >=20 > I think that setting sysctl machdep.prot_fault_translation=3D1 would do w= hat > you want. This might be an indication of the issue with the toolchains you use, in particular, with the linker or csu. The default selection for the signal is based on the note osver, linked into the binary from crt1.o. Either linker omits the note, or wrong crt1 is used. You did not specified anything about version of the FreeBSD used, nor the exact compiler invocations. Using the crystal ball, I see the r244600 for HEAD and r244904 for stable/9, if you use --gc-sections flags. This is more or less consistent with what you reported, since gcc from ports uses binutils from ports, which have newer ld with bugfix already applied. --ms/uB3aZsWYC/mdj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRG+WHAAoJEJDCuSvBvK1BFtQQAJzAiDsyd4NDdJx01fzJmnn2 xcIx3FICcKLPX1guF5D/mp1uDUy/1XcN0rFk16GoAm3lVL9flK4Bqk9R8mjZsVpO UUHoMloFEwvZAtVlkNxWBJmEgcRFe3Ij4pluqC58p55ICR+axE/IL4R77W+bndKk iDRtNePm7t+t9gKX1iS8UV/LhvsLIQTckBltwNDgTgef0c2f3o6BH4DaB8harujz HYaTojOwtDlsHlsIRH307VJDTjUAzuKKBI6sQfnyW1qUcjJQ9pub56aiDRS2kQ6t SqvU82qX5Vk7Y4Ee0mlQl+Ut+sQBDSyEFHsHdU1KKb35RYfGr9czmlp8aerP4+xg +eRp8JbW6QV2SsJst9tzEP3hBGUjpfNUps5DWOvg+jioLMEN95LDczGaWJJZpIVb gBCfRgq7jso3KVvL+kXdWKYnj0ptVOyqTeOHif/+2GL8G8onSYnEwXn69Hc2ddB2 sND5IJkaA0xl9lmO0vHxlwGCQsbFGrpGEhXJ+V07D28Huu3Nx89Ju/HowtkJAq4V d57TxMXOrp43oip9K8uhVEQhZSqnfv2X2yQcCr3xQTMTauvL6eMVPPtez0bdRedU 11w1OxJAlsEcFCx0B9jJzS+b423GCpQrwvFvZh7Q1jOWgcpYVi6Q5DYmyZUuSnzf LcFLF0mHNmNyjhN9XzQT =izrt -----END PGP SIGNATURE----- --ms/uB3aZsWYC/mdj--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130213191208.GR2522>