TBrowser destroys my Graphical Environment (Linux/Gnome)

kgizdov · February 9, 2016, 3:16pm

Hi,

I’m having the strangest issue. After I run TBrowser to view a file, my GUI hangs completely. It affects all other windows and in some cases catastrophically. For example, I’m not able to use any of the installed web browsers - Chome & Firefox cannot function after TBrowser is run. This continues even after TBrowser is closed and is only rectified with restart. What’s even more strange is GUI programs start fine, but they are unresponsive after they load. However, I can still click ‘X’ and exit them without any errors.

I’m running this on a HiDPI screen (Dell XPS13), Arch Linux, Gnome UI and ROOT 6.06/00. ROOT runs fine in the terminal or when I compile code. I’m not sure why TBrowser is an exception. Not sure if it matters, but I should also mention that TBrowser itself is very slow when going through files and the interface does not scale with the HiDPI screen - the buttons/text are all very tiny.

Does anyone have an idea what exactly could be causing this and how can I work around it? Is TBrowser interfering/tampering with GTK or something? I’m not sure how to test it.

Thanks for the help!

bellenot · February 10, 2016, 8:34am

Hi,

No idea what could be the problem. What is your screen resolution? Does it happens also with a TCanvas?
Is the TBrowser using any other plugin than a TCanvas and a text editor (the default option)?
And FYI, the Root GUI is only using X11 (Xlib), and no Gnome/GTK…

Cheers, Bertrand.

kgizdov · February 11, 2016, 1:47pm

Screen resolution is 3200x1800 with x2 scaling - effectively 1600x900 in properly scaling applications. For what I want TBrowser is loaded with the defaults. I tried recompiling with a few different options and it turns out disabling the new GCC ABI improves performance a bit. However, it’s still pretty laggy. The good thing is it does not seem to be crashing other windows anymore.

I’m worried about a memory leak of some sort or some other weird exception as ROOT does not seem to have been designed with HiDPI screens in mind. The same installation works fine on a smaller resolution virtual machine - again Arch with Gnome. This leads me to believe it’s definitely resolution related. Unfortunately, I am not sure on how to proceed to debug and improve performance further. Any help is much appreciated.

Thanks.

couet · February 11, 2016, 2:15pm

I am now looking at TGX11 to try to display correctly on High Def Screen. A user reported a very small TBrowser. I saw it … yes it is small… But no crash… I am now trying to adjust the size taking car of the #dpi.

kgizdov · March 17, 2016, 1:11pm

Latest version made it worse. TBrowser with ROOT (6.06/02) crashes X server completely every time. I am sure Valgrind will reveal the problem, but unfortunately I cannot run it since my GUI gets destroyed. For troubleshooting notes, I have tried compiling in several ways:
[ul]
- as described on the docs page
- this way from the Arch AUR packages
- this way from a customised package
- a bunch of other ways I tried on my own (disabling the new ABI, using old GCC, old LLVM, C++11/C++14, etc)
[/ul]
but nothing works
I hope this can be corrected, as I am not stuck to using X Forwarding from LXPLUS.

couet · March 21, 2016, 2:14pm

Do you have a traceback of the crash ?

kgizdov · May 6, 2016, 12:16pm

Hi,

Sorry for the late response.

Since my last post, GNOME and X have both been updated. Also ROOT has moved to GSL-2.0, however my issue still persists.

What is somehow an improvement is that I cannot reproduce a system wide crash anymore, only some apps suffer. But I can still confirm some form of X memory bug/pollution, as all X dependent apps continue to misbehave after TBrowser launch, which can only be rectified by X restart. This is confirmed by the fact that if I start GNOME in Wayland, I do not experience those issues - I presume since the GUIs are now dependent on Wayland to render them, X pollution would not affect them. This (included below) is the latest debug info I have and there are some X Server calls that seem to be inconsistent. Still the X Server call errors are present in both cases with GNOME on X and Wayland - as expected ROOT spawns X to display TBrowser, but since in Wayland applications are guaranteed memory isolation, TBrowser cannot pollute. Please have a look:

GNOME on Wayland:

