Hi Ken,
----- Original Message -----
> Getting a FPE.
Hmmm - oddly enough, this test is passing for me...
> From divide by zero here
> #0 0x0000000000406953 in gendskline (ss=0x658f10, tstamp=0x426d4d "
> ",
> selector=<optimised out>) at atopsar.c:1346
>
> Because hertz is 0.
>
> Because here
> #0 extract_integer (result=0x656c30, descs=descs@entry=0x7fffffffc930,
> value=value@entry=6) at various.c:639
>
> numval is 0
>
> (gdb) p *result->vset[6]
> $8 = {pmid = 251658288, numval = 0, valfmt = 0, vlist = {{inst = 324, value =
> {
> pval = 0x21, lval = 33}}}}
>
> and this is for pmid ...
>
> $ pminfo -mM | grep 251658288
> kernel.all.hz PMID: 60.0.48 = 251658288 = 0xf000030
>
> Needs someone who understands the code and/or the QA test to take it from
> here.
So, there's at least one problem here - firstly, we should have a fallback for
hertz if we cannot fetch it. But, the archive from this test *does* actually
have a kernel.all.hz in the 2nd record (see pmdumplog -a qa/archives/pcp-atop)
- a discrete metric too. I'll add some default-hertz code, but any ideas as to
what's going on when fetching that metric? (and why it might work for me but
not you?)
cheers.
--
Nathan
|