This is the mail archive of the
mailing list for the GDB project.
Re: "record save" failure
- From: Cedric Roux <sed at free dot fr>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: Hui Zhu <teawater at gmail dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Wed, 22 Jan 2014 16:44:25 +0100
- Subject: Re: "record save" failure
- Authentication-results: sourceware.org; auth=none
- References: <52DE76B2 dot 3070302 at free dot fr> <CANFwon26TA-z0t5TNM4EJFHxA-Sr3cSZhc_-+y_Fn1OzpZ83-A at mail dot gmail dot com> <m338kgyal3 dot fsf at redhat dot com>
On 01/22/2014 04:11 AM, Sergio Durigan Junior wrote:
On Tuesday, January 21 2014, Hui Zhu wrote:
Prec didn't support multithread.
Even so, GDB shouldn't segfault like that.
Cedric, thanks for the report. Would it be possible for you to test
this with our git HEAD? Also, if you still find the issue with git
HEAD, could you please file a bug in our bugzilla about this issue?
fails too with GNU gdb (GDB) 18.104.22.16840121-cvs (git cloned yesterday)
Attached is a little C program that exhibits the problem.
You need two terminals: Tprog and Tgdb.
In Tprog: compile and run recthr.
When it stops, in Tgdb, launch gdb.
Then press enter in Tprog, and, well, follow what the program
asks you to do.
What it does is: create a thread th1, wait for gdb, th1 quits
(so that gdb sees th1 leaving, I think that's the triggering
event) and th2 is created, then gdb records a function run by that
thread and when it's done the user asks for "record save"
which fails. Then the user types "info record" and everyone
goes back to nowhere. (Maybe th2 is not necessary here.)
I think you set a global variable to the TID of th1. But th1 has gone
away when I record th2, so asking the kernel for th1's registers' values
fails. Or something like that.
I still have a 64b computer here, with debian. But I bet it would fail
with something else. (Maybe you have to run the linux kernel, not
even sure about that...)
I let you deal with your bug tracking stuff, I'm not good with those. :)
On my side I will try to change the TID for the one I record but since
you don't support multi-threading recording I won't bother you with my
little hacks, which, I fear, will be terribly dirty. (Note though
that the recording is done with "scheduler-locking on", which means I
record a single thread.)
/* compile with: gcc -pthread -Wall recthr.c -o recthr */
volatile int th1_done;
void *th1(void *_)
printf("run\ngdb -p %d\nthen in gdb type:\ncont\nand press enter in this term\n", getpid());
th1_done = 1;
for (x = 0; x < 10; x++) i += x*2;
void after_traceme(int x)
void *th2(void *x)
int i = traceme();
void new_thread(void *(*f)(void *))
pthread_create(&th, 0, f, 0);
while (!th1_done) usleep(10*1000);
printf("type:\nctrl+c\nhb *%p\nhb *%p\ncont\nin gdb and press enter in this term\n",
printf("type:\nset scheduler-locking on\nrecord full\ncont\nin gdb\n");
printf("then:\nrecord save /tmp/XX\nit should fail\n");
printf("then type:\ninfo record\nit should segfault\n");
printf("and happy debugging to you too.:)\n");
while (1) pause();