Hanging process. C/C++ function to get process information.

[Miguel Sanchez_2]

Hell Volker,

Attached is the output of SDA with the thread stack information.

Thanks,
Miguel

[Anthony Magana]

I had some "fun" debugging a C++ program that was threaded a few months back. A few points that might help:

- You can use debug/keep on the process thats hanging. Then you can actually do a show calls to see where in your app its hanging. The sequence you would follow is:
1. debug/keep
2. At debug prompt : connect
3. type cmd: show task/all to see all
the threads running in your app and their
state.
4. set task to set context to
a particular thread.
5. show calls to see the call stack for
the thread.

Even better if you have the code built debug, you can then set break to a function and see where in the code its sitting.

- Other common problem that is encountered with threaded apps is the the pthread stack size being too small. Sometimes the app doesn't fail in obvious ways. The default stack size is oftentimes too small. You can explicitly set it with a call to pthread_attr_setstacksize. If some thread that is is supposed to sync up with some other threads dies before that sync point the other threads could be waiting there forever waiting for that sync point which will never happen because of the dead thread.

[Volker Halle]

Miguel,

unfortunately, the SDA> SHOW STACK 277990;60 (of the blocked exit-handling thread) did not provide enough information. Next time, try SDA> SHOW STACK ...;100

Or - even better - try the kept debugger as suggested by Anthony.

Volker.

[Miguel Sanchez_2]

Hi Volker,

I have attached the output from SDA, this time with more pthread stack info.

I have checked with the system administrator and they have the latest pthread patches installed.

Anthony:
We have tried to debug the process but we get the error:
DBG> connect WSM_BGH1SW_P_1
%DEBUG-E-NOCONNECT, CONNECT command failed
-SYSTEM-W-NONEXPR, nonexistent process

But that is actually the process name. What are we doing wrong?.
Another question: how can I get the pthread stack size?

Thanks for your help,
Miguel

[Volker Halle]

Miguel,

to use DBG> CONNECT process-name, both processes must be running under the same group UIC. Alternatively you can use:

DBG> CONNECT %PROCESS_PID pid-of-process

If it hangs the next time and the thread -4 stack pointer is again 277990, you can look at the call frames with

SDA> SHOW CALL 277A60
SDA> SHOW CALL/NEXT
and so on, or

SDA> CLUE CALL 277A60

277A60 seems to be a valid FP pointing to the stack where the PDSC address (Procedure Descriptor) of PTHREAD_MUTEX_BLOCK is stored.

When looking at the call frames, try to find the first Return address in P0 space, i.e. in your WMSRV image. The look up the map and source listing and find out, what code is running at that address and what it's trying to do.

Volker.

[Anthony Magana]

In the app I worked with there was a mix of C and C++ code. The threads were explicitly created and started from C code with pthread_create calls. Before the call to the create we would set up the thread attribute with the desired stack size by calling pthread_attr_setstacksize. If you don't explicitly set the stack size there is some default that pthreads uses (don't remember offhand what it is). As I'm not that familiar with C++, I don't if there is some language native construct for creating threads in C++. I'd guess that you would be using the pthreads lib if the app explicitly codes to use threads.