From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80134 invoked by alias); 23 Mar 2016 08:50:30 -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 80116 invoked by uid 89); 23 Mar 2016 08:50:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=remained, H*r:ip*192.168.0.10, lkd, reliably X-HELO: mail-wm0-f53.google.com Received: from mail-wm0-f53.google.com (HELO mail-wm0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 23 Mar 2016 08:50:19 +0000 Received: by mail-wm0-f53.google.com with SMTP id p65so223735054wmp.1 for ; Wed, 23 Mar 2016 01:50:19 -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=i9oc+g8YEsVHcRP/97BVLTT+5Z7bqQ+jnviOgz3KaWY=; b=Bsa9UGfwqzdrIaZzOwuA+89LqtEaOHWtFgFykydQ3JBA3A6NBrIljaOlDTb5TAzON8 OiToDdw7ZGLkZakFoR0bvoSqq2x08DZ1qSbzPMsqyk4ad8QkKVDB3rdD7dk5aF0X6h5i J6pKgWubBBYSQFmxNU32J+MFeNJhStkAam197pm+ZvvPVFLZRpyLDEd1b21AesFKvuOj /o+g89/QbC1jZSchHUX7Uxi5wnfXPVTWHgd8gvvQvOkQs9pKyXV8ZYlgs9kRNeg7F8oB N6m/289b3uj2weSwoAZVlvmFD+cvA4i6ymyNPb4ex5E/sML0TH9DSuSC56O5x2W/2/dd g/fA== X-Gm-Message-State: AD7BkJI9KII/PcnG69pwDN9DxXM7QU7SSEl1WU9z0i1zro5ZooDXhsO44YbNQ3hSA3OBAmsb X-Received: by 10.28.223.70 with SMTP id w67mr2311535wmg.92.1458723016973; Wed, 23 Mar 2016 01:50:16 -0700 (PDT) Received: from [192.168.0.10] (cpc87017-aztw30-2-0-cust65.18-1.cable.virginm.net. [92.232.232.66]) by smtp.gmail.com with ESMTPSA id e127sm21155736wma.20.2016.03.23.01.50.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Mar 2016 01:50:16 -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> Cc: Peter Griffin , gdb@sourceware.org From: Kieran Bingham Message-ID: <56F258C2.2010007@linaro.org> Date: Wed, 23 Mar 2016 08:50: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: <56F18761.8030901@siemens.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00035.txt.bz2 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 #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 >> >