HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Crash in U_STACK_TRACE function
Operating System - HP-UX
1834178
Members
2482
Online
110064
Solutions
Forums
Categories
Company
Local Language
back
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
back
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
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- 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
11-21-2008 06:48 AM
11-21-2008 06:48 AM
Crash in U_STACK_TRACE function
Hi,
I am calling U_STACK_TRACE function from my application and getting crash at following location
#11 0xc00000000192c9a0:0 in uwx_restore_reg+0x1a0 ()
from /usr/lib/hpux64/libunwind.so.1
#12 0xc000000001950d60:0 in uwx_step+0x15e0 ()
from /usr/lib/hpux64/libunwind.so.1
#13 0xc00000000195ed40:0 in _UNW_STACK_TRACE_COMMON(FILE*,uwx_env*,uwx_self_in
fo*)+0x120 () from /usr
/lib/hpux64/libunwind.so.1
#14 0xc00000000195eab0:0 in U_STACK_TRACE+0x1f0 ()
from /usr/lib/hpux64/libunwind.so.1
At this point ulimit -a says that stack limit for process is 8192
When I increase stack space available for process by "ulimit -s" command, to some large value say 32767, I do not encounter the error!
Is there any specific reason for this behavior?
Thanks
I am calling U_STACK_TRACE function from my application and getting crash at following location
#11 0xc00000000192c9a0:0 in uwx_restore_reg+0x1a0 ()
from /usr/lib/hpux64/libunwind.so.1
#12 0xc000000001950d60:0 in uwx_step+0x15e0 ()
from /usr/lib/hpux64/libunwind.so.1
#13 0xc00000000195ed40:0 in _UNW_STACK_TRACE_COMMON(FILE*,uwx_env*,uwx_self_in
fo*)+0x120 () from /usr
/lib/hpux64/libunwind.so.1
#14 0xc00000000195eab0:0 in U_STACK_TRACE+0x1f0 ()
from /usr/lib/hpux64/libunwind.so.1
At this point ulimit -a says that stack limit for process is 8192
When I increase stack space available for process by "ulimit -s" command, to some large value say 32767, I do not encounter the error!
Is there any specific reason for this behavior?
Thanks
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-21-2008 07:07 AM
11-21-2008 07:07 AM
Re: Crash in U_STACK_TRACE function
>getting crash at following location
What type of crash? Signal 11 stack overflow?
Do you have the latest Unwind Lib patches? PHSS_38139 for 11.31.
>Is there any specific reason for this behavior?
You have answered your own question. You must have a large enough stack to call U_STACK_TRACE.
What type of crash? Signal 11 stack overflow?
Do you have the latest Unwind Lib patches? PHSS_38139 for 11.31.
>Is there any specific reason for this behavior?
You have answered your own question. You must have a large enough stack to call U_STACK_TRACE.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-21-2008 08:39 PM
11-21-2008 08:39 PM
Re: Crash in U_STACK_TRACE function
>What type of crash? Signal 11 stack overflow?
Do you have the latest Unwind Lib patches? PHSS_38139 for 11.31.
I am getting SIGSEGV.
I do not have latest patch of libunwind.so.1.
> Is there any specific reason for this behavior?
Thread dump showed that even with stack size cap of 8192, stack was not fully used still I got the crash. However with increased stack size this was prevented. That is why I asked.
Do you have the latest Unwind Lib patches? PHSS_38139 for 11.31.
I am getting SIGSEGV.
I do not have latest patch of libunwind.so.1.
> Is there any specific reason for this behavior?
Thread dump showed that even with stack size cap of 8192, stack was not fully used still I got the crash. However with increased stack size this was prevented. That is why I asked.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-21-2008 11:14 PM
11-21-2008 11:14 PM
Re: Crash in U_STACK_TRACE function
>I am getting SIGSEGV.
But are you getting stack overflow? Or have you enabled sigaltstack(2)?
>I do not have latest patch of libunwind.so.1.
Make it so.
>Thread dump showed that even with stack size cap of 8192, stack was not fully used
What's this? Are you dealing with the main stack or a thread stack?
If the latter, 1/2 of the stack is used for the RSE stack.
>with increased stack size this was prevented. That is why I asked.
Again, your changes answered your question.
You should ignore the incorrect/lying "Thread dump".
But are you getting stack overflow? Or have you enabled sigaltstack(2)?
>I do not have latest patch of libunwind.so.1.
Make it so.
>Thread dump showed that even with stack size cap of 8192, stack was not fully used
What's this? Are you dealing with the main stack or a thread stack?
If the latter, 1/2 of the stack is used for the RSE stack.
>with increased stack size this was prevented. That is why I asked.
Again, your changes answered your question.
You should ignore the incorrect/lying "Thread dump".
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP