711195 - Perform the range checks for non-boolean telemetry pings at compile time

Status: RESOLVED FIXED

(Toolkit :: Telemetry, defect)

Description

[(no longer active)]

I was bitten by not reading the docs correctly, and use 0 as the minimum value for the UPDATE_STATUS histogram.  I'm adding a compile-time check to catch these types of mistakes at compile time, to reduce the pain for the next person to hit this bug.

I have a patch for doing that.  I'm also fixing the UPDATE_STATUS and GC_REASON probes which were affected by this bug.

Comment 1

[(no longer active)]

Attachment: Patch (v1)

Comment 2

[(dormant account)]

Comment on attachment 582047 [details] [diff] [review]
Patch (v1)

Whoa.

Comment 3

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9f93eaff43d0

Comment 4

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/9f93eaff43d0

Comment 5

[Andrew McCreight (out of office until 8/21) [:mccr8]]

This has been landed for a few days.  Looking at my about:telemetry, I see that GC_REASON is showing up now, where it wasn't before.  But also I notice that more than half of the values are 0, which is less than the minimum bucket size (this telemetry reports an enum).  Is it okay to report 0 values when the minimum bucket is 0?  That seems weird to me.

Comment 6

[(dormant account)]

(In reply to Andrew McCreight [:mccr8] from comment #5)
> This has been landed for a few days.  Looking at my about:telemetry, I see
> that GC_REASON is showing up now, where it wasn't before.  But also I notice
> that more than half of the values are 0, which is less than the minimum
> bucket size (this telemetry reports an enum).  Is it okay to report 0 values
> when the minimum bucket is 0?  That seems weird to me.

minimum bucket is the first non-0 bucket. It's a little confusing, there is always a 0 bucket.

Comment 7

[Andrew McCreight (out of office until 8/21) [:mccr8]]

Ah, I see.  Thanks.  Do you want to try to get this into 10?  I guess it will be rolling over into beta tomorrow, but it seems like a fairly low risk change, and having GC_REASON working might give some information about GC scheduling regressions.  Just a thought.

Comment 8

[(dormant account)]

(In reply to Andrew McCreight [:mccr8] from comment #7)
> Ah, I see.  Thanks.  Do you want to try to get this into 10?  I guess it
> will be rolling over into beta tomorrow, but it seems like a fairly low risk
> change, and having GC_REASON working might give some information about GC
> scheduling regressions.  Just a thought.

up to you. There is 0 risk in this patch.

Comment 9

[Andrew McCreight (out of office until 8/21) [:mccr8]]

Comment on attachment 582047 [details] [diff] [review]
Patch (v1)

Nominating for Firefox 10 because it is low risk and may let us get more information about garbage collector performance in Firefox 10 via telemetry (GC_REASON was broken prior to this patch).

Comment 10

[LegNeato]

Comment on attachment 582047 [details] [diff] [review]
Patch (v1)

[triage comment]
Approving for beta. Looks low risk and the additional data may uncover other issues. Please land as soon as possible.

Also note that there is never "0 risk" ;-)

Comment 11

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I removed the fix for UPDATE_STATUS which is not in beta.

https://hg.mozilla.org/releases/mozilla-beta/rev/1e13590c5969

Comment 12

[u279076]

Marking qa- as I don't think this is anything QA needs to verify. Please mark qa+ if this is not the case.