Bug 25674

I did a gdb test run with check-read1, and ran into:
...
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: no new threads (timeout)
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: set breakpoint always-inserted on
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: break break_fn
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: reset timer in the inferior
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: detach
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: set breakpoint always-inserted off
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: info breakpoints (got interactive prompt)
ERROR: breakpoints not deleted
...

But when trying to reproduce this by just running that test-case (in parallel with "stress -c 5", on a dual-core 4 thread cpu), I didn't manage to reproduce at exactly that point, only later in the test-case.

However, when looking at the first bit in the gdb.log, I found:
...
(gdb) attach 8734^M
Attaching to program: /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.threads/attach-many-short-lived-threads/attach-many-short-lived-threads, process 8734^M
[New LWP 1776]^M
[New LWP 1781]^M
[New LWP 1783]^M
  ...
[New LWP 2047]^M
[New LWP 2048]^M
[New LWP 2049]^M
[New LWP 2050]^M
Error while reading shared library symbols for /lib64/libpthread.so.0:^M
Cannot find user-level thread for LWP 1810: generic error^M
[LWP 1789 exited]^M
[LWP 1810 exited]^M
[LWP 1776 exited]^M
[LWP 1783 exited]^M
[LWP 1788 exited]^M
[LWP 1781 exited]^M
0x00007f452a3030f0 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffdb200ab90, remaining=remaining@entry=0x7ffdb200ab90) at ../sysdeps/unix/sysv/linux/nanosleep.c:27^M
27        return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M
(gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: attach
...

We can see that thread 1810 has exited, so the "Cannot find user-level thread for LWP 1810: generic error" part of the message looks correct.

It's not clear however, why we should be accessing this user thread while trying to read symbols.

Anyway, the thread error message is from an exception which seems to have interrupted symbols reading, and I think that is a bug.