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

[VAXman- at SendSpamHere.ORG]

In article <cc2253d9-cffd-4a8f-90fa-8bcab85bb4d2 at w36g2000vbi.googlegroups.com>, San <rsandeep80 at gmail.com> writes:
>On Feb 14, 5:35=A0pm, 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=3DA0pm, VAXman- =A0 at SendSpamHere.ORG wrote:
>> >> In article <5c565fb6-35f4-43cb-9d74-0dff5efd9... at d16g2000yqd.googlegro=
>ups=3D
>> >..com>, San <rsandee... at gmail.com> writes:
>>
>> >> >> I'm trying to get the trcWriteIV ( ) after this to produce some out=
>put
>> >> >> but I've not gotten the proper incantation. =3D3DA0Can you advise? =
>=3D3DA0=3D
>> >I'm als=3D3D
>> >> >o
>> >> >> confuse as to where the OTS$MOVE, which appears in the PRF PC trace=
>, i=3D
>> >s
>> >> >> coming into play.
>>
>> >> >Traces are turned off, by default. To turn it on, the library needs t=
>o
>> >> >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. =3DA0I have established EXE$SIGTORET to return errors ins=
>tead
>> >> of signaling them. =3DA0Perhaps, I could remove them and I might see s=
>ome-
>> >> thing cough up an exception. =3DA0I don't have anything issuing an $UN=
>WIND
>> >> in this code that *I* have explicitly written into it.
>>
>> >> --
>> >> VAXman- A Bored Certified VMS Kernel Mode Hacker =3DA0 =3DA0VAXman(at)=
>TMESIS(=3D
>> >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. =A0I started the process again to ge=
>t
>> it into this "tailspin" and I used the EXCeption extension in SDA as Ian
>> had suggested. =A0There is nothing in the tracing.
>>
>> --
>> 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.
>
>
>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.

Wilco.

Sorry about the bounce.  I realized just now that your email was gmail.com.
I block most of the signup and SPAM email providers.  I'll put you onto the
whitelist

This instrumented threads library images would have the tracing that I was
looking to enable?

FYI, the run yesterday, from which I made the video, is now:

 Elapsed CPU time:          0 00:17:39.07
 Connect time:              0 14:07:58.85

-- 
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.