Crash when object allocated on stack but not when on heap

[Viesturs]

If I allocate an object on stack

TH1F h("histo", "histo", 100, 0, 100);

there is a crash. The problem is resolved when the object is instead allocated on heap:

TH1F * h = new TH1F("histo", "histo", 100, 0, 100);

The two methods should be the same, but apparently there is some difference. What exactly?

[pcanal]

Where/When did it crash? What was the stack trace?

[Viesturs]

The stack trace starts at the line

TH1F h("histo", "histo", 100, 0, 100);

and ends with

#0  0x00007ffacf55082e in waitpid () from /lib64/libc.so.6
#1  0x00007ffacf4e2479 in do_system () from /lib64/libc.so.6
#2  0x00007ffad1d22a89 in TUnixSystem::StackTrace() () from /cvmfs/cms.cern.ch/slc6_amd64_gcc530/cms/cmssw-patch/CMSSW_8_0_26_patch1/external/slc6_amd64_gcc530/lib/libCore.so
#3  0x00007ffad1d2498c in TUnixSystem::DispatchSignals(ESignals) () from /cvmfs/cms.cern.ch/slc6_amd64_gcc530/cms/cmssw-patch/CMSSW_8_0_26_patch1/external/slc6_amd64_gcc530/lib/libCore.so
#4  <signal handler called>
#5  _Unwind_Resume (exc=exc
entry=0x0) at ../../../libgcc/unwind.inc:229

[pcanal]

Which version of ROOT, OS and compiler are you using? (i.e. this is surprinsing, this is a common operation that usually work). Can you also run the failing case under valgrind?

[Viesturs]

ROOT version 6.06/01
Scientific Linux CERN SLC release 6.9 (Carbon)
Compiled by running

scram b -j9

of CMSSW_8_0_26_patch1

The valgrind output is rather cryptic consisting of blocks like

==11164== 42,196 bytes in 193 blocks are still reachable in loss record 273 of 273
==11164==    at 0x4027C00: malloc (in /cvmfs/cms.cern.ch/slc6_amd64_gcc530/external/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11164==    by 0x466742: xmalloc (in /bin/bash)
==11164==    by 0x438980: ??? (in /bin/bash)
==11164==    by 0x438C5E: maybe_make_export_env (in /bin/bash)
==11164==    by 0x42F4EB: ??? (in /bin/bash)
==11164==    by 0x430462: execute_command_internal (in /bin/bash)
==11164==    by 0x43110D: execute_command (in /bin/bash)
==11164==    by 0x41D6D5: reader_loop (in /bin/bash)
==11164==    by 0x41CEBB: main (in /bin/bash)

[Viesturs]

I later discovered a bug in my code of the type:

int x [] = {2, 3};
int y = x[2];

Fixing this problems allows now to allocate a histogram on stack. I think this bug caused a cryptic error elsewhere.