From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65975 invoked by alias); 20 Apr 2017 16:08:41 -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 65956 invoked by uid 89); 20 Apr 2017 16:08:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=HOME, H*r:sk:gdb@sou, there=e2, PROCESS?= X-HELO: mail-io0-f171.google.com Received: from mail-io0-f171.google.com (HELO mail-io0-f171.google.com) (209.85.223.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Apr 2017 16:08:38 +0000 Received: by mail-io0-f171.google.com with SMTP id k87so76448309ioi.0 for ; Thu, 20 Apr 2017 09:08:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j0RItJiFfWNUpgPrBNAKWOBM1wd85QuR/T+LKiQpdQI=; b=Kdq2mRAPeMpH8HXl3ZVrCNYGkKpfF1/AGU/Fx/JmMpQSWvye0S7H7LcH3k8dErmUWG hKWkPJ8IwiI/1OhBSGLzpMI6KCx9gmdiEgfV/IC32h1ahz1Q5jOqe8qgjpfBQw8FZfWf gegFZCGVQsHSGPsed8mlzVyA7CYHOgF9MmxW8JgMSLv098wPmv7g09Uieq2n5cuBbqHx zGaJuK96sF0CWcIrd4N63IPTNonfVVYF8M/RMcm+JYnMmF/r4mGU6iHdHfn/XWNzC3il z2sQnZCdbwg6nxOX+H9iyeXD/2ojqWwCe4Jgr4RZ7/Lou/YVCihsHO3qf/p2pTO4h05x Elyw== X-Gm-Message-State: AN3rC/56HfL/JS7Y/PgTnpdI+0aNuz8i/0R2adOnY0YHMztigxqnUDj5 CCDXc7asT+UEZ/FVvGw= X-Received: by 10.107.58.131 with SMTP id h125mr11033065ioa.37.1492704477561; Thu, 20 Apr 2017 09:07:57 -0700 (PDT) Received: from [192.168.2.9] (108-219-175-115.lightspeed.iplsin.sbcglobal.net. [108.219.175.115]) by smtp.gmail.com with ESMTPSA id h71sm2876173ioe.9.2017.04.20.09.07.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 09:07:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: internal-error inferior_thread(): Assertion `tp' failed From: Luke Dalessandro In-Reply-To: Date: Thu, 20 Apr 2017 16:08:00 -0000 Cc: gdb@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <02849E66-1C91-4453-9C92-5BDF9CC1C0F1@gmail.com> References: To: Simon Marchi X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00027.txt.bz2 > On Apr 20, 2017, at 11:45 AM, Simon Marchi wrot= e: >=20 > On 2017-04-20 10:13, Luke Dalessandro wrote: >> One of my main uses of gdb is to attach to multithreaded valgrind >> processes run as `valgrind --vgdb=3Dyes --vgdb-error=3D0` >> With recent builds of gdb I have started to encounter this assertion >> when the valgrind process is creating new threads. >> thread.c:89: internal-error: thread_info* inferior_thread(): >> Assertion `tp' failed. >> I suspect that this has something to do with my environment (I=E2=80=99m >> configuring and running from a $HOME relative prefix), but the >> assertion itself doesn=E2=80=99t given me much information to go on, goo= gle >> has been unhelpful, and I=E2=80=99m not aware of any specific changes th= at >> I=E2=80=99ve made to my environment. >> Does anyone have experience with this problem? >> Thanks, >> Luke >=20 > Hi Luke, >=20 > This error is quite generic. It means that the currently selected thread= in GDB (identified by a process/thread id) doesn't have a corresponding en= try in the GDB thread list. That's definitely a GDB bug, since it's a stat= e it shouldn't be in. >=20 > If you want to increase the chances of someone looking at the problem, yo= u should provide an easy way to reproduce your problem (small test program,= gdb commands used, etc). >=20 > Thanks, >=20 > Simon Thanks Simon, To reproduce using two shells: $ cat hello.cpp=20 #include #include using namespace std; int main() { thread([](){ cout << "hello world\n=E2=80=9D; }).join(); return 0; } $ g++ -pthread -o hello hello.cpp=20 $ ./hello=20 hello world $ valgrind --vgdb-error=3D0 ./hello =3D=3D10408=3D=3D Memcheck, a memory error detector =3D=3D10408=3D=3D Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward = et al. =3D=3D10408=3D=3D Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for c= opyright info =3D=3D10408=3D=3D Command: ./hello =3D=3D10408=3D=3D=20 =3D=3D10408=3D=3D (action at startup) vgdb me ...=20 =3D=3D10408=3D=3D=20 =3D=3D10408=3D=3D TO DEBUG THIS PROCESS USING GDB: start GDB like this =3D=3D10408=3D=3D /path/to/gdb ./hello =3D=3D10408=3D=3D and then give GDB the following command =3D=3D10408=3D=3D target remote | /u/ldalessa/.local/modules/valgrind/HEA= D/lib/valgrind/../../bin/vgdb --pid=3D10408 =3D=3D10408=3D=3D --pid is optional if only one valgrind process is running =3D=3D10408=3D=3D=20 $ gdb ./hello=20 GNU gdb (GDB) 8.0.50.20170420-git Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./hello...(no debugging symbols found)=E2=80=A6done. (gdb) target remote | /u/ldalessa/.local/modules/valgrind/HEAD/lib/valgrind= /../../bin/vgdb --pid=3D10408 Remote debugging using | /u/ldalessa/.local/modules/valgrind/HEAD/lib/valgr= ind/../../bin/vgdb --pid=3D10408 relaying data between gdb and process 10408 warning: remote target does not support file transfer, attempting to access= files from local filesystem. Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /us= r/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done. done. 0x00000000040012d0 in _start () from /lib64/ld-linux-x86-64.so.2 (gdb) c Continuing. thread.c:100: internal-error: thread_info* inferior_thread(): Assertion `tp= ' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y This is a bug, please report it. For instructions, see: . thread.c:100: internal-error: thread_info* inferior_thread(): Assertion `tp= ' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) y Aborted (core dumped) If this is really a bug I can just report along with the gdb stack trace vi= a bugzilla. I just wanted to verify that there=E2=80=99s not something obvi= ous on my end that would cause this. Thanks, Luke >From gdb-return-45725-listarch-gdb=sources.redhat.com@sourceware.org Thu Apr 20 16:53:03 2017 Return-Path: Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 65465 invoked by alias); 20 Apr 2017 16:53:02 -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 Delivered-To: mailing list gdb@sourceware.org Received: (qmail 65447 invoked by uid 89); 20 Apr 2017 16:53:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-1.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=there=e2, PROCESS, online, transfer?= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Apr 2017 16:52:59 +0000 Received: by simark.ca (Postfix, from userid 33) id 545AA1E48E; Thu, 20 Apr 2017 12:52:59 -0400 (EDT) To: Luke Dalessandro Subject: Re: internal-error inferior_thread(): Assertion `tp' failed X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 20 Apr 2017 16:53:00 -0000 From: Simon Marchi Cc: gdb@sourceware.org In-Reply-To: <02849E66-1C91-4453-9C92-5BDF9CC1C0F1@gmail.com> References: <02849E66-1C91-4453-9C92-5BDF9CC1C0F1@gmail.com> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.4 X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00028.txt.bz2 Content-length: 3546 On 2017-04-20 12:07, Luke Dalessandro wrote: > To reproduce using two shells: > > > > $ cat hello.cpp > #include > #include > using namespace std; > int main() { > thread([](){ cout << "hello world\n”; }).join(); > return 0; > } > > $ g++ -pthread -o hello hello.cpp > > $ ./hello > hello world > > $ valgrind --vgdb-error=0 ./hello > ==10408== Memcheck, a memory error detector > ==10408== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et > al. > ==10408== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for > copyright info > ==10408== Command: ./hello > ==10408== > ==10408== (action at startup) vgdb me ... > ==10408== > ==10408== TO DEBUG THIS PROCESS USING GDB: start GDB like this > ==10408== /path/to/gdb ./hello > ==10408== and then give GDB the following command > ==10408== target remote | > /u/ldalessa/.local/modules/valgrind/HEAD/lib/valgrind/../../bin/vgdb > --pid=10408 > ==10408== --pid is optional if only one valgrind process is running > ==10408== > > > > $ gdb ./hello > GNU gdb (GDB) 8.0.50.20170420-git > Copyright (C) 2017 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from ./hello...(no debugging symbols found)…done. > > (gdb) target remote | > /u/ldalessa/.local/modules/valgrind/HEAD/lib/valgrind/../../bin/vgdb > --pid=10408 > Remote debugging using | > /u/ldalessa/.local/modules/valgrind/HEAD/lib/valgrind/../../bin/vgdb > --pid=10408 > relaying data between gdb and process 10408 > warning: remote target does not support file transfer, attempting to > access files from local filesystem. > Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols > from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done. > done. > 0x00000000040012d0 in _start () from /lib64/ld-linux-x86-64.so.2 > > (gdb) c > Continuing. > thread.c:100: internal-error: thread_info* inferior_thread(): > Assertion `tp' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) y > > This is a bug, please report it. For instructions, see: > . > > thread.c:100: internal-error: thread_info* inferior_thread(): > Assertion `tp' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Create a core file of GDB? (y or n) y > Aborted (core dumped) I've tried those steps and the program runs to completion normally. I am using valgrind-3.10.1 and 8.0.50.20170420-git. > If this is really a bug I can just report along with the gdb stack > trace via bugzilla. I just wanted to verify that there’s not something > obvious on my end that would cause this. An internal error from GDB is always a bug. If you could report it in bugzilla with as much details as you can, it would be appreciated. Thanks! Simon