This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/17158] New: strsignal does not know about signals that GLibc reserves for internal use
- From: "sstewartgallus00 at mylangara dot bc.ca" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 14 Jul 2014 20:37:03 +0000
- Subject: [Bug libc/17158] New: strsignal does not know about signals that GLibc reserves for internal use
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17158
Bug ID: 17158
Summary: strsignal does not know about signals that GLibc
reserves for internal use
Product: glibc
Version: 2.21
Status: NEW
Severity: enhancement
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: sstewartgallus00 at mylangara dot bc.ca
CC: drepper.fsp at gmail dot com
strsignal gives "Unknown signal %d" for signals that GLibc reserves
for internal use.
One might think that there is no reason for strsignal to know about
the signals that GLibc uses internally but in fact a legitimate use of
strsignal is for a debugger that logs signals and their
descriptions. Not sure how legitimate this use case is given that it's
possible to have multiple libcs on a system so a debugger really can't
know what a program uses a signal for. Anyways, this will only take a
tiny amount of effort to fix so it might as well be fixed.
Some possible resolutions:
- don't assume a specific libc and display realtime signals without
numbering them according to distance from SIGRTMIN
- assume a specific libc and display signals as things like "Internal
pthread cancel signal"
- keep the status quo the same and don't care about this corner case
My personal use for this was that I track and monitor services by
ptracing them and I log a description when my tasks get signals and I
send them back.
--
You are receiving this mail because:
You are on the CC list for the bug.