This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/20248] New: debug/tst-longjump_chk2 calls printf from a signal handler
- From: "fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 13 Jun 2016 10:10:47 +0000
- Subject: [Bug libc/20248] New: debug/tst-longjump_chk2 calls printf from a signal handler
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=20248
Bug ID: 20248
Summary: debug/tst-longjump_chk2 calls printf from a signal
handler
Product: glibc
Version: 2.24
Status: NEW
Severity: normal
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: fweimer at redhat dot com
CC: drepper.fsp at gmail dot com
Target Milestone: ---
stackoverflow_handler contains this:
/* Using printf is not really kosher in signal handlers but we know
it will work. */
printf ("%*sin signal handler\n", pass, "");
The comment is incorrect. printf calls vfprintf (~1760 bytes of stack space),
vfprintf calls buffered_vfprintf (~8592 bytes of stack space), and this calls
vfprintf again (~1760 bytes of stack space). Total space requirement is around
12 KiB, and the kernel places siginfo_t and ucontext_t on the stack (which can
be as large 5 KiB). As a result, a SIGSTKSZ value of 16 KiB is just not large
enough.
This causes the test case to fail on aarch64 since the value of SIGSTKSZ has
been increased. Before that, the test passed, presumably because the 8 KiB
stack allocation in buffered_vfprintf conveniently jumped over the stack frame
created by do_test. (Currently, the return address saved by do_test is
clobbered by vfprintf.)
Reducing the stack space usage of vfprintf is a different task. It is quite
close to exceeding PTHREAD_STACK_MIN on some architectures.
--
You are receiving this mail because:
You are on the CC list for the bug.