Double free or corruption error at end of macro

[wamlet]

I am reliably able to crash root with my macro at the very end of its execution with such an error:

*** glibc detected *** /home/wam/src/root/bin/root.exe: double free or corruption (!prev): 0x0a1261c0 ***

In this macro I read and fit some histograms from a file using:

TH1F *avgasy = (TH1F*)f->GetObjectChecked("Avg","TH1F"); 

TH1F *scans[numscans];

char scanname[100];

for (int i=0;i<numscans;i++) {
 sprintf(scanname,"Asymmetry for scan %d",i+1);
 scans[i+1]=(TH1F*)f->GetObjectChecked(scanname,"TH1F");
}

I open several canvases and make some plots, and it all works fine until the execution reaches the end of the macro where it crashes with

*** glibc detected *** /home/wam/src/root/bin/root.exe: double free or corruption (!prev): 0x0a1261c0 ***
======= Backtrace: =========
/lib/libc.so.6(+0x72ac2)[0xb6d66ac2]
/home/wam/src/root/lib/libCint.so(G__destroy_upto+0x231)[0xb6749be1]
/home/wam/src/root/lib/libCint.so(G__interpret_func+0x31d5)[0xb6721f25]
/home/wam/src/root/lib/libCint.so(G__getfunction+0x2555)[0xb673d8d5]
/home/wam/src/root/lib/libCint.so(G__getitem+0x985)[0xb67b1a75]
/home/wam/src/root/lib/libCint.so(G__getexpr+0x5377)[0xb67b8107]
/home/wam/src/root/lib/libCint.so(G__calc_internal+0x343)[0xb67c4393]
/home/wam/src/root/lib/libCint.so(G__process_cmd+0x3001)[0xb66e3321]
/home/wam/src/root/lib/libCore.so(_ZN5TCint11ProcessLineEPKcPN12TInterpreter10EErrorCodeE+0x484)[0xb7539b24]
/home/wam/src/root/lib/libCore.so(_ZN5TCint16ProcessLineSynchEPKcPN12TInterpreter10EErrorCodeE+0xa3)[0xb752f663]
/home/wam/src/root/lib/libCore.so(_ZN12TApplication11ExecuteFileEPKcPib+0x863)[0xb750da53]
/home/wam/src/root/lib/libCore.so(_ZN12TApplication11ProcessFileEPKcPib+0x2c)[0xb750de4c]
/home/wam/src/root/lib/libCore.so(_ZN12TApplication11ProcessLineEPKcbPi+0x851)[0xb750c611]
/home/wam/src/root/lib/libRint.so(_ZN5TRint3RunEb+0x42d)[0xb6ffda9d]
/home/wam/src/root/bin/root.exe(main+0x70)[0x8048e30]
/lib/libc.so.6(__libc_start_main+0xf5)[0xb6d0d3d5]
/home/wam/src/root/bin/root.exe[0x8048ead]
======= Memory map: ========
08048000-0804a000 r-xp 00000000 08:02 8661213 /home/wam/src/root/bin/root.exe

I suspect it may be a memory management issue, but nothing is obvious to me.

valgrind does find some memory loss from the heap (with a g++ compiled version of the macro)

==15825== 116 (72 direct, 44 indirect) bytes in 1 blocks are definitely lost in loss record 29,836 of 38,310
==15825== at 0x402BF09: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==15825== by 0x4BBD6E0: TStorage::ObjectAlloc(unsigned int) (in /home/wam/src/root/lib/libCore.so)
==15825== by 0x804BA8D: TObject::operator new(unsigned int) (in /home/wam/src/1f/test.out)
==15825== by 0x804A9E7: main (in /home/wam/src/1f/test.out)

Thanks for any suggestions!

Andrew

[tpochep]

[quote=“wamlet”]
…
TH1F scans[numscans];
…
for (int i=0;i<numscans;i++) {
…
scans[i+1]=(TH1F)f->GetObjectChecked(scanname,“TH1F”);//**
…
}
[/code]

** what is this ‘i + 1’? What is the value of i + 1 when i == numscans - 1 (the last iteration) ?
Do you really need valgrind?

[wamlet]

you are right! foiled by indexing… thanks