- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - Linux
- >
- Re: 4k-"hole" in pthread stack on 11.23 Itanium
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2008 11:54 PM
05-29-2008 11:54 PM
we're getting segfaults in one of our applications (multithreaded) while accessing an array element somewhere in the middle of the array. Elements at the beginning and at the end are fine. The array in question occupies ~64kb on the stack.
Using pstat_getprocvm() and mprotect() I found out that there is a one-page "hole" in the middle of the pthread's stack, which is neither readable nor writeable.
The attached program is a reduced test case which spawns a thread allocating an 192kb character array on the stack. That should be fine since the default stack size is 256kb.
When compiled with "aCC +DD64 -mt -g -o stackhole stackhole.c" or "gcc -g -mlp64 -pthread -o stackhole stackhole.c" it crashes at char 61456 with the default stack size.
Setting PTHREAD_DEFAULT_STACK_SIZE moves the "crash point", e.g. PTHREAD_DEFAULT_STACK_SIZE=320000 crashes at 28688.
This make only half of a thread's stack usable and clearly looks like a bug to me. Is there a patch available?
Regards
/Michael
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-30-2008 01:27 AM - edited 09-11-2011 02:21 PM
05-30-2008 01:27 AM - edited 09-11-2011 02:21 PM
Solution>This makes only half of a thread's stack usable and clearly looks like a bug to me.
You are confused. The default stacksize on IPF is 256 Kb. With half assigned to the user stack and then a guard page then the other half assigned to the RSE stack.
If you don't like the default allocation you are free to change it with:
pthread_attr_setrsestacksize_np
pthread_attr_getrsestacksize_np
pthread_default_rsestacksize_np
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-30-2008 01:41 AM
05-30-2008 01:41 AM