From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2149 invoked by alias); 13 May 2005 16:00:18 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 1950 invoked from network); 13 May 2005 16:00:09 -0000 Received: from unknown (HELO palrel12.hp.com) (156.153.255.237) by sourceware.org with SMTP; 13 May 2005 16:00:09 -0000 Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.72]) by palrel12.hp.com (Postfix) with ESMTP id E36D640312F; Fri, 13 May 2005 09:00:08 -0700 (PDT) Received: from cacexc04.americas.cpqcorp.net ([16.92.1.26]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 08:59:19 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Is it possible to overflow baton->size in dwarf_mark_symbols_computed() in dwarf2read.c? Date: Fri, 13 May 2005 16:00:00 -0000 Message-ID: From: "Cuthbertson, Reva D." To: "Daniel Jacobowitz" Cc: X-OriginalArrivalTime: 13 May 2005 15:59:19.0130 (UTC) FILETIME=[B893BBA0:01C557D4] X-SW-Source: 2005-05/txt/msg00153.txt.bz2 Your suggestion worked. Thanks so much! Reva Cuthbertson reva.cuthbertson@hp.com -----Original Message----- From: Daniel Jacobowitz [mailto:drow@false.org]=20 Sent: Friday, May 13, 2005 8:40 AM To: Cuthbertson, Reva D. Cc: gdb@sources.redhat.com Subject: Re: Is it possible to overflow baton->size in dwarf_mark_symbols_computed() in dwarf2read.c? On Fri, May 13, 2005 at 08:37:41AM -0700, Cuthbertson, Reva D. wrote: > Yes, I ran into the problem. I tried changing the declaration of the > "size" field in dwarf2_loclist_baton and dwarf2_locexpr_baton in > dwarf2loc.h to be an unsigned integer instead and that seemed to fix the > problem I encountered. Do you think this a reasonable solution? No. It should saturate instead; it only needs to be longer than any supported location list/expression, and 64k is entirely reasonable for that. Int would waste a lot of memory. Could you try that? Something like if (expression < 65536) ->size =3D expression; else size =3D 65535; --=20 Daniel Jacobowitz CodeSourcery, LLC