From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10154 invoked by alias); 5 Apr 2003 15:27:19 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 10146 invoked from network); 5 Apr 2003 15:27:18 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 5 Apr 2003 15:27:18 -0000 Received: from tooth.toronto.redhat.com (tooth.toronto.redhat.com [172.16.14.29]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 9A808800091; Sat, 5 Apr 2003 10:27:17 -0500 (EST) Received: from tooth.toronto.redhat.com (IDENT:caVqMnGCB0yhrPCyO3F4DXeHzrwW+Gvp@localhost [127.0.0.1]) by tooth.toronto.redhat.com (8.12.8/8.12.5) with ESMTP id h35FRH8m012430; Sat, 5 Apr 2003 10:27:17 -0500 Received: (from fche@localhost) by tooth.toronto.redhat.com (8.12.8/8.12.8/Submit) id h35FRGNk012427; Sat, 5 Apr 2003 10:27:16 -0500 Date: Sat, 05 Apr 2003 21:17:00 -0000 From: "Frank Ch. Eigler" To: Eyal Lebedinsky Cc: "list, gcc" Subject: Re: mudflap: how do I give size for 'void *' objects? - example Message-ID: <20030405152716.GA16333@redhat.com> References: <3E8CCC43.3F317393@eyal.emu.id.au> <3E8E7721.FAAEF08F@eyal.emu.id.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <3E8E7721.FAAEF08F@eyal.emu.id.au> User-Agent: Mutt/1.4.1i X-SW-Source: 2003-04/txt/msg00222.txt.bz2 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 3354 Hi - On Sat, Apr 05, 2003 at 04:26:41PM +1000, Eyal Lebedinsky wrote: > > I have a problem where I get a large number of reported violations > > when accessing objects acquired through something like > > p = shmat() > > where the size of the object is unknown (unless mudflap uses > > extra internal knowledge). In general, libmudflap does not have suitable wrapper functions already, the application may manually register/unregister objects using functions declared in mf-runtime.h. shmat() wrapping will be a bit tricky, because the size of the newly mapped memory region is not present as a local parameter of the call. libmudflap will probably need to intercept shmget() too just to get this information. > Here is a simple program that demonstrates the problem with ctime(). > Note how the fprintf() works OK (no violation) but the strlen() > fails. I assume that mudflap has its own strlen() wrapper that > trips on the "foreign" pointer returned from ctime(). Right. Enabling libmudflap heuristics (e.g. "-heur-proc-map") should cases like this work, if one does not want to write more wrappers. It would be nice to think of a way of getting such data pointers out of libraries. Or compile them in such a way that they are able to register their individual static variables (but without necessarily the full mudflap internal checking). You also wrote: > And while I am on the ebox, why do I not see a proper stack trace > with line numbers? What I got for this test is below. The > 'zz.c:19 (usemem)' > is correct, but I would have liked to see (and expected) > 'zz.c:48 (main)' You're not looking at a stack trace. These strings are not extracted from the debugging information, but is rather constructed at compile-time into literal strings from the trees, to identify the check site or variable. To parse the quoted error message: > mudflap violation 1 (check/read): time=1049530365.371258 ptr=08051f30 > size=1 pc=080487f9 location=`zz.c:19 (usemem) -> The usemem function at zz.c:19 made a one-byte memory read of the given address. > ./zz(__mf_check+0x245) [0x80487f9] > ./zz(main+0x52) [0x8048876] > /lib/libc.so.6(__libc_start_main+0xbb) [0x4005714f] -> The stack traceback, as supplied by glibc, went thusly. Since usemem doesn't show up, maybe it was inlined here, or maybe glibc doesn't show it in the traceback for another reason. > Nearby object 1: checked region begins 0B into and ends 0B into > mudflap object 08051f60: name=`malloc region' > bounds=[08051f30,08051f34] size=5 area=heap check=1r/0w liveness=1 > watching=0 -> This is the first read to a heap region. It hasn't been written to, as far as libmudflap knows ("0w"), and it was not registered as initialized ("area=heap"), so the initialization checking code detected a violation. If you just want to shut this check up, you can use MUDFLAP_OPTIONS="-no-check-initialization", though it would be better to find out why libmudflap thinks that the buffer hasn't been written to already. > alloc time=1049530365.371099 pc=40019f32 > /usr/local/gcc-mudflap/lib/libmudflap.so.0(__real_malloc+0x142) > [0x40019f32] > ./zz(__mf_check+0xfc) [0x80486b0] > ./zz(main+0x25) [0x8048849] > number of nearby objects: 1 -> This is the glibc stack traceback at the moment of allocation. - FChE --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+jvXTVZbdDOm/ZT0RAo3YAJ41gJjxXYjaRGoZEFiasZOVhbxogQCeKlR7 NzdfLWGa0oYNHqvgBAQi+hw= =IJGL -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr--