gdb backtrace - don't understand it

[blackwater]

Hi,

I have a backtrace and I don't know what has happened with the thread # 3. What do you recommend in this situation?

Thread 4 (system thread 2017014):
#0 0xc00000000033c7d0:0 in __ksleep+0x30 () from /lib/hpux64/libc.so.1
#1 0xc0000000001284b0:0 in __mxn_sleep () at /ux/core/libs/threadslibs/src/common/pthreads/sleep.c:1148
#2 0xc0000000000c1230:0 in <unknown_procedure> + 0xcd0 () at /ux/core/libs/threadslibs/src/common/pthreads/cond.c:2493
#3 0xc0000000000c36b0:0 in pthread_cond_timedwait () at /ux/core/libs/threadslibs/src/common/pthreads/cond.c:2067
#4 0xc000000007d624b0:0 in agentx::agentx_trap::execute()+0x710 () from /usr/local/net-snmp/ps/lib/libptrsrvsnmp.so
#5 0xc000000007d85df0:0 in threads::thread::thread_proc(threads::thread*)+0x100 () from /usr/local/net-snmp/ps/lib/libptrsrvsnmp.so
#6 0xc000000007d86010:0 in start_routine_thread+0x30 () from /usr/local/net-snmp/ps/lib/libptrsrvsnmp.so
#7 0xc0000000000d0f40:0 in __pthread_bound_body () at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:4594

Thread 3 (system thread 2017013):
#0 0xc000000000008800 in <unknown_procedure> ()
#1 0xc000000000004280 in <unknown_procedure> ()

Thread 2 (system thread 2016985):
#0 0xc000000000343f30:0 in sched_yield+0x30 () from /lib/hpux64/libc.so.1
#1 0xc0000000000e2a30:0 in __vp_yield () at /ux/core/libs/threadslibs/src/common/pthreads/vp.c:1153
#2 0xc0000000000f2fb0:0 in __spin_lock_spin () at /ux/core/libs/threadslibs/src/common/pthreads/spin.c:382
#3 0xc000000000128ee0:0 in __mxn_sleep () at /ux/core/libs/threadslibs/src/common/pthreads/sleep.c:1156
#4 0xc0000000000c1230:0 in <unknown_procedure> + 0xcd0 () at /ux/core/libs/threadslibs/src/common/pthreads/cond.c:2493
#5 0xc0000000000c36b0:0 in pthread_cond_timedwait () at /ux/core/libs/threadslibs/src/common/pthreads/cond.c:2067
#6 0x4000000000272110:0 in dtl::msgqueue::dequeue()+0x570 ()
#7 0x400000000076cdb0 in LOG::log_controller::execute()+0x40 ()
#8 0x4000000000273e40:0 in dtl::_threadproc(void*)+0x70 ()
#9 0xc0000000000d0f40:0 in __pthread_bound_body () at /ux/core/libs/threadslibs/src/common/pthreads/pthrea

P.S. This thread has been moved from HP-UX > General to HP-UX > languages - HP Forums Moderator

[blackwater]

The program is run on HP-UX 11-23 ia64. It is compiled with gcc 4.3.1

[Dennis Handly]

>I don't know what has happened with the thread #3. What do you recommend in this situation?

This could be dld? If you do "info shared", you can get the start and end of each load module. And from that, you can match up the PC addresses to find what contains 0xc000000000008800.

Is this a core file? Any reason you are looking at thread 3?

What version of gdb do you have? The latest is 6.0:
http://www.hp.com/go/wdb

[blackwater]

Dennis, thank you for a prompt response.

1) Is this a core file?
Yes it is.

2) Any reason you are looking at thread 3?
Cause it doesn't have any backtrace. The other threads ot the application do that I expect and their backtraces do not look suspicious.

3) What version of gdb do you have?
I have asked a customer to provide this information but still did get the answer. If the version is not 6.0 I will ask whem to install the latest gdb.

[Matti_Kurkela · Accepted solution]

So this is a core dump backtrace on Itanium.

Is this analysis done on the machine that produced the core?

If not, was the "packcore" utility used before transferring the core to another system for analysis?

If not, the analysis system must have *exactly* the same software and patches installed as on the system that produced the core, otherwise the analysis may have errors.

MK

[blackwater]

Matti, thanks.

This is a good point about analyzing core on the same machine. I knew about it but forgot to tell the customer about doing it in this way. My mistake. Thank you.

[Suganya Thirumurthy]

Please refer to "Debugging core files using HP WDB" at www.hp.com/go/wdb for more details on core file debugging.

[Dennis Handly]

>Cause it doesn't have any backtrace. The other threads of the application do that I expect and their backtraces do not look suspicious.

Did the process abort with a signal, if so, which thread? That's where you start.
If it is hung, then you need to hunt.

In your case, both thread 4 and 2 are sleeping, so they can be bad.

Have you enabled thread debugging?
Otherwise for every thread, you have to determine what they are waiting for and what resources they have locked.

[blackwater]

My mistake was that I had not asked a customer to get backtrace properly. Having read these recommendations I asked the customer to get backtrace again using the latest gdb and with the correct set of libraries.

Unfortunately, I haven't received any response from him for a few days. Anyway as the first backtrace was gotten under completely wrong conditions (gdb 5.6 for PA-RISC although the application was compiled for ia64 and possibly with not complete set of libraries) I decided to close this thread.