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.
Jean-François
That makes sense. Unfortunately the following code also crashes ROOT. Removing that space has the same result as before.
[code]class Thing
{
public:
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];
}
[/code]
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()
Crash:
.L thing.C
*** Break *** segmentation violation
Generating stack trace...
0x00000001032b309e in G__getexpr (in libCint.so) + 29790
0x000000010329d95e in G__define_var (in libCint.so) + 9646
0x000000010332fd72 in G__exec_statement (in libCint.so) + 25394
0x000000010332cd43 in G__exec_statement (in libCint.so) + 13059
0x00000001032dfcce in G__make_ifunctable(G__FastAllocString&) (in libCint.so) + 29790
0x00000001032a1ac3 in G__define_var (in libCint.so) + 26387
0x00000001033303cd in G__exec_statement (in libCint.so) + 27021
0x00000001032f6df8 in G__loadfile (in libCint.so) + 7256
0x0000000103337217 in G__reloadfile (in libCint.so) + 711
0x000000010333a91b in G__process_cmd (in libCint.so) + 11915
0x0000000102b1e4c0 in TCint::ProcessLine(char const*, TInterpreter::EErrorCode*) (in libCore.so) + 928
0x0000000102a7af1b in TApplication::ProcessLine(char const*, bool, int*) (in libCore.so) + 2027
0x000000010395a3e3 in TRint::HandleTermInput() (in libRint.so) + 659
0x0000000103958a87 in TTermInputHandler::Notify() (in libRint.so) + 23
0x000000010395aaed in TTermInputHandler::ReadNotify() (in libRint.so) + 13
0x0000000102b568be in TUnixSystem::CheckDescriptors() (in libCore.so) + 318
0x0000000102b5f30a in TMacOSXSystem::DispatchOneEvent(bool) (in libCore.so) + 394
0x0000000102adc9ca in TSystem::InnerLoop() (in libCore.so) + 26
0x0000000102adc82e in TSystem::Run() (in libCore.so) + 206
0x0000000102a7bac4 in TApplication::Run(bool) (in libCore.so) + 36
0x0000000103959d3c in TRint::Run(bool) (in libRint.so) + 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 libCint.so.
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.
Jean-François
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.