From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117711 invoked by alias); 1 Feb 2016 18:40:42 -0000 Mailing-List: contact gdb-testers-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-testers-owner@sourceware.org Received: (qmail 117690 invoked by uid 89); 1 Feb 2016 18:40:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_05 autolearn=ham version=3.3.2 spammy=extreme, detects, directs, relating X-HELO: kwanyin.sergiodj.net Received: from kwanyin.sergiodj.net (HELO kwanyin.sergiodj.net) (176.31.208.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 01 Feb 2016 18:40:41 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [binutils-gdb] gdb: Guard against undefined behaviour in mi-vla-fortran.exp From: sergiodj+buildbot@redhat.com To: gdb-testers@sourceware.org Message-Id: <37a8db1a336ce78a46bf7f303e47e17b2a1bf694@gdb-build> Date: Mon, 01 Feb 2016 18:40:00 -0000 X-SW-Source: 2016-q1/txt/msg03882.txt.bz2 *** TEST RESULTS FOR COMMIT 37a8db1a336ce78a46bf7f303e47e17b2a1bf694 *** Author: Andrew Burgess Branch: master Commit: 37a8db1a336ce78a46bf7f303e47e17b2a1bf694 gdb: Guard against undefined behaviour in mi-vla-fortran.exp The test gdb.mi/mi-vla-fortran.exp reveals an issue with the DWARF generated by gfortran. In the test a pointer variable 'pvla2' is created: real, pointer :: pvla2 (:, :) Initially this variable will be unassociated, so something like this: l = associated(pvla2) should return false. In the test gdb stops at a point _before_ pvla2 is associated with anything, and we then try to print pvla2, the expectation is that gdb should reply . The problem is that the data the DWARF directs gdb to read (to identify if the variable is associated or not) is not initialised until the first time pvla2 is accessed. As a result gdb ends up reading uninitialised memory, sometimes this uninitialised memory indicates the variable is associated (when it's not). This first mistake can lead to a cascade of errors, reading uninitialised memory, with the result that gdb builds an invalid type to associate with the variable pvla2. In some cases, this invalid type can be very large, which when we try to print pvla2 causes gdb to allocate a large amount of memory. A recent commit added a new gdb variable 'max-value-size', which prevents gdb from allocating values of extreme size. As a result directly trying to print pvla2 will now now error rather than allocate a large amount of memory. However, some of the later tests create a varobj for pvla2, and then ask for the children of that varobj to be displayed. In the case where an invalid type has been computed for pvla2 then the number of children can be wrong, and very big, in which case trying to display all of these children can cause gdb to consume an excessive amount of memory. This commit first detects if printing pvla2 triggers the max-value-size error, if it does then we avoid all the follow on tests relating to the unassociated pvla2, which avoids the second error printing the varobj children. gdb/testsuite/ChangeLog: * gdb.mi/mi-vla-fortran.exp: Add XFAIL for accessing unassociated pointer. Don't perform further tests on the unassociated pointer if the first test fails.