From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7961 invoked by alias); 11 Dec 2015 21:38:48 -0000 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 Received: (qmail 7947 invoked by uid 89); 11 Dec 2015 21:38:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail-wm0-f43.google.com Received: from mail-wm0-f43.google.com (HELO mail-wm0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 11 Dec 2015 21:38:46 +0000 Received: by mail-wm0-f43.google.com with SMTP id c201so90321805wme.0 for ; Fri, 11 Dec 2015 13:38:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=sFOskUDGwdnhVgPjBouQxdIeES48wnoZDGQutcbi1p0=; b=BQaQehGseS8wfo4ieuqOnyObXdGV07wZkgrTCApB5Q7u0HxqTLWF0SZdDIxERgSU7x mhOG/GVfq13KnDOL6EzjNk5wIj3BeXrYs8N6zUBmC1ZIVoe1wRmAokf3x2xsHkDJ4pby t4bxrQlveo4PWS5uswyVlsSpiZ4VmdzSlwmdO/K/DqIe+mCXPSNzq/PWzGJmNmTMuZ8N tGhTzaY50ByfqDCfcyzWWWqHAWZHP++QXSC2OYYcw6MIOOUyFwCiWFebvzPHJPr/Ed2K noN4XTIKxEaivjAauNRx+YGjly4IH5hCHeO6pG9bVG7OdtJPzGi8GNaEMHxvEu23MAVz xqAA== X-Gm-Message-State: ALoCoQnaxujE07vfVD9fEbRCBMX0PngQp//5n00D1/OXocFtAt2T2+qQuFss6kQijwxCv2aXMN6hmz8I9jzKBQsGS7l5AAotoQ== X-Received: by 10.194.209.235 with SMTP id mp11mr25721049wjc.53.1449869923635; Fri, 11 Dec 2015 13:38:43 -0800 (PST) Received: from localhost (host86-138-95-213.range86-138.btcentralplus.com. [86.138.95.213]) by smtp.gmail.com with ESMTPSA id h7sm5051598wmf.0.2015.12.11.13.38.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Dec 2015 13:38:42 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCH 0/2] Problems with gdb.mi/mi-vla-fortran.exp Date: Fri, 11 Dec 2015 21:38:00 -0000 Message-Id: X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00245.txt.bz2 I recently ran into an issue while running the gdb regression tests, the symptom was that one of the tests was causing gdb to consume a large amount of memory, 3G+. I tracked this down to the test gdb.mi/mi-vla-fortran.exp. The specific causes of the issue appears to be a bug in gfortran. In the test we have gdb stop at vla.f90:35, which looks like this: pvla2 => vla2 ! pvla2-not-associated Before this point, the pvla2 pointer variable is not associated, and so, something like: l = associated(pvla2) Would return false. In order to determine if pvla2 is associated gdb makes use of the DWARF DW_AT_associated property which is an attribute of the DWARF type corresponding to pvla2. The DW_AT_associated property for the type of pvla2 is this (newlines added by me for clarity): DW_AT_associated : 4 byte block: 97 6 30 2e \ (DW_OP_push_object_address; \ DW_OP_deref; DW_OP_lit0; \ DW_OP_ne) So, take the address of the object (in this case the address is on the stack), and use that to load an address sized block from memory, and if that loaded block is not zero, then the the variable (pvla2) is associated. The problem is that gfortran does not initialise the block of memory that the object address points to until the first time that pvla2 is accessed. Before that time the contents of the memory are undefined, and if gdb accesses them we will see undefined behaviour. I've confirmed that above behaviour by using the '-fdump-tree-all' option to gfortran, then examining the pseudo-C code that is dumped. >From a compiler / code correctness point of view this behaviour is perfectly understandable, and for performance, this is probably a win, the problem (as I see it) is that a promise has been made in the DWARF, which is not being honoured in the code. I think gfortran either needs more complex DWARF, or to initialise the memory block for associatable variables earlier on. Given the above mistake, what follows is just undefined behaviour kicking in; gdb reads the uninitialised memory, which happens to be non-zero, so it believes pvla2 is associated, it then tries to figure out what it's associated with, and reads yet more uninitialised memory. In this end it figures that pvla2 is pointing at a huge 3G+ array, which in the gdb.mi/mi-vla-fortran.exp test we gdb to print. This causes gdb to allocate the 3G+ of memory to hold the contents of the value. My question is what to do next from the gdb side of things? We could leave the test unchanged, arguing that gdb is asking sensible questions, and it's gfortran that's getting things wrong. Or we could remove, or comment out, the offending test. Leaving the test in place unchanged would be a bit of a shame, I know that 3G of memory isn't much on a lot of machines, but it's still making my experience running the testsuite pretty painful; I can't be the only one. I think that this issue has highlighted a bigger issue that effects gdb, when dealing with languages that support dynamic types, like fortran. An incorrect program can result in gdb having invalid type information, it would be nice if this invalid information did not cause gdb to do something so obviously wrong that it brings the maching running gdb down. The following patches are my attempt to address this issue. The first adds a mechansim to stop gdb allocating overly large arrays for value contents, the second enables this mechanism withn the test suite, while the third makes additional changes to the mi-vla-fortran.exp test to prevent additional errors that are a consequence of the above issue. Thoughts and comments welcome. Thanks, Andrew --- Andrew Burgess (3): gdb: New set/show max-value-size command. gdb: Set max-value-size before running tests. gdb: Guard against undefined behaviour in mi-vla-fortran.exp gdb/ChangeLog | 11 +++++ gdb/NEWS | 6 +++ gdb/doc/ChangeLog | 4 ++ gdb/doc/gdb.texinfo | 35 +++++++++++++++ gdb/testsuite/ChangeLog | 17 ++++++++ gdb/testsuite/gdb.base/max-value-size.c | 26 +++++++++++ gdb/testsuite/gdb.base/max-value-size.exp | 66 ++++++++++++++++++++++++++++ gdb/testsuite/gdb.mi/mi-vla-fortran.exp | 48 ++++++++++++++------- gdb/testsuite/lib/gdb.exp | 10 +++++ gdb/testsuite/lib/mi-support.exp | 10 +++++ gdb/value.c | 71 +++++++++++++++++++++++++++++-- 11 files changed, 284 insertions(+), 20 deletions(-) create mode 100644 gdb/testsuite/gdb.base/max-value-size.c create mode 100644 gdb/testsuite/gdb.base/max-value-size.exp -- 2.5.1