Bug 30700 - fast/media/mq-transform-02.html failed on Leopard Commit Bot
Summary: fast/media/mq-transform-02.html failed on Leopard Commit Bot
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-22 18:03 PDT by Eric Seidel (no email)
Modified: 2009-10-25 22:29 PDT (History)
4 users (show)

See Also:


Attachments
update qtVersion check (1.41 KB, patch)
2009-10-23 11:35 PDT, Eric Seidel (no email)
eric.carlson: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2009-10-22 18:03:50 PDT
fast/media/mq-transform-02.html failed on Leopard Bot

https://bugs.webkit.org/show_bug.cgi?id=30669#c5
https://bugs.webkit.org/show_bug.cgi?id=28284#c10

I think it is that I just upgraded QuickTime on the commit-queue machine and now the compositing is not longer disabled due to the version check in DRT.
Comment 1 Mark Rowe (bdash) 2009-10-22 18:22:38 PDT
Eric, which Leopard build bot did these tests fail on?  I don’t see any link to the buildbot results.
Comment 2 Eric Seidel (no email) 2009-10-23 11:19:59 PDT
commit bot.  Sorry if that wasn't clear.

To resolve this I think I just need to update the version check in DumpRenderTree.

Before I do that, I need to know if a fix for rdar://problem/7189153 has already been shipped in QuickTime.

This started failing when I installed QuickTime 7.6.4 on the commit-bot.

#if defined(BUILDING_ON_LEOPARD)
    // Disable hardware composititing to avoid timeouts and crashes from buggy CoreVideo teardown code.
    // https://bugs.webkit.org/show_bug.cgi?id=28845 and rdar://problem/7228836
    SInt32 qtVersion;
    OSErr err = Gestalt(gestaltQuickTimeVersion, &qtVersion);
    assert(err == noErr);
    // Bug 7228836 exists in at least 7.6.3 and 7.6.4, hopefully it will be fixed in 7.6.5.
    // FIXME: Once we know the exact versions of QuickTime affected, we can update this check.
    if (qtVersion <= 0x07640000)
        [preferences setAcceleratedCompositingEnabled:NO];
    else
#endif
        [preferences setAcceleratedCompositingEnabled:YES];

Is the current check in DumpRenderTree.mm
Comment 3 Eric Seidel (no email) 2009-10-23 11:28:35 PDT
According to:
    OSErr err = Gestalt(gestaltQuickTimeVersion, &qtVersion);
    printf("\n\nQuickTime version: %lx\n\n", qtVersion);

My quicktime version is:
QuickTime version: 7648000

So I'll update the version check:
    if (qtVersion <= 0x07640000)
 assuming that the QuickTime crasher still isn't fixed.

I guess the leopard build bots haven't upgraded quicktime versions yet.
Comment 4 Simon Fraser (smfr) 2009-10-23 11:33:02 PDT
Yes, oddly, Leopard gets QT 7.6.4, and SL has 7.6.3.
Comment 5 Eric Seidel (no email) 2009-10-23 11:35:24 PDT
Created attachment 41737 [details]
update qtVersion check
Comment 6 Eric Seidel (no email) 2009-10-23 11:37:42 PDT
Doing a version check here at all is a little strange as these two tests will fail for anyone who has a new enough version of QuickTime on leopard.  I'm assuming QuickTime hasn't been fixed yet and have posted a patch to disable HW compositing under 7.6.4.8 (which is what the commit-bot got installed on it yesterday).
Comment 7 Eric Carlson 2009-10-23 11:47:04 PDT
Comment on attachment 41737 [details]
update qtVersion check

> -    // Bug 7228836 exists in at least 7.6.3 and 7.6.4, hopefully it will be fixed in 7.6.5.
> +    // Bug 7228836 exists in at least 7.6.3 through 7.6.4.8, hopefully it will be fixed in 7.6.5.

This comment is incorrect. The version is encoded in BCD where the third byte is the "release stage", and 80 indicates the final release (see http://developer.apple.com/mac/library/technotes/tn/tn1132.html).

r=me with a fixed comment
Comment 8 Eric Seidel (no email) 2009-10-23 11:57:52 PDT
Committed r49984: <http://trac.webkit.org/changeset/49984>
Comment 9 Darin Adler 2009-10-25 16:28:15 PDT
If it was me, I would have done:

    < 0x07650000

or:

    <= 0x0764FFFF

We'll probably be OK with 0x07648000, but back when we originally designed this BCD scheme (and one of the first things I did my first time at Apple was write the technical note describing it), there was such a thing as "final 2" and such, which would have some nonzero digits in the low byte. It may be that QuickTime won't do such a thing.
Comment 10 Eric Seidel (no email) 2009-10-25 22:29:00 PDT
I agree.  "< 0x07650000" would have been cleaner.  If 7.6.5 doesn't have the fix I'll do that for 7.6.6. :)