From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 16:18:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F01CAAC6 for ; Wed, 13 Feb 2013 16:18:27 +0000 (UTC) (envelope-from natris@centrum.cz) Received: from gmmr4.centrum.cz (gmmr4.centrum.cz [IPv6:2a00:da80:1:502::3]) by mx1.freebsd.org (Postfix) with ESMTP id 9EA36DEA for ; Wed, 13 Feb 2013 16:18:27 +0000 (UTC) Received: from mail1008.cent (unknown [10.32.3.100]) by gmmr4.centrum.cz (Postfix) with ESMTP id A749C11D for ; Wed, 13 Feb 2013 17:18:25 +0100 (CET) Received: by mail1008.cent (Postfix, from userid 33) id A1A7C40570F46; Wed, 13 Feb 2013 17:18:25 +0100 (CET) To: Subject: =?utf-8?q?SIGSEGV=2FSIGBUS_when_accessing_after_end_of_mmapped_file=3B_why_it_differs_with_GCC=3F?= Received: from 212.4.138.50 (X-Forwarded-For: 212.4.138.50) by mail1008.centrum.cz (centrum.cz multimail) with HTTP Date: Wed, 13 Feb 2013 17:18:25 +0100 From: X-Mailer: Centrum Email 5.3 X-Priority: 3 X-Original-From: natris@centrum.cz MIME-Version: 1.0 Message-Id: <20130213171825.76D3A9DC@centrum.cz> X-Maser: Georgo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 13 Feb 2013 16:56:03 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:18:28 -0000 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