Closed
Bug 612573
Opened 14 years ago
Closed 13 years ago
Crash in content process - RenderCreatePicture: BadDrawable (invalid Pixmap or Window parameter)
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(status1.9.2 unaffected, status1.9.1 unaffected, fennec-)
VERIFIED
FIXED
Firefox 4.0
Tracking | Status | |
---|---|---|
status1.9.2 | --- | unaffected |
status1.9.1 | --- | unaffected |
fennec | - | --- |
People
(Reporter: MikeK, Assigned: cjones)
References
Details
(Keywords: testcase, Whiteboard: [approved-patches-landed])
Attachments
(4 files)
8.07 KB,
text/plain
|
Details | |
751 bytes,
text/html
|
Details | |
2.64 KB,
text/plain
|
Details | |
2.48 KB,
patch
|
karlt
:
review+
dougt
:
approval2.0+
|
Details | Diff | Splinter Review |
When loading pages from the local file system crashing is frequent, when loading the same pages from a web-server it doesn't crash. The page I have been using to reproduce this is attached together with a stack trace from gdb.
Reporter | ||
Comment 1•14 years ago
|
||
To reproduce load this page into Fennec, if it doesn't fail immediately, then just hit "reload" until it does.
Please run with --sync to get a useful stack.
Severity: major → critical
Keywords: stackwanted
Summary: Crash in content process (Seems to originate from passing bad stuff into X) → Crash in content process - RenderCreatePicture: BadDrawable (invalid Pixmap or Window parameter)
Updated•14 years ago
|
tracking-fennec: --- → ?
Comment 3•14 years ago
|
||
I have the same crash. I load this code: <!DOCTYPE html> <html> <body> <div>i</div> </body> </html> on a local http server. The dump in the console: ###!!! ABORT: RenderCreatePicture: BadDrawable (invalid Pixmap or Window parameter); 21 requests ago: file /builds/slave/linux-fennec-trunk-nightly/build/mozilla-central/toolkit/xre/nsX11ErrorHandler.cpp, line 190 ###!!! ABORT: RenderCreatePicture: BadDrawable (invalid Pixmap or Window parameter); 21 requests ago: file /builds/slave/linux-fennec-trunk-nightly/build/mozilla-central/toolkit/xre/nsX11ErrorHandler.cpp, line 190 If I run fennec --sync, "almost" no crash (maybe once every 20 loads), with the same dump.
Comment 4•14 years ago
|
||
Stacktrace of paul's example, I've tried to get one using the --sync flag but I've been unable to crash with it
Updated•14 years ago
|
tracking-fennec: ? → 2.0-
Comment 5•14 years ago
|
||
i don't think that this happens on device, but it is pretty annoying for debugging on the desktop.
Assignee | ||
Comment 6•14 years ago
|
||
(In reply to comment #2) > Please run with --sync to get a useful stack. I don't believe that works properly with content processes, but I know that setting MOZ_X_SYNC=1 in the environment definitely does. (In reply to comment #5) > i don't think that this happens on device, but it is pretty annoying for > debugging on the desktop. It won't because we barely use X11 in fennec on maemo, and only in the chrome process. A "workaround" is to build with --enable-mobile-optimize on desktop, which fennec devs ought to be doing anyway ;). (I have been for a very long time, probably why I never saw this crash.) I can't repro with MOZ_X_SYNC=1, which might mean that this is an inter-process synchronization issue :S. In the readback part of the basic layers swap-and-readback code, this - if (OptionalThebesBuffer::Tnull_t == aReadOnlyFrontBuffer.type()) { + if (true || OptionalThebesBuffer::Tnull_t == aReadOnlyFrontBuffer.type()) { makes the crashes go away. It sure looks to me like we're syncing correctly on layers transactions, but I'll work this out on paper.
Assignee | ||
Comment 7•14 years ago
|
||
The layers log showed the problem here. The synchronization logic is still OK, but the model it depends on was being violated by layers being destroyed in in the middle of transactions (i.e., there was a missing Hold() during txns). The race condition this created was C P ------------------------------------ ---------------------- [finish txn] BasicShadowableThebesLayer(X): (1) [request copy from front-->back] BeginTxn() SetRoot(newRoot) ~oldRoot() ~BasicShadowableThebesLayer (2) Send__delete__() ... BasicShadowThebesLayer Recv__delete__() (3) [destroy front] A ShadowableThebesLayer fired off the readback request (1) to the X server through the content-process's Display. Then, that same ShadowableThebesLayer was deleted (erroneously!) during a layers txn. This caused the __delete__ message to be delivered to the parent, which set off the request to destroy the parent's front buffer, through the chrome-process's Display. The processing of the readback request then raced with the processing of the destroy request in the X server, and on the occasions when the readback lost, the content process got the X error and aborted. This patch fixes up the model violation by ensuring that setting a new root doesn't destroy the old root or its children during a txn, and adds a guard assertion for thebeslayers.
Assignee: nobody → jones.chris.g
Attachment #492930 -
Flags: review?(karlt)
Updated•14 years ago
|
Attachment #492930 -
Flags: review?(karlt) → review+
Updated•14 years ago
|
Keywords: stackwanted
Assignee | ||
Comment 8•14 years ago
|
||
Comment on attachment 492930 [details] [diff] [review] Make sure shadowable layers aren't destroyed in the middle of transactions Safe patch for a bug that's going to bite fennec-on-desktop and people working on multi-process desktop firefox.
Attachment #492930 -
Flags: approval2.0?
Comment 9•14 years ago
|
||
Comment on attachment 492930 [details] [diff] [review] Make sure shadowable layers aren't destroyed in the middle of transactions chris, is there a test needed for this change? I see the problem every day and it is a pita.
Attachment #492930 -
Flags: approval2.0? → approval2.0+
Assignee | ||
Comment 10•14 years ago
|
||
I would really like a test, but it would be next to impossible to write one that's at all reliable (I don't know how to, at least). This bug could have appeared intermittently in existing mochitests, if we were running them on a machine with remote=true and X rendering enabled.
Assignee | ||
Comment 11•14 years ago
|
||
s/mochitests/any tests that paint/
Comment 12•14 years ago
|
||
yeah, i was trying to think of how you would tickle this problem. it is a pretty inconsistent failure and I'll be glad when it is gone.
Assignee | ||
Comment 13•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/dde5e4be82c1
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
I am still seeing the issue with the desktop version: !! remote browser loaded loading about:blank, 1 [TabChild] RESIZE to (w,h)= (800d, 500d) ###!!! ABORT: RenderCreatePicture: BadDrawable (invalid Pixmap or Window parameter); 10 requests ago: file /builds/slave/places-mobile-browser-linux-nightly/build/places/toolkit/xre/nsX11ErrorHandler.cpp, line 190 ###!!! ABORT: RenderCreatePicture: BadDrawable (invalid Pixmap or Window parameter); 10 requests ago: file /builds/slave/places-mobile-browser-linux-nightly/build/places/toolkit/xre/nsX11ErrorHandler.cpp, line 190 ###!!! [Parent][AsyncChannel] Error: Channel error: cannot send/recv The steps I took were to: 1) open a new tab 2) open to http://people.mozilla.com/~nhirata/html_tp/ 3) try to open div.html
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 15•14 years ago
|
||
I can't repro using steps from comment 14 in both opt and debug desktop builds of m-c/m-b (without --enable-mobile-optimize). Which build were you testing?
Assignee | ||
Comment 16•14 years ago
|
||
(m-c 9a0741efda5c and m-b 4a2c0c666d7b)
Updated•14 years ago
|
Assignee | ||
Comment 18•13 years ago
|
||
While working on the reftest-ipc harness, I ran firefox through the shadow-layer+X11 code path probably >1000 times and didn't see a crash like this. Is anyone still seeing this?
Comment 19•13 years ago
|
||
I just started seeing this (or something like it) again in my Linux desktop builds. No symbols unfortunately, but I can turn them on and see if I get a stack.
Updated•13 years ago
|
Whiteboard: [approved-patches-landed]
Comment 20•13 years ago
|
||
patches landed, i don't see this. if you still see this sort of problem, please open a new bug and include a stack.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 13 years ago
Resolution: --- → FIXED
Comment 21•13 years ago
|
||
VERIFIED FIXED on: Build Id: Mozilla /5.0 (Android;Linux armv7l;rv:7.0a1) Gecko/20110530 Firefox/7.0a1 Fennec/7.0a1 Build Id:Mozilla /5.0 (Android;Linux armv7l;rv:6.0a2) Gecko/20110529 Firefox/6.0a2 Fennec/6.0a2 Device: HTC Desire Z (Android 2.2)
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
Target Milestone: --- → Firefox 4.0
You need to log in
before you can comment on or make changes to this bug.
Description
•