Bug 30700 – fast/media/mq-transform-02.html failed on Leopard Commit Bot

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Eric Seidel (no email)]

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.

[Mark Rowe (bdash)]

Eric, which Leopard build bot did these tests fail on?  I don’t see any link to the buildbot results.

[Eric Seidel (no email)]

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

[Eric Seidel (no email)]

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.

[Simon Fraser (smfr)]

Yes, oddly, Leopard gets QT 7.6.4, and SL has 7.6.3.

[Eric Seidel (no email)]

Created attachment 41737 [details]
update qtVersion check

[Eric Seidel (no email)]

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).

[Eric Carlson]

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

[Eric Seidel (no email)]

Committed r49984: <http://trac.webkit.org/changeset/49984>

[Darin Adler]

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.

[Eric Seidel (no email)]

I agree.  "< 0x07650000" would have been cleaner.  If 7.6.5 doesn't have the fix I'll do that for 7.6.6. :)