Wierdness in SDA on VMS 8-3 (Itanium)

[Brian Reiter]

Hi Folks,

Had a terminal sessions (running a DCL script) which started consuming a 100% CPU. Running the script manually caused no problems so decided to have a poke about and find out what was going on.


From a SHO SYS the process is visible:

0000081E _TNA5: CUR 1 4 30539 0 01:25:57.54 14633 274
0000041F MANAGER LEF 6 114752 0 00:00:11.91 37858 468

However a SHOW PROC (either /ID=xxxx or proc_name) hangs. Using ANAL/SYS to get some more information (primarily interested in the PC values) results in:

SDA> set proc _tna5:
SDA> sho call
Cannot display call frame (error)
SDA>

Also unable to stop the deviant process (either by /ID=xxxx or name). Doing a CTRL-T from the logged in session doesn't do anything either.

Any thoughts?


cheers

Brian

[Jan van den Ende]

Brian,

I am assuming that the CUR process consumes lots of CPU?
My first move would be to set the prio of that process to 0 (zero).
That typically does take some time to sink in, but thereafter it is a lot easier to investigate.

hth

Proost.

Have one on me.

jpe

[Richard Whalen]

I would suspect that the SHOW PROCESS command or any process specific command from SDA would probably queue a special kernel mode AST to the process to get the information. Your only solution to this may be to cause the system to take a dump and present the dump to HP. Most likely the process is running at or above ASTDEL.

[Jur van der Burg]

If you want to see what a looping process is doing, it's much easier to use pcs:

$ ana/sys
SDA> pcs load
SDA> pcs start trace/pid=xxxx [/tickdelay=0]
SDA> set proc/pid=xxxx
SDA> read/exec
SDA> pcs show trace [/statistics]

That will give you a list of pc samples with symbols resolved as much as possible. You can even save the trace with PCS DUMP.

Jur (PCS author)

[Brian Reiter]

Hi there,

Well the PCS trick helped a lot (assuming I got it right!). I've attached a trace, hopefully somebody with more experience can have a look.

At this point, the process is interactive and should have no access (locking or otherwise) to any other part of the application.

Many thanks and more digging to do.


cheers


Brian

[Richard Whalen]

I see a lot of spinlock activity.

Can you try the SPL SDA callout to see what spinlocks are busy?

SDA>SPL LOAD
SDA>SPL START TRACE
!wait a few minutes
SDA>SPL STOP TRACE
SDA>SPL SHOW TRACE/SUMMARY

[Brian Reiter]

I ended up having to reboot the system, ended up with 2 tasks sat at a 100% CPU (in kernal mode), with no apparent means to kill them off.

Did manage to have a quick look at the spinlock stuff and recovered the attached.

Just repeats forever.....

cheers

Brian