why does have unknow status for some system stack

[edward wang_1]

Hi all
need you help, thanks first
log:
$ Ana/sys
> set process /id=******
> show call /sum

all Frame Summary
------------------

Frame Type Frame Address Return PC Procedure
Entry
-------------------- ----------------- -----------------
-----------------
Stack Frame 00000000.7AE670C0 FFFFFFFF.801764B4
FFFFFFFF.80176120 PROCESS_MANAGEMENT+36120
Stack Frame 00000000.7AE67100 FFFFFFFF.80176644
FFFFFFFF.80176340 EXE_STD$SYNCH_LOOP_C
Possible Null Frame 00000000.7AE67130 --
FFFFFFFF.80176620 EXE$SYNCH_LOOP_C
Stack Frame 00000000.7AE67190 00000000.00EC40EC
FFFFFFFF.8015C560 PROCESS_MANAGEMENT+1C560
Possible Null Frame 00000000.7AE671B0 --
FFFFFFFF.80217540 MESSAGE_ROUTINES+07540
Stack Frame 00000000.7AE67230 00000000.00EC45E8
00000000.00EC4000 TOFFSHR+30000
Stack Frame 00000000.7AE672B0 FFFFFFFF.80AC348C
00000000.00EC44B0 TOFFSHR+304B0
Possible Null Frame 00000000.7AE673F0 --
FFFFFFFF.80176620 EXE$SYNCH_LOOP_C
Stack Frame 00000000.7AE67730 FFFFFFFF.800B511C
FFFFFFFF.80AC33C0 DECC$SHR_EV56+2F3C0
Exception Dispatcher 00000000.7AE67780 FFFFFFFF.800B2340
FFFFFFFF.800B50F0 EXCEPTION+090F0
Stack Frame 00000000.7AE67A10 00000000.000C554C
00000000.000C5590 AM83+C5590
Stack Frame 00000000.7AE67A70 FFFFFFFF.80383CE4
00000000.000C54D0 AM83+C54D0
Stack Frame 00000000.7AE67B00 FFFFFFFF.8014A22C
FFFFFFFF.80383B50 IMAGE_MANAGEMENT+15B50
Stack Frame 00000000.7AE67B90 FFFFFFFF.8014A0A8
FFFFFFFF.8014A0E0 PROCESS_MANAGEMENT+0A0E0 Cannot display further call frames (Bottom of stack)

GS1280,VMS
cu application's some process no response in some time, and view it , cu make sure its process is waiting some VMS system process or function, so hope HP to help analysis for stack PROCESS_MANAGEMENT、EXE_STD$SYNCH_LOOP_C、EXE$SYNCH_LOOP_C、PROCESS_MANAGEMENT、MESSAGE_ROUTINES. and provide some info to cu.

edward

[Jon Pinkley]

Please read

http://andrewferguson.net/2007/10/03/psychic-debugging-why-doesnt-xyz-work-it-just-says-lmnop/

[Willem Grooters · Accepted solution]

To find out what a process is waiting for, the very first thing to do is check the process data, not the stack. Check:
* process state
* event flags.
* busy channels (input and output)
* outstanding IO on any device

What is mentioned "" seem to me to be P1 addresses, not values. These are noth known by SDA unless they belong to a system-allocated strcuture (like JIB) AND the data of that structure is loaded into SDA.
Chances are these addresses refer to program information you're looking for. Examine the data at these locations, and keep in mind you may have to dig deeper.

For further help, specify VMS version, and more detail on what actually happens. Is it within DCL that theer is a problem (command procedure), some image that runs, what type of process? The first screen in SDA,

SDA> SHOW SUMMARY
SDA> SHOW PROCESS/INDEX=nnnn

will supply sufficient information to start with.

[Wim Van den Wyngaert]

Try sampling in PSDC/VPA/data collector.

Q>How to do PC sampling ?
-------------------------
PC sampling allows to find out which process is using which cpu mode.
It also reports the statistic per driver.

adv coll sys /out=wim1.lis/end=
adv coll rep sys /out=wim2.lis wim1.lis

Wim

[edward wang_1]

Hi up

thanks all of you, I had asked cu to get some info for which process have problem.

edward

[Hoff]

By "cu", I assume you mean "customer". The customer is asking for help with a customer application, and particularly whether the application is stuck?

In isolation, that question is unanswerable by anyone other than the customer and by the folks that have the source code to particular the application. Some applications I've worked with sit entirely idle for days or weeks, waiting for an event.

Here, chances are the application is probably stuck, or we would not even be having this discussion. (I would hope.)

Which then means it's time to go look at the application source code and figure out what's really going on. The first rule of debugging being "it's your bug until you prove the misbehavior is in code elsewhere", of course.

ANALYZE /SYSTEM (SDA) isn't usually centrally used to debug a stuck application. SDA can help determine the current state and such of the process, but that is typically an adjunct to examining the source code and the program logic.

An application that has run flawlessly for a decade or more is not necessarily a bug-free application. (And in my experience, an application that's not been modified in many years usually has its share of weird bugs and timing bugs and race conditions; what are usually considered stable applications usually aren't, somewhat surprisingly.)

[edward wang_1]

Hi Hoff
thank you help, about SDA function describe. that is cu source code debug problem.

[Ian Miller.]

You may find doing
READ/EXEC
before the SHOW CALL will help as this adds more symbols to the SDA symbol table.

[labadie_1]

Wim

To do PC sampling, the Sda extension PCS is great.

$ ana/sys
pcs
SDA> pcs
PC Sampling Utility PCS commands:

PCS LOAD
PCS UNLOAD
PCS START TRACE [/BUFFER=pages] (Default=1280, good for 54 minutes for o
ne CPU)
[/MINIPL=minimum ipl]
[/PID=pid]
[/TICKDELAY=ticks] (Default=10)
PCS STOP TRACE
PCS SHOW TRACE [/PID=pid]
[/IPL=ipl]
[/MINIPL=minimum ipl]
[/STATISTICS]
[/CONTINUOUS]
[/INTERVAL=seconds]
PCS DEBUG

SDA>