Xserver crash when opening graphical apps through X11 forwarding

J

just-22

Hello,

I'm experiencing systematic crashes when I try to open a graphical app through ssh forwarding; these are the last lines in /var/log/Xorg.0.log:

Code: 
Segmentation fault: 11 at address 0x10

Fatal server error:
Caught signal 11 (Segmentation fault: 11). Server aborting


Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

(II) UnloadModule: "mouse"
(II) UnloadModule: "kbd"
(II) intel(0): xf86UnbindGARTMemory: unbind key 65
(II) intel(0): xf86UnbindGARTMemory: unbind key 66
(II) intel(0): xf86UnbindGARTMemory: unbind key 67
(II) intel(0): xf86UnbindGARTMemory: unbind key 68
(II) intel(0): xf86UnbindGARTMemory: unbind key 69
(II) intel(0): xf86UnbindGARTMemory: unbind key 70
(II) intel(0): xf86UnbindGARTMemory: unbind key 71
(WW) intel(0): drmDropMaster failed: Unknown error: -1

This happens with any graphical apps (I tried gvim, ristretto and a few others).

The relevant part of my /etc/ssh/ssh_config is:

Code: 
ForwardX11 yes
ForwardX11Trusted yes

Is this a video driver issue? Any hints to proceed with the debug?
 
Client and server are both 32/64 bit or is there a mix here?
 
The client is 32 bit, the server 64. Is this a problem? I guessed that the protocol was independent...
 
I have problems when I start a graphical app in a 32 bit wine on 64 bit FreeBSD - so yes, this can be a problem.
 
Crivens said:
I have problems when I start a graphical app in a 32 bit wine on 64 bit FreeBSD - so yes, this can be a problem.
Click to expand...
Except, this has nothing to do with the X protocols.
 
SirDice said:
Does X work correctly on the client?
Click to expand...

Yes, X (apparently) works fine on the client. I'm saying "apparently" because I didn't observe any malfunction so far, except the reported one.
 
Crivens said:
I have problems when I start a graphical app in a 32 bit wine on 64 bit FreeBSD - so yes, this can be a problem.
Click to expand...

Well, some more debugging here:

- FreeBSD 32-bit client, Linux 64-bit server: Xserver crashes;
- FreeBSD 32-bit client, Linux 32-bit client: X11 forwarding works as expected.

I cannot try with a Linux 32-bit client and a Linux 64-bit server at the moment, but I never observed any strange behavior in the past, so this seems FreeBSD related...

Any idea?
 
just-22 said:
- FreeBSD 32-bit client, Linux 32-bit client: X11 forwarding works as expected.
Click to expand...

Sorry for the typo, I meant:

- FreeBSD 32-bit client, Linux 32-bit server: X11 forwarding works as expected.
 
Just a guess, but the graphical application is linked to libGL, which is causing AIGLX to kick in on the X server. Does the crash happen if AIGLX is disabled?

Adam
 
SirDice said:
Except, this has nothing to do with the X protocols.
Click to expand...

I'm not sure where the direct rendering is located in that stack but it happens there.
After tracking it down to the DRM, I got the impression that somewhere in there seems dependencies on "sizeof(void*)" or something else which changes the data stream layout to something incompatible on different pointersizes.
 
As far as I know the 32 bit application on 64 bit (like wine) is an API/ABI issue. It's a 32 bit application that tries to access a 32 bit ABI that doesn't exist.

This however has nothing to do with the client-server protocol of X. Which, to the best of my knowledge, does not depend on the buswidth of either client or server.
 
adamk said:
Just a guess, but the graphical application is linked to libGL, which is causing AIGLX to kick in on the X server. Does the crash happen if AIGLX is disabled?

Adam
Click to expand...

Hello Adam,

I did the same guess, but the crash persist even after having recompiled the xorg-server port without AIGLX.
 
SirDice said:
As far as I know the 32 bit application on 64 bit (like wine) is an API/ABI issue. It's a 32 bit application that tries to access a 32 bit ABI that doesn't exist.

This however has nothing to do with the client-server protocol of X. Which, to the best of my knowledge, does not depend on the buswidth of either client or server.
Click to expand...

I had core dumps from Xorg where the backtrace showed that the DRM called yyerror(), which in turn then brought everything down. This seems to be related to a parser generated by yacc/bison, which I suppose is to parse the rendering command stream. Now if the data sizes differ, the parser looses sync and quits. That is where I quit the analysis, but the most likely reason for the rendering commands to be malformed in this case is different sizes of basic types, and a protocol which does not abstract this.
 
I've found, that when I switch to vesa driver* the remote applications (with both x11 forwarding and using the remote display) run fine.

So suspecting the intel driver I've compiled intel29 - and it works! No crash with x11 forwarding and wine applications (32/64). However some time ago I rememeber reading that using intel29 is discouraged, couldn't find exactly why.

* with default mode 16 bit, othewrwise the screen is garbled with 1440x900
 
The question now is - do you still have acceleration? When the trouble is in the DRM part, switching to a driver which does not have any would certainly solve the problem, at the price of slow graphics.
 
A simple test with glxgears shows an fps drop from ~59 to ~38 (with intel29)...

By the way, why the intel29 wouldn't provide acceleration?
 
aragats said:
A simple test with glxgears shows an fps drop from ~59 to ~38 (with intel29)...

By the way, why the intel29 wouldn't provide acceleration?
Click to expand...

OpenGL and other types of acceleration need to use DRI/DRM to access the screen memory. If that is not supported, OpenGL falls back to software rasterizers and movement of windows may be seriously slower.
 
What about multilib?

Why does freebsd not have a multilib in base system? It will be a good idea to create such compatibility on 64-bit system.
 
If you mean with multilib that you have both 32 and 64 bit libraries, that is already the case. The problem is that the DRM/DRI is not a library but part of a driver, it can not be present twice in the system.
 
You must log in or register to reply here.
Back
Top