This code crashes ROOT

I wanted to use Jira but I don’t have a CERN account. Sorry if I’m being inappropriate.

I’m running version 5.34/24 on Windows 7. I have the following code in a file.

void f() { const long * const a = 0; const long b = a[0]; }

If I .L this file, ROOT crashes.

The following equivalent code does not crash ROOT.

void f() { const long* const a = 0; //Note the missing space const long b = a[0]; }

I’m not an expert at this stuff, but here’s my take:

Dereferencing a null pointer is undefined behaviour. Undefined behaviour means that anything could happen. That you observe a crash or not depending on a space does not mean that the space is responsible, as it’s probably just that one case tries to access allocated memory, and the other tries to access unallocated memory. Both are UB, but your memory protection is kicking in for one case but not the other, causing the crash.


That makes sense. Unfortunately the following code also crashes ROOT. Removing that space has the same result as before.

[code]class Thing
Thing(const int n) { p = new long[n]; }
long* p;

void foo()
Thing b(16);
const long * bp = b.p;
const long r = bp[0];

I can confirm that with my ROOT 5.34/18, the code in your reply has the following behavior. Suppose I save it in a file thing.C.

No crash:

.L thing.C++ foo()

.L thing.C
 *** Break *** segmentation violation
 Generating stack trace...
 0x00000001032b309e in G__getexpr (in + 29790
 0x000000010329d95e in G__define_var (in + 9646
 0x000000010332fd72 in G__exec_statement (in + 25394
 0x000000010332cd43 in G__exec_statement (in + 13059
 0x00000001032dfcce in G__make_ifunctable(G__FastAllocString&) (in + 29790
 0x00000001032a1ac3 in G__define_var (in + 26387
 0x00000001033303cd in G__exec_statement (in + 27021
 0x00000001032f6df8 in G__loadfile (in + 7256
 0x0000000103337217 in G__reloadfile (in + 711
 0x000000010333a91b in G__process_cmd (in + 11915
 0x0000000102b1e4c0 in TCint::ProcessLine(char const*, TInterpreter::EErrorCode*) (in + 928
 0x0000000102a7af1b in TApplication::ProcessLine(char const*, bool, int*) (in + 2027
 0x000000010395a3e3 in TRint::HandleTermInput() (in + 659
 0x0000000103958a87 in TTermInputHandler::Notify() (in + 23
 0x000000010395aaed in TTermInputHandler::ReadNotify() (in + 13
 0x0000000102b568be in TUnixSystem::CheckDescriptors() (in + 318
 0x0000000102b5f30a in TMacOSXSystem::DispatchOneEvent(bool) (in + 394
 0x0000000102adc9ca in TSystem::InnerLoop() (in + 26
 0x0000000102adc82e in TSystem::Run() (in + 206
 0x0000000102a7bac4 in TApplication::Run(bool) (in + 36
 0x0000000103959d3c in TRint::Run(bool) (in + 1436
 0x0000000102a71e1f in main (in root.exe) + 79
 0x00007fff90dd75fd in start (in libdyld.dylib) + 1
Root > 

I also tried with ROOT6. I tried .L thing.C, .L thing.C++, and #include “thing.C” (and executing foo() after), and none of them crash. Thus it’s probably something CINT-specific, since ROOT6 doesn’t use CINT. I guess if I read the traceback I would have been able to see that too, it occurs somewhere in

Usually this is the point where an expert tells you to open a ticket in JIRA. I was able to get a lightweight CERN account that allows me to post in JIRA, even though I’m not a CERN user. If you don’t want to go through the hassle, I can open the ticket for you.


Perhaps related, also

double* p;

crashes ROOT 5.xx (unresolved issue ROOT-5341).

Would you please? I appreciate it. I’d get the account but I don’t think I’m going to stick with ROOT. It has some great features but it just doesn’t feel solid. I’ll come back when v6 is out.