https://bugs.kde.org/show_bug.cgi?id=432870
Mark Wielaard <m...@klomp.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |philippe.waroquiers@skynet.
| |be
--- Comment #6 from Mark Wielaard <m...@klomp.org> ---
Currently nlcontrol works because gdbserver_tests/nlcontrolc.stdinB.gdb does:
# Here, all tasks should be blocked in a loooonnnng select, all in WaitSys
info threads
# We will unblock them by changing their timeout argument
# To avoid going into the frame where the timeval arg is,
# it has been defined as global variables, as the nr
# of calls on the stack differs between 32bits and 64bits,
# and/or between OS.
# ensure select finishes in a few milliseconds max:
p t[0].tv_sec = 0
p t[1].tv_sec = 0
p t[2].tv_sec = 0
p t[3].tv_sec = 0
First, I am surprised this works. Once the thread is stuck in the select system
call it seems changing the user space tv_sec shouldn't have effect on the
select call in progress. Also each new select call will reset the tv_sec:
t[s->t].tv_sec = sleepms / 1000;
t[s->t].tv_usec = (sleepms % 1000) * 1000;
And sleepms won't change. So it seems it only worked by accident. It doesn't
seem to work on other kernels as stated in nlcontrol.vgtest:
# This test is disabled on Solaris because modifying select/poll/ppoll timeout
# has no effect if a thread is already blocked in that syscall.
Now that glibc always seems to call pselect6 for which it has to copy and
translate the given timeval to a timespec, the GNU/Linux implementation also
won't work anymore with this testcase.
This also explains why it never worked on arm64, because that doesn't have a
plain select syscall. So glibc was always translating the given timeval
already.
Ideally we fix this by interrupting the select syscalls some other way. But I
don't know how to do that.
--
You are receiving this mail because:
You are watching all bug changes.
