JMX plugin test failure

Thomas Segismont tsegismo at redhat.com
Thu Jan 31 10:54:05 UTC 2013


News on ProcCredName problem.

eng-ops team has fixed gcc infrastructure on jon10 (had only 32-bit 
headers despite jon10 is 64 bit Linux). I was able to compile and run 
the C code extracted from Sigar source. It does not fail to resolve 
hudson user.

Since then, John Sanda has re-triggered rhq-cassandra-backend job on 
jon10 and jmx plugin test still fails.

After that, I decided to run the credname.java test case from VMWare 
again, first with the Sigar build used by RHQ, second with a Sigar build 
compiled on jon10.
The credname.java test case fails with sigar-dist-1.6.5.132-3 (brew 
build) but passes with trunk (jon10 build).

So I think we may have a look at the sources we have for 
sigar-dist-1.6.5.132-3. The file list [1] shows that we have a mix of 
different Sigar JNI / C sources according to library files last 
modification date.

Thomas

[1] http://pastebin.test.redhat.com/125533

Le 30/01/2013 16:57, Thomas Segismont a écrit :
> Not sure actually. John Sanda says the ProcCredName failing test works
> on his Mac. I also tried the test case from VMWare on my Linux amd64 box
> and it does not fail.
>
> Another thing: the VMWare test case fails on jon10 but only with
> processes owned by hudson user.
>
> Le 30/01/2013 16:54, Charles Crouch a écrit :
>> So do you think its worth putting a testcase together on github that
>> would determine whether the ProcCredName issue is a problem anywhere
>> else than on x64 linux?
>>
>> ----- Original Message -----
>>> Hi,
>>>
>>> Follow up investigation on both matters.
>>>
>>> 1. I have built Sigar from source[1] as discussed with Stefan
>>> yesterday.
>>> I ran the ProcState test again (on my box) and it also failed.
>>>
>>> 2. I have found two JIRA issues [2] [3] on the ProcCredName error
>>> "Numerical result out of range". The first one says they incremented
>>> the
>>> buffer size and the second one says they should look at the
>>> _SC_GETPW_R_SIZE_MAX value from sysconf to determine it. When I look
>>> at
>>> the latest source code [4] there is no runtime call to sysconf, just
>>> a
>>> constant defined.
>>>
>>> 3. In the first JIRA issue Doug MacEachern attached a test case which
>>> I
>>> tried on jon10 and jon11. On jon11 ProcCredName is correctly read.
>>> Not
>>> on jon10. So I think the issue we have in JMX plugin tests does not
>>> come
>>> from my ProcessInfo changeset but rather from sigar native lib on
>>> this
>>> system.
>>>
>>> 4. I wanted to see how pure C code would behave so I wrote a C source
>>> file [6] (from Sigar code). The '1000' parameter is my user id on my
>>> box. I changed this to 600 on jon{10,11} (hudson user id). It
>>> compiles
>>> and run on my box and jon11. Not on jon10. From the output [7] you
>>> can
>>> see that gnu/stubs-64.h is missing, whereas gnu/stubs-32.h is in
>>> place.
>>> And jon10 is 64 bit Linux. How can we get this fixed?
>>>
>>> Thomas
>>>
>>> [1] branches 1.6 and master on GitHub:
>>> https://github.com/hyperic/sigar
>>> [2] https://jira.hyperic.com/browse/SIGAR-27
>>> [3] https://jira.hyperic.com/browse/SIGAR-231
>>> [4] http://pastebin.test.redhat.com/125297
>>> [5] https://jira.hyperic.com/secure/attachment/10639/credname.java
>>> [6] http://pastebin.test.redhat.com/125303
>>> [7] http://pastebin.test.redhat.com/125310
>>>
>>> Le 30/01/2013 11:38, Thomas Segismont a écrit :
>>>> The two problems come out differently:
>>>> * when calling getProcCredName (found in JMX plugin tests by John)
>>>> * when calling getProcState (found in Apache plugin integration
>>>> tests by
>>>> me)
>>>>
>>>> John quickly reviewed the test case I wrote yesterday and found
>>>> nothing
>>>> strange. So the test case is likely to be good.
>>>>
>>>> Thomas
>>>>
>>>> Le 30/01/2013 00:55, Charles Crouch a écrit :
>>>>> So whatever you've found Thomas looks different to the problem
>>>>> hitting
>>>>> master:
>>>>>
>>>>> (5:47:26 PM) ccrouch: ok once again from the top :-)
>>>>> (5:47:40 PM) ccrouch: plugin test: passes on ....
>>>>> (5:47:44 PM) jsanda: jon11
>>>>> (5:48:02 PM) jsanda: fails on jon10 and jon12
>>>>> (5:47:59 PM) ccrouch: and thomas' test fails on jon10 and jon11 ?
>>>>> (5:48:14 PM) jsanda: appears that way
>>>>> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RHQ/job/sigar-test/2/console
>>>>>
>>>>>
>>>>> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RHQ/job/sigar-test/3/console
>>>>>
>>>>>
>>>>> (5:48:24 PM) ccrouch: ok, so that just means its a bad test :-/
>>>>> (5:48:27 PM) ccrouch: or a different bug
>>>>> (5:48:43 PM) jsanda: seems that way
>>>>>
>>>>> ----- Original Message -----
>>>>>> Sure thing. I'll run the test and reply to the thread. Thanks
>>>>>> again
>>>>>> for your help.
>>>>>>
>>>>>> - John
>>>>>> On Jan 29, 2013, at 3:46 PM, Thomas Segismont
>>>>>> <tsegismo at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I'm really confused with that change I made. The bug I found on
>>>>>>> Sigar#getProcState came up while working on it (debugging the
>>>>>>> Apache plugin integration tests). Now you say the jmx plugin
>>>>>>> tests
>>>>>>> fail since the changeset was merged into master...
>>>>>>>
>>>>>>> And still:
>>>>>>> * I had wrote a test on ProcessInfo before changing
>>>>>>> implementation
>>>>>>> and it finds no regression
>>>>>>> * The changeset only affects our Java code (no Sigar version
>>>>>>> change) and both problems (getProcState and getProcCredName)
>>>>>>> seem
>>>>>>> to come from Sigar native libraries
>>>>>>> * The jmx plugins tests passes if you run the cassandra-backend
>>>>>>> job
>>>>>>> on jon11 ...
>>>>>>>
>>>>>>> I'll work on that tomorrow as it's indeed becoming a huge
>>>>>>> problem
>>>>>>> for 4.6 release.
>>>>>>>
>>>>>>> By the way, can you please run the test case for getProcState
>>>>>>> and
>>>>>>> reply on RHQ mailing list?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Thomas
>>>>>>>
>>>>>>> Le 29/01/2013 20:53, John Sanda a écrit :
>>>>>>>> Hi Thomas,
>>>>>>>>
>>>>>>>> Thanks for looking at that Sigar issue with me earlier. I tried
>>>>>>>> calling
>>>>>>>> freshSnapshot() to work around the NPE, but as you expected, we
>>>>>>>> still
>>>>>>>> hit it. Would you mind doing further investigation into this
>>>>>>>> since
>>>>>>>> it
>>>>>>>> related to the work you have been doing? As for why it is not
>>>>>>>> failing in
>>>>>>>> the rhq-master job, you will note from the conversation below
>>>>>>>> that
>>>>>>>> it
>>>>>>>> may be because jon11, where rhq-master runs, is 32 bit, whereas
>>>>>>>> jon10
>>>>>>>> and jon12 are both 64 bit. Here is the chat we had a bit
>>>>>>>> earlier
>>>>>>>> in
>>>>>>>> #jboss-on:
>>>>>>>>
>>>>>>>>
>>>>>>>> 1
>>>>>>>> 4:30
>>>>>>>> 14:30jsanda: ccrouch: made some headway with the jmx plugin
>>>>>>>> test
>>>>>>>> failure
>>>>>>>> and it looks like it might be 4.6 blocker
>>>>>>>> ccrouch: grr
>>>>>>>> 14:30jsanda: earlier i enabled logging in the plugin tests
>>>>>>>> 14:30jsanda: and saw that an NPE was getting thrown
>>>>>>>> 14:31jsanda: it's in in the ProcessInfo code where
>>>>>>>> tsegismont|dinner
>>>>>>>> made changes to deal with the stale state
>>>>>>>> 14:31jsanda: we were discussing it earlier
>>>>>>>> 14:31jsanda: he thinks we might be hitting
>>>>>>>> 14:31jsanda: https://jira.hyperic.com/browse/SIGAR-231
>>>>>>>> 14:32jsanda: as for why it's not failing on jon11 where
>>>>>>>> rhq-master
>>>>>>>> runs,
>>>>>>>> stefan_n just pointed out that jon11 is 32 bit whereas jon10
>>>>>>>> and
>>>>>>>> jon12
>>>>>>>> are 64 bit
>>>>>>>> 14:35jsanda: ccrouch: the test started failing consistently
>>>>>>>> after
>>>>>>>> these
>>>>>>>> changes -
>>>>>>>> http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?id=3ded44d88b2700c95d3e107d2cfdbe48524a41e8
>>>>>>>>
>>>>>>>>
>>>>>>>> 14:37jsanda: but at this point, i'd rather let
>>>>>>>> tsegismont|dinner
>>>>>>>> take
>>>>>>>> the reigns on this since it is related to the stuff he's been
>>>>>>>> working on
>>>>>>>> 14:37jsanda: and for now, i'll just disable the test in the
>>>>>>>> cassandra-backend branch so that i can hopefully get a good
>>>>>>>> build
>>>>>>>> 14:39stefan_n: ccrouch, *jsanda*, I think it's a 4.6 blocker
>>>>>>>> because we
>>>>>>>> cannot prove that it does not happen on other 32bit Linux
>>>>>>>> platforms (eg.
>>>>>>>> RHEL 5) beyond the RHEL6 32bit is passing on
>>>>>>>> 14:39stefan_n: and 64bit is already broken
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list