This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug threads/20291] Set scheduler-locking on doesn't work correctly with pthread_create
- From: "palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Wed, 22 Jun 2016 21:20:34 +0000
- Subject: [Bug threads/20291] Set scheduler-locking on doesn't work correctly with pthread_create
- Auto-submitted: auto-generated
- References: <bug-20291-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=20291
--- Comment #2 from Pedro Alves <palves at redhat dot com> ---
What I imagine is happening is that:
- Before, whenever a new thread appeared, everything would stop for the thread
event breakpoint, and then the event got reported to infrun.c. infrun.c would
then only continue the thread that was originally resumed.
- Now, new threads don't cause a infrun.c-visible stop.
linux-nat.c:resume_stopped_resumed_lwps resumes the new thread right after we
handle the PTRACE_EVENT_CLONE that discovered the new thread.
The problem is that the target backend has no idea whether infrun wants new
threads to be resumed or whether it wants them stopped.
I think one solution would for infrun to enable the new support for reporting
thread create/exit events (target_thread_events ->
TARGET_WAITKIND_THREAD_CREATED) whenever schedlock is in effect.
> I'm still surprised that it didn't cause any regressions on the schedlock
> tests, though. I'll take a deeper look at this and report back.
I think schedlock.c doesn't spawn new threads while the meat of the test is
running. Instead, it first starts all threads in a preparation phase.
--
You are receiving this mail because:
You are on the CC list for the bug.