https://bugs.kde.org/show_bug.cgi?id=445743
Paul Floyd changed:
What|Removed |Added
Status|CONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #20 from Paul Floyd ---
(In reply to Nick Briggs from comment #19)
> c.f. restart_syscall(2) in the Linux kernel --
> https://man7.org/linux/man-pages/man2/restart_syscall.2.html
That might be useful for Linux if/when someone implements
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #19 from Nick Briggs ---
c.f. restart_syscall(2) in the Linux kernel --
https://man7.org/linux/man-pages/man2/restart_syscall.2.html
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #18 from Paul Floyd ---
In the FreeBSD kernel it looks like the mutex functions are only restartable if
they don't have a timeout.
The 3 cases that I see are
UMTX_OP_MUTEX_LOCK
UMTX_OP_MUTEX_TRYLOCK
and
UMTX_OP_MUTEX_WAIT when the timeout
https://bugs.kde.org/show_bug.cgi?id=445743
Bart Van Assche changed:
What|Removed |Added
Assignee|bart.vanassche+...@gmail.co |jsew...@acm.org
|m
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #17 from Paul Floyd ---
One thing that I'm not sure about is whether restartable syscalls re-read their
userland arguments or whether they reuse the copyin()'d arguments.
--
You are receiving this mail because:
You are watching all bug
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #16 from Paul Floyd ---
(In reply to Nick Briggs from comment #15)
> Also note: drd/tests/pth_mutex_signal when run under simple memcheck, fails
> because pthread_mutex_lock() returns EINTR, while POSIX says of it (and
> related functions)
https://bugs.kde.org/show_bug.cgi?id=445743
Nick Briggs changed:
What|Removed |Added
CC||afraid-splicer...@icloud.co
|
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #14 from Paul Floyd ---
If I add to the previous patch
*flags |= SfMayBlock;
* start add*
if ((ARG2 & (VKI_FUTEX_PRIVATE_FLAG|VKI_FUTEX_LOCK_PI)) ==
(VKI_FUTEX_PRIVATE_FLAG|VKI_FUTEX_LOCK_PI)) {
*flags |= SfKernelRestart;
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #13 from Paul Floyd ---
Created attachment 149549
--> https://bugs.kde.org/attachment.cgi?id=149549=edit
Patch for FreeBSD
This patch fixes the drd/tests/pth_mutex_signal testcase on FreeBSD. I think
that it should extend easily to
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #12 from Paul Floyd ---
Looks similar on FreeBSD. truss output, standalone
78094: thr_kill(133780,SIGRT59) = 0 (0x0)
78094: _umtx_op(0x800684008,UMTX_OP_MUTEX_LOCK,0x0,0x0,0x0) ERESTART
78094: SIGNAL 124 (SIGRT59)
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #11 from Paul Floyd ---
I think that I understand the problem, at least on Linux.
PTHREAD_PRIO_INHERIT causes the type of mutex to change so that it will return
ERESTARTNOINTR if interrupted.
I see, with strace
14177 <... futex resumed>
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #10 from Paul Floyd ---
On FreeBSD, single stepping out after the user interrupt I get here
sleep_in_kernel:
if (abstime == NULL)
ret = __thr_umutex_lock(>m_lock, id); // RETURN HERE UNDER
VG
else if
https://bugs.kde.org/show_bug.cgi?id=445743
Alexander Kanavin changed:
What|Removed |Added
CC||alex.kana...@gmail.com
--- Comment #9 from
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #8 from Paul Floyd ---
On FreeBSD I get
mutex initialized
thread attributes initialized
thread created
sleeping
signalling
sleeping
nullHandler running
Assertion failed: (ret == 0), function contender_start, file
pth_mutex_signal.c, line
https://bugs.kde.org/show_bug.cgi?id=445743
Bart Van Assche changed:
What|Removed |Added
Status|REPORTED|CONFIRMED
Ever confirmed|0
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #6 from Paul Floyd ---
Unfortunately this doesn't seem to help on Linux.
The problem seems to be that after the signal contender doesn't return to
waiting.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #5 from Paul Floyd ---
And this post on SO covers why the contender mutex lock fails.
https://stackoverflow.com/questions/12781944/pthread-mutex-lock-returns-invalid-argument
--
You are receiving this mail because:
You are watching all
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #4 from Paul Floyd ---
I can also reproduce the problem on FreeBSD.
What I see so far is that main runs all the way to pthread_join. contender does
not run at all, despite the sleep. Only after main is blocked in the
pthread_join does
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #3 from Paul Floyd ---
I tried running both the the standalone and DRD under strace.
Under DRD I see the main thread getting as far as the kill, then I see
futex(0x4a814c0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #2 from Paul Floyd ---
Created attachment 143748
--> https://bugs.kde.org/attachment.cgi?id=143748=edit
reproducer with DRD extras
I tried to merge the extras (wrapper + mutex + CV) that DRD adds.
However this does not reproduce the
https://bugs.kde.org/show_bug.cgi?id=445743
--- Comment #1 from Paul Floyd ---
Interesting.
With Helgrind I get
==13857== Thread #2: Bug in libpthread: write lock granted on mutex/rwlock
which is currently wr-held by a different thread
==13857==at 0x403586F: mutex_lock_WRK
https://bugs.kde.org/show_bug.cgi?id=445743
Paul Floyd changed:
What|Removed |Added
CC||pjfl...@wanadoo.fr
--
You are receiving this
https://bugs.kde.org/show_bug.cgi?id=445743
Vladimir Nikolov changed:
What|Removed |Added
CC||vladimir.niko...@aicas.de
--
You are
24 matches
Mail list logo
