Bug 214856

Summary: www/firefox in jail intermittently crashed with BadRequest X error
Product: Ports & Packages Reporter: freebsd
Component: Individual Port(s)Assignee: freebsd-gecko mailing list <gecko>
Status: New ---    
Severity: Affects Some People CC: x11
Priority: ---    
Version: Latest   
Hardware: amd64   
OS: Any   

Description freebsd 2016-11-26 19:46:39 UTC
Running firefox in a jail on 11.0 via the jailme utility. Since the update to firefox 50 every now and then I get sudden crashes with this error message in the shell:

(firefox:18057): Gdk-WARNING **: The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 9248927 error_code 1 request_code 216 (unknown) minor_code 0)
  (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.)

I might try the ESR version to see if this is really related to version 50.
Comment 1 Jan Beich freebsd_committer 2016-11-27 21:55:05 UTC
From x11@ side:
- What's the version of host kernel?
- What DDX driver and its version?
- What are the versions for Mesa packages?
- Do you pass -m allow.sysvipc=1 to jail(8) ?

From gecko@ side:
- Can you reliably reproduce?
- What's the last event before the crash?
- Do you use freebsd.org package or build yourself?
- Can you post Graphics section and "Multiprocess Windows" from about:support?
Comment 2 freebsd 2016-11-28 00:25:06 UTC
Well great, something like it just happened when I was just about to click Save Changes... The browser windows just stopped responding, with some strange "clipping error" in a small part of one window. But the browser windows themselves still got redrawn properly when moving other windows on top of them. Not sure if this has something to do with this bug though.

- What's the version of host kernel?
11.0p3 with VIMAGE compiled in. But a on a stock 11.0 p(1?) kernel I had the same issue alrady.

- What DDX driver and its version?
Google tells me DDX has something to do with DRI, so pkg info | grep dri:
dri-11.2.2,2
dri2proto-2.8
linux-c6-dri-11.0.7_3
nvidia-driver-367.44_2

- What are the versions for Mesa packages?
pkg info | grep mesa
libglapi-11.2.2
linux-c6-dri-11.0.7_3
mesa-demos-8.3.0


- Do you pass -m allow.sysvipc=1 to jail(8) ?
No, wasn't necessary so far.

From gecko@ side:
- Can you reliably reproduce?
- What's the last event before the crash?
Hard to say. Firefox seemingly needs to be running for tens of hours before this happens. At first I though JS heavy sites or HTML5 video might be the culprit, but those are not always present. It seems I can basically do anything before such a crash.

- Do you use freebsd.org package or build yourself?
Original packages.

- Can you post Graphics section and "Multiprocess Windows" from about:support?
Graphics
Features
Compositing	Basic
Asynchronous Pan/Zoom	none
WebGL Renderer	WebGL creation failed: * Refused to create native OpenGL context because of blacklist entry: * Exhausted GL driver options.
WebGL2 Renderer	(no info)
Hardware H264 Decoding	No
Audio Backend	alsa
GPU #1
Active	Yes
Description	GLXtest process failed (exited with status 1): X error occurred in GLX probe, error_code=2, request_code=153, minor_code=3
Diagnostics
AzureCanvasAccelerated	0
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
CairoUseXRender	0
Decision Log
HW_COMPOSITING	
blocked by default: Acceleration blocked by platform
OPENGL_COMPOSITING	
unavailable by default: Hardware compositing is disabled

Multiprocess Windows 	0/2 (Disabled)
Comment 3 freebsd 2016-12-03 02:34:55 UTC
Just experienced several crashes within minutes under high load. I compiled firefox-esr and had a HTML5 video running, that seemed to trigger the error every few minutes. Just compiling, but not running the video seemed to stabilise it a bit.
btw: the serial, error_code, and request_code numbers always change, but the minor_code stays 0.
Comment 4 freebsd 2016-12-03 13:00:48 UTC
firefox-esr exhibits the same bug, just different error msg:

[26858] ###!!! ABORT: Request 196.0: BadRequest (invalid request code or no such operation); 33 requests ago: file /usr/ports/www/firefox-esr/work/firefox-45.5.1esr/toolkit/xre/nsX11ErrorHandler.cpp, line 157
[26858] ###!!! ABORT: Request 196.0: BadRequest (invalid request code or no such operation); 33 requests ago: file /usr/ports/www/firefox-esr/work/firefox-45.5.1esr/toolkit/xre/nsX11ErrorHandler.cpp, line 157
Comment 5 freebsd 2016-12-22 22:12:34 UTC
Update: Running firefox heavy duty for over a week after moving the .mozilla dir from the jail to my $HOME on the host, so this seems to be VNET or even general jail related. I'll test out a non-VNET jail until the end of year to cover more ground.
Comment 6 freebsd 2017-01-07 18:26:25 UTC
Running in a non-VNET jail for quite some time now, seems stable enough. Minor things like sometimes HTML5 video just stopping to work, but no sudden crashes. So this seems VNET-related. Should this go to the jail mailing list as well?
Comment 7 freebsd 2017-02-03 22:28:46 UTC
Update:
since a few days ago, every now and then I now get another error:

(firefox:93986): Gdk-WARNING **: The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'RenderBadPicture (invalid Picture parameter)'.
  (Details: serial 28746 error_code 141 request_code 138 (RENDER) minor_code 7)
  (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.)

Firefox is still running in a non-VNET jail, has been stable until this started happening. Firefox on host seems to run fine by comparison.
Comment 8 freebsd 2017-02-16 15:55:46 UTC
Hello? Anyone there?
So, firefox in a jail is almost unusable at this point. Is no one else seeing this? Or is seriously no one else using firefox in a jail?

I get repeated crashes when I load a site with javascript disabled, then enabling it with uMatrix. After reloading the site, firefox crashes. Sometimes immediately, sometimes after a few seconds where I could scroll on the page.

If this could be a bug in VNET code in the kernel, and I'm willing to do some work to get you all the information you need to debug this, but someone needs to talk me through it!