Closed
Bug 739604
Opened 12 years ago
Closed 12 years ago
Crash in ThebesLayerOGL when using MOZ_DUMP_PAINT_LIST
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla14
Tracking | Status | |
---|---|---|
blocking-fennec1.0 | --- | - |
People
(Reporter: cwiiis, Assigned: cwiiis)
Details
(Keywords: crash, Whiteboard: [native-crash])
Attachments
(3 files, 1 obsolete file)
2.54 KB,
patch
|
cwiiis
:
review+
|
Details | Diff | Splinter Review |
1.23 KB,
patch
|
mattwoodrow
:
review+
|
Details | Diff | Splinter Review |
3.20 KB,
patch
|
mattwoodrow
:
review+
|
Details | Diff | Splinter Review |
If you enable MOZ_DUMP_PAINT_LIST when using tiles and GL layers, you'll almost certainly get a crash due to uninitialised memory access. This is caused by using TextureImage calls before calling BeginIteration (meaning it may be in an inconsistent state).
Assignee | ||
Comment 1•12 years ago
|
||
erk, so fixing that issue unfortunately just shows it crashing later down the line :( Trying to debug, but it's not giving me a stack...
Assignee | ||
Comment 2•12 years ago
|
||
This restores the behaviour of TiledTextureImage::NextTile to before the patches in bug 732917. This fixes/avoids (at least) one of the crashes, I'm not sure what the cause of the other is yet.
Attachment #609741 -
Flags: review?(ajuma)
Comment 3•12 years ago
|
||
Comment on attachment 609741 [details] [diff] [review] Restore old TiledTextureImage::NextTile behaviour Review of attachment 609741 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/gl/GLContext.cpp @@ +1084,5 @@ > + mCurrentImage++; > + else > + return false; > + > + return continueIteration; It's cleaner to go back to the way it was before: if (mCurrentImage + 1 < mImages.Length()) { mCurrentImage++; return continueIteration; } return false;
Attachment #609741 -
Flags: review?(ajuma) → review+
Updated•12 years ago
|
Assignee | ||
Comment 4•12 years ago
|
||
Updated as suggested, and reset mCurrentImage when resizing - carrying over r+.
Attachment #609741 -
Attachment is obsolete: true
Attachment #610098 -
Flags: review+
Assignee | ||
Comment 5•12 years ago
|
||
This fixes the next crash I was seeing, where gfxUtils::sDumpPaintFile was NULL, but fprintf was being called using it as a parameter.
Attachment #610099 -
Flags: review?(matt.woodrow)
Assignee | ||
Comment 6•12 years ago
|
||
MOZ_DUMP_PAINT_LIST is still not useful on mobile anymore because it enables read-back of (almost) every texture (which causes every composite to take in the region of 800-1500ms, instead of the usual 10-40ms) - This read-back also doesn't work correctly with tiled texture-images anyway, so I'll write a patch to separate it into a different option.
Assignee | ||
Comment 7•12 years ago
|
||
Attachment #610119 -
Flags: review?(matt.woodrow)
Updated•12 years ago
|
Attachment #610099 -
Flags: review?(matt.woodrow) → review+
Updated•12 years ago
|
Attachment #610119 -
Flags: review?(matt.woodrow) → review+
Assignee | ||
Comment 8•12 years ago
|
||
Pushed to inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/35546f02ddb1 http://hg.mozilla.org/integration/mozilla-inbound/rev/f4ab0eddbe90 http://hg.mozilla.org/integration/mozilla-inbound/rev/2fbd3599386c
blocking-fennec1.0: --- → ?
Target Milestone: --- → mozilla14
Updated•12 years ago
|
blocking-fennec1.0: ? → -
Comment 9•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/35546f02ddb1 https://hg.mozilla.org/mozilla-central/rev/f4ab0eddbe90 https://hg.mozilla.org/mozilla-central/rev/2fbd3599386c
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•