Closed Bug 512327 (CVE-2009-3377) Opened 11 years ago Closed 11 years ago

Update liboggz


(Core :: Audio/Video, defect)

Not set



Tracking Status
status1.9.2 --- beta1-fixed
blocking1.9.1 --- .4+
status1.9.1 --- .4-fixed


(Reporter: cpearce, Assigned: cpearce)



(Keywords: verified1.9.1)


(2 files, 1 obsolete file)

We should update liboggz to pickup recent fixes.
Assignee: nobody → chris
Depends on: 511584
Attached patch Patch (obsolete) — Splinter Review
Update liboggz to rev 20609d34c41fa.
Attachment #397088 - Flags: review?(chris.double)
Attachment #397088 - Flags: review?(chris.double) → review+
Pushed to m-c:
Closed: 11 years ago
Resolution: --- → FIXED
Also backed out bug 512327 so that test pass without bug 512328:
Resolution: FIXED → ---
Attached patch Patch v2Splinter Review
Updates liboggz to rev cf5feeaab69b05e24. This includes the fix for bug 515376, and all tests pass with just this patch. I've pushed it to tryserver several times, and not seen the intermittent harness timeout as per bug 515376, so I assume that hang only occurs when the liboggplay update of bug 512328 is present, and was not caused by a liboggz update which was pushed at the same time. I think we should land this now, and land the liboggplay separately (or just cherry pick changesets from it). This also fixes bug 496051
Attachment #397088 - Attachment is obsolete: true
Attachment #400399 - Flags: review?(chris.double)
Attachment #400399 - Flags: review?(chris.double) → review+
Pushed to m-c:
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Can we get this on 1.9.2? It fixes bug 511038 (the mobile guys want this on fennec1.0), fixes bug 515376, and is required for some of the (pending) oggplay updates. We'll also need bug 511584 on 1.9.2 if we take this on 1.9.2.
Flags: wanted1.9.2?
Flags: blocking1.9.2?
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.3a1
Flags: wanted1.9.2?
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Patch backported to 1.9.1. We require this patch for bug 512327, which is
required for bug 512328 which people want on 1.9.1.
Attachment #403697 - Flags: review+
Attachment #403697 - Flags: approval1.9.1.4?
blocking1.9.1: --- → .4+
Comment on attachment 403697 [details] [diff] [review]
Patch backported to 1.9.1

Approved for, a=dveditz
Attachment #403697 - Flags: approval1.9.1.4? → approval1.9.1.4+
Blocks: 506878
Including comments from cpearce on what types of test regressions to focus on.

The liboggplay update landed on 1.9.1 last night, is in last night's nightly. We need to test general video playback, ensure there's no new hangs, that sort of thing. 
> It would probably be wise to take it on 1.9.1, provided we have some
> QA guys testing it. We'd need to take the recent libfishsound (bug
> 511584) and liboggz updates (bug 512327) as well, liboggplay depends
> on them.
> The liboggplay update has only been on trunk and 1.9.2 for about a
> week, and I'm not terribly trusting of it, so if we took it on 1.9.1
> we'd definitely need some QA guys bashing on it to be sure that
> nothing was broken. It seems stable on trunk, but that's quite a way
> ahead of 1.9.1 now, so it may interact with our code differently than
> on current trunk.
How can QA verify that this fix works properly?
Yeah, if everything works as it previously did, then we're ok.
Verified for 1.9.1 based on the testing that Tony Chung and Anthony Hughes have done on the 1.9.1 nighties.
Keywords: verified1.9.1
Alias: CVE-2009-3377
You need to log in before you can comment on or make changes to this bug.