valgrind --leak-check=full --track-origins=yes root
==3274== Memcheck, a memory error detector
==3274== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==3274== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==3274== Command: root
==3274== 
==3274== Syscall param writev(vector[...]) points to uninitialised byte(s)
==3274==    at 0x5E31310: __writev_nocancel (in /usr/lib/libc-2.23.so)
==3274==    by 0x60FCDA8: ??? (in /usr/lib/libxcb.so.1.1.0)
==3274==    by 0x60FD19C: ??? (in /usr/lib/libxcb.so.1.1.0)
==3274==    by 0x60FD224: xcb_writev (in /usr/lib/libxcb.so.1.1.0)
==3274==    by 0x4E7818D: _XSend (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x4E6D50C: XPutImage (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x538F465: xpmCreatePixmapFromImage (in /usr/lib/libXpm.so.4.11.0)
==3274==    by 0x538FDA4: XpmReadFileToPixmap (in /usr/lib/libXpm.so.4.11.0)
==3274==    by 0x403C48: ROOT::ROOTX::LoadROOTSplashscreenPixmap(char const*, bool) (in /usr/bin/root)
==3274==    by 0x403A8C: ROOT::ROOTX::CreateSplashscreenImageAndShapeMask() (in /usr/bin/root)
==3274==    by 0x404BC6: PopupLogo(bool) (in /usr/bin/root)
==3274==    by 0x403499: main (in /usr/bin/root)
==3274==  Address 0x6d9620a is 74 bytes inside a block of size 32,148 alloc'd
==3274==    at 0x4C2ABD0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3274==    by 0x4E7AB90: _XAllocScratch (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x4E6CC5F: ??? (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x4E6D50C: XPutImage (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x538F465: xpmCreatePixmapFromImage (in /usr/lib/libXpm.so.4.11.0)
==3274==    by 0x538FDA4: XpmReadFileToPixmap (in /usr/lib/libXpm.so.4.11.0)
==3274==    by 0x403C48: ROOT::ROOTX::LoadROOTSplashscreenPixmap(char const*, bool) (in /usr/bin/root)
==3274==    by 0x403A8C: ROOT::ROOTX::CreateSplashscreenImageAndShapeMask() (in /usr/bin/root)
==3274==    by 0x404BC6: PopupLogo(bool) (in /usr/bin/root)
==3274==    by 0x403499: main (in /usr/bin/root)
==3274==  Uninitialised value was created by a heap allocation
==3274==    at 0x4C2ABD0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3274==    by 0x53909C7: ??? (in /usr/lib/libXpm.so.4.11.0)
==3274==    by 0x5393C43: xpmParseDataAndCreate (in /usr/lib/libXpm.so.4.11.0)
==3274==    by 0x538FBC2: XpmReadFileToImage (in /usr/lib/libXpm.so.4.11.0)
==3274==    by 0x538FD5F: XpmReadFileToPixmap (in /usr/lib/libXpm.so.4.11.0)
==3274==    by 0x403C48: ROOT::ROOTX::LoadROOTSplashscreenPixmap(char const*, bool) (in /usr/bin/root)
==3274==    by 0x403A8C: ROOT::ROOTX::CreateSplashscreenImageAndShapeMask() (in /usr/bin/root)
==3274==    by 0x404BC6: PopupLogo(bool) (in /usr/bin/root)
==3274==    by 0x403499: main (in /usr/bin/root)
==3274== 
   ----------------------------------------------------------------
  | Welcome to ROOT 6.06/02                    http://root.cern.ch |
  |                                   (c) 1995-2014, The ROOT Team |
  | Built for linuxx8664gcc                                        |
  | From heads/master@v6-07-02-437-gb06340c, Mar 02 2016, 19:01:57 |
  | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q'     |
   ----------------------------------------------------------------

root [0] TBrowser a
(TBrowser &) Name: Browser Title: ROOT Object Browser
root [1] (TFile *) 0x3555ac0
(TFile *) 0x3919080

root [1] .q
==3274== 
==3274== HEAP SUMMARY:
==3274==     in use at exit: 101,574 bytes in 300 blocks
==3274==   total heap usage: 2,146 allocs, 1,846 frees, 1,398,733 bytes allocated
==3274== 
==3274== 192 (16 direct, 176 indirect) bytes in 1 blocks are definitely lost in loss record 33 of 45
==3274==    at 0x4C2CB1D: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3274==    by 0x4E8AE40: ??? (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x4E8B3B3: ??? (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x4E8CC9E: ??? (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x4E8D4AB: _XlcCreateLC (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x4EAA8AF: _XlcDefaultLoader (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x4E94D3D: _XOpenLC (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x4E94F4A: _XrmInitParseInfo (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x4E7C96F: ??? (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x4E7FF4D: XrmGetStringDatabase (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x4E5CA63: ??? (in /usr/lib/libX11.so.6.3.0)
==3274==    by 0x4E5CC8D: XGetDefault (in /usr/lib/libX11.so.6.3.0)
==3274== 
==3274== LEAK SUMMARY:
==3274==    definitely lost: 16 bytes in 1 blocks
==3274==    indirectly lost: 176 bytes in 4 blocks
==3274==      possibly lost: 0 bytes in 0 blocks
==3274==    still reachable: 101,382 bytes in 295 blocks
==3274==         suppressed: 0 bytes in 0 blocks
==3274== Reachable blocks (those to which a pointer was found) are not shown.
==3274== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==3274== 
==3274== For counts of detected and suppressed errors, rerun with: -v
==3274== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

GNOME on X:

# valgrind --leak-check=full --track-origins=yes root
==21965== Memcheck, a memory error detector
==21965== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==21965== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==21965== Command: root
==21965== 
==21965== Syscall param writev(vector[...]) points to uninitialised byte(s)
==21965==    at 0x5E31310: __writev_nocancel (in /usr/lib/libc-2.23.so)
==21965==    by 0x60FCDA8: ??? (in /usr/lib/libxcb.so.1.1.0)
==21965==    by 0x60FD19C: ??? (in /usr/lib/libxcb.so.1.1.0)
==21965==    by 0x60FD224: xcb_writev (in /usr/lib/libxcb.so.1.1.0)
==21965==    by 0x4E7818D: _XSend (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x4E6D50C: XPutImage (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x538F465: xpmCreatePixmapFromImage (in /usr/lib/libXpm.so.4.11.0)
==21965==    by 0x538FDA4: XpmReadFileToPixmap (in /usr/lib/libXpm.so.4.11.0)
==21965==    by 0x403C48: ROOT::ROOTX::LoadROOTSplashscreenPixmap(char const*, bool) (in /usr/bin/root)
==21965==    by 0x403A8C: ROOT::ROOTX::CreateSplashscreenImageAndShapeMask() (in /usr/bin/root)
==21965==    by 0x404BC6: PopupLogo(bool) (in /usr/bin/root)
==21965==    by 0x403499: main (in /usr/bin/root)
==21965==  Address 0x6d9214a is 74 bytes inside a block of size 32,148 alloc'd
==21965==    at 0x4C2ABD0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21965==    by 0x4E7AB90: _XAllocScratch (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x4E6CC5F: ??? (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x4E6D50C: XPutImage (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x538F465: xpmCreatePixmapFromImage (in /usr/lib/libXpm.so.4.11.0)
==21965==    by 0x538FDA4: XpmReadFileToPixmap (in /usr/lib/libXpm.so.4.11.0)
==21965==    by 0x403C48: ROOT::ROOTX::LoadROOTSplashscreenPixmap(char const*, bool) (in /usr/bin/root)
==21965==    by 0x403A8C: ROOT::ROOTX::CreateSplashscreenImageAndShapeMask() (in /usr/bin/root)
==21965==    by 0x404BC6: PopupLogo(bool) (in /usr/bin/root)
==21965==    by 0x403499: main (in /usr/bin/root)
==21965==  Uninitialised value was created by a heap allocation
==21965==    at 0x4C2ABD0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21965==    by 0x53909C7: ??? (in /usr/lib/libXpm.so.4.11.0)
==21965==    by 0x5393C43: xpmParseDataAndCreate (in /usr/lib/libXpm.so.4.11.0)
==21965==    by 0x538FBC2: XpmReadFileToImage (in /usr/lib/libXpm.so.4.11.0)
==21965==    by 0x538FD5F: XpmReadFileToPixmap (in /usr/lib/libXpm.so.4.11.0)
==21965==    by 0x403C48: ROOT::ROOTX::LoadROOTSplashscreenPixmap(char const*, bool) (in /usr/bin/root)
==21965==    by 0x403A8C: ROOT::ROOTX::CreateSplashscreenImageAndShapeMask() (in /usr/bin/root)
==21965==    by 0x404BC6: PopupLogo(bool) (in /usr/bin/root)
==21965==    by 0x403499: main (in /usr/bin/root)
==21965== 
   ----------------------------------------------------------------
  | Welcome to ROOT 6.06/02                    http://root.cern.ch |
  |                                   (c) 1995-2014, The ROOT Team |
  | Built for linuxx8664gcc                                        |
  | From heads/master@v6-07-02-437-gb06340c, Mar 02 2016, 19:01:57 |
  | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q'     |
   ----------------------------------------------------------------

root [0] TBrowser a
(TBrowser &) Name: Browser Title: ROOT Object Browser
root [1] (TFile *) 0x444fee0
(TFile *) 0x47de1a0
(TFile *) 0x48aea70
(TFile *) 0x4ad9070
(TFile *) 0x4d63970

root [1] .q
==21965== 
==21965== HEAP SUMMARY:
==21965==     in use at exit: 101,574 bytes in 300 blocks
==21965==   total heap usage: 2,160 allocs, 1,860 frees, 1,381,748 bytes allocated
==21965== 
==21965== 192 (16 direct, 176 indirect) bytes in 1 blocks are definitely lost in loss record 33 of 45
==21965==    at 0x4C2CB1D: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21965==    by 0x4E8AE40: ??? (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x4E8B3B3: ??? (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x4E8CC9E: ??? (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x4E8D4AB: _XlcCreateLC (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x4EAA8AF: _XlcDefaultLoader (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x4E94D3D: _XOpenLC (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x4E94F4A: _XrmInitParseInfo (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x4E7C96F: ??? (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x4E7FF4D: XrmGetStringDatabase (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x4E5CA63: ??? (in /usr/lib/libX11.so.6.3.0)
==21965==    by 0x4E5CC8D: XGetDefault (in /usr/lib/libX11.so.6.3.0)
==21965== 
==21965== LEAK SUMMARY:
==21965==    definitely lost: 16 bytes in 1 blocks
==21965==    indirectly lost: 176 bytes in 4 blocks
==21965==      possibly lost: 0 bytes in 0 blocks
==21965==    still reachable: 101,382 bytes in 295 blocks
==21965==         suppressed: 0 bytes in 0 blocks
==21965== Reachable blocks (those to which a pointer was found) are not shown.
==21965== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==21965==

Felice_Pantaleo · August 1, 2017, 8:58am

Hello,
Sorry for grave digging this thread, but the problem still persists.
I am not able to use TBrowser, not even through X2Go…
Using ROOT 6.10/03

couet · August 1, 2017, 9:35am

Sorry it seems we missed that one. I do not have access to that sort of High Def screen under linux. I have only my Mac… which is High def to… And I do not see the problem . XPu Image is a low level X11 function … may be it is not adapted for your high res screen. I do not a clear idea how to help …

kgizdov · August 1, 2017, 9:45am

I believe in the end this was an X.org bug or something. Since X.org 1.19.1 I no longer have this problem. The only problem that I have now is that ROOT does not respect HiDPI settings and ROOT GUIs are not scaled - icons and text are ridiculously small. Otherwise, it all works for me. Which version of xorg-server are you running? What is your distro?

couet · August 1, 2017, 11:58am

Some how mac retina dimply deals with the HiRes screen … X11 on mac manages this … there is nothing to do … GUI looks fine

kgizdov · August 1, 2017, 12:30pm

I fail to see how your comment in any way addresses the situation. X11 on Mac is given the “wrong” resolution when spawned, so it runs in a windowed sandboxed frame with whatever resolution the Mac window manager said. Then this is translated back. If I run in Wayland mode on Linux, which runs X in the same way as the Mac system does, then ROOT looks fine. This however is not what we are talking about or what the solution will entail. ROOT probably needs to have an .rootrc setting to specify scaling factor and apply that in X11 requests to deal with this.

couet · August 1, 2017, 12:38pm

I fail to see myself what the solution could be. I think at some point in the past we tried this scaling factor idea but we did not managed to make it work. If you end up finding a solution it is of course welcome.

ferhue · May 19, 2022, 2:02pm

Maybe related to the last problem you mention: use proper bitmap_pad in XCreateImage by ferdymercury · Pull Request #8681 · root-project/root · GitHub