Crash in ThebesLayerOGL when using MOZ_DUMP_PAINT_LIST

RESOLVED FIXED in mozilla14

Status

()

Core
Graphics
--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: cwiiis, Assigned: cwiiis)

Tracking

({crash})

Trunk
mozilla14
ARM
Android
crash
Points:
---

Firefox Tracking Flags

(blocking-fennec1.0 -)

Details

(Whiteboard: [native-crash])

Attachments

(3 attachments, 1 obsolete attachment)

(Assignee)

Description

5 years ago
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

5 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

5 years ago
Created attachment 609741 [details] [diff] [review]
Restore old TiledTextureImage::NextTile behaviour

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

5 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

5 years ago
Severity: normal → critical
Keywords: crash
Whiteboard: [native-crash]
(Assignee)

Comment 4

5 years ago
Created attachment 610098 [details] [diff] [review]
Restore old TiledTextureImage::NextTile behaviour

Updated as suggested, and reset mCurrentImage when resizing - carrying over r+.
Attachment #609741 - Attachment is obsolete: true
Attachment #610098 - Flags: review+
(Assignee)

Comment 5

5 years ago
Created attachment 610099 [details] [diff] [review]
Add NULL check in Layers.cpp:WriteSnapshotToDumpFile_internal

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

5 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

5 years ago
Created attachment 610119 [details] [diff] [review]
Split out paint buffer dumping from paint list dumping
Attachment #610119 - Flags: review?(matt.woodrow)
Attachment #610099 - Flags: review?(matt.woodrow) → review+
Attachment #610119 - Flags: review?(matt.woodrow) → review+
(Assignee)

Comment 8

5 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
blocking-fennec1.0: ? → -
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
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.