crash in libgdk-3.so.0.2000.3@0x3ebf2

RESOLVED FIXED in Firefox 49

Status

()

--
critical
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: njn, Assigned: lsalzman)

Tracking

({crash})

Trunk
mozilla49
Unspecified
Linux
crash
Points:
---

Firefox Tracking Flags

(firefox48 affected, firefox49 fixed)

Details

(Whiteboard: [gfx-noted], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
This bug was filed from the Socorro interface and is 
report bp-845253ef-0006-43ed-98d0-35a642160414.
=============================================================

I see 22 crashes with this signature in the past 7 days, across 11 installations, a mixture of 47.0 and 48.0.

Stack trace:

> 0 	libgdk-3.so.0.2000.3 	libgdk-3.so.0.2000.3@0x3ebf2 	
> 1 	libxul.so 	mozilla::layers::CompositorOGL::CreateContext 	gfx/layers/opengl/CompositorOGL.cpp
> 2 	libxul.so 	mozilla::layers::CompositorOGL::Initialize 	gfx/layers/opengl/CompositorOGL.cpp
> 3 	libxul.so 	mozilla::layers::CompositorBridgeParent::NewCompositor 	gfx/layers/ipc/CompositorBridgeParent.cpp
> 4 	libxul.so 	mozilla::layers::CompositorBridgeParent::InitializeLayerManager 	gfx/layers/ipc/CompositorBridgeParent.cpp
> 5 	libxul.so 	mozilla::layers::CompositorBridgeParent::AllocPLayerTransactionParent 	gfx/layers/ipc/CompositorBridgeParent.cpp
> 6 	libxul.so 	mozilla::layers::PCompositorBridgeParent::OnMessageReceived 	obj-firefox/ipc/ipdl/PCompositorBridgeParent.cpp
> 7 	libxul.so 	mozilla::ipc::MessageChannel::DispatchSyncMessage 	ipc/glue/MessageChannel.cpp
> 8 	libxul.so 	mozilla::ipc::MessageChannel::DispatchMessage 	ipc/glue/MessageChannel.cpp

All the crashes are at the address 0xe8.
(Reporter)

Comment 1

2 years ago
karlt, is this code you know about? I'm not sure who's best to ask for this one.
Flags: needinfo?(karlt)
Not code I know, but this should only be called if hidden prefs have been changed.

If some stack frames are missing then GDK might be involved in getting the default display, which makes me wonder whether Wayland is involved.
https://hg.mozilla.org/mozilla-central/annotate/91115264629d/gfx/layers/opengl/CompositorOGL.cpp#l139
Flags: needinfo?(karlt)
(Assignee)

Comment 3

2 years ago
Created attachment 8746112 [details] [diff] [review]
check for valid X11 display in nsWindow::GetNativeData(NS_NATIVE_DISPLAY)

It's trying to access the xdisplay field off a null pointer because gdk_display_get_default is returning null. That's obviously not safe. This fixes that.
Assignee: nobody → lsalzman
Status: NEW → ASSIGNED
Attachment #8746112 - Flags: review?(karlt)
Comment on attachment 8746112 [details] [diff] [review]
check for valid X11 display in nsWindow::GetNativeData(NS_NATIVE_DISPLAY)

(In reply to Lee Salzman [:lsalzman] from comment #3)
> It's trying to access the xdisplay field off a null pointer because
> gdk_display_get_default is returning null. That's obviously not safe. This
> fixes that.

Most of Gecko assumes that there is a default display, because that is set up on app startup.  The exceptions are some unit tests.

How do you know the display is null?  That sounds like a different bug.

Still, this change is correct, thanks, because the default display may be a wayland display or other.

>         return nullptr;

>         break;

Feel free to remove the existing unreached break, if you like.
Attachment #8746112 - Flags: review?(karlt) → review+

Comment 6

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/28834c52d1f9
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox49: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
You need to log in before you can comment on or make changes to this bug.