Crash in [@ _g_log_abort | g_log_writer_default]
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: gsvelto, Unassigned)
References
Details
(Keywords: crash, Whiteboard: [tbird crash])
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/c041ff74-922f-425f-aa71-50cf20200924
Top 10 frames of crashing thread:
0 libglib-2.0.so.0 _g_log_abort ../../../glib/gmessages.c:557
1 libglib-2.0.so.0 g_log_writer_default ../../../glib/gmessages.c:2694
2 libglib-2.0.so.0 g_log_structured_array ../../../glib/gmessages.c:1898
3 libglib-2.0.so.0 g_log_structured_standard ../../../glib/gmessages.c:1982
4 libgdk-3.so.0 _gdk_x11_display_error_event ../../../../../gdk/x11/gdkdisplay-x11.c:2763
5 libgdk-3.so.0 gdk_x_error ../../../../../gdk/x11/gdkmain-x11.c:269
6 libX11.so.6 _XError ./build/src/../../src/XlibInt.c:1491
7 libX11.so.6 handle_error ./build/src/../../src/xcb_io.c:199
8 libX11.so.6 handle_response ./build/src/../../src/xcb_io.c:324
9 libX11.so.6 _XEventsQueued ./build/src/../../src/xcb_io.c:344
There seems to be multiple issues lurking under this signatures besides bug 1645776. This is one, I'll file another bug for the other stack I found.
Reporter | ||
Comment 1•4 years ago
|
||
I'll also try and add more functions to our skip/ignore list so we can tell the crashes apart.
Reporter | ||
Comment 3•4 years ago
|
||
The signatures changed and they will change again soon. What's common to all these crashes is that at some point in the stack we reach XTranslateCoordinates()
and it appears that the error originates there.
Reporter | ||
Comment 4•4 years ago
|
||
This should be the last signature change, now the signature should be specific to this crash.
Reporter | ||
Updated•4 years ago
|
Comment hidden (Intermittent Failures Robot) |
Updated•3 years ago
|
Comment 6•3 years ago
|
||
In the most recent Firefox Developer Beta Releases (97.0b5), I can consistently reproduce crashes with this signature with the following steps to reproduce:
- Use Debian Bullseye in X11 with i3 window manager (in my case running on Radeon RX550/550 graphics with the standard open source drivers as provided by Debian).
- Create two Firefox windows from the same Firefox instance, in a horizontally tiled arrangement (using the i3 Window Manager).
- Have at least two tabs open in one of the window visible on the screen. This works even if the tabs are about:blank.
- Drag a tab from one open window to the second window.
- Reproducibility is not 100% - but it appears to be greater than 50% per drag, so continue to drag the tab back and forwards between the two windows until the crash occurs.
The crash occurs during the drag - before the dragged tab is dropped on its target. Debugging in the same X11 session is difficult, because hitting a breakpoint during the drag blocks the session.
From my local backtrace (which is consistent with this: https://crash-stats.mozilla.org/report/index/8aa21da7-d1af-4348-932e-d40560220120) the crash appears to be caused during nsWindow::OnMotionNotifyEvent which fires during the drag, which causes a reflow and calls nsWindow::WidgetToScreenOffset, which in turns calls through GDK to XTranslateCoordinates.
The X11 server returns a BadWindow response to XTranslateCoordinates (with error type 0, code 3, minor opcode 2, major opcode 129), which after a few stack frames leads to a SIGTRAP abort.
Comment 7•3 years ago
|
||
(In reply to Andrew Miller from comment #6)
Please test https://nightly.mozilla.org. This should have been fixed by bug 1750017. Can you confirm that this has been fixed or do you still get a crash, maybe even without "BadWindow" now?
Comment 8•3 years ago
|
||
I have attempted to reproduce this on 98.0a1(2022-01-19) using enough tab moves to consistently trigger it with 97.0b5, and have been unsuccessful.
Attempting to reproduce does not result in any console output such as about BadWindow.
I therefore think there is a high chance this bug (or at least many recent crashes matching the pattern, if not the earlier ones) is a duplicate of bug 1750017.
Comment 9•3 years ago
|
||
https://crash-stats.mozilla.org/report/index/5f6b35d5-9919-4888-bad8-85e4b0220302
Please take a look at this report. It was reproduced with firefox nightly started with GDK_SYNCHRONIZE=1 ./firefox
It seems I can reproduce the crash on https://www.rt.com/on-air/rt-player/ just by starting playback, changing quality to 360p and it crashes immediately after I click the picture-in-picture Firefox button.
ATTENTION: default value of option mesa_glthread overridden by environment.
libva info: VA-API version 1.13.0
libva info: User environment variable requested driver 'i965'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
(firefox-nightly:597293): Gdk-ERROR **: 18:30:31.063: The program 'firefox-nightly' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
(Details: serial 45682 error_code 9 request_code 154 (DRI2) minor_code 8)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
ExceptionHandler::GenerateDump cloned child 597824
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
Failed to open curl lib from binary, use libcurl.so instead
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Trace/breakpoint trap (core dumped)
libva info: VA-API version 1.13.0
libva info: User environment variable requested driver 'i965'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.13 (libva 2.12.0)
vainfo: Driver version: Intel i965 driver for Intel(R) CherryView - 2.4.1
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Simple : VAEntrypointEncSlice
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264MultiviewHigh : VAEntrypointVLD
VAProfileH264StereoHigh : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointEncPicture
VAProfileVP8Version0_3 : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointVLD
Comment 10•1 year ago
|
||
Setting to S2 as this appears to be relatively high volume.
Updated•1 year ago
|
Comment 11•1 year ago
|
||
Since the crash volume is low (less than 15 per week), the severity is downgraded to S3
. Feel free to change it back if you think the bug is still critical.
For more information, please visit BugBot documentation.
Description
•