Need help understanding X server freeze

[jeetu.golani at gmail.com]

Hi Thomas,

I had the opportunity to run more tests based on your suggestion. The
following are my findings :

-

LIBGL_ALWAYS_INDIRECT=1
LIBGL_ALWAYS_SOFTWARE=1
LIBGL_DRI3_DISABLE=1

These environment variables do not seem to have made any difference. I
was still getting the desktop freeze with these set.

(However, thank you for pointing me in this direction. Didn't know of
these and it's definitely something I can use in the future :) )

- I tried uxa acceleration, both standalone, and also in combination
with the above variables. Again no difference with regards the desktop
freeze.

- However, with uxa acceleration and the environment variables set, I
got the following error when I tried gnome-calculator :

(gnome-calculator:2931): Gdk-ERROR **: The program 'gnome-calculator'
received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAccess (attempt to access private resource denied)'.
  (Details: serial 171 error_code 10 request_code 130 (MIT-SHM) minor_code 1)
  (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.)
Trace/breakpoint trap

- gedit worked well in the above setting and it is my impression
(maybe just perception) that I could use it for a bit longer, though
eventually it failed with a desktop freeze.

- This time I saw the following error in my dmesg at the desktop end :

gnome-session-f[26955]: segfault at 0 ip 00007fd8c3587299 sp
00007fff64f47280 error 4 in libgtk-3.so.0.2200.1[7fd8c32a5000+6f7000]


- Now, considering the above mention of gtk and your observation that
it could be a gtk3 related issue, I tried out a non-gtk application -
the Chromium browser.

- Et Voila , it worked absolutely fine. Though it is a far heavied
application and I spent a lot of time surfing within it (Slashdot and
arstechnica at that :) ).....no hiccups at al.

- I then turned off uxa acceleration i.e. just the intel driver and
again tried Chromium, no issues at all once again :)



So, I don't know what to make of all of the above as yet, though the
following surmise what we are seeing :


- Gtk3 based applications seem to be causing a desktop freeze when SSH
X forwarded through my tunnel.

- Non-GTK applications or at least Chromium work perfectly.

- Gtk3 applications such as gnome-calculator and gedit seem to work
fine if forwarded to a Xephyr X server and also within Virtualbox.

- These applications also work when not using my tunnel and just plain
SSH X forwarding over LAN (since my tunnel works over the internet
rather than LAN, could the latency be a factor in triggering this
behaviour?).


Can you think of something else we can try so we can further pinpoint
where the problem lies or any thoughts at all on the above?


Once again, thank you one and all for taking the time to help me with
this. I truly appreciate it :)

Bye for now


On Wed, Oct 5, 2016 at 2:53 AM, Thomas Lübking <thomas.luebking at gmx.de> wrote:
> On Wed, Oct 05, 2016 at 12:38:52AM +0530, jeetu.golani at gmail.com wrote:
>>
>> Hi Thomas,
>>
>> Thank you for replying. I truly am at wits end here and appreciate any
>> help.
>>
>>> Can you calso cause this with something >simple as "xterm" (ie, running
>>> gnome terminal under xfce likely won't >help much)
>>
>>
>> If I X forward something simple like xterm over my Retroshare tunnel via
>> SSH, it works perfectly without any hiccups. Even if I try to run say a du
>> on / just to generate a lot of scrolling traffic.
>>
>> It's only when I run something like gnome-calculator or gedit that the
>> whole desktop hags up at some point down the line usually when I have
>> pressed a button or tried to trigger a menu or dialog box.
>
>
> Ie. gtk3 issue (so far), maybe GL?
> LIBGL_ALWAYS_INDIRECT=1 LIBGL_ALWAYS_SOFTWARE=1 LIBGL_DRI3_DISABLE=1 gedit
>
> If this works, I'd suspect LIBGL_ALWAYS_SOFTWARE to be the key.
>
> Cheers,
> Thomas