- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Unable to get stack trace from core file using gdb
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
Discussions
Discussions
Forums
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
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-21-2009 10:00 PM
тАО05-21-2009 10:00 PM
Unable to get stack trace from core file using gdb
We execute gdb command "thread apply all where" on a core file and collect the stack trace.
On HP-UX, sometimes we see that the crashing thread's stack trace is as below and not useful:
Thread 8 (system thread 2743852):
#0 0xc00000000003e190:0 in __sigenable+0x50 () from /usr/lib/hpux64/dld.so
#1 0xc00000000003e820:0 in apply_lazy_iplt_reloc+0x510 ()
from /usr/lib/hpux64/dld.so
I see from our logs that our signal handler was called. I would like to know whether the above stack is reliable and/or how to interpret it.
Is it a crash at loader, or the stack is not readable by gdb from core. If so, is there someway to overcome it.
This is intermittent, I had seen crash at a similar time (from application point of view) would show stack trace that we relate to our code.
Appreciate any help on this.
Thanks,
Krishna R
HP-UX version: "B.11.23 U ia64"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-21-2009 10:20 PM
тАО05-21-2009 10:20 PM
Re: Unable to get stack trace from core file using gdb
I had asked a variant of this question a few months ago, but didn't recollect it (Searching thru the forums, I thought I found a similar question from somebody else, only to find it was from me).
http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1242972043968+28353475&threadId=1262423
Dennis had suggested to apply latest dld patch. The problem here, its our customers who are hitting the crashes in their production environment, and applying the patch is not an option due to:
a. until we know for sure that it is going to help (ultimately it might help seeing stack trace, but not help in solving the original crash)
b. customer's IT policy governing the timeframe when they can apply a OS patch.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-22-2009 02:03 AM - edited тАО09-03-2011 05:57 PM
тАО05-22-2009 02:03 AM - edited тАО09-03-2011 05:57 PM
Re: Unable to get stack trace from core file using gdb
>sometimes we see that the crashing thread's stack trace is as below and not useful:
Why do you think this is the crashing thread?
Unless you have a thread stack overflow, this thread is just the victim.
What do all the other threads show?
>a. Until we know for sure that it is going to help ...
>b. Customer's IT policy governing the timeframe when they can apply a OS patch.
Why are you wasting time here then? Have the customer contact the Response Center.