Seg viol in TCling.cxx::ExecAutoParse

Dear Rooters,

I have a tedious problem when running my application grope.exe
on a i386 Ubuntu 18.04, ROOT 6.21.01 (I need 32bit because of OPAL/ZEBRA)
(Useless to say that I cannot provide the whole program,
it contains apart from ROOT, CERNLIB and OPALs analysis ROPE and GROPE)

I get a seg viol in TCling.cxx::ExecAutoParse

#0  __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:50
#1  0xb49311ef in std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >::operator+=(char const*) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#2  0xafb1ac2d in ExecAutoParse (what=0xa5495c00
     <error: Cannot access memory at address 0xa5495c00>, header=false, 

I could follow the erroneous address up to:
TCling.cxx::6108

(gdb) p iter
$9 = 
    {first = 405046428, second = std::vector of length 3,
    capacity 4 = {0xa5495c00 <error: Cannot access memory at address 0xa5495c00>,
     0xa5495c00 <error: Cannot access memory at address 0xa5495c00>,
     0xa66c00 "\n#line 1 \"G__ropecmdsDict dictionary payload\"
     \n\n\n#define _BACKWARD_BACKWARD_WARNING_H\n// Inline headers\n#include
     \"build/ropecmds.h\"\n#include \"build/Trapezoid.h\"\n#include \"build/TPol3D.h\
     "\n#include \"buil"...}}

The ExecAutoParse was triggered by TQObject::Connect( when
looking up a slot in class RopeCmds.
I run in the directory which has e.g.: build/ropecmds.h
Setting ROOT_INCLUDE_PATH doesnt help.
I add the full backtrace and dictionary file as att.

The program was and is still running with ROOT 5.34.21
Could 32bit a problem or the BACKWARD_BACKWARD_WARNING_H?

I hope somebody has a hint how to fix that.

Cheers
Otto
bt.txt (3.4 KB) G__ropecmdsDict.cxx (24.1 KB)

This is odd.

Can you run the failing example with:
valgrind --suppressions=$ROOTSYS/etc/valgrind-root.supp ....
?

Hi,
yesterday evening I found the problem when tracing with gdb
the place where the fClassesHeadersMap gets filled TCling.cxx:2232
and found that this happened before the real start of the program.
I have a set of many routines: higz2root.cxx replacing all of
HIGZ and HBOOK of cernlib needed in Grope of OPAL.
In its header was:

THStack gStackLego("Grope_Lego", "");

That triggered TCling::RegisterModule
Replacing that by THStack *gStackLego and postponing
the instantiation into the body of the routine needing it first time
solved the problem.

However I still dont know if this construct was legal with Cling,
CINT obviously did digest it.
Also I dont know where the fClassesHeadersMap gets messed up
but that might be irrelevant.

Cheers
Otto

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.