* Break * segmentation violation closing root

coburn · June 11, 2020, 9:35am

Hi everyone,
first of all I use this version:
ROOT Version: 6.20/04
Built for linuxx8664gcc on Apr 01 2020, 08:28:48
From tags/v6-20-04@v6-20-04

I’m trying to do a program using 3D libraries. I decided to try to compile a root macro to learn how to do it, so I decided to compile the macro named
csgdemo.C
contained in the directory
/root/tutorials/eve

To do it I just followed some instructions I found on some papers I found:
-include header files
-add the main function where the commands are the following:

int main()
{
 TApplication theApp("Dynamic System", 0, 0);
 csgdemo();
 theApp.Run(kTRUE);
 return 0;
}

Everything works correctly, but when I select QUIT ROOT occures the following error:

 **** Break *** segmentation violation*



*===========================================================*
*There was a crash.*
*This is the entire stack trace of all threads:*
*===========================================================*

*Thread 5 (Thread 0x7f683d864700 (LWP 19852)):*
*#0  futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5616e95f0168) at ../sysdeps/nptl/futex-internal.h:183*
*#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5616e95f0118, cond=0x5616e95f0140) at pthread_cond_wait.c:508*
*#2  __pthread_cond_wait (cond=0x5616e95f0140, mutex=0x5616e95f0118) at pthread_cond_wait.c:638*
*#3  0x00007f684396c3db in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so*
*#4  0x00007f684396bfeb in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so*
*#5  0x00007f6858d27609 in start_thread (arg=<optimized out>) at pthread_create.c:477*
*#6  0x00007f6858f14103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95*

*Thread 4 (Thread 0x7f683e065700 (LWP 19851)):*
*#0  futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5616e95f0168) at ../sysdeps/nptl/futex-internal.h:183*
*#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5616e95f0118, cond=0x5616e95f0140) at pthread_cond_wait.c:508*
*#2  __pthread_cond_wait (cond=0x5616e95f0140, mutex=0x5616e95f0118) at pthread_cond_wait.c:638*
*#3  0x00007f684396c3db in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so*
*#4  0x00007f684396bfeb in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so*
*#5  0x00007f6858d27609 in start_thread (arg=<optimized out>) at pthread_create.c:477*
*#6  0x00007f6858f14103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95*

*Thread 3 (Thread 0x7f683e866700 (LWP 19850)):*
*#0  futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5616e95f0168) at ../sysdeps/nptl/futex-internal.h:183*
*#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5616e95f0118, cond=0x5616e95f0140) at pthread_cond_wait.c:508*
*#2  __pthread_cond_wait (cond=0x5616e95f0140, mutex=0x5616e95f0118) at pthread_cond_wait.c:638*
*#3  0x00007f684396c3db in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so*
*#4  0x00007f684396bfeb in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so*
*#5  0x00007f6858d27609 in start_thread (arg=<optimized out>) at pthread_create.c:477*
*#6  0x00007f6858f14103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95*

*Thread 2 (Thread 0x7f683f067700 (LWP 19849)):*
*#0  futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5616e95f0168) at ../sysdeps/nptl/futex-internal.h:183*
*#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5616e95f0118, cond=0x5616e95f0140) at pthread_cond_wait.c:508*
*#2  __pthread_cond_wait (cond=0x5616e95f0140, mutex=0x5616e95f0118) at pthread_cond_wait.c:638*
*#3  0x00007f684396c3db in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so*
*#4  0x00007f684396bfeb in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so*
*#5  0x00007f6858d27609 in start_thread (arg=<optimized out>) at pthread_create.c:477*
*#6  0x00007f6858f14103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95*

*Thread 1 (Thread 0x7f6856d09b40 (LWP 19821)):*
*#0  0x00007f6858ed7c6f in __GI___wait4 (pid=19855, stat_loc=stat_loc*
*entry=0x7ffda42e39a8, options=options*
*entry=0, usage=usage*
*entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:27*
*#1  0x00007f6858ed7beb in __GI___waitpid (pid=<optimized out>, stat_loc=stat_loc*
*entry=0x7ffda42e39a8, options=options*
*entry=0) at waitpid.c:38*
*#2  0x00007f6858e470e7 in do_system (line=<optimized out>) at ../sysdeps/posix/system.c:172*
*#3  0x00007f685a1af55e in TUnixSystem::StackTrace() () from /home/harem/root/root/lib/libCore.so.6.20*
*#4  0x00007f685a1ac27c in TUnixSystem::DispatchSignals(ESignals) () from /home/harem/root/root/lib/libCore.so.6.20*
*#5  <signal handler called>*
*#6  0x0000000000000000 in ?? ()*
*#7  0x00007f6857eb783b in TGMenuBar::~TGMenuBar() () from /home/harem/root/root/lib/libGui.so.6.20*
*#8  0x00007f6857eb79ed in TGMenuBar::~TGMenuBar() () from /home/harem/root/root/lib/libGui.so.6.20*
*#9  0x00007f685a1044a0 in THashList::Delete(char const*) () from /home/harem/root/root/lib/libCore.so.6.20*
*#10 0x00007f6857e22d2d in TGClient::~TGClient() () from /home/harem/root/root/lib/libGui.so.6.20*
*#11 0x00007f6857e22dcd in TGClient::~TGClient() () from /home/harem/root/root/lib/libGui.so.6.20*
*#12 0x00007f6857f39d93 in TRootApplication::~TRootApplication() () from /home/harem/root/root/lib/libGui.so.6.20*
*#13 0x00007f6857f39dad in TRootApplication::~TRootApplication() () from /home/harem/root/root/lib/libGui.so.6.20*
*#14 0x00007f685a05e01e in TApplication::~TApplication() () from /home/harem/root/root/lib/libCore.so.6.20*
*#15 0x00005616e60c9d24 in main ()*
*===========================================================*


*The lines below might hint at the cause of the crash.*
*You may get help by asking at the ROOT forum http://root.cern.ch/forum*
*Only if you are really convinced it is a bug in ROOT then please submit a*
*report at http://root.cern.ch/bugs Please post the ENTIRE stack trace*
*from above as an attachment in addition to anything else*
*that might help us fixing this issue.*
*===========================================================*
*#6  0x0000000000000000 in ?? ()*
*#7  0x00007f6857eb783b in TGMenuBar::~TGMenuBar() () from /home/harem/root/root/lib/libGui.so.6.20*
*#8  0x00007f6857eb79ed in TGMenuBar::~TGMenuBar() () from /home/harem/root/root/lib/libGui.so.6.20*
*#9  0x00007f685a1044a0 in THashList::Delete(char const*) () from /home/harem/root/root/lib/libCore.so.6.20*
*#10 0x00007f6857e22d2d in TGClient::~TGClient() () from /home/harem/root/root/lib/libGui.so.6.20*
*#11 0x00007f6857e22dcd in TGClient::~TGClient() () from /home/harem/root/root/lib/libGui.so.6.20*
*#12 0x00007f6857f39d93 in TRootApplication::~TRootApplication() () from /home/harem/root/root/lib/libGui.so.6.20*
*#13 0x00007f6857f39dad in TRootApplication::~TRootApplication() () from /home/harem/root/root/lib/libGui.so.6.20*
*#14 0x00007f685a05e01e in TApplication::~TApplication() () from /home/harem/root/root/lib/libCore.so.6.20*
*#15 0x00005616e60c9d24 in main ()*
*===========================================================*

Can someone help me? I cannot understand what I’m doing wrong.
Maybe the execution of the macro calls a destructor I have to call explicitly… no idea

thank you!

bellenot · June 11, 2020, 9:58am

You’re not doing anything wrong, it seems that the csgdemo.C macro simply doesn’t work when it is compiled. We will investigate

coburn · June 11, 2020, 10:23am

thank you a lot,
but the fact is that this problem occurs even in other macros, for example
lineset.C
which is in the same directory
root/tutorials/eve
These for sure are not the only two programs because I tried with several macro using 3D libraries but every time the error in closure was the same. For this reason I thought it is a problem of a library, but maybe I’m wrong

Thank you a lot!

bellenot · June 11, 2020, 10:57am

Well, maybe the underlying issue is coming from Eve/OpenGL, we will have to investigate.

coburn · July 19, 2020, 5:05pm

I was asking myself if there can be a way to avoid this error. Maybe can I somehow explicitly delete the TGMenuBar? Or maybe is there an alternative way to execute the program avoiding this error in closure? For example in a way that the system automatically forces program closure?

coburn · October 8, 2020, 5:06pm

We’ve found a solution: an easy way to avoid the problem is defining in the heap the tApplication instead of in the stuck. This way everything is automaticly destructed and the problem of the destructor is avoided

*** Break *** segmentation violation closing root

* Break * segmentation violation closing root