pcp
[Top] [All Lists]

Re: [pcp] qa/859 and python problem in fetchgroup wrapper?

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] qa/859 and python problem in fetchgroup wrapper?
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Thu, 17 Mar 2016 09:49:42 +1100
Cc: PCP <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <9566995.32026348.1458166426505.JavaMail.zimbra@xxxxxxxxxx>
References: <56E9CD24.4050501@xxxxxxxxxxxxxxxx> <9566995.32026348.1458166426505.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
On 17/03/16 09:13, Nathan Scott wrote:
> Mornin' Ken,
> 
> ----- Original Message -----
>> On Mac OS X, qa/859 is failing thusly
>>
>> QA output created by 859
>> pmfg -   File "/Users/kenj/src/pcp/qa/src/test_pmfg.py", line 123, in
>> test_pmfg
>>      test_pmfg_live(self, c_api.PM_CONTEXT_HOST, "local:")
>>    File "/Users/kenj/src/pcp/qa/src/test_pmfg.py", line 46, in test_pmfg_live
>>      print ("time: %s" % tt())
>>    File "/usr/local/lib/python2.6/site-packages/pcp/pmapi.py", line 2132, in
>>    __call__
>>      ts.tm_hour, ts.tm_min, ts.tm_sec, us, None)
>> OverflowError: signed integer is greater than maximum
>>
>>
>> I've eventually tracked this down to a bogus value for tv_usec in a struct
>> timeval in the __call__ method of the fetchgroup_timestamp class where
>> tv_sec= 1458160058 and tv_usec= 4295837705 ... tv_usec should be no larger
>> than 999999.
> 
> The src/python/pcp/pmapi.py wrapper code defines ...
> 
> class timeval(Structure):
>      _fields_ = [("tv_sec", c_long),
>                  ("tv_usec", c_long)]
> 
> Maybe tv_usec is not a c_long on Mac OS X (or this version thereof)?

Yep ... tv_usec here is of type suseconds_t ...

/usr/include/sys/_types.h:typedef __int32_t     __darwin_suseconds_t;   /* 
[???] microseconds */
/usr/include/sys/time.h:typedef __darwin_suseconds_t    suseconds_t;

Is there an "approved" way of dealing with this in Python wrapper code?

> 
>> The value for tv_usec is not constant, but it is always really big and in hex
>> is something like 1000XXXX
>>
>> I'm not sure if the problem is in the python wrapper code, or the python test
>> program, so I'd really appreciate some help.
> 
>  From inspection, the below looks like a bug too - similar area, but not sure
> that it could explain your above issue (the test is using an event metric at
> one point, but not near the stack trace you're seeing AFAICT)... maybe worth
> a run with this fix anyway though:
> 
> diff --git a/src/python/pcp/pmapi.py b/src/python/pcp/pmapi.py
> index dee6dff..21c63c8 100644
> --- a/src/python/pcp/pmapi.py
> +++ b/src/python/pcp/pmapi.py
> @@ -233,7 +233,7 @@ class timespec(Structure):
>       def __init__(self, sec = 0, nsec = 0):
>           Structure.__init__(self)
>           self.tv_sec = sec
> -        self.tv_nsec = usec
> +        self.tv_nsec = nsec
>   
>   class tm(Structure):
>       _fields_ = [("tm_sec", c_int),
> 

sure looks like a bug ... but I don't think that's anywhere near the place my 
test is blowing up.

<Prev in Thread] Current Thread [Next in Thread>