Closed
Bug 631953
Opened 13 years ago
Closed 13 years ago
Linked video makes Firefox enter a busy loop
Categories
(Core :: Audio/Video, defect)
Core
Audio/Video
Tracking
()
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: tiagomatos, Assigned: kinetik)
References
()
Details
(Keywords: hang, regression, Whiteboard: [softblocker])
Attachments
(1 file)
2.67 KB,
patch
|
cpearce
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10) Gecko/20100101 Firefox/4.0b10 Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10) Gecko/20100101 Firefox/4.0b10 Visiting the video in the URL makes Firefox enter a 100% CPU using loop. The only way out is killing the process. Reproducible: Always
Comment 1•13 years ago
|
||
I can confirm a hang with Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110205 Firefox/4.0b12pre SeaMonkey/2.1b3pre
Severity: normal → critical
Status: UNCONFIRMED → NEW
Component: General → Video/Audio
Ever confirmed: true
Keywords: hang
OS: Linux → All
Product: Firefox → Core
QA Contact: general → video.audio
Hardware: x86_64 → All
Version: unspecified → Trunk
Assignee | ||
Comment 2•13 years ago
|
||
Hangs a current nightly on Linux x86_64 for me, but doesn't hang with my current development debug build.
blocking2.0: --- → ?
Comment 3•13 years ago
|
||
One problem here is that nsOggReader::mVorbisSerial is initialized to 0, but that's the actual value of the Theora stream's serial (there's no Vorbis stream in that video). So the Ogg @buffered implementation is trying to use Theora pages to calculate Vorbis timestamps. That might be the problem; it's at least causing assertions to fire (for me). We perhaps need to add flags to nsOggReader to denote whether we have Vorbis and Theora streams. There may be other problems here...
Assignee | ||
Comment 4•13 years ago
|
||
It doesn't hang for me with a local optimized build either (gcc 4.4.5 vs gcc 4.3.3 for the nightlies). I grabbed the symbols for my current nightly and got a plausible looking stack... it looks like the hang is the problem cpearce already discovered: #0 ogg_page_checksum_set (og=0x7fff05e2e7a0) at media/libogg/src/ogg_framing.c:294 #1 ogg_sync_pageseek (oy=0x7fff05e2e900, og=0x7fff05e2e8e0) at media/libogg/src/ogg_framing.c:691 #2 PageSync(nsMediaStream *, struct {...} *, PRBool, PRInt64, PRInt64, struct {...} *, int &) (aStream=0x7f74db4be000, aState=0x7fff05e2e900, aCachedDataOnly=1, aOffset=1513812796, age=0x7fff05e2e8e0, aSkippedBytes=@0x7fff05e2e92c) at content/media/ogg/nsOggReader.cpp:1287 #3 nsOggReader::GetBuffered (this=0x7f74d8f75800, aBuffered=0x7f74f0357b20, aStartTime=0) at content/media/ogg/nsOggReader.cpp:1601 #4 nsHTMLMediaElement::GetBuffered (this=0x7f74ddc91ee0, aBuffered=0x7fff05e2ebd0) at content/html/content/src/nsHTMLMediaElement.cpp:2565
blocking2.0: final+ → ?
Assignee | ||
Comment 5•13 years ago
|
||
I can reproduce this with a optimized build built with gcc 4.3.3. This patch fixes the hang.
Assignee: nobody → kinetik
Status: NEW → ASSIGNED
Attachment #510507 -
Flags: review?(chris)
Attachment #510507 -
Flags: approval2.0?
blocking2.0: ? → final+
Updated•13 years ago
|
Attachment #510507 -
Flags: review?(chris) → review+
Assignee | ||
Updated•13 years ago
|
Attachment #510507 -
Flags: approval2.0?
Assignee | ||
Updated•13 years ago
|
Whiteboard: [softblocker] → [softblocker][needs landing]
Comment 6•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/dcc45003a979
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [softblocker][needs landing] → [softblocker]
Cannot reproduce with Firefox 4.0b12pre 20110218.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•