This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug threads/20291] Set scheduler-locking on doesn't work correctly with pthread_create


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]