From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10393 invoked by alias); 13 Feb 2013 11:24:21 -0000 Received: (qmail 10381 invoked by uid 22791); 13 Feb 2013 11:24:19 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Feb 2013 11:23:57 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1DBNtHU026183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Feb 2013 06:23:55 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1DAo049026904; Wed, 13 Feb 2013 05:50:01 -0500 Message-ID: <511B6FD8.10607@redhat.com> Date: Wed, 13 Feb 2013 11:24:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Franck Jullien CC: Sergio Durigan Junior , gdb@sourceware.org Subject: Re: Lot of FAILs with gdb.base/structs.exp References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00044.txt.bz2 On 02/13/2013 10:18 AM, Franck Jullien wrote: > Do you have any advice on the investigation method you'd use with a > program exiting like this ?: ... > (gdb) PASS: gdb.base/structs.exp: p chartest > ptype foo1 > type = struct struct1 { > tc a; > } > (gdb) PASS: gdb.base/structs.exp: ptype foo1; structs-tc > p/c fun1() > [Inferior 1 (process 42000) exited with code 0400] > The program being debugged exited while in a function called from GDB. So you have some kind of bug in your inferior function call implementation. For some reason gdb doesn't regain control after the call ends. At this point I'd just switch to reproducing the problem manually while debugging gdb, and try to figure things out. Did this work with 7.2? That should make things easier, as you have a basis to compare. Maybe something to do with the fact that we now default to putting the call dummy on stack, while it would go on entry before. -- Pedro Alves