Segfault when starting blender #48700

Closed
opened 2016-06-21 18:14:18 +02:00 by Stephane Mutz · 15 comments

System Information
Linux Mint 17.3 VM (KVM) running on Dell R610 server with remote X connection (X2go)

Blender Version
Broken: latest git tree as of 2016-06-21
Worked: (optional)

Short description of error
Blender crashes with an Xerror:
Received X11 Error:
error code: 1
request code: 147
minor code: 34
error text: BadRequest (invalid request code or no such operation)
Segmentation fault
Thhis happens before the splash screen (or has it is being drawns)

Exact steps for others to reproduce the error
Compile blender from the git tree as described in the wiki for Ubuntu distribution
on a Linux Mint 17.3 VM. Run blender over x2go connection.

**System Information** Linux Mint 17.3 VM (KVM) running on Dell R610 server with remote X connection (X2go) **Blender Version** Broken: latest git tree as of 2016-06-21 Worked: (optional) **Short description of error** Blender crashes with an Xerror: Received X11 Error: error code: 1 request code: 147 minor code: 34 error text: BadRequest (invalid request code or no such operation) Segmentation fault Thhis happens before the splash screen (or has it is being drawns) **Exact steps for others to reproduce the error** Compile blender from the git tree as described in the wiki for Ubuntu distribution on a Linux Mint 17.3 VM. Run blender over x2go connection.
Author

Changed status to: 'Open'

Changed status to: 'Open'
Author

Added subscriber: @smutz

Added subscriber: @smutz

Added subscriber: @NikoLeopold

Added subscriber: @NikoLeopold

147 should be about GLX (OpenGL Extension to the X Window System).
What version of OpenGL / GLX does your system implement? Check via glxinfo | grep -i version.
Could be that your client requires a more recent version not compatible with what X2Go supports: It seems that X2Go is based on nxagent which supports GLX only up to 1.2.
http://wiki.x2go.org/doku.php/doc:de-compat
It also says that Cinnamon 2.2 (Linux Mint 17) is not compatible and reverts to fallback mode.

Maybe that could be the reason?

147 should be about GLX (OpenGL Extension to the X Window System). What version of OpenGL / GLX does your system implement? Check via `glxinfo | grep -i version`. Could be that your client requires a more recent version not compatible with what X2Go supports: It seems that X2Go is based on nxagent which supports GLX only up to 1.2. http://wiki.x2go.org/doku.php/doc:de-compat It also says that Cinnamon 2.2 (Linux Mint 17) is not compatible and reverts to fallback mode. Maybe that could be the reason?
Author

A GLX related issue would not be surprising indeed. This is the glxinfo results:
server glx version string: 1.2
client glx version string: 1.4
GLX version: 1.2
OpenGL version string: 2.1 Mesa 10.1.3
OpenGL shading language version string: 1.30

Is there a compatibilty issue?

A GLX related issue would not be surprising indeed. This is the glxinfo results: server glx version string: 1.2 client glx version string: 1.4 GLX version: 1.2 OpenGL version string: 2.1 Mesa 10.1.3 OpenGL shading language version string: 1.30 Is there a compatibilty issue?

Since X2Go only supports GLX until 1.2 and your client has 1.4 that could be it.
Did you try any other OpenGL apps?

Since X2Go only supports GLX until 1.2 and your client has 1.4 that could be it. Did you try any other OpenGL apps?
Author

CAD tools using OpenGL we use are working fine. So does glxgears.

CAD tools using OpenGL we use are working fine. So does glxgears.

Only thing i can guess is that Blender needs some specific functions related to GLX >1.2 and then crashes.
Found this possible workaround but haven't looked into it: http://wiki.x2go.org/doku.php/wiki:development:glx-xlib-workaround

Only thing i can guess is that Blender needs some specific functions related to GLX >1.2 and then crashes. Found this possible workaround but haven't looked into it: http://wiki.x2go.org/doku.php/wiki:development:glx-xlib-workaround

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'

This issue was referenced by e783fddc01

This issue was referenced by e783fddc0167eeb58bd69ed08ff31d0746772ad6

Added subscriber: @ideasman42

Added subscriber: @ideasman42

We now depend on OpenGL2.1,
If GLX fails to initialize, its unlikely we can work-around this (unless its a mistake or so).
However since this is remote desktop software, its likely a limit in its GLX support.
So for now just avoid crash and fail gracefully.

We now depend on OpenGL2.1, If GLX fails to initialize, its unlikely we can work-around this (unless its a mistake or so). However since this is remote desktop software, its likely a limit in its GLX support. So for now just avoid crash and fail gracefully.
Author

Ok, that's clear. Remote desktops are often limited in which version of OpenGL is supported. We use it extensively to share more powerful servers so it would have been convenient. Anyway, a graceful failure is preferable to a crash. Thank you for the very reactive feedback.

Ok, that's clear. Remote desktops are often limited in which version of OpenGL is supported. We use it extensively to share more powerful servers so it would have been convenient. Anyway, a graceful failure is preferable to a crash. Thank you for the very reactive feedback.

Note that in cases like this it can work to use software-gl

Run blender-softwaregl or set LIBGL_ALWAYS_SOFTWARE,

Of course software gl may be unusably slow. YMMV.

Note that in cases like this it can work to use software-gl Run blender-softwaregl or set LIBGL_ALWAYS_SOFTWARE, Of course software gl may be unusably slow. YMMV.
Author

I tested the latest tree this morning. The segfault is gone but I get only a window frame and the executable remains stuck in this state with the Xerror reported in the shell. So in short, no more crash but no graceful exit either.
I tried the sotftwaregl option (both through the var and the command line option) and the result is the same. glxinfo outputs the same openGL version info. I believe this is due to x2go and I will check on this side what limits the openGL version supported in software rendering.
The speed would not be a major concern as I intend to explore how I could use Blender for radio wave propagation simulations in relatively simple geometries (by modifying the renderer). My fallback is to switch to a local VM and see if I can make it work there.

I tested the latest tree this morning. The segfault is gone but I get only a window frame and the executable remains stuck in this state with the Xerror reported in the shell. So in short, no more crash but no graceful exit either. I tried the sotftwaregl option (both through the var and the command line option) and the result is the same. glxinfo outputs the same openGL version info. I believe this is due to x2go and I will check on this side what limits the openGL version supported in software rendering. The speed would not be a major concern as I intend to explore how I could use Blender for radio wave propagation simulations in relatively simple geometries (by modifying the renderer). My fallback is to switch to a local VM and see if I can make it work there.
Sign in to join this conversation.
4 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: blender/blender#48700
No description provided.