Closed Bug 1410187 Opened 8 years ago Closed 3 years ago

IPDL protocol error: Handler returned error code!

Categories

(Core :: Graphics: Layers, defect, P3)

Product:
Core
Component:
Graphics: Layers
Version:
56 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: modournation, Unassigned)

Details

Attachments

(3 files)

src.zip
7.18 KB, application/zip
Details
Logs from relavant GPU reset.
6.38 KB, text/plain
Details
Logs_releavant_reset_gpu
6.38 KB, text/plain
Details
Attached file src.zip —
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce: I am using gecko driver and running multiple tests on a single machine. Actual results: [GFX1-]: (gfxWindowsPlatform) Detected device reset: 3 [GFX1-]: (gfxWindowsPlatform) scheduled device update. [GFX1-]: LayerManager::EndTransaction skip RenderLayer(). [GFX1-]: GFX: D3D11 skip BeginFrame with device-removed. [GFX1-]: (gfxWindowsPlatform) Detected device reset: 3 [GFX1-]: (gfxWindowsPlatform) scheduled device update. [GFX1-]: LayerManager::EndTransaction skip RenderLayer(). [GFX1-]: (gfxWindowsPlatform) Detected device reset: 3 [GFX1-]: (gfxWindowsPlatform) scheduled device update. [GFX1-]: LayerManager::EndTransaction skip RenderLayer(). [GFX1-]: (gfxWindowsPlatform) Detected device reset: 3 [GFX1-]: (gfxWindowsPlatform) scheduled device update. [GFX1-]: LayerManager::EndTransaction skip RenderLayer(). IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (ind icating failure) Which results in the browser hanging. Expected results: Should have navigated to a website.
Component: Untriaged → geckodriver
Product: Firefox → Testing
This is not a geckodriver bug, but as it looks like bad crashes in the IPC component. As such moving it to that component. Originally we got this reported as https://github.com/mozilla/geckodriver/issues/1002. The version of Firefox in use is 56.0. Kevin, as it looks like I missed to ask you to also check with a 57.0 beta build, and a 58.0a1 nightly build. Would you mind trying how those work? Also the videos are all 10min long. Is there a time we should seek to, to actually see this problem?
Component: geckodriver → IPC
Flags: needinfo?(modournation)
Product: Testing → Core
Yes I will try that now.
Flags: needinfo?(modournation)
(In reply to Kevin Yeske from comment #3) > Yes I will try that now. Seems as though the 58.0a1 nightly build has stopped the errors. Thanks! been trying to figure this out for weeks.
Kevin, which means the latest 57 beta is still affected by that crash? In that case it would be good to know which patch actually fixed your problem in Nightly.
Flags: needinfo?(modournation)
I jumped straight to 58.0a1 as thats what was downloaded when i went to grab the nightly build. It seems though it is still affected. Logs are now saying this and stopping- [GFX1-]: Receive IPC close with reason=AbnormalShutdown
Flags: needinfo?(modournation)
Kevin, could you please attach a trace-level log from geckodriver? How to do that for Java is explained in this document: https://searchfox.org/mozilla-central/source/testing/geckodriver/doc/TraceLogs.md
Flags: needinfo?(modournation)
After doing that it logs into the accounts and does nothing.. Seems that it keeps running out of memory. Which it wasnt doing before adding in the to show the trace-level log. Here is the log from the ones that crashed - https://www.mediafire.com/file/l3c021jdemo652b/threadlogcrash.txt. Seems as though this is causing more of an output which is causing crashes.
Flags: needinfo?(modournation)
Priority: -- → P3
The log is indeed huge and is not that helpful here. Would you mind just running your test again but with normal logging? Also are you using a 32bit or 64bit binary of Firefox Nightly? Maybe try both.
Flags: needinfo?(modournation)
i'M GETTING THIS TOO IN BUILD FF-DESKTOP FOR LINUX DEBIAN Version 67.0.3396.99 ( ON KERNEL 4.13.0-45 GPU ), also multiple sandbox errors possible it's a container issue tied to a sight security certificate.
Flags: needinfo?(berry.whitetiger)
I've been getting this error for the past 6 months or so, when trying to open the metamask addon. Clicking on the metamask icon will briefly open the addon's window, then it closes immediately (making the addon unusable). Ubuntu 18.04, firefox 63.0b8. stdout from firefox shows: IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (indicating failure)
This is where LayerTransactionParent::RecvReleaseLayer would be reporting failure: https://searchfox.org/mozilla-central/rev/881a3c5664ede5e08ee986d76433bc5c4b5680e6/gfx/layers/ipc/LayerTransactionParent.cpp#1012 And this appears to be a graphics bug: the IPC stack provides the ability to reject messages, and graphics is using it.
Component: IPC → Graphics: Layers
Arch Linux
Kernel 4.20.7-zen1-1-zen
Firefox 65.0.1

Same problem:

(firefox:26626): Gtk-WARNING **: 17:23:01.822: Theme parsing error: <data>:1:34: Expected ')' in color definition

(firefox:26626): Gtk-WARNING **: 17:23:01.822: Theme parsing error: <data>:1:77: Expected ')' in color definition
IPDL protocol Error: Received an invalid file descriptor
IPDL protocol Error: Received an invalid file descriptor
IPDL protocol Error: Received an invalid file descriptor
[Parent 26626, Gecko_IOThread] WARNING: pipe error (127): Connection reset by peer: file /build/firefox/src/mozilla-unified/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 349

april 5, 2019:
fedora 30
memory: 7.3GiB
processor: AMD* A9-9425 radeon r5,5compute cores 2c+3gx2
graphics: AMD* Stoney
GNOME: Version 3.32.0
OS type: 64-bit
Disk: 1TB

Yesterday, I created bug: 1542011 which started off with just the first two Errors. Then today, I did some tests and figured out how to replicate quite a few errors, including some mentioned in this blog. I am going to try and do something with the bug 1542011 I created in case anyone actually happens on it, they should be here.

want to add this to bug 1410187

the following nine error messages are all related to when new windows are opened and closed. With the first three error messages related to the positioning que of where and when new pages are opened and if they are opened or closed in the original window opened with firefox. the fourth to ninth error messages all related to the original window getting closed before rest are closed
and

are possible

security concerns ??

All but the first Error is related to the closing of your first/original opened firefox window before closing the rest of the firefox windows producing different problems - and interestly, and the reason I think a potential security issue is that what your accessing on the internet is triggering different communication protocols - that are having problems syncing to ?? because the "mother" window aka: first or original window opened has been closed and your still using google etc. So it seems the first firefox window opened is controlling the behaviour of all subsequent windows including the direction and location of syncing messages - keylogger? - the subsequent windows opened don't seem to be able to follow through on communication protocols, issuing the below Errors.

First Error:
IPDL protocol Error: Received an invalid file descriptor

Second Error:
[Parent 19349, Gecko_IOThread] WARNING: pipe error (68): Connection reset by peer: file /builddir/build/BUILD/firefox-66.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 357

Third Error:
[Parent 19349, Gecko_IOThread] WARNING: pipe error (187): Connection reset by peer: file /builddir/build/BUILD/firefox-66.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 357

Fourth Error:
IPDL protocol error: Handler returned error code!

Fifth Error:
###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (indicating failure)

sixth or second Error:
[Parent 27585, Gecko_IOThread] WARNING: pipe error (128): Connection reset by peer: file /builddir/build/BUILD/firefox-66.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 357

seventh Error:
###!!! [Child][MessageChannel] Error: (msgtype=0x520011,name=PHttpChannel::Msg___delete__) Channel closing: too late to send/recv, messages will be lost

eigth Error:
###!!! [Child][MessageChannel] Error: (msgtype=0x5F0029,name=PNecko::Msg_RemoveRequestContext) Channel closing: too late to send/recv, messages will be lost

ninth error:
###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

#------------------------------------------------------------
conditons needed: open more than three windows: and the tabs opened are of random - AND performed some google searches to get links for opening in a new window and *Not from opening new windows from links in the default homepage which is fedora wiki writing

the following events will trigger the error message:

First Error:
IPDL prIPDL protocol Error: Received an invalid file descriptor

Each time firefox browser is opened for first time will produce the FIRST ERROR

AND

the fIRST error message shows up each time a new tab in that same window is opened
BUT

as soon as you open a page in a new window instead of a new tab then that error stops repeating itself except
it will continue to repeat itself when you open new tabs in the original window - but not the second window.
UNLESS

you open more than two windows and than all the error messages stop - doesn't matter what window your in and opening new tabs, no new error messages.
UNTIL

you close any window EXCEPT the original/first window you will get the FIRST ERROR Repeated again.

you will get that error message repeating itself just once when you close one of your new windows and all its tabs.
UNLESS

you close the original window first opened leaving subsequent windows still open and with google searches* and then you get the other error message:

SECOND ERROR:

[Parent 19349, Gecko_IOThread] WARNING: pipe error (68): Connection reset by peer: file /builddir/build/BUILD/firefox-66.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 357
IPDL protocol Error: Received an invalid file descriptor

*now your terminal is showing that second error message because you closed the originally opened firefox window but you still have one or more opened windows.

Now the FIRST ERROR message doesn't seem to repeat itself anymore
UNTIL

you close all the windows Except one.
so now just one window left - that isn't the original window actually opened by firefox

and now opening new pages in new tabs will start the FIRST ERROR message to repeat itself with each new page opened in a new tab again.

so now the above process repeats, UNTIL. you close ALL the windows and you then get the THIRD ERROR:

[Parent 19349, Gecko_IOThread] WARNING: pipe error (187): Connection reset by peer: file /builddir/build/BUILD/firefox-66.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 357

*to get the above error message, just close all the windows - and the last window to close is not the original window opened.

#------------------------------------------------

Changing Conditions of what pages/links are opened in new tabs and windows:

open a new window and then open second/third windows from the default fedora page - so not from a link gotten from a google search of random crap.

Now. FIRST ERROR is the ONLY error possible to get.
and that error repeats for every window opening new pages - and Not doing google searches,
just opening new tabs from a link found in original home page and not found from a google search.

$ firefox
then in new window it has a homepage of fedora and i opened a blank page of new tab - and that gave error in terminal. repeat
then go back to homepage of fedora and right clicked fedora wiki and opened link/page in new window and repeated above steps - with this time, every new page/tab opened - blank new page in any and every window will repeat the FIRST ERROR mesage each time.

closing the windows in any order did NOT produce SECOND or THIRD ERROR or any other error.

#-------------------------------------------------

Changing Conditions of what pages/links are opened in new tabs and windows before closing windows:

start fresh and open a new browser:

$ firefox
opened new tabs and then hit random keys on keyboard and did a google search.
picked a random result from google search results,
and opened the link found in a google search in a new window

and repeated this to open four windows. - all with google searches

FIRST ERROR repeats itself on first and
second window for each new tab opened
UNTIL

a google search is done on one of the other windows

and then all the error messages stop - for all windows.

and now opening new windows or tabs produces zero errors
UNTIL

you start closing windows.
and then the following:

IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (indicating failure)

IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (indicating failure)

IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (indicating failure)

IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (indicating failure)

[Parent 27585, Gecko_IOThread] WARNING: pipe error (128): Connection reset by peer: file /builddir/build/BUILD/firefox-66.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 357

###!!! [Child][MessageChannel] Error: (msgtype=0x520011,name=PHttpChannel::Msg___delete__) Channel closing: too late to send/recv, messages will be lost

###!!! [Child][MessageChannel] Error: (msgtype=0x5F0029,name=PNecko::Msg_RemoveRequestContext) Channel closing: too late to send/recv, messages will be lost

###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

#-------------------------------------

*/ OK> so the above messages happen after closing original "mother" window BEFORE
closing rest of windows AND
doing google searches on remaining windows before closing them.

so. i need some help to understand the error messages regarding these message channels as I am now thinking these messages are
possible

security issue??

Why: because in extracting words from:

Fifth Error: the parent is msg releaselayer --
so the parent or control window is missing hence the returning false
because I closed the first window before the rest but

the error messages are saying the parent is a DispatchAsyncMessage. so, ok,
dispatching a sync message -
that seems simple - sending to a remote location is getting something -- a sync message.

that seems simple. the remote location which I presume is the parent window/ first window/ is in control of a remote location of ??

that is syncing all the messages given to the firefox window. but.
since the parent window. first window. was closed before the other windows. and
i did google searches in all the windows,
not just the first or two windows doing google searchs, i get lots of errors

with closing windows after closing the first/parent/original window and leaving the rest open.
and they are all indicating messages and syncing and channels

so I think this means the original window is opening a particular port
to sync all the messages or keylogger that is happening on the firefox windows ???

When I look at the error messages for further reason
to support my paranoia/curiousity of who could care that much,

I am seeing in seventh Error : msgtype=0z520011 and then name and message

-- so that is a key, signature, credentials, it opens stuff,
it has authority, what does it have? whose is it? but its closing the channel

  • so I thnk that means it is closing the port because it lost all the messages and can't sync
    because I closed the original window first. ??

when I google 0x520011 it seems to be owned by microsoft. I am not versed enough to know gpg command to find ownership quickly.

Regardless. If you play around with opening a browser from a google search link, and then opening and closing windows - with and without google searches, this produces different Error Messages - when your original window gets closed.

If you don't do any google searches, you don't get any of these Errors - except the first one.

So, maybe it isn't considered a security breach because its google scripting keyloggers
for its new apps but its still a keylogger of sorts
-- unless I am just way out in left field as to how I understand this stuff. Which wouldn't be the first or last time.

So, if anyone could offer some help to understand these as well as 'fix' them.

Thanks for help.
jp
*/

Firefox 94.0.1 64 bit.

Debian 10

I have been seeing this error for weeks if not months now.
I know this is an old bug but it apparently is still on the loose.

I run a barebones window manager (Icewm) with a plank doc and a minimal picom for some transparency.

This is a sample

###!!! [Parent][DispatchAsyncMessage] Error: PClientManager::Msg_ExpectFutureClientSource Processing error: message was deserialized, but the handler returned false (indicating failure)

IPDL protocol error: Handler returned error code!

I also notice this once in a while.

ATTENTION: default value of option mesa_glthread overridden by environment.

Im able to reliably reproduce this bug on 95.0.2 on archlinux build with disneyplus.com loaded. Started recently after updating to .2 release.

On Wayland with hardware acceleration enabled, wayland. But no media playing. Just browsing on home screen

Dec 26 16:53:02 stormstar firefox.desktop[124570]: [GFX1-]: Failed to connect WebRenderBridgeChild.
Dec 26 16:53:02 stormstar firefox.desktop[124424]: [GFX1-]: GFX: RenderThread detected a device reset in PostUpdate
Dec 26 16:53:02 stormstar firefox.desktop[124424]: IPDL protocol error: Handler returned error code!
Dec 26 16:53:02 stormstar firefox.desktop[124424]: ###!!! [Parent][DispatchSyncMessage] Error: PCompositorBridge::Msg_NotifyChildRecreated Processing error: message was deserialized, but the handler returned false (indicating failure)
Tried again and recorded journalctl output ``` Dec 26 17:00:22 stormstar kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vcn_dec timeout, signaled seq=200946, emitted seq=200948 Dec 26 17:00:22 stormstar kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Isolated Web Co pid 136607 thread firefox:cs0 pid 136968 Dec 26 17:00:22 stormstar kernel: amdgpu 0000:03:00.0: amdgpu: GPU reset begin! Dec 26 17:00:22 stormstar firefox.desktop[136244]: [GFX1-]: GFX: RenderThread detected a device reset in PostUpdate Dec 26 17:00:22 stormstar firefox.desktop[136244]: [GFX1-]: GFX: RenderThread detected a device reset in PostUpdate Dec 26 17:00:22 stormstar firefox.desktop[136244]: [GFX1-]: GFX: RenderThread detected a device reset in PostUpdate Dec 26 17:00:22 stormstar firefox.desktop[136607]: [GFX1-]: Failed to connect WebRenderBridgeChild. Dec 26 17:00:22 stormstar firefox.desktop[136607]: [GFX1-]: IPC Channel is already torn down unexpectedly Dec 26 17:00:22 stormstar firefox.desktop[136244]: [GFX1-]: GFX: RenderThread detected a device reset in PostUpdate Dec 26 17:00:22 stormstar firefox.desktop[136244]: IPDL protocol error: Handler returned error code! Dec 26 17:00:22 stormstar firefox.desktop[136244]: ###!!! [Parent][DispatchSyncMessage] Error: PCompositorBridge::Msg_NotifyChildRecreated Processing error: message was deserialized, but the handler returned false (indicating failure) ``` ```
Tried again and recorded journalctl output ``` Dec 26 17:00:22 stormstar kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vcn_dec timeout, signaled seq=200946, emitted seq=200948 Dec 26 17:00:22 stormstar kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Isolated Web Co pid 136607 thread firefox:cs0 pid 136968 Dec 26 17:00:22 stormstar kernel: amdgpu 0000:03:00.0: amdgpu: GPU reset begin! Dec 26 17:00:22 stormstar firefox.desktop[136244]: [GFX1-]: GFX: RenderThread detected a device reset in PostUpdate Dec 26 17:00:22 stormstar firefox.desktop[136244]: [GFX1-]: GFX: RenderThread detected a device reset in PostUpdate Dec 26 17:00:22 stormstar firefox.desktop[136244]: [GFX1-]: GFX: RenderThread detected a device reset in PostUpdate Dec 26 17:00:22 stormstar firefox.desktop[136607]: [GFX1-]: Failed to connect WebRenderBridgeChild. Dec 26 17:00:22 stormstar firefox.desktop[136607]: [GFX1-]: IPC Channel is already torn down unexpectedly Dec 26 17:00:22 stormstar firefox.desktop[136244]: [GFX1-]: GFX: RenderThread detected a device reset in PostUpdate Dec 26 17:00:22 stormstar firefox.desktop[136244]: IPDL protocol error: Handler returned error code! Dec 26 17:00:22 stormstar firefox.desktop[136244]: ###!!! [Parent][DispatchSyncMessage] Error: PCompositorBridge::Msg_NotifyChildRecreated Processing error: message was deserialized, but the handler returned false (indicating failure) ``` ```

Redirect needinfos that are pending on inactive users to the triage owner.
:bhood, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(modournation)
Flags: needinfo?(bhood)
Flags: needinfo?(berry.whitetiger)

Rohan, if this is still reproducible on your system, can you attach the about:support for that system to this bug, please?

Flags: needinfo?(bhood) → needinfo?(rohan)

Hi Bob, it looks like the bug is no longer reproducible on the Disney+ site.

Flags: needinfo?(rohan)
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: