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

[San]

On Feb 14, 5:35 pm, VAXman-  @SendSpamHere.ORG wrote:
> In article <489fcce5-556d-42d5-864a-710b99ba5... at d12g2000vbz.googlegroups.com>, hb <becker.isman... at freenet.de> writes:
>
>
>
>
>
>
>
>
>
> >On Feb 14, 12:27=A0pm, 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. =3DA0Can you advise? =3DA0=
> >I'm als=3D
> >> >o
> >> >> confuse as to where the OTS$MOVE, which appears in the PRF PC trace, i=
> >s
> >> >> 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. =A0I have established EXE$SIGTORET to return errors instead
> >> of signaling them. =A0Perhaps, I could remove them and I might see some-
> >> thing cough up an exception. =A0I 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 =A0 =A0VAXman(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.
>
> It's probably not exception related.  I started the process again to get
> it into this "tailspin" and I used the EXCeption extension in SDA as Ian
> had suggested.  There is nothing in the tracing.
>
> --
> 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.


I agree that the unwind PCs might just be an effect of the "actual"
problem. Ideally, the null thread is not supposed to eat up CPU
cycles. As you say, it might be something to do with the threads
library.

Did you see the call stack of null thread? Was there anything
suspicious there? The following commands will give the call stack of
the null threads.

SDA> pthread thread -ao u
SDA> SHOW CALL /SUMM <unwind seed for null thread>

PS: I tried replying to your mail, but it bounced. Hence posting it
here. You can contact Office of OpenVMS Programs
(OpenVMS.Programs at hp.com)? With that, I can provide the instrumented
threads library images that can trace what is going on in the null
thread.