From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32408 invoked by alias); 13 Mar 2009 01:21:45 -0000 Received: (qmail 32400 invoked by uid 22791); 13 Mar 2009 01:21:44 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 Mar 2009 01:21:40 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 588482C6727 for ; Thu, 12 Mar 2009 21:21:38 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NGmncCpsho1I for ; Thu, 12 Mar 2009 21:21:38 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 20BCF2C6704 for ; Thu, 12 Mar 2009 21:21:38 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id D648DF5C8D; Thu, 12 Mar 2009 18:21:34 -0700 (PDT) Date: Fri, 13 Mar 2009 01:35:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: [commit/Ada] Use our builtin type when evaluating conditional expressions Message-ID: <20090313012134.GA11284@adacore.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-03/txt/msg00186.txt.bz2 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1345 This is a problem reported by a customer who was debugging a gigantic application. I think it was on pa-hpux, but it might have been on x86-linux, and the target is actually not relevant. We reproduced the problem with the following command: (gdb) p null /= null It first hangs for a while, and then we get: utils.c:1020: internal-error: virtual memory exhausted: can't allocate 4072 bytes. A problem internal to GDB has been detected, further debugging may prove unreliable. Jerome Guitton did the investigation and said: The problem comes from the fact that GDB casts "null /= null" into the language boolean type (i.e. "standard.boolean"). And it lookups the boolean type into the debug info of the application. As type boolean is defined in every compilation unit, every psymtabs matchs; as a consequence, all the corresponding symtabs are built. This roughly means that the debugger loads every symbols when evaluating a conditional expression. As the application is really huge, we run out of memory before completing the operation. This problem is avoided by making sure that we use our boolean builtin type rather than trying to look it up... 2009-03-12 Jerome Guitton * language.c (lang_bool_type): Set lai->bool_type_symbol to NULL. Tested on amd64-linux. Checked in. -- Joel --Q68bSM7Ycu6FN28Q Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="06-builtin-boolean.diff" Content-length: 424 diff --git a/gdb/ada-lang.c b/gdb/ada-lang.c index 0724804..0ec724f 100644 --- a/gdb/ada-lang.c +++ b/gdb/ada-lang.c @@ -11013,7 +11013,7 @@ ada_language_arch_info (struct gdbarch *gdbarch, TYPE_NAME (lai->primitive_type_vector [ada_primitive_type_system_address]) = "system__address"; - lai->bool_type_symbol = "boolean"; + lai->bool_type_symbol = NULL; lai->bool_type_default = builtin->builtin_bool; } --Q68bSM7Ycu6FN28Q--