From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36778 invoked by alias); 23 Mar 2016 13:26:00 -0000 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 Received: (qmail 36695 invoked by uid 89); 23 Mar 2016 13:25:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f51.google.com Received: from mail-wm0-f51.google.com (HELO mail-wm0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 23 Mar 2016 13:25:48 +0000 Received: by mail-wm0-f51.google.com with SMTP id r129so136303001wmr.1 for ; Wed, 23 Mar 2016 06:25:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=D7x480rn/e5Kj5E4jzpclPL3CjM1WUanLwbZcQBzW/4=; b=GedO57wPpcOpSSzpxnWLCOyuy1xvJ1uDxUBKjwBQXtRD6vjnd9tlTvhKZbcqxuAURz FxdFB2UhX/kzmi1vSLDWn4hmd8Sg1uNmuwaoaUH2nSsgbsF46APnmbM/KRNuE8d53Gs3 7vR+S/sc3+x88SIXM1LC1QQxdjWFenMu01JNFDM3tEBnysHw5iVJdQw0i9YhtGrOqSaB p/aIFtXAqX+FvIKpsFScVDUc6YMfs1x3E6b6U4hb2DVzSxsY1zpBr98j4BfdPq8WrcvD uHz9wiJ18AW4ZZX9OqXqvnnRYGNJI+Np9ukpe4ecsTxnxroGevvrgbpHSSBz/kWn5CMl ZlMw== X-Gm-Message-State: AD7BkJKkazHTLgevrMYC6YRNBqnDSSlRFiS0xXDwclO6r2BVs/hGL7RreXLWzHsiUAOnRppD X-Received: by 10.194.111.199 with SMTP id ik7mr3873071wjb.150.1458739537247; Wed, 23 Mar 2016 06:25:37 -0700 (PDT) Received: from [10.101.180.46] ([46.233.116.129]) by smtp.gmail.com with ESMTPSA id 192sm3013838wmw.0.2016.03.23.06.25.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Mar 2016 06:25:36 -0700 (PDT) Subject: Re: gdb.Value returning a string of length 1 (linux lx-version bug) To: Jan Kiszka References: <56F186C1.1080803@linaro.org> <56F18761.8030901@siemens.com> <56F258C2.2010007@linaro.org> Cc: Peter Griffin , gdb@sourceware.org From: Kieran Bingham Message-ID: <56F2994F.9020507@linaro.org> Date: Wed, 23 Mar 2016 13:26:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56F258C2.2010007@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00037.txt.bz2 On 23/03/16 08:50, Kieran Bingham wrote: > On 22/03/16 17:56, Jan Kiszka wrote: >> Hi Kieran, >> >> On 2016-03-22 18:54, Kieran Bingham wrote: >>> Hi Jan, >>> >>> Me and Pete have just been looking into the gdb.Value object bug where >>> the lx-version command returns a string of length 1. >>> >>> As I recall at FOSDEM, you were also hitting the bug. >>> Out of interest, what compiler version are you using? >> >> gcc (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064] > > Thanks, well that means it's unlikely to be any optimiser changes, as > your compiler is earlier than Petes. > >>> >>> We've made some head way, but we are suspicious that compiler versions >>> may affect the issue ! :( >>> >>> The crux of the issue, is that the valpy_string() calls c_get_string() >>> which in turn calls get_discrete_bounds(). >>> >>> On my broken version, get_discrete_bounds, is setting both lowp, and >>> highp to 0x0; where as on Peters working version, his highp gets set >>> correctly. (there is a +1 added later which results in the string >>> producing a strlen of 1) >>> >>> I'm running gcc 5.2.1-22ubuntu2, whereas Pete is running gcc 4.8.4. >>> >>> Pete's version of his compiled binutils-gdb always seems to function >>> correctly, where as I hit the bug - *occasionally* >>> >>> Of course, since I have compiled with -g3 -O0 -fsanitize=undefined I >>> can't reproduce the issue, and now even removing the optimise levels I >>> haven't been able to reproduce. >>> >>> We have a Heisenbug :( >> >> Maybe wait for someone seeing this more reproducibly? :-/ > > I think I may have found a way to reproduce reliably! > > By running some commands, and ensured the issue occurred, and then > reducing the command set down until only one remained, I've narrowed > down the cause a little. > > I have discovered that the issue only appears if you have run a > 'backtrace (bt)' *before* calling lx-version. > > (gdb) bt > > (gdb) lx-version > L(gdb) ## Note the single char output on the left > > > Now - having determined how to reliably reproduce, I have re-enabled > -fsanitize=undefined : > > (gdb) bt > /home/linuxembedded/linaro/lkd/openst-lkd/sources/binutils-gdb/gdb/dwarf2-frame.c:254:3: > runtime error: null pointer passed as argument 2, which is declared to > never be null This warning comes from a memcpy on a register struct in dwarf2_frame_state_copy_regs(), however, the code correctly identifies that there are 0 registers, and so tries to copy zero bytes from a NULL pointer. So I don't think this particular warning is causing the next fault - but there is still some strong correlation between the bt command and the failing string object. Peter has also tested the issue and can reliably reproduce by running 'bt' before 'lx-version' -- Kieran > #0 0xc0222c68 in cpu_v7_do_idle () > at > /home/linuxembedded/linaro/lkd/openst/sources/linux/arch/arm/mm/proc-v7.S:74 > #1 0xc0210728 in arch_cpu_idle () > at > /home/linuxembedded/linaro/lkd/openst/sources/linux/arch/arm/kernel/process.c:72 > #2 0xc027de78 in cpu_startup_entry () > at > /home/linuxembedded/linaro/lkd/openst/sources/linux/kernel/sched/idle.c:150 > #3 0xc027de78 in cpu_startup_entry () > at > /home/linuxembedded/linaro/lkd/openst/sources/linux/kernel/sched/idle.c:246 > #4 0xc027de78 in cpu_startup_entry (state=) > at > /home/linuxembedded/linaro/lkd/openst/sources/linux/kernel/sched/idle.c:294 > #5 0xc09e0160 in rest_init () at > /home/linuxembedded/linaro/lkd/openst/sources/linux/init/main.c:412 > #6 0xc0da2ca8 in start_kernel () > at /home/linuxembedded/linaro/lkd/openst/sources/linux/init/main.c:683 > #7 0x8020807c in () > (gdb) lx-version > L(gdb) > > > UBSAN to the rescue! > > I'll see if I can determine the cause / effect of the Null pointer, and > that is likely worth submitting as a dedicated GDB bug. > -- > Kieran > >> Jan >> >>> >>> Has anyone else on the GDB Mailinglist experienced any intermittent >>> errors with gdb.Value strings from python? >>> -- >>> Kieran >>> >>