[Bug libc/27581] New: Threaded program crashes under ulimit -s unlimited

[Bug libc/27581] New: Threaded program crashes under ulimit -s unlimited

[jdelvare at suse dot de]

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

            Bug ID: 27581
           Summary: Threaded program crashes under ulimit -s unlimited
           Product: glibc
           Version: 2.33
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: jdelvare at suse dot de
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 13312
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13312&action=edit
Reproducer

I have a simple program using pthreads which runs fine with the default ulimit
-s setting (8192) but crashes midway through execution when ran under ulimit -s
unlimited:

# ulimit -s unlimited
# ./thread_stack 
MAIN 0x7ffe292afc2c
THREAD 0x14ae0f69befc
START 6
DONE 0x14ae0f5f92a0
START 5
DONE 0x14ae0f556650
START 4
DONE 0x14ae0f4b3a00
Segmentation fault (core dumped)

Is this a glibc bug?

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

[Bug libc/27581] Threaded program crashes under ulimit -s unlimited

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
Once you have multiple threads, there is really no such thing as an unlimited
stack anymore for conceptual reasons, so glibc just picks a 2 MiB default and
applies it to all the created stacks.

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

[Bug libc/27581] Threaded program crashes under ulimit -s unlimited

[hpj at urpla dot net]

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

Hans-Peter Jansen <hpj at urpla dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hpj at urpla dot net

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

[Bug libc/27581] Threaded program crashes under ulimit -s unlimited

[carlos at redhat dot com]

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #2 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #1)
> Once you have multiple threads, there is really no such thing as an
> unlimited stack anymore for conceptual reasons, so glibc just picks a 2 MiB
> default and applies it to all the created stacks.

Right the relevant code is in nptl/nptl-init.c
(__pthread_initialize_minimal_internal).

Users still see these values of conceptually muddled, and it's hard to explain
the distinction between executable stack and the relation to thread stack
because there appears to be one but there isn't, there are just defaults being
adjusted to be heuristic matches.

In the case you need more control we provide pthread_setattr_default_np() that
allows you to set a larger default stack size for all threads by default. This
way you can independently control the stack size of all threads and the stack
size of the main program.

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

[Bug libc/27581] Threaded program crashes under ulimit -s unlimited

[jdelvare at suse dot de]

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

Jean DELVARE <jdelvare at suse dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |NOTABUG
             Status|NEW                         |RESOLVED

--- Comment #3 from Jean DELVARE <jdelvare at suse dot de> ---
Thank you very much for the quick answers. Closing as NOTABUG.

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