Closed Bug 619983 Opened 14 years ago Closed 14 years ago

Add install time to web interface

Categories

(Socorro :: General, task)

Product:
Socorro
Component:
General
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: chofmann, Assigned: ryansnyder)

References

(
URL
)

Details

Attachments

(3 files)

ns create dups
6.43 KB, text/plain
Details
Post-fix screenshot, install time in signature
597.08 KB, image/png
Details
Post-fix screenshot, install time in a report
553.10 KB, image/png
Details
to surface possible duplicates during crash analysis we need to surface "install time" in the signature list reports like: http://crash-stats.mozilla.com/report/list?signature=NS_strlen%28unsigned%20short%20const*%29 since it sounds like we toss install time during processing of reports we need some way to back track and convert "install age" back to "install time". lars had some ideas on this.
Depends on: 579136
so here is the frequent (and strange) pattern in incrementing install age that I see in the data. a crash appears at 201012071434 with an old "time since last crash" then rapid fire reports come in with date processed changing very little, but incrementing install age and last crash. like this set of crashes the easiest way to understand this pattern is to take install age of the first report then add last crash of the second report to get install age of the of the second report. e.g. 25265 + 12 = 25277 25277 + 3 = 25280 ___checking nsBidi::GetVisualRun.int,.int.,.int.,.nsBidiDirection.. in 20101207-crashdata.csv install_age last_crash date_processed client_crash_date uuid_url 25265 24507 201012071434 201012071434 25277 12 201012071434 201012071434 25280 3 201012071434 201012071434 25284 4 201012071434 201012071434 25300 16 201012071435 201012071435 25313 13 201012071435 201012071435 25326 13 201012071435 201012071435 25338 12 201012071435 201012071435 25352 5 201012071435 201012071435 25418 62 201012071437 201012071437 25438 20 201012071437 201012071437
even if we can't get back to an "install time" calculation just expressing "install age" in and a few of these times consistently (in minutes?) might be the key to quickly identifying these kind of dups. here is what the table might look like with install age in minutes. ___checking nsBidi::GetVisualRun.int,.int.,.int.,.nsBidiDirection.. in 20101207-crashdata.csv install_age sec/min last_crash_sec uptime_min d date_processed client_crash_date yr mo day hr min yr mo day hr min 25265 421.083 24507 58 201012071434 201012071434 25277 421.283 12 2 201012071434 201012071434 25280 421.333 3 1 201012071434 201012071434 25284 421.4 4 2 201012071434 201012071434 25300 421.667 16 2 201012071435 201012071435 25313 421.883 13 1 201012071435 201012071435 25326 422.1 13 1 201012071435 201012071435 25338 422.3 12 2 201012071435 201012071435 25352 422.533 5 1 201012071435 201012071435 25418 423.633 62 2 201012071437 201012071437 25438 423.967 20 1 201012071437 201012071437
so the way to read the table above is that between the 3 minute period between 1434 and 1437 on dec. 7 we got a batch of crashes in where the install age was also within a 3 minute window. so if we convert client crash date to minute format, then subtract install age from that, we get should get install time for this set of crashes, then lets convert back to the year month day hour min format to make it easy to read. we might loose a bit of precision in the conversions back and forth but if the number are close then it should be a lot easier to spot the dup pattern visually.
so basically all the reports in comment 3 can from system(s) where the installation happened 438.8 minutes ago.
(In reply to comment #5) > so basically all the reports in comment 3 can from system(s) where the > installation happened 438.8 minutes ago. er, I think it means install time was around 438.8 or 7.31 hours before the crashes started appearing or at around 2010 12 07 07 17
Attached file ns create dups —
here is an interesting pile of reports, all close in crash time and from the same build id, where install age actually drifts a bit so this might be a combination of a few crashes from the same system plus dup submissions. signature is http://crash-stats.mozilla.com/report/list?signature=NS_CreateShortcutResolver and the time period is around Dec 19, 2010 10:45 - Dec 19, 2010 11:26
Assignee: nobody → ryan
Target Milestone: --- → 1.7.7
This is easy to calculate as far as I can tell: install time = crash time - install age Just add that to the UI.
Is "crash time" client_crash_date or date_processed? I would assume client_crash_date is timestamp upon which the client crashed, and date_processed is the timestamp upon which Socorro processed the crash. But I'm seeing that date_processed < client_crash_date, when I would expect that to be the opposite.
"crash time" would have to be client_crash_date. End user supplied timestamps should never be mixed into calculations with Socorro supplied timestamps because end user supplied timestamps are untrustworthy. In your example, it is likely that date_processed (from socorro) < client_crash_date (from the user) because the user had his machine's clock set badly. install_time = client_crash_date - install_age
Crash time is client_crash_date. The easiest way to calculate this is in the SQL query: ( client_crash_date - ( install_age * INTERVAL '1 second' ) ) as install_time
Adding install time to report list and to crash details page. == Sending application/libraries/CrashReportDump.php Sending application/models/common.php Sending application/views/common/list_reports.php Sending application/views/report/index.php Sending js/socorro/report_list.js Transmitting file data ..... Committed revision 2957.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updating the crash report page to list install time properly. == Sending views/report/index.php Transmitting file data . Committed revision 2958.
Its hard to say if a bad time setting on a client was present at install time *and* crash time(s), or was only present at crash time, so either value could probably be used to back compute install time. I think what we have here is fine. Lets see how the data looks.
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: