Seg viol in TCling.cxx::ExecAutoParse

ROOT
1

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)

2

This is odd.

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

3

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