Closed Bug 1119753 Opened 9 years ago Closed 9 years ago

Intermittent browser_windowopen_reflows.js | application crashed [@ js::GCMethods<JSObject*>::needsPostBarrier(JSObject*)]

Categories

(Core :: JavaScript: GC, defect)

Product:
Core
Component:
JavaScript: GC
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla38
Tracking Flags:
Tracking Status
firefox36 --- unaffected
firefox37 --- fixed
firefox38 --- fixed
firefox-esr31 --- unaffected

People

(Reporter: cbook, Assigned: billm)

References

(
URL
)

Details

(Keywords: crash, intermittent-failure)

Attachments

(1 file)

cpow-gc-fix
3.80 KB, patch
jonco
: review+
Sylvestre
: approval-mozilla-aurora+
Details | Diff | Splinter Review 
Ubuntu VM 12.04 fx-team opt test mochitest-e10s-browser-chrome-1

https://treeherder.mozilla.org/logviewer.html#?job_id=1629546&repo=fx-team

18:41:03 WARNING - PROCESS-CRASH | browser/base/content/test/general/browser_windowopen_reflows.js | application crashed [@ js::GCMethods<JSObject*>::needsPostBarrier(JSObject*)]
18:41:03 INFO - Crash dump filename: /tmp/tmpVqWswm.mozrunner/minidumps/26145172-fffe-b998-5d46bfe5-0ddcb4cf.dmp
18:41:03 INFO - Operating system: Linux
18:41:03 INFO - 0.0.0 Linux 3.2.0-23-generic-pae #36-Ubuntu SMP Tue Apr 10 22:19:09 UTC 2012 i686
18:41:03 INFO - CPU: x86
18:41:03 INFO - GenuineIntel family 6 model 45 stepping 7
18:41:03 INFO - 1 CPU
18:41:03 INFO - Crash reason: SIGSEGV
18:41:03 INFO - Crash address: 0x75cffff0
18:41:03 INFO - Thread 0 (crashed)
18:41:03 INFO - 0 libxul.so!js::GCMethods<JSObject*>::needsPostBarrier(JSObject*) [RootingAPI.h:44fb93810fc2 : 669 + 0x0]
18:41:03 INFO - eip = 0xb36a55f7 esp = 0xbfbb98b8 ebp = 0xbfbb98b8 ebx = 0xb6e92290
18:41:03 INFO - esi = 0x8a0ce2bc edi = 0x8a0ce400 eax = 0x75cffff0 ecx = 0x00000005
18:41:03 INFO - edx = 0x8a0ce2bc efl = 0x00010206
18:41:03 INFO - Found by: given as instruction pointer in context
18:41:03 INFO - 1 libxul.so!JS::Heap<JSObject*>::~Heap() [RootingAPI.h:44fb93810fc2 : 224 + 0x9]
18:41:03 INFO - eip = 0xb3a1829d esp = 0xbfbb98c0 ebp = 0xbfbb98d8 ebx = 0xb6e92290
18:41:03 INFO - esi = 0x8a0ce2bc edi = 0x8a0ce400
18:41:03 INFO - Found by: call frame info
18:41:03 INFO - 2 libxul.so!js::detail::HashTable<js::HashMapEntry<mozilla::jsipc::ObjectId, JS::Heap<JSObject*> >, js::HashMap<mozilla::jsipc::ObjectId, JS::Heap<JSObject*>, mozilla::jsipc::ObjectIdHasher, js::SystemAllocPolicy>::MapHashPolicy, js::SystemAllocPolicy>::~HashTable() [HashTable.h:44fb93810fc2 : 625 + 0xe]
18:41:03 INFO - eip = 0xb3a18799 esp = 0xbfbb98e0 ebp = 0xbfbb9918 ebx = 0xb6e92290
18:41:03 INFO - esi = 0x8a0ce2b0 edi = 0x8a0ce400
18:41:03 INFO - Found by: call frame info
18:41:03 INFO - 3 libxul.so!mozilla::jsipc::JavaScriptParent::~JavaScriptParent() [JavaScriptParent.cpp:44fb93810fc2 : 39 + 0x8]
18:41:03 INFO - eip = 0xb3a18f6e esp = 0xbfbb9920 ebp = 0xbfbb9938 ebx = 0xb6e92290
18:41:03 INFO - esi = 0x98eaab70 edi = 0xbfbb9970
18:41:03 INFO - Found by: call frame info
18:41:03 INFO - 4 libxul.so!mozilla::jsipc::JavaScriptShared::decref() [JavaScriptShared.cpp:44fb93810fc2 : 204 + 0x8]
18:41:03 INFO - eip = 0xb3a179eb esp = 0xbfbb9940 ebp = 0xbfbb9958 ebx = 0xb6e92290
18:41:03 INFO - esi = 0x98eaab98 edi = 0xbfbb9970
18:41:03 INFO - Found by: call frame info
18:41:03 INFO - 5 libxul.so!mozilla::jsipc::WrapperOwner::drop(JSObject*) [WrapperOwner.cpp:44fb93810fc2 : 751 + 0xd]
18:41:03 INFO - eip = 0xb3a1eb7b esp = 0xbfbb9960 ebp = 0xbfbb9988 ebx = 0xb6e92290
Given the timing, I have to believe that this and bug 1119751 are the same issue.
Component: JavaScript Engine → JavaScript: GC
Flags: needinfo?(terrence)
Flags: needinfo?(jcoppeard)
Bill, this is happening inside CPOWProxyHandler::finalize().  Any idea what might have caused it?
Flags: needinfo?(wmccloskey)
Looking at the logs we have this just before the crash:

09:00:13 INFO - 718 INFO TEST-OK | browser/base/content/test/general/browser_windowopen_reflows.js | took 353ms
09:00:15 INFO - ###!!! [Child][MessageChannel::SendAndWait] Error: Channel error: cannot send/recv
09:00:15 INFO - TEST-INFO | Main app process: exit status 1
09:00:15 INFO - 719 INFO checking window state
09:00:15 INFO - 720 INFO Console message: [JavaScript Warning: "unsafe CPOW usage" {file: "resource://app/modules/sessionstore/TabState.jsm" line: 96}]
09:00:15 INFO - 721 INFO Console message: [JavaScript Warning: "unsafe CPOW usage" {file: "resource://app/modules/sessionstore/TabState.jsm" line: 96}]
09:00:15 INFO - 722 ERROR TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_windowopen_reflows.js | application terminated with exit code 1

So some bad CPOW use seems implicated.
Flags: needinfo?(jcoppeard)
FWIW I've seen the same "unsafe CPOW usage" just in a regular run so I don't know if it indicates anything.
In fact, I looked at a random e10s bc1 log and there were over 100 of them.  I guess I should file a bug on that.
(In reply to Andrew McCreight [:mccr8] from comment #12)
> In fact, I looked at a random e10s bc1 log and there were over 100 of them. 
> I guess I should file a bug on that.

Filed bug 1119884.
This appears to be the same as Bug 1119604 as well.
Flags: needinfo?(terrence)
Attached patch cpow-gc-fix — — Splinter Review 
I audited the CPOW GC code and found a possible problem. If we do a GC after the child process dies, we won't trace objects_ in JavaScriptParent. Later when JavaScriptParent dies, we'll destroy the stale Heap references and we might crash.

I also added an assertion that cpows_ is empty when JavaScriptShared dies. We use refcounting to ensure that.
Flags: needinfo?(wmccloskey)
Attachment #8547824 - Flags: review?(jcoppeard)
Comment on attachment 8547824 [details] [diff] [review]
cpow-gc-fix

Review of attachment 8547824 [details] [diff] [review]:
-----------------------------------------------------------------

Nice, that looks like the problem!

::: js/ipc/JavaScriptParent.cpp
@@ +59,5 @@
> +        // Make sure we kill off these references, which potentially will be
> +        // stale after the GC completes.
> +        objects_.clear();
> +        unwaivedObjectIds_.clear();
> +        waivedObjectIds_.clear();

Just a thought - can we clear these tables when the child process dies and trace them unconditionally here?
Attachment #8547824 - Flags: review?(jcoppeard) → review+
Assignee: nobody → wmccloskey
https://hg.mozilla.org/mozilla-central/rev/8c6cbca7251a
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Please nominate this for Aurora approval when you get a chance.
status-firefox38: affected → fixed
Flags: needinfo?(wmccloskey)
Comment on attachment 8547824 [details] [diff] [review]
cpow-gc-fix

This patch fixes some test failures on aurora, so the sheriffs would like it fixed. However, this is not code that we ship to users in aurora or later (it's part of e10s), so there's basically no chance of regression.

Approval Request Comment
[Feature/regressing bug #]: don't know
[User impact if declined]: none
[Describe test coverage new/current, TreeHerder]: on m-c
[Risks and why]: None.
[String/UUID change made/needed]: None.
Flags: needinfo?(wmccloskey)
Attachment #8547824 - Flags: approval-mozilla-aurora?
Attachment #8547824 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: