Fedora11 and ROOT 5.18

euridice · November 5, 2009, 9:15pm

Hi all,

I’m using ROOT 5.18 on Fedora Core 11 Kernel Linux 2.6.29.5-191.fc11.i586 with
gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2).

I wrote a macro to add some differents gamma spectra obtained from differents measurements.
When I run this macro it appears to work and it produces the results (correct results??) but at the end I also get the following message :

Maybe the problem is Fedora11 and ROOT 5.18 ?
Can I do or change something ?
(Unforunatly I cannot change this ROOT version…)

Many thanks for your help!

*** glibc detected *** /usr/local/root/bin/root.exe: free(): invalid pointer: 0x09488200 ***
======= Backtrace: =========
/lib/libc.so.6[0xd602a1]
/usr/local/root/lib/libCint.so(G__destroy_upto+0x56d)[0x3ca475]
/usr/local/root/lib/libCint.so(G__interpret_func+0x323e)[0x35605e]
/usr/local/root/lib/libCint.so(G__getfunction+0x1912)[0x342816]
/usr/local/root/lib/libCint.so(G__getitem+0x3d8)[0x326cb8]
/usr/local/root/lib/libCint.so(G__getexpr+0x20e3)[0x3298ff]
/usr/local/root/lib/libCint.so(G__calc_internal+0x28c)[0x332c18]
/usr/local/root/lib/libCint.so(G__process_cmd+0x37e5)[0x3a8af1]
/usr/local/root/lib/libCore.so(_ZN5TCint11ProcessLineEPKcPN12TInterpreter10EErrorCodeE+0x343)[0x822f5f]
/usr/local/root/lib/libCore.so(_ZN5TCint16ProcessLineSynchEPKcPN12TInterpreter10EErrorCodeE+0x4a)[0x823096]
/usr/local/root/lib/libCore.so(_ZN12TApplication11ExecuteFileEPKcPi+0x857)[0x79274b]
/usr/local/root/lib/libCore.so(_ZN12TApplication11ProcessFileEPKcPi+0x1e)[0x792a6e]
/usr/local/root/lib/libCore.so(_ZN12TApplication11ProcessLineEPKcbPi+0x55a)[0x790a96]
/usr/local/root/lib/libRint.so(_ZN5TRint15HandleTermInputEv+0x1c8)[0x1441a8]
/usr/local/root/lib/libRint.so(_ZN17TTermInputHandler6NotifyEv+0x24)[0x142840]
/usr/local/root/lib/libRint.so(_ZN17TTermInputHandler10ReadNotifyEv+0x12)[0x144a56]
/usr/local/root/lib/libCore.so(_ZN11TUnixSystem16CheckDescriptorsEv+0x1d2)[0x84e37a]
/usr/local/root/lib/libCore.so(_ZN11TUnixSystem16DispatchOneEventEb+0x448)[0x852598]
/usr/local/root/lib/libCore.so(_ZN7TSystem9InnerLoopEv+0x18)[0x7e60e8]
/usr/local/root/lib/libCore.so(_ZN7TSystem3RunEv+0x7e)[0x7e5eae]
/usr/local/root/lib/libCore.so(_ZN12TApplication3RunEb+0x32)[0x790c52]
/usr/local/root/lib/libRint.so(_ZN5TRint3RunEb+0x372)[0x142fb2]
/usr/local/root/bin/root.exe(main+0x52)[0x8048d36]
/lib/libc.so.6(__libc_start_main+0xe6)[0xd06a66]
/usr/local/root/bin/root.exe(_ZN15TApplicationImp11ShowMembersER16TMemberInspectorPc+0x31)[0x8048c5d]
======= Memory map: ========
00110000-00113000 r-xp 00000000 08:03 10269 /lib/libdl-2.10.1.so
00113000-00114000 r–p 00002000 08:03 10269 /lib/libdl-2.10.1.so
00114000-00115000 rw-p 00003000 08:03 10269 /lib/libdl-2.10.1.so
00115000-0012b000 r-xp 00000000 08:03 10268 /lib/libpthread-2.10.1.so
0012b000-0012c000 —p 00016000 08:03 10268 /lib/libpthread-2.10.1.so
0012c000-0012d000 r–p 00016000 08:03 10268 /lib/libpthread-2.10.1.so
0012d000-0012e000 rw-p 00017000 08:03 10268 /lib/libpthread-2.10.1.so
0012e000-00130000 rw-p 0012e000 00:00 0
00130000-00132000 r-xp 00000000 08:03 12226 /lib/libnss_mdns4_minimal.so.2
00132000-00133000 rw-p 00001000 08:03 12226 /lib/libnss_mdns4_minimal.so.2
00133000-00135000 r-xp 00000000 08:03 1077 /usr/lib/libXau.so.6.0.0
00135000-00136000 rw-p 00001000 08:03 1077 /usr/lib/libXau.so.6.0.0
00136000-00137000 r-xp 00136000 00:00 0 [vdso]
00137000-0015d000 r-xp 00000000 08:03 263413 /usr/local/root/lib/libRint.so
0015d000-0015f000 rw-p 00025000 08:03 263413 /usr/local/root/lib/libRint.so
0015f000-00242000 r-xp 00000000 08:03 921 /usr/lib/libstdc++.so.6.0.12
00242000-00246000 r–p 000e2000 08:03 921 /usr/lib/libstdc++.so.6.0.12
00246000-00248000 rw-p 000e6000 08:03 921 /usr/lib/libstdc++.so.6.0.12
00248000-0024e000 rw-p 00248000 00:00 0
0024e000-00253000 r-xp 00000000 08:03 1433622 /lib/libnss_dns-2.10.1.so
00253000-00254000 r–p 00004000 08:03 1433622 /lib/libnss_dns-2.10.1.so
00254000-00255000 rw-p 00005000 08:03 1433622 /lib/libnss_dns-2.10.1.so
00255000-00275000 r-xp 00000000 08:03 8248 /lib/ld-2.10.1.so
00275000-00276000 r–p 0001f000 08:03 8248 /lib/ld-2.10.1.so
00276000-00277000 rw-p 00020000 08:03 8248 /lib/ld-2.10.1.so
00277000-00472000 r-xp 00000000 08:03 263299 /usr/local/root/lib/libCint.so
00472000-00476000 rw-p 001fb000 08:03 263299 /usr/local/root/lib/libCint.so
00476000-0064f000 rw-p 00476000 00:00 0
0064f000-00675000 r-xp 00000000 08:03 10123 /lib/libm-2.10.1.so
00675000-00676000 r–p 00025000 08:03 10123 /lib/libm-2.10.1.so
00676000-00677000 rw-p 00026000 08:03 10123 /lib/libm-2.10.1.so
00677000-00682000 r-xp 00000000 08:03 1433634 /lib/libnss_files-2.10.1.so
00682000-00683000 r–p 0000a000 08:03 1433634 /lib/libnss_files-2.10.1.so

pcanal · November 5, 2009, 10:45pm

[quote]Can I do or change something ?
[/quote]You could try to compile your script. You could also try to run with valgrind to get more information on the reason for the problem.

Cheers,
Philippe.

euridice · November 5, 2009, 11:20pm

Thanks for your answer.

Do you think that the problem is a generic error in my script
and not some incompatibility between Fedora11 and ROOT 5.18
(as someone suggested)?

Usually I did .x sumspectra.C ,
I tried to debug some errors using much more cout in the code,
but I don’t identified any error although I think
that the spectra resulting are very strange and wrong
(and also when I compile the code at the end it crashes ).

I have never used valgrind, I will try…alternatively I will attach my script.

Cheers.

pcanal · November 5, 2009, 11:24pm

Hi,

[quote]Do you think that the problem is a generic error in my script
[/quote]I have no conclusive proof either way. However if you successfully build ROOT on your machine and it started okay, it points towards your script.

Cheers,
Philippe.

euridice · November 5, 2009, 11:34pm

Yes,
I was using ROOT 5.18 since last june under new Fedora 11 release.

Only sometimes I have found this kind of error .

Thanks again, Rosy

pcanal · November 6, 2009, 12:23am

[quote]Only sometimes I have found this kind of error .
[/quote]Then It suggest a real memory error. Do try valgrind

Cheers,
Philippe.

euridice · November 7, 2009, 6:10pm

Hi,

before to debug with valgrind I tried to compile my script on differents O.S.
and ROOT versions:

Fedora11 + ROOT 5.18 (already discussed) it produces results but at th eend it crashes …
*** glibc detected *** /usr/local/root/bin/root.exe…

Fedora11 + ROOT 5.24 as before.

Scientific Linux 5.2+ ROOT 5.20 finally it works without any errors at the end !!

Then it seems better to me to use SL5 !

Cheers,
Rosy.

[/quote]

pcanal · November 9, 2009, 12:51pm

Hi,

[quote]Then it seems better to me to use SL5 ![/quote]Please note that we still don’t know what the problem is. Your experiment could be explained by the use of uninitialized memory (either in ROOT or in your code) which would lead to random behavior (even occasional success). I still strongly recommend you run example through valgrind to see if there is any memory problem. In addition this would help us to know if there was really a regression between 5.20 and 5.24.

Cheers,
Philippe.

euridice · November 9, 2009, 2:56pm

Hi and many thanks Philippe.

As you suggested I installed valgrind
and I tried to use it for the first time,
but may be I need again your help
(I don’t know any expertise of valgrind program )

First, I have done the command

valgrind --leak-check=full root

and after I have run .x sumspectra_two.C (my script)

01518000-01595000 r-xp 0==20391==
==20391== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 27 from 1)
==20391== malloc/free: in use at exit: 0 bytes in 0 blocks.
==20391== malloc/free: 1,473 allocs, 1,473 frees, 767,980 bytes allocated.
==20391== For counts of detected errors, rerun with: -v
==20391== All heap blocks were freed – no leaks are possible.

[silvestri@pcexotic3 Prog_Analysis]$ valgrind -v --leak-check=full root
==20450== Memcheck, a memory error detector.
==20450== Copyright © 2002-2008, and GNU GPL’d, by Julian Seward et al.
==20450== Using LibVEX rev 1884, a library for dynamic binary translation.
==20450== Copyright © 2004-2008, and GNU GPL’d, by OpenWorks LLP.
==20450== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==20450== Copyright © 2000-2008, and GNU GPL’d, by Julian Seward et al.
==20450==
–20450-- Command line
–20450-- root
–20450-- Startup, with flags:
–20450-- -v
–20450-- --leak-check=full
–20450-- Contents of /proc/version:
–20450-- Linux version 2.6.29.5-191.fc11.i586 (mockbuild@xenbuilder2.fedora.redhat.com) (gcc version 4.4.0 20090506 (Red Hat 4.4.0-4) (GCC) ) #1 SMP Tue Jun 16 23:11:39 EDT 2009
–20450-- Arch and hwcaps: X86, x86-sse1-sse2
–20450-- Page sizes: currently 4096, max supported 4096
–20450-- Valgrind library directory: /usr/lib/valgrind
–20450-- Reading syms from /lib/ld-2.10.1.so (0x255000)
–20450-- Reading syms from /usr/local/root/bin/root (0x8048000)
–20450-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck (0x38000000)
–20450-- object doesn’t have a dynamic symbol table
–20450-- Reading suppressions file: /usr/lib/valgrind/default.supp
–20450-- REDIR: 0x26d840 (index) redirected to 0x3803b253 (vgPlain_x86_linux_REDIR_FOR_index)
–20450-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_core.so (0x4001000)
–20450-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x4003000)
==20450== WARNING: new redirection conflicts with existing – ignoring it
–20450-- new: 0x0026d840 (index ) R-> 0x040073c0 index
–20450-- REDIR: 0x26da10 (strlen) redirected to 0x4007680 (strlen)
–20450-- Reading syms from /usr/lib/libXpm.so.4.11.0 (0x51da000)
–20450-- object doesn’t have a symbol table
–20450-- Reading syms from /usr/lib/libXext.so.6.4.0 (0x722000)
–20450-- object doesn’t have a symbol table
–20450-- Reading syms from /usr/lib/libX11.so.6.2.0 (0x59e000)
–20450-- object doesn’t have a symbol table
–20450-- Reading syms from /usr/lib/libXft.so.2.1.13 (0x51c4000)
–20450-- object doesn’t have a symbol table
–20450-- Reading syms from /usr/lib/libstdc++.so.6.0.12 (0x8e2000)
–20450-- object doesn’t have a symbol table
–20450-- Reading syms from /lib/libm-2.10.1.so (0x3ec000)
–20450-- Reading syms from /lib/libgcc_s-4.4.1-20090729.so.1 (0x8b5000)
–20450-- object doesn’t have a symbol table
–20450-- Reading syms from /lib/libc-2.10.1.so (0x402c000)
–20450-- Reading syms from /usr/lib/libXau.so.6.0.0 (0x6ed000)
–20450-- object doesn’t have a symbol table
–20450-- Reading syms from /usr/lib/libxcb.so.1.1.0 (0x6cf000)
–20450-- object doesn’t have a symbol table
–20450-- Reading syms from /lib/libdl-2.10.1.so (0x416000)
–20450-- Reading syms from /usr/lib/libfontconfig.so.1.4.1 (0x7f1000)
–20450-- object doesn’t have a symbol table
–20450-- Reading syms from /usr/lib/libfreetype.so.6.3.20 (0x734000)
–20450-- object doesn’t have a symbol table
–20450-- Reading syms from /usr/lib/libXrender.so.1.3.0 (0x82d000)
–20450-- object doesn’t have a symbol table
–20450-- Reading syms from /lib/libexpat.so.1.5.2 (0x6f9000)
–20450-- object doesn’t have a symbol table
–20450-- REDIR: 0x40a5570 (rindex) redirected to 0x40072a0 (rindex)
–20450-- REDIR: 0x40a5130 (strlen) redirected to 0x4007660 (strlen)
–20450-- REDIR: 0x40a5310 (strncmp) redirected to 0x4007910 (strncmp)
–20450-- REDIR: 0x40a03c0 (calloc) redirected to 0x4004d90 (calloc)
–20450-- REDIR: 0x40a0ba0 (malloc) redirected to 0x4006e70 (malloc)
–20450-- REDIR: 0x40a7370 (memcpy) redirected to 0x4007ae0 (memcpy)
–20450-- REDIR: 0x40a9e20 (strchrnul) redirected to 0x4008720 (strchrnul)
–20450-- REDIR: 0x40a0020 (free) redirected to 0x4005b10 (free)
–20450-- REDIR: 0x41211e0 (__strcpy_chk) redirected to 0x4008ca0 (__strcpy_chk)
–20450-- REDIR: 0x40a6e90 (memset) redirected to 0x4008630 (memset)
–20450-- REDIR: 0x40a6e20 (memmove) redirected to 0x40086a0 (memmove)
–20450-- REDIR: 0x40a1860 (realloc) redirected to 0x4006f90 (realloc)
–20450-- REDIR: 0x40a5400 (strncpy) redirected to 0x40077a0 (strncpy)
–20450-- REDIR: 0x40a4c40 (strcpy) redirected to 0x40076c0 (strcpy)
–20450-- REDIR: 0x40a48b0 (strcat) redirected to 0x4007420 (strcat)
–20451-- REDIR: 0x999c40 (operator new[](unsigned int)) redirected to 0x4006060 (operator new[](unsigned int))
–20451-- REDIR: 0x405a4c0 (putenv) redirected to 0x4008910 (putenv)
–20451-- REDIR: 0x40a4a60 (index) redirected to 0x4007390 (index)
–20451-- REDIR: 0x40a51e0 (strnlen) redirected to 0x4007620 (strnlen)

At the end of my job, this is the test result

==20450== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 27 from 1)
–20450–
–20450-- supp: 27 dl-hack3-cond-1
==20450== malloc/free: in use at exit: 0 bytes in 0 blocks.
==20450== malloc/free: 1,473 allocs, 1,473 frees, 767,980 bytes allocated.
==20450==
==20450== All heap blocks were freed – no leaks are possible.
–20450-- memcheck: sanity checks: 68 cheap, 4 expensive
–20450-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
–20450-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10
–20450-- memcheck: auxmaps_L2: 0 searches, 0 nodes
–20450-- memcheck: SMs: n_issued = 42 (672k, 0M)
–20450-- memcheck: SMs: n_deissued = 8 (128k, 0M)
–20450-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M)
–20450-- memcheck: SMs: max_undefined = 8 (128k, 0M)
–20450-- memcheck: SMs: max_defined = 73 (1168k, 1M)
–20450-- memcheck: SMs: max_non_DSM = 40 (640k, 0M)
–20450-- memcheck: max sec V bit nodes: 0 (0k, 0M)
–20450-- memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
–20450-- memcheck: max shadow mem size: 944k, 0M
–20450-- translate: fast SP updates identified: 5,975 ( 89.5%)
–20450-- translate: generic_known SP updates identified: 460 ( 6.8%)
–20450-- translate: generic_unknown SP updates identified: 237 ( 3.5%)
–20450-- tt/tc: 11,497 tt lookups requiring 11,999 probes
–20450-- tt/tc: 11,497 fast-cache updates, 3 flushes
–20450-- transtab: new 5,147 (106,273 -> 1,551,942; ratio 146:10) [0 scs]
–20450-- transtab: dumped 0 (0 -> ??)
–20450-- transtab: discarded 5 (115 -> ??)
–20450-- scheduler: 6,860,958 jumps (bb entries).
–20450-- scheduler: 68/11,111 major/minor sched events.
–20450-- sanity: 69 cheap, 4 expensive checks.
–20450-- exectx: 1,543 lists, 825 contexts (avg 0 per list)
–20450-- exectx: 3,672 searches, 3,262 full compares (888 per 1000)
–20450-- exectx: 0 cmp2, 56 cmp4, 0 cmpAll
–20450-- errormgr: 8 supplist searches, 31 comparisons during search
–20450-- errormgr: 27 errlist searches, 56 comparisons during search

I have seen that there are one or more error
but I don’t unterstand where.
Initially I was thinking that valgrind shows me the line of the error in my scrypt.

Are there some other options to unterstand much more things?

pcanal · November 9, 2009, 4:07pm

Hi,

Because the executable ‘root’ is a small wrapper around the real executable (root.exe) and because we are not interested here in memory leaks, please use:valgrind root.exe. Also please run this on the ‘failing’ platform.

Thanks,
Philippe.

euridice · November 9, 2009, 4:53pm

Thanks again,
finally I have found some things not so good ,
because when I’m running on the “failing” platform with your command the program seems to start but after that I get this message

==21044== Invalid read of size 1
==21044== at 0x4007B88: memcpy (mc_replace_strmem.c:402)
==21044== by 0x41745A6: TString::Replace(int, int, char const*, int) (in /usr/local/root/lib/libCore.so)
==21044== by 0x41746D5: TString::operator=(char const*) (in /usr/local/root/lib/libCore.so)
==21044== by 0x4153B9E: TNamed::SetName(char const*) (in /usr/local/root/lib/libCore.so)
==21044== by 0x4143BC9: TDirectory::SetName(char const*) (in /usr/local/root/lib/libCore.so)
==21044== by 0x64AEFD1: TFile::TFile(char const*, char const*, char const*, int) (in /usr/local/root/lib/libRIO.so)
==21044== by 0x652037B: G__G__IO_100_0_23(G__value*, char const*, G__param*, int) (in /usr/local/root/lib/libRIO.so)
==21044== by 0x469FA5E: Cint::G__ExceptionWrapper(int ()(G__value, char const*, G__param*, int), G__value*, char*, G__param*, int) (in /usr/local/root/lib/libCint.so)
==21044== by 0x475C326: G__call_cppfunc (in /usr/local/root/lib/libCint.so)
==21044== by 0x47418DC: G__interpret_func (in /usr/local/root/lib/libCint.so)
==21044== by 0x472F9D3: G__getfunction (in /usr/local/root/lib/libCint.so)
==21044== by 0x475AA01: G__new_operator (in /usr/local/root/lib/libCint.so)
==21044== Address 0x542b20d is 1 bytes after a block of size 100 alloc’d
==21044== at 0x400612D: operator new[](unsigned int) (vg_replace_malloc.c:268)
==21044== by 0x469F662: Cint::G__new_interpreted_object(int) (in /usr/local/root/lib/libCint.so)
==21044== by 0x475A2B0: G__new_operator (in /usr/local/root/lib/libCint.so)
==21044== by 0x4717BAC: G__getexpr (in /usr/local/root/lib/libCint.so)
==21044== by 0x470616B: G__define_var (in /usr/local/root/lib/libCint.so)
==21044== by 0x47833CB: G__exec_statement (in /usr/local/root/lib/libCint.so)
==21044== by 0x4742702: G__interpret_func (in /usr/local/root/lib/libCint.so)
==21044== by 0x472F815: G__getfunction (in /usr/local/root/lib/libCint.so)
==21044== by 0x4713CB7: G__getitem (in /usr/local/root/lib/libCint.so)
==21044== by 0x47168FE: G__getexpr (in /usr/local/root/lib/libCint.so)
==21044== by 0x471FC17: G__calc_internal (in /usr/local/root/lib/libCint.so)
==21044== by 0x4795AF0: G__process_cmd (in /usr/local/root/lib/libCint.so)

Thanks for your help,
now I hope to perform some correction…
In any do you think that my previuos results obtained when the script crashed
may be right ?

Cheers,
Rosy

pcanal · November 9, 2009, 5:02pm

[quote]I get this message

==21044== Invalid read of size 1
==21044== at 0x4007B88: memcpy (mc_replace_strmem.c:402)
==21044== by 0x41745A6: TString::Replace(int, int, char const*, int) (in /usr/local/root/lib/libCore.so)
==21044== by 0x41746D5: TString::operator=(char const*) (in /usr/local/root/lib/libCore.so)
==21044== by 0x4153B9E: TNamed::SetName(char const*) (in /usr/local/root/lib/libCore.so)
==21044== by 0x4143BC9: TDirectory::SetName(char const*) (in /usr/local/root/lib/libCore.so)
==21044== by 0x64AEFD1: TFile::TFile(char const*, char const*, char const*, int) (in /usr/local/root/lib/libRIO.so) [/quote]Ah . This problem was just finally solved in revision 30924 of the trunk (2 weeks ago). It is a problem reading either large files or ‘old’ files in recent version of ROOT.

[quote]In any do you think that my previuos results obtained when the script crashed
may be right ?[/quote]If this is the only problem shown by valgrind, then the results you get when the script does not crash are correct.

Cheers,
Philippe.

euridice · November 9, 2009, 5:26pm

Then do you suggest to change the OS , the version of ROOT or some other things
(I don’t know exactly what is “trunk”?) to solve my problem?

Cheers,
R.

pcanal · November 9, 2009, 5:30pm

Hi,

The right way to solve the problem is to download the latest version of the ROOT source code from the Subversion repository. A work-around is to use whichever version/platform combination you found to work for you .

Cheers,
Philippe.

euridice · November 10, 2009, 4:23pm

Hi,

at the end as at the beginning I choose to change my OS,
from Fedora11 to SL 5 because I can’t change the version of ROOT.

Let me hope …

Cheers,
Rosy