ASSERTION: Target channel not in the process of opening: 'ChannelOpening == aTargetChan->mChannelState

RESOLVED FIXED in mozilla14

Status

()

Core
IPC
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: romaxa, Assigned: romaxa)

Tracking

Trunk
mozilla14
x86
Linux
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
Created attachment 616364 [details] [diff] [review]
Fix proposal

On attempt to initialize Compositor Parent channel for OMTC rendering in embedding setup: see bug 746800#c1
I see next assertion:
**************************************
1034701888[3dc647f0]: ###!!! ASSERTION: Target channel not in the process of opening: 'ChannelOpening == aTargetChan->mChannelState', file ipc/glue/AsyncChannel.cpp, line 368
###!!! ASSERTION: Target channel not in the process of opening: 'ChannelOpening == aTargetChan->mChannelState', file ipc/glue/AsyncChannel.cpp, line 368
1034701888[3dc647f0]: ###!!! ASSERTION: Target channel not in the process of opening: 'ChannelOpening == aTargetChan->mChannelState', file ipc/glue/AsyncChannel.cpp, line 375
###!!! ASSERTION: Target channel not in the process of opening: 'ChannelOpening == aTargetChan->mChannelState', file ipc/glue/AsyncChannel.cpp, line 375
**********************************
which is coming right after PostTask(NewRunnableMethod(aTargetChan, &AsyncChannel::OnOpenAsSlave,)
http://mxr.mozilla.org/mozilla-central/source/ipc/glue/AsyncChannel.cpp#342

it looks like AsyncChannel::OnOpenAsSlave executed in child thread 
before mChannelState = ChannelOpening set

Moving mChannelState = ChannelOpening before PostTask call, fixing the problem
Attachment #616364 - Flags: feedback?(jones.chris.g)
(Assignee)

Updated

5 years ago
Blocks: 746800
Comment on attachment 616364 [details] [diff] [review]
Fix proposal

This makes sense.  I was able to reproduce the assertion when running the ipdl/c++ tests, |make -C $objdir/ipc/ipdl/test/cxx check|.  Please test your patch against those tests and all good.

Thanks!
Attachment #616364 - Flags: feedback?(jones.chris.g) → feedback+
(Assignee)

Comment 2

5 years ago
Comment on attachment 616364 [details] [diff] [review]
Fix proposal

Tested this with make check
Cannot catch that locally on desktop gtk debug build (probably different timings)
Test same with patch and don't see any new errors.
Attachment #616364 - Flags: review?(jones.chris.g)
Attachment #616364 - Flags: review?(jones.chris.g) → review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
Attachment #616364 - Flags: approval-mozilla-central?
This code runs in native-fennec, and fixes a race condition/logic error that native-fennec is vulnerable to hit.  If there are debug builds of native-fennec it's quite likely they were tripping this assertion.

The fix itself has basically no risk.  I'm not sure if the defect it fixes could cause user-visible issues, but it's possible.
(Assignee)

Comment 4

5 years ago
https://tbpl.mozilla.org/?tree=Try&rev=55d3402d5186

Updated

5 years ago
Assignee: nobody → romaxa
Attachment #616364 - Flags: approval-mozilla-central? → approval-mozilla-central+
https://hg.mozilla.org/integration/mozilla-inbound/rev/8ef46e071f65

Any chance of getting a test for this?
Flags: in-testsuite?
Keywords: checkin-needed
Target Milestone: --- → mozilla14
(Assignee)

Comment 6

5 years ago
not sure, this is timing dependent issue.. depends on how fast thread could be created
https://hg.mozilla.org/mozilla-central/rev/8ef46e071f65
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
This is caught by existing tests.  They don't run on tinderbox though.
You need to log in before you can comment on or make changes to this bug.