From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13719 invoked by alias); 23 Apr 2003 23:45:33 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13712 invoked from network); 23 Apr 2003 23:45:32 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 23 Apr 2003 23:45:32 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h3NNjWD07054 for ; Wed, 23 Apr 2003 19:45:32 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h3NNjWq31868 for ; Wed, 23 Apr 2003 19:45:32 -0400 Received: from localhost.localdomain (vpn50-7.rdu.redhat.com [172.16.50.7]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h3NNjWk03922 for ; Wed, 23 Apr 2003 19:45:32 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h3NNjQf13644 for gdb-patches@sources.redhat.com; Wed, 23 Apr 2003 16:45:26 -0700 Date: Thu, 24 Apr 2003 01:05:00 -0000 From: Kevin Buettner Message-Id: <1030423234526.ZM13643@localhost.localdomain> To: gdb-patches@sources.redhat.com Subject: [RFA] dwarf2expr.c: Fix some stack [re]allocation problems MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-04/txt/msg00457.txt.bz2 The patch below fixes some problems with the dwarf expression stack. First, the stack is not being initialized correctly. The ``stack_len'' member indicates the position of the top of the stack and it was being set to 10. This value should be zero, and, as a consequence, none of the underflow checking code was actually working properly. Furthermore, the field which indicates the amount of space actually allocated wasn't being initialized at all! The function which grows the stack also has a bug. It uses a loop which doubles the new size so long as that size isn't yet large enough to accomodate the new space request. The problem with this is that if the size starts out at zero, the loop will never terminate. Computing this sort of thing with a loop is silly anyway, so I've simplified the mechanism used to allocate more space. It seems unlikely that the DWARF 2 expression stack will grow very quickly, hence the new code is conservative and allocates a mere 10 elements (at a time) more than required. Okay? * dwarf2expr.c (new_dwarf_expr_context): Set ``stack_len'' to correctly indicate an empty stack and ``stack_allocated'' to the indicate the number of elements initially allocated. (dwarf_expr_grow_stack): Simplify method for computing new stack size. Don't loop infinitely if ``stack_len'' is zero. Index: dwarf2expr.c =================================================================== RCS file: /cvs/src/src/gdb/dwarf2expr.c,v retrieving revision 1.6 diff -u -p -r1.6 dwarf2expr.c --- dwarf2expr.c 13 Apr 2003 15:53:44 -0000 1.6 +++ dwarf2expr.c 23 Apr 2003 23:19:38 -0000 @@ -39,8 +39,9 @@ new_dwarf_expr_context (void) { struct dwarf_expr_context *retval; retval = xcalloc (1, sizeof (struct dwarf_expr_context)); - retval->stack_len = 10; - retval->stack = xmalloc (10 * sizeof (CORE_ADDR)); + retval->stack_len = 0; + retval->stack_allocated = 10; + retval->stack = xmalloc (retval->stack_allocated * sizeof (CORE_ADDR)); return retval; } @@ -61,12 +62,10 @@ dwarf_expr_grow_stack (struct dwarf_expr { if (ctx->stack_len + need > ctx->stack_allocated) { - size_t templen = ctx->stack_len * 2; - while (templen < (ctx->stack_len + need)) - templen *= 2; + size_t newlen = ctx->stack_len + need + 10; ctx->stack = xrealloc (ctx->stack, - templen * sizeof (CORE_ADDR)); - ctx->stack_allocated = templen; + newlen * sizeof (CORE_ADDR)); + ctx->stack_allocated = newlen; } }