How to debug root with electric fence, (rootcint crashes)

ROOT
1

Has anybody checked root with Electric Fence ?

I linked rootcint to Electric Fence on FC3 and FC4 and
rootcint crashes. root 5

on FC4
El. Fence says rootcint wants to allocate 0 bytes…:

Generating DICTIONARY for LegsRun.h

Electric Fence 2.2.0 Copyright © 1987-1999 Bruce Perens bruce@perens.com

ElectricFence Aborting: Allocating 0 bytes, probably a bug.
make[1]: *** [LegsRunDict.cxx] Illegal instruction
make[1]: *** Deleting file `LegsRunDict.cxx’

on FC3 it does not even link properly:

Electric Fence 2.1 Copyright © 1987-1998 Bruce Perens.
/home/sasy/root/bin/rootcint: symbol lookup error: /home/sasy/root/bin/rootcint: undefined symbol: G__set_ioctortype_handler

2

Hi,

I do not have any experience with Electric Fence. I prefer to use valgrind which does not require a full recompile.

One of the possible cause I can think of is that the cintdlls where not build with electric fence (see $ROOTSYS/build/unix/makecintdlls.sh)

Cheers,
Philippe.

3

g++ -g -pipe -Wall -W -Woverloaded-virtual -fPIC -Iinclude -DG__REGEXP -DG__UNIX -DG__SHAREDLIB -DG__OSFDLL -DG__ROOT -DG__REDIRECTIO -DG__STD_EXCEPTION -pthread -o cint/src/v6_newlink.o -c cint/src/v6_newlink.cxx
cint/src/v6_newlink.cxx: In function void G__set_ioctortype_handler(int (*)(const char*))': cint/src/v6_newlink.cxx:64: error:G__p_i’ undeclared (first use this function)
cint/src/v6_newlink.cxx:64: error: (Each undeclared identifier is reported only once for each function it appears in.)
cint/src/v6_newlink.cxx:64: error: expected `;’ before "octortype_handler"
cint/src/v6_newlink.cxx: At global scope:
cint/src/v6_newlink.cxx:63: warning: unused parameter 'p2f’
make: *** [cint/src/v6_newlink.o] Error 1

4

When do you get this error message (compiler version, ROOT version, platform)?

Philippe.

5

FC3 updated to non-can-do anymore on AMD AThlon MP, 2-cpu

[ardashev@legsux1 hist]$ g++ -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.4/specs
Configured with: …/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)

during compilation of ROOT I plugged in valgrind in front of call to rootcint_tmp

It looks like some dictionaries may potentially be screwed up if rootcint has unaccounted memory leaks…

Originally the problem started with me getitng errors of old size new size mismatch during creation of large TTrees.

I decided to check my program-ROOT combo with valgrind for memory mishandling. But before doing that I wanted to make sure there are no errors with rootcint that is used to generate dictionaries for root installation, which is rootcint_tmp here…

During creation of my classes dictionaries with rootcint though, I don’t have any errors. So, it must be combo of rootcint_tmp and some root classes that gives these memory leaks.

Feel free to ask whatever you need me to do to sort it out. I am really concerned about correctness of TTrees and I don’t want any memory leaks.

Once this one is resolved I will proceed to valgrinding my program

6

forgot to mention, ROOT is the latest cvs.

7

Just to make sure that the latest CVS still produces the problem I have updated ROOT and here is it, some bytes are lost…

Generating dictionary cont/src/G__Cont.cxx…
valgrind --tool=memcheck --tool=addrcheck --leak-check=yes utils/src/rootcint_tmp -f cont/src/G__Cont.cxx -c cont/inc/TArrayC.h cont/inc/TArrayD.h cont/inc/TArrayF.h cont/inc/TArray.h cont/inc/TArrayI.h cont/inc/TArrayL.h cont/inc/TArrayS.h cont/inc/TBits.h cont/inc/TBtree.h cont/inc/TClassTable.h cont/inc/TClonesArray.h cont/inc/TCollection.h cont/inc/TCollectionProxy.h cont/inc/TContainerConverters.h cont/inc/TEmulatedCollectionProxy.h cont/inc/TEmulatedMapProxy.h cont/inc/TExMap.h cont/inc/TGenCollectionProxy.h cont/inc/TGenCollectionStreamer.h cont/inc/THashList.h cont/inc/THashTable.h cont/inc/TIterator.h cont/inc/TList.h cont/inc/TMap.h cont/inc/TObjArray.h cont/inc/TObjectTable.h cont/inc/TOrdCollection.h cont/inc/TRefArray.h cont/inc/TRefTable.h cont/inc/TSeqCollection.h cont/inc/TSortedList.h cont/inc/TVirtualCollectionProxy.h cont/inc/LinkDef.h
==10459== Addrcheck, a fine-grained address checker for x86-linux.
==10459== Copyright © 2002-2004, and GNU GPL’d, by Julian Seward et al.
==10459== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==10459== Copyright © 2000-2004, and GNU GPL’d, by Julian Seward et al.
==10459== For more details, rerun with: -v
==10459==
==10459==
==10459== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==10459== malloc/free: in use at exit: 1606 bytes in 54 blocks.
==10459== malloc/free: 33330 allocs, 33276 frees, 7624875 bytes allocated.
==10459== For counts of detected errors, rerun with: -v
==10459== searching for pointers to 54 not-freed blocks.
==10459== checked 5266960 bytes.
==10459==
==10459== 8 bytes in 2 blocks are definitely lost in loss record 1 of 7
==10459== at 0x3414BC25: calloc (vg_replace_malloc.c:176)
==10459== by 0x81485A3: G__malloc (v6_malloc.cxx:263)
==10459== by 0x81D28E4: G__allocvariable (v6_var.cxx:6252)
==10459== by 0x81C38C6: G__letvariable (v6_var.cxx:2862)
==10459==
==10459==
==10459== 1182 bytes in 47 blocks are possibly lost in loss record 7 of 7
==10459== at 0x3414B41F: operator new(unsigned) (vg_replace_malloc.c:133)
==10459== by 0x341ED271: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator const&) (in /usr/lib/libstdc++.so.6.0.3)
==10459== by 0x341ED9B9: std::string::_M_mutate(unsigned, unsigned, unsigned) (in /usr/lib/libstdc++.so.6.0.3)
==10459== by 0x341EDCB8: std::string::assign(char const*, unsigned) (in /usr/lib/libstdc++.so.6.0.3)
==10459==
==10459== LEAK SUMMARY:
==10459== definitely lost: 8 bytes in 2 blocks.
==10459== possibly lost: 1182 bytes in 47 blocks.
==10459== still reachable: 416 bytes in 5 blocks.
==10459== suppressed: 0 bytes in 0 blocks.
==10459== Reachable blocks (those to which a pointer was found) are not shown.
==10459== To see them, rerun with: --show-reachable=yes

8

Hi,

You said you got the error:

[quote]g++ -g -pipe -Wall -W -Woverloaded-virtual -fPIC -Iinclude -DG__REGEXP -DG__UNIX -DG__SHAREDLIB -DG__OSFDLL -DG__ROOT -DG__REDIRECTIO -DG__STD_EXCEPTION -pthread -o cint/src/v6_newlink.o -c cint/src/v6_newlink.cxx
cint/src/v6_newlink.cxx: In function void G__set_ioctortype_handler(int (*)(const char*))': cint/src/v6_newlink.cxx:64: error:G__p_i’ undeclared (first use this function) [/quote]
Do you still have this error? If you do, let me know when and where!

[quote]It looks like some dictionaries may potentially be screwed up if rootcint has unaccounted memory leaks… [/quote]This is extremely unlikely! The memory leak only consequence should be that rootcint uses more memory than it could. Even more, in most case the likely is only apparent (i.e. it leaks only because we do not properly clean up at the end of the process).

[quote]==10459== 8 bytes in 2 blocks are definitely lost in loss record 1 of 7
==10459== at 0x3414BC25: calloc (vg_replace_malloc.c:176)
==10459== by 0x81485A3: G__malloc (v6_malloc.cxx:263)
==10459== by 0x81D28E4: G__allocvariable (v6_var.cxx:6252)
==10459== by 0x81C38C6: G__letvariable (v6_var.cxx:2862)
[/quote]
For now please ignore this ‘leak’.

[quote]Originally the problem started with me getitng errors of old size new size mismatch during creation of large TTrees.[/quote]This should not be related to dictionary generation.

[quote]During creation of my classes dictionaries with rootcint though, I don’t have any errors. … [/quote]Your dictionary are problably just fine.

Cheers,
Philippe.