Bug 43616

Summary: LD_ASSUME_KERNEL changes number of pthreads available.
Product: [Retired] Red Hat Linux Reporter: Ed McKenzie <eem12>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: fweimer
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-06-05 21:18:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ed McKenzie 2001-06-05 21:18:01 UTC 
Description of Problem:
Without LD_ASSUME_KERNEL=2.2.5, the number of pthreads is limited to ~256,
while with that symbol exported the available pthreads rises to ~1024,
which is more consistent with other distributions/platforms.

How Reproducible:
100%

Steps to Reproduce:
1. Write a test program in {python|C|C++} that creates an infinite number
of threads. It should print the number of threads after the first thread
creation fails.
2. Run it without LD_ASSUME_KERNEL=2.2.5.
3. Run it again with that symbol defined.

Actual Results:
Out of the box, RHL 7.1 only supports ~256 threads on i686.

Expected Results:
Other platforms support many more threads. 

Additional Information:
none
Comment 1 Jakub Jelinek 2001-06-05 21:29:24 UTC 
But, unlike when running with LD_ASSUME_KERNEL=2.2.5 (= non-LDT
based threads, no floating thread stacks), this is no hard constant.
It is as easy as
ulimit -s 2048
to get the same thread limit as without LDT based threads, but one
can even
ulimit -s 256
and get loads of threads with smaller stacks.
Of course, threads apps may call setrlimit before doing first
pthread_create instead of relying on ulimit to be called in parent
shell first.