[Info-vax] HIBertanting DECthreads process accrues CPU time.

[hb]

On Feb 14, 12:27 pm, VAXman-  @SendSpamHere.ORG wrote:
> In article <5c565fb6-35f4-43cb-9d74-0dff5efd9... at d16g2000yqd.googlegroups.com>, San <rsandee... at gmail.com> writes:
>
>
>
> >> I'm trying to get the trcWriteIV ( ) after this to produce some output
> >> but I've not gotten the proper incantation. =A0Can you advise? =A0I'm als=
> >o
> >> confuse as to where the OTS$MOVE, which appears in the PRF PC trace, is
> >> coming into play.
>
> >Traces are turned off, by default. To turn it on, the library needs to
> >be re-compiled.
> >I could see a lot of "unwind" code in the PC sampling. So someone is
> >trying to
> >unwind the stack. It would be interesting to know who is doing that.
>
> Interesting.  I have established EXE$SIGTORET to return errors instead
> of signaling them.  Perhaps, I could remove them and I might see some-
> thing cough up an exception.  I don't have anything issuing an $UNWIND
> in this code that *I* have explicitly written into it.
>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG
>
> All your spirit rack abuses, come to haunt you back by day.
> All your Byzantine excuses, given time, given you away.

On I64 "unwind" is also in the names of the functions/modules which do
call stack walking, which is necessary for unwinding, but doesn't
necessarily mean unwinding.

IF this is exception related, it is worth to run a test on 8.4: a lot
of "unwind data" for exception handling is now cached. But if there
are calls from other code into the unwind functions, the optimization
may have no effect.