Re: [pcp] URGENT potentially serious regression in 3.7.0

[Ken McDonell <kenj@xxxxxxxxxxxxxxxx>]

On 10/03/13 08:21, Nathan Scott wrote:
> Hi Ken,
>
> Is this with a NSS-enabled or disabled build?  (pmconfig -L)
Looks like it is enabled

kenj@bozo-laptop:~$ pmconfig -L
pmapi_version=2
multi_threaded=true
fault_injection=false
secure_sockets=true
ipv6=true

> I suspect the former.  Do you have this commit in your builds?
>
> commit 75ab98afb0aa4a0a6dddc1bd7b84b9522bb43343
> Author: Nathan Scott <nathans@xxxxxxxxxx>
> Date:   Thu Mar 7 14:56:00 2013 +1100
>
>      Fix timeout handling for NSS-enabled server builds
Yep.

Is qa/169 passing for you?

A bit more evidence on the __pmDataIPC storm issue.

This is pmcd's log for ONE iteration of a fetch for pmval -i 'bin-500'

__pmDataIPC: fd=1027
__pmDataIPC: fd=1027, data=0xb7c4f688(sz=8)
__pmDataIPC: fd=1024
__pmDataIPC: fd=1024, data=0xb7c4f658(sz=8)
__pmDataIPC: fd=1025
__pmDataIPC: fd=1025, data=0xb7c4f668(sz=8)
__pmDataIPC: fd=1026
__pmDataIPC: fd=1026, data=0xb7c4f678(sz=8)
__pmDataIPC: fd=1027
__pmDataIPC: fd=1027, data=0xb7c4f688(sz=8)
__pmDataIPC: fd=1024
__pmDataIPC: fd=1024, data=0xb7c4f658(sz=8)
__pmDataIPC: fd=1025
__pmDataIPC: fd=1025, data=0xb7c4f668(sz=8)
__pmDataIPC: fd=1026
__pmDataIPC: fd=1026, data=0xb7c4f678(sz=8)
__pmDataIPC: fd=1027
__pmDataIPC: fd=1027, data=0xb7c4f688(sz=8)
__pmDataIPC: fd=1024
__pmDataIPC: fd=1024, data=0xb7c4f658(sz=8)
__pmDataIPC: fd=1025
__pmDataIPC: fd=1025, data=0xb7c4f668(sz=8)
__pmDataIPC: fd=1026
__pmDataIPC: fd=1026, data=0xb7c4f678(sz=8)
__pmDataIPC: fd=1027
__pmDataIPC: fd=1027, data=0xb7c4f688(sz=8)
__pmDataIPC: fd=1027
__pmDataIPC: fd=1027, data=0xb7c4f688(sz=8)
__pmDataIPC: fd=1027
__pmDataIPC: fd=1027, data=0xb7c4f688(sz=8)
__pmDataIPC: fd=1027
__pmDataIPC: fd=1027, data=0xb7c4f688(sz=8)
__pmDataIPC: fd=1027
__pmDataIPC: fd=1027, data=0xb7c4f688(sz=8)
__pmDataIPC: fd=1027
__pmDataIPC: fd=1027, data=0xb7c4f688(sz=8)
__pmDataIPC: fd=1027
__pmDataIPC: fd=1027, data=0xb7c4f688(sz=8)
__pmDataIPC: fd=1027
__pmDataIPC: fd=1027, data=0xb7c4f688(sz=8)
__pmDataIPC: fd=1027
__pmDataIPC: fd=1027, data=0xb7c4f688(sz=8)
__pmDataIPC: fd=1027
__pmDataIPC: fd=1027, data=0xb7c4f688(sz=8)
__pmDataIPC: fd=1027
__pmDataIPC: fd=1027, data=0xb7c4f688(sz=8)
[13220]pmGetPDU: FETCH fd=1027 len=32 from=0
000:       20     7003        0        0        0        0  1000000 
6004007
[13220]pmXmitPDU: FETCH fd=11 len=32
000:       20     7003        1        0        0        0  1000000 
6004007
__pmDataIPC: fd=12
__pmDataIPC: fd=12, data=0xb7c4b718(sz=8)
__pmDataIPC: fd=12
__pmDataIPC: fd=12, data=0xb7c4b718(sz=8)
__pmDataIPC: fd=12
__pmDataIPC: fd=12, data=0xb7c4b718(sz=8)
__pmDataIPC: fd=12
__pmDataIPC: fd=12, data=0xb7c4b718(sz=8)
__pmDataIPC: fd=12
__pmDataIPC: fd=12, data=0xb7c4b718(sz=8)
__pmDataIPC: fd=12
__pmDataIPC: fd=12, data=0xb7c4b718(sz=8)
__pmDataIPC: fd=12
__pmDataIPC: fd=12, data=0xb7c4b718(sz=8)
[13220]pmGetPDU: RESULT fd=12 len=44 from=0
000:       2c     7001        0        0        0  1000000  6004007 
1000000
008:        0 f4010000 f4010000
pmResult dump from 0xb7c56758 timestamp: 0.000000 10:00:00.000 numpmid: 1
  29.0.6 (sample.bin): numval: 1 valfmt: 0 vlist[]:
    inst [500 or ???] value 500 7.0064923e-43 0x1f4
pmResult dump from 0xb7c61af0 timestamp: 1362864213.614811 08:23:33.614 
numpmid: 1
  29.0.6 (sample.bin): numval: 1 valfmt: 0 vlist[]:
    inst [500 or ???] value 500 7.0064923e-43 0x1f4
[13220]pmXmitPDU: RESULT fd=1027 len=44
000:       2c     7001        0 55a83b51 9b610900  1000000  6004007 
1000000
008:        0 f4010000 f4010000


I can't see the repeated iterate over all fd's from 0 to 1027 problem 
that qa/169 is exposing, but there do appear to be an _awful_ lot of 
repeated calls to __pmDataIPC here, given that the only IPCs are
- pdu in from client
- pdu out to pmcda
- pdu back from pmda
- send pdu to client