topic Unable to get stack trace from core file using gdb in Operating System - HP-UX

Unable to get stack trace from core file using gdb

Krishna R — Fri, 22 May 2009 05:00:11 GMT

Hi,

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"

Re: Unable to get stack trace from core file using gdb

Krishna R — Fri, 22 May 2009 05:20:58 GMT

Apologize for being very dumb.

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.

Re: Unable to get stack trace from core file using gdb

Dennis Handly — Sun, 04 Sep 2011 00:57:26 GMT

>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.