| Summary: | pthread_setcanceltype fails to set type | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Robin Gareus <robin> |
| Component: | nptl | Assignee: | Adhemerval Zanella <adhemerval.zanella> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | adhemerval.zanella, drepper.fsp |
| Priority: | P2 | ||
| Version: | 2.35 | ||
| Target Milestone: | 2.36 | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | 2022-05-31 00:00:00 | |
| Attachments: | example code to reproduce the bug | ||
|
Description
Robin Gareus
2022-05-31 17:19:20 UTC
It affects master as well, I will take a look. The problem seems not to be on pthread_setcanceltype, but rather on nptl/libc-clenaup.c that implements handlers used by printf. If you remove the printf on the thread function the thread is cancelled as expected. Could you check if the following patch fixes it?
diff --git a/nptl/libc-cleanup.c b/nptl/libc-cleanup.c
index c4a83591bf..2ce59388d4 100644
--- a/nptl/libc-cleanup.c
+++ b/nptl/libc-cleanup.c
@@ -57,7 +57,8 @@ __libc_cleanup_pop_restore (struct _pthread_cleanup_buffer *buffer)
THREAD_SETMEM (self, cleanup, buffer->__prev);
int cancelhandling = atomic_load_relaxed (&self->cancelhandling);
- if (cancelhandling & CANCELTYPE_BITMASK)
+ if (buffer->__canceltype != PTHREAD_CANCEL_DEFERRED
+ && (cancelhandling & CANCELTYPE_BITMASK) == 0)
{
int newval;
do
I will send a patch along with a testcase.
Yes, that patch fixes the issue. Confirmed with both the test-tool, as well as the "real world" issue with jackd + Ardour! Thanks for the amazingly fast response and fix! (In reply to Robin Gareus from comment #3) > Yes, that patch fixes the issue. Confirmed with both the test-tool, as well > as the "real world" issue with jackd + Ardour! > > Thanks for the amazingly fast response and fix! Well, I was the one that actually messed up the revert ;) > The problem seems not to be on pthread_setcanceltype, but rather on nptl/libc-clenaup.c that implements handlers used by printf. The issue is also present with a direct call, without printf() or checking the return value. Regardless, the patch fixes this as well. > Well, I was the one that actually messed up the revert ;) No shame in that, it happens to the best. 404656009b459658138ed1bd18f3c6cf3863e6a6 is a large complex commit as well. It's really distros who are to blame for shipping somewhat random git non tagged git revision. Then again arch users asked for it :) debian/sid, ubuntu use 2.35 tagged release and are not affected. Keep up the good work! Fixed on 2.36. |