Bug 84196 - run-webkit-tests picked up an old crash log
Summary: run-webkit-tests picked up an old crash log
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Dirk Pranke
URL: http://build.webkit.org/results/Lion%...
Keywords:
: 85267 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-04-17 14:49 PDT by Simon Fraser (smfr)
Modified: 2012-06-08 15:44 PDT (History)
9 users (show)

See Also:


Attachments
Patch (14.58 KB, patch)
2012-04-18 15:00 PDT, Dirk Pranke
rniwa: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 2012-04-17 14:49:49 PDT
http://build.webkit.org/results/Lion%20Debug%20(WebKit2%20Tests)/r114380%20(6092)/fast/loader/form-state-restore-with-locked-back-forward-list-crash-log.txt is a crash log from:

Date/Time:       2012-04-02 03:32:12.508 -0700

yet the tests ran on 4/17. I guess the bot has accumulated a lot of crash logs, and the scripts picked up an old one because the PIDs have wrapped around.

The scripts should probably delete old crash logs from the machines at some point.
Comment 1 Dirk Pranke 2012-04-17 14:51:22 PDT
Good point. It should be easy enough to change the code to notice when run-webkit-tests starts and not pick up any crash logs older than that start time.
Comment 2 Simon Fraser (smfr) 2012-04-18 11:33:11 PDT
Another one:
http://build.webkit.org/results/Lion%20Debug%20(WebKit2%20Tests)/r114521%20(6121)/fast/dom/htmlcollection-detectability-crash-log.txt

Date/Time:       2012-04-11 00:07:16.193 -0700
Comment 3 Dirk Pranke 2012-04-18 15:00:58 PDT
Created attachment 137778 [details]
Patch
Comment 4 Dirk Pranke 2012-04-18 15:01:51 PDT
I think this patch should fix things, although I haven't tested this against a real-world instance.
Comment 5 Ryosuke Niwa 2012-04-18 15:04:41 PDT
Comment on attachment 137778 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=137778&action=review

> Tools/Scripts/webkitpy/common/system/crashlogs.py:38
> +    def find_newest_log(self, process_name, pid=None, include_errors=False, newer_than=None):

I'm not sure if newer_than makes sense as the variable name. I think start_time would be semantically clearer.
Comment 6 Dirk Pranke 2012-04-18 15:12:07 PDT
(In reply to comment #5)
> (From update of attachment 137778 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=137778&action=review
> 
> > Tools/Scripts/webkitpy/common/system/crashlogs.py:38
> > +    def find_newest_log(self, process_name, pid=None, include_errors=False, newer_than=None):
> 
> I'm not sure if newer_than makes sense as the variable name. I think start_time would be semantically clearer.

Interesting, newer_than seems clear to me (show me crash logs newer than X), but start_time not at all (logs don't have a start time) ... why do you think the opposite? Are you thinking that you're looking for processes started after X? The process doesn't have to have started after X, though, just crashed after X.

Maybe "created_after" would be better, or "crashed_after", or just "after"?

Note that there is a minor correctness issue in that you actually want ctime > X, not mtime > X, but there is no filesystem.ctime() routine. I could add one, but it seemed unnecessary since ctime will presumably equal mtime nearly all of the time ...
Comment 7 Ryosuke Niwa 2012-04-18 15:25:50 PDT
Comment on attachment 137778 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=137778&action=review

>>> Tools/Scripts/webkitpy/common/system/crashlogs.py:38
>>> +    def find_newest_log(self, process_name, pid=None, include_errors=False, newer_than=None):
>> 
>> I'm not sure if newer_than makes sense as the variable name. I think start_time would be semantically clearer.
> 
> Interesting, newer_than seems clear to me (show me crash logs newer than X), but start_time not at all (logs don't have a start time) ... why do you think the opposite? Are you thinking that you're looking for processes started after X? The process doesn't have to have started after X, though, just crashed after X.
> 
> Maybe "created_after" would be better, or "crashed_after", or just "after"?
> 
> Note that there is a minor correctness issue in that you actually want ctime > X, not mtime > X, but there is no filesystem.ctime() routine. I could add one, but it seemed unnecessary since ctime will presumably equal mtime nearly all of the time ...

Ah, I see what you're saying. Okay.
Comment 8 Dirk Pranke 2012-04-18 16:19:36 PDT
Committed r114577: <http://trac.webkit.org/changeset/114577>
Comment 9 Dirk Pranke 2012-06-08 15:44:44 PDT
*** Bug 85267 has been marked as a duplicate of this bug. ***