From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32481 invoked by alias); 5 Dec 2002 10:06:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 32467 invoked by uid 71); 5 Dec 2002 10:06:02 -0000 Date: Thu, 05 Dec 2002 02:06:00 -0000 Message-ID: <20021205100602.32466.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Edward Welbourne Subject: Re: c/8743: receiving result from __builtin_return_address() beyond stack top causes segfault Reply-To: Edward Welbourne X-SW-Source: 2002-12/txt/msg00267.txt.bz2 List-Id: The following reply was made to PR c/8743; it has been noted by GNATS. From: Edward Welbourne To: bangerth@dealii.org, gcc-gnats@gcc.gnu.org Cc: biere@inf.ethz.ch, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, steven.robbins@videotron.ca Subject: Re: c/8743: receiving result from __builtin_return_address() beyond stack top causes segfault Date: Thu, 05 Dec 2002 11:04:34 +0100 Also: note that the work-around only fixes the problem for the *first* LEVEL at which it would otherwise seg-fault (which *is* just enough to enable backtracing in ccmalloc); it does nothing about the segfault at greater depth, which also happens in __builtin_frame_address(); if you use __builtin_frame_address(3) in place of __builtin_return_address(2) in the example code, you'll get a segfault just the same (on x86). [All of which rather hints that these functions do a zig-zag chain of pointer dereferences, which is missing an `are we zero yet' test. I naively imagine this will be easy to fix.] I've now had the opportunity to test the same on a ppc: __builtin_return_address(2) segfaults, as does __builtin_frame_address(4), but __builtin_frame_address(3) actually succeeds ! This is with a 2.95.? version and with 3.2.1. Eddy.