bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug hurd/24110] New: SS_DISABLE never set in stack_t value returned by


From: bruno at clisp dot org
Subject: [Bug hurd/24110] New: SS_DISABLE never set in stack_t value returned by sigaltstack
Date: Sun, 20 Jan 2019 16:37:55 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=24110

            Bug ID: 24110
           Summary: SS_DISABLE never set in stack_t value returned by
                    sigaltstack
           Product: glibc
           Version: 2.24
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: hurd
          Assignee: unassigned at sourceware dot org
          Reporter: bruno at clisp dot org
                CC: address@hidden, tschwinge at sourceware dot org
  Target Milestone: ---

Created attachment 11550
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11550&action=edit
Test case

When sigaltstack() is used to query the current state of the alternate stack
(a) immediately after entering main(),
(b) in a freshly created thread,
on GNU Hurd 0.9 it returns a 'stack_t' value with SS_DISABLE not set in
ss_flags, and ss_sp and ss_size both 0.

According to POSIX
https://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaltstack.html
"The ss_flags member specifies the new stack state. If it is set to SS_DISABLE,
the stack is disabled and ss_sp and ss_size are ignored. Otherwise, the stack
shall be enabled, and the ss_sp and ss_size members specify the new address and
size of the stack."

So the sigaltstack() is reporting that an alternate stack is enabled but with a
stack of size 0 at address 0 - which makes no sense.

On all other platforms I tested (Linux, macOS, FreeBSD, NetBSD, OpenBSD, AIX,
HP-UX, Solaris, Haiku, Cygwin), the 'stack_t' value has SS_DISABLE set in
ss_flags in these situations.

How to reproduce:
$ gcc -Wall foo.c -lpthread
$ ./a.out

-- 
You are receiving this mail because:
You are on the CC list for the bug.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]