[Bug testsuite/31312] attach-many-short-lived-threads gives inconsistent results

["thiago.bauermann at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31312

--- Comment #21 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
(In reply to Carl E Love from comment #20)
> I tried the prototype patch from Thiago.  It seems to fix the hangs on
> detach.  I ran the many-short-lived threads test 500 times.  I did have
> three runs that encountered a new error I haven't seen before.  
> 
> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 6: break at
> break_fn: 1
> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 6: break at
> break_fn: 2 (the program is no longer running)
> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 6: break at
> break_fn: 3 (the program is no longer running)
> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 6: reset timer
> in the inferior
> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 6: detach (the
> program is no longer running)
> 
> It seems the workload had finished before the expect script finished
> running.  So we may want to address that as a separate patch later. 

If you see "Program terminated with signal SIGTRAP, Trace/breakpoint trap." in
gdb.log, then it's issue 3 in comment #19. What happens is that two iterations
without seeing new thread in linux_proc_attach_tgid_threads () isn't always
enough for GDB to attach to all inferior threads, and then an unattached thread
trips on the breakpoint instruction that GDB put in the inferior. I was also
able to reproduce it on two x86_64-linux machines after hundreds of runs of the
testcase.

> Thiago's fix seems to work well on Power 10.

That's great! Thank you for testing it.

> I did work on the strace as suggested.  I was trying to get strace to attach
> to the gdb thread from the expect script.  Haven't got the script to get the
> correct gdb PID yet.  I think I was trying to attach to the expect script
> which strace fails to attach to.  I tried writing a script that I could run
> after the workload started that would call ps and try to grep out the gdb
> process id and attach to it but again I haven't got that working yet either.
> 
> 
> I will try and work on the strace thing some more but not sure if it is
> really needed at this point given that Thiago seems to have figured out the
> issues.

It's not necessary for the issue you saw. It would probably be helpful in the
case of issue 2, but that one is hard to reproduce, and I haven't started
investigating it yet (also, I don't think I'll have time to dive into it in the
next couple of weeks).

I'll open separate bugzillas for these other issues to untangle the discussion.

-- 
You are receiving this mail because:
You are on the CC list for the bug.