# Xserver crash when opening graphical apps through X11 forwarding



## just-22 (Nov 1, 2012)

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:


```
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:


```
ForwardX11 yes
ForwardX11Trusted yes
```

Is this a video driver issue? Any hints to proceed with the debug?


----------



## Crivens (Nov 1, 2012)

Client and server are both 32/64 bit or is there a mix here?


----------



## just-22 (Nov 1, 2012)

The client is 32 bit, the server 64. Is this a problem? I guessed that the protocol was independent...


----------



## SirDice (Nov 1, 2012)

Does X work correctly on the client?


----------



## Crivens (Nov 1, 2012)

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.


----------



## SirDice (Nov 1, 2012)

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.


Except, this has nothing to do with the X protocols.


----------



## just-22 (Nov 1, 2012)

SirDice said:
			
		

> Does X work correctly on the client?



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.


----------



## just-22 (Nov 1, 2012)

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.



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 (Nov 2, 2012)

just-22 said:
			
		

> - FreeBSD 32-bit client, Linux 32-bit client: X11 forwarding works as expected.



Sorry for the typo, I meant:

- FreeBSD 32-bit client, Linux 32-bit server: X11 forwarding works as expected.


----------



## adamk (Nov 2, 2012)

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


----------



## Crivens (Nov 2, 2012)

SirDice said:
			
		

> Except, this has nothing to do with the X protocols.



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.


----------



## SirDice (Nov 2, 2012)

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.


----------



## just-22 (Nov 2, 2012)

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



Hello Adam,

I did the same guess, but the crash persist even after having recompiled the xorg-server port without AIGLX.


----------



## aragats (Jan 23, 2013)

I had all kinds of problems described in this thread, yesterday I've finally found the solution:

http://forums.freebsd.org/showthread.php?p=206229#post206229

and it looks that AIGLX has nothing to do with this, I've compiled with it.


----------



## Crivens (Jan 24, 2013)

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.



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.


----------



## aragats (Jan 28, 2013)

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


----------



## Crivens (Jan 29, 2013)

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.


----------



## aragats (Jan 30, 2013)

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?


----------



## Crivens (Jan 30, 2013)

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?



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.


----------



## StrikerASD (Feb 7, 2013)

*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.


----------



## Crivens (Feb 7, 2013)

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.


----------

