This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/14744] New: kill -32 $pid or kill -33 $pid on a process cancels a random thread
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Sat, 20 Oct 2012 01:36:32 +0000
- Subject: [Bug nptl/14744] New: kill -32 $pid or kill -33 $pid on a process cancels a random thread
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=14744
Bug #: 14744
Summary: kill -32 $pid or kill -33 $pid on a process cancels a
random thread
Product: glibc
Version: unspecified
Status: NEW
Severity: minor
Priority: P2
Component: nptl
AssignedTo: unassigned@sourceware.org
ReportedBy: bugdal@aerifal.cx
CC: drepper.fsp@gmail.com
Classification: Unclassified
Signals 32 and 33 are used internally by NPTL. There's nothing wrong with this,
as they are not advertised as being available to applications (SIGRTMIN shows
up as 34 in multi-threaded applications, if I recall). However, if an outside
process sends these signals, the target process acts on the signal as if it
were a cancellation request for whichever thread happened to receive the
signal. This could cause severe breakage and data corruption in applications
which are not written to use cancellation and lack cleanup handlers.
I am unsure whether the impact is limited to user error (issuing the kill
command manually) or could arise in other ways. In any case, for robustness, I
think the signal handler should be a no-op unless pthread_cancel was really
called in the application.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.