Need help understanding X server freeze

[jeetu.golani at gmail.com]

Hi everyone,

Just thought I would write a quick update on this issue and moreover a
thank you to all the people who have been helping me resolve this.

As it currently stands, while I have not managed to resolve this, I
strongly believe this does not have much to do with the X server and
related technologies but is most likely due to my code causing a
locking of threads. I have been discussing this with the Retroshare
team and the way it looks it's probably an issue with my tunnel code
and possibly some other RS components. More once I actually do figure
this out :)

Thank you though all of you for sharing your thoughts and your time in
helping me :)

Regards,
Jeetu





On Thu, Oct 6, 2016 at 11:53 PM, jeetu.golani at gmail.com
<jeetu.golani at gmail.com> wrote:
> Hi again,
>
> Felix, Thomas and Ilya, thank you so much for the suggestions.
>
>>Try a substantially different environment, one without GDM, and as little of >GTK as possible (QT-based, unlike XFCE4), e.g. TDE:
>>https://wiki.trinitydesktop.org/DebianInstall
>
> I see that they don't have stable packages for Stretch / Sid as of
> now. Will probably try the preliminary packages for the next release
> and see how it goes.
>
> Was thinking of putting on KDE, but that's quite huge.
>
>
>>Only more wild guesses, maybe input/event handling?
>>GTK_IM_MODULE=xim GDK_CORE_DEVICE_EVENTS=1 gedit
>>
>>You could also export GTK_DEBUG and GDK_DEBUG, see
>>https://developer.gnome.org/gtk3/3.8/gtk-running.html
>
> Will definitely be interesting to see the results of these environment
> variables.
>
>>You  could  try to use wireshark and/or tcpdump to dump and ana-
>>lyze what's going on on the connection on the ssh  server   side.
>>In  fact,     DISPLAY     localhost:10.0     points     to    ad-
>>dress/port 127.0.0.1:6010 , which could be easily captured.
>
> This will definitely be interesting.....this will surely give a wealth
> of information, hope it's something we can interpret and use to
> pinpoint the problem. I will probably try this once am done trying the
> above two tests.
>
> Thank you again :)....been in the dark for so long, now it feels like
> we will finally get to the bottom of this :)
>
> Will report back soon :)
>
> Bye for now
>
>
>
>
> On Thu, Oct 6, 2016 at 1:38 PM, Ilya Anfimov <ilan at tzirechnoy.com> wrote:
>> On Mon, Oct 03, 2016 at 11:22:36PM +0530, jeetu.golani at gmail.com wrote:
>>> Hi everyone,
>>>
>>> First, I am a big fan of the remote display capabilities of X, thank
>>> you very much to all who have worked on this project over the years.
>>>
>>
>>  You  could  try to use wireshark and/or tcpdump to dump and ana-
>> lyze what's going on on the connection on the ssh  server   side.
>> In  fact,     DISPLAY     localhost:10.0     points     to    ad-
>> dress/port 127.0.0.1:6010 , which could be easily captured.
>>
>>  Also, the Debian distribution  contains  debugging  symbols  for
>> xorg  X  server and most of it's drivers. Analyzing the internals
>> of X server with gdb is really easy when using them.
>>
>>  Just beware, that gdb stops process it attach to -- therefore it
>> is  not  reasonably  to do that from client of that X server (or,
>> sometimes it is, when all is done by some script, but you  should
>> have a reasonable way to quit gdb).
>>
>> _______________________________________________
>> xorg at lists.x.org: X.Org support
>> Archives: http://lists.freedesktop.org/archives/xorg
>> Info: https://lists.x.org/mailman/listinfo/xorg
>> Your subscription address: %(user_address)s