* Re: internal-error inferior_thread(): Assertion `tp' failed
[not found] ` <e62820802979355efb778f100f8f2535@polymtl.ca>
@ 2017-04-20 16:08 ` Luke Dalessandro
[not found] ` <a5e0da9289019cce511d45c8eafa61f0@polymtl.ca>
0 siblings, 1 reply; 4+ messages in thread
From: Luke Dalessandro @ 2017-04-20 16:08 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 10226 bytes --]
> On Apr 20, 2017, at 11:45 AM, Simon Marchi <simon.marchi@polymtl.ca> wrote:
>
> 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=yes --vgdb-error=0`
>> 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’m
>> configuring and running from a $HOME relative prefix), but the
>> assertion itself doesn’t given me much information to go on, google
>> has been unhelpful, and I’m not aware of any specific changes that
>> I’ve made to my environment.
>> Does anyone have experience with this problem?
>> Thanks,
>> Luke
>
> Hi Luke,
>
> 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 entry in the GDB thread list. That's definitely a GDB bug, since it's a state it shouldn't be in.
>
> If you want to increase the chances of someone looking at the problem, you should provide an easy way to reproduce your problem (small test program, gdb commands used, etc).
>
> Thanks,
>
> Simon
Thanks Simon,
To reproduce using two shells:
<shell 1>
$ cat hello.cpp
#include <iostream>
#include <thread>
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==
<shell 2>
$ 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 <http://gnu.org/licenses/gpl.html>
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:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
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:
<http://www.gnu.org/software/gdb/bugs/>.
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 via bugzilla. I just wanted to verify that there’s not something obvious 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: <gdb-return-45725-listarch-gdb=sources.redhat.com@sourceware.org>
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: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
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â, 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 <ldalessandro@gmail.com>
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 <simon.marchi@polymtl.ca>
Cc: gdb@sourceware.org
In-Reply-To: <02849E66-1C91-4453-9C92-5BDF9CC1C0F1@gmail.com>
References: <F24E67E5-CC2F-45E5-9833-C6476B683B83@gmail.com> <e62820802979355efb778f100f8f2535@polymtl.ca> <02849E66-1C91-4453-9C92-5BDF9CC1C0F1@gmail.com>
Message-ID: <a5e0da9289019cce511d45c8eafa61f0@polymtl.ca>
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:
>
> <shell 1>
>
> $ cat hello.cpp
> #include <iostream>
> #include <thread>
> 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
> =\x10408== Memcheck, a memory error detector
> =\x10408== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et
> al.
> =\x10408== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for
> copyright info
> =\x10408== Command: ./hello
> =\x10408=> =\x10408== (action at startup) vgdb me ...
> =\x10408=> =\x10408== TO DEBUG THIS PROCESS USING GDB: start GDB like this
> =\x10408== /path/to/gdb ./hello
> =\x10408== and then give GDB the following command
> =\x10408== target remote |
> /u/ldalessa/.local/modules/valgrind/HEAD/lib/valgrind/../../bin/vgdb
> --pid\x10408
> =\x10408== --pid is optional if only one valgrind process is running
> =\x10408=>
> <shell 2>
>
> $ 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
> <http://gnu.org/licenses/gpl.html>
> 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:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> 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\x10408
> Remote debugging using |
> /u/ldalessa/.local/modules/valgrind/HEAD/lib/valgrind/../../bin/vgdb
> --pid\x10408
> 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:
> <http://www.gnu.org/software/gdb/bugs/>.
>
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread