Closed Bug 619983 Opened 12 years ago Closed 11 years ago

Add install time to web interface

Categories

(Socorro :: General, task)

task
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: chofmann, Assigned: ryansnyder)

References

()

Details

Attachments

(3 files)

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: 11 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.