From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1931 invoked by alias); 13 Feb 2013 13:23:30 -0000 Received: (qmail 1755 invoked by uid 22791); 13 Feb 2013 13:23:28 -0000 X-SWARE-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-la0-f48.google.com (HELO mail-la0-f48.google.com) (209.85.215.48) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Feb 2013 13:23:23 +0000 Received: by mail-la0-f48.google.com with SMTP id fq13so1134391lab.7 for ; Wed, 13 Feb 2013 05:23:22 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.103.33 with SMTP id ft1mr2201828lbb.48.1360761801766; Wed, 13 Feb 2013 05:23:21 -0800 (PST) Received: by 10.112.37.35 with HTTP; Wed, 13 Feb 2013 05:23:21 -0800 (PST) In-Reply-To: <511B6FD8.10607@redhat.com> References: <511B6FD8.10607@redhat.com> Date: Wed, 13 Feb 2013 13:23:00 -0000 Message-ID: Subject: Re: Lot of FAILs with gdb.base/structs.exp From: Franck Jullien To: Pedro Alves Cc: Sergio Durigan Junior , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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/msg00046.txt.bz2 2013/2/13 Pedro Alves : > 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 > Ok, thank you guys. I'd say it works with GDB 7.2 but I have to double check. I'll see what I can find and will keep you informed. Franck.