Bug 149727 - cannot set thread stack size over 2M, using glibc 2.3.2-95.30
cannot set thread stack size over 2M, using glibc 2.3.2-95.30
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-25 14:35 EST by Gavin Liu
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-01 03:30:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
The test C programe. (1.68 KB, text/plain)
2005-02-25 14:37 EST, Gavin Liu
no flags Details
make file for the test case. (219 bytes, text/plain)
2005-02-25 14:38 EST, Gavin Liu
no flags Details

  None (edit)
Description Gavin Liu 2005-02-25 14:35:56 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
The attached program shows that it will fail to "setstatcksize" to
over 2M.

Please also note, that it only happened on glibc-2.3.2-95.30(the one
we recently upgrade), but NOT on glibc-2.3.2-95.6.

Version-Release number of selected component (if applicable):
glibc-2.3.2-95.30

How reproducible:
Always

Steps to Reproduce:
1.do a "make" to compile the files, 
2.on a "glibc 95.30" machine, run "./test 2097152", (2M), you should
see "exit normally"(OK). 
3.on a "glibc 95.30" machine, run "./test 2097153", (any >2M number),
you should see "Error in set stack size" error msg.(FAILED!!)
4.on a "glibc 95.6" machine, run "./test 2097153", (or any other
number), you should see "exit normally"(OK).
    

Expected Results:  I expect on all machine, I can set some large stack
size, say 8M or even bigger.

Additional info:

I already try to "unlimit stacksize", but no luck.
Comment 1 Gavin Liu 2005-02-25 14:37:38 EST
Created attachment 111437 [details]
The test C programe.

use gcc-3.3.3 to compile.
Comment 2 Gavin Liu 2005-02-25 14:38:10 EST
Created attachment 111438 [details]
make file for the test case.
Comment 3 Jakub Jelinek 2005-02-25 14:52:28 EST
Works for me just fine:
rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' glibc; ./test 8388608; ldd
./test
glibc-2.3.2-95.30.i686
try to set stacksize to 8388608
soft limit for stack size=10485760
hard limit for stack size=4294967295
exit normally.
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7fc6000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7f12000)
        libm.so.6 => /lib/tls/libm.so.6 (0xb7ef0000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7ee7000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7daf000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000)

Make sure: 1) you have i686.rpm glibc installed, not the i386.rpm one
2) you don't have LD_ASSUME_KERNEL set in the environment

Non-FLOATING_STACK LinuxThreads really doesn't allow a thread stack larger than
2MB, as stack slots in that case are in fixed 2MB array.  But that library never
supported bigger stacks.  The i386.rpm glibc includes only this library,
but if your CPU is i686+, that's not what you should have installed.
Also, LD_ASSUME_KERNEL=2.4.0 and down to 2.2.5 selects that library even in
i686.rpm glibc, but then again, this is for compatibility with broken apps and
you should only set that env var for the app that reallly needs it, not for all
other apps as well.
Comment 4 Jakub Jelinek 2005-03-01 03:30:27 EST
I'm assuming you were using non-FLOATING_STACK LinuxThreads.  If not, please
reopen with details.
Comment 5 Gavin Liu 2005-03-01 08:39:00 EST
Yes, by using the correct 'i686' package my problem is gone. Our sys admin 
wrongly installed a 'i386' package on a i686 machine, that cause this wired 
behaviour. Thanks. 

Note You need to log in before you can comment on or make changes to this bug.