All crash reports return uptime as '0'

VERIFIED FIXED

Status

Socorro
General
P2
major
VERIFIED FIXED
10 years ago
6 years ago

People

(Reporter: Samuel Sidler (old account; do not CC), Assigned: lars)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Socorro's not displaying uptime right. When I crash the browser, I can see CrashTime and StartupTime just fine, but it's not being calculated as uptime on Socorro.

This bug should block 1.9 and probably beta 4.
Flags: blocking1.9?

Comment 1

10 years ago
really need this to help focus attention on start up crashes.

morgamic and I talked about a short statistical summary for the top of each stack signature summary report...



Stack Signature: xxxxxxxx
Total Reports: Y
Unique users: X
Ave. time to this crash since session startup: Z seconds


first two help us figure out if the crashes for a stack signature are from a few bozo's running the same test case over and over, or if there is fairly wide distribution across many users.

the later helps to pin point thinks like start up crashes which really take a high priority in the analysis and fixing.  If users can find something that crashes the browser within a few seconds after start up we really focus a lot of attention on those...

Priority: -- → P1

Updated

10 years ago
Flags: tracking1.9? → blocking1.9?
Status: NEW → ASSIGNED
+'ing w/ P2.  Shouldn't block betas as it doesn't necessarily *require* a beta to know that it works or cause regressions.

Who's going to take the bug?  
Flags: blocking1.9? → blocking1.9+
Priority: P1 → P2
This is a bug in the processor, Lars will take a look.
Assignee: nobody → lars
Status: ASSIGNED → NEW

Comment 4

10 years ago
lars, any progress on this?  we have a bunch of crashes that look like migration or start up crashes, and adding this to the reports would help us to confirm or deny these theories and help focus analysis...
(Assignee)

Comment 5

10 years ago
In the refactoring of Socorro Processor, I've discovered this bit of code in processor.py:

  0048: uptime = 0
        #...
  0061:    if 'StartupTime' in json \
  0062:        and timePattern.match(str(json['StartupTime'])) \
  0063:        and crash_time < int(json['StartupTime']):
  0064:      uptime = crash_time - int(json['StartupTime'])

It appears that uptime will always have the value of 0 if the time of the crash happened before Firefox actually starts.  Hmmm, could this be simply a case of a reversed operator: "<" instead of ">" or ">=" ?  The question is, why would this test even be done?  Is there a legitimate case where the crash_time would be before the StartupTime?

In my refactoring, I am simply swapping ">=" for "<".  If someone knows why this would not be a proper solution to this problem, please speak up.  

Morgamic, would you like me to make this same swap in the working code?
Wow, did I actually check that in? That looks pretty bogus. Obviously the crash time ought to be after the startup time. We're doing the test just to make sure we don't wind up with a negative value if a client submits bogus data. Please do check that in to the trunk!
Yeah, make the swap.
We should push that to production ASAP.
(Assignee)

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Comment 9

10 years ago
looks like its all been pushed and the times are now showing up in reports.  Thanks!

Updated

10 years ago
Status: RESOLVED → VERIFIED
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.