Unknown cause of segmentation violation when using RDataFrame

ROOT crashes when I run the following macro, but I have no idea why.
No “barbarbar” in output, so it seems thet my macro crashes when drawing the histogram.
I would appreciate if you could help me.
I’m a beginner at RDataFrame. Please forgive me if the cause is my lack of understanding about RDataFrame.

int myMacro()
    auto fileName = "target.root";
    auto treeName = "tree";

    auto c = new TCanvas();

    ROOT::RDataFrame df(treeName, fileName);

    auto sq = [](double x){ return x*x; };
    auto h_squared = df.Define("sq", sq, {"Esum"})
                       .Histo1D({"h_squared", "test", 1000, 0, 10000}, {"sq"});

    std::cout << "foofoofoo" << std::endl;
    std::cout << "barbarbar" << std::endl;
    return 0;


[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCore.so] TUnixSystem::DispatchSignals(ESignals) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCore.so] SigHandler(ESignals) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCore.so] sighandler(int) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCore.so] textinput::TerminalConfigUnix::HandleSignal(int) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCore.so] (anonymous namespace)::TerminalConfigUnix__handleSignal(int) (no debug info)
[/usr/lib/system/libsystem_platform.dylib] _sigtramp (no debug info)
[/Users/harada/SingleBeta/Fitting_with_BG/kaiseki_cpp.so] void ROOT::Internal::RDF::InitRDFValues<std::__1::tuple<ROOT::Internal::RDF::RColumnValue<double> >, 0ul>(unsigned int, std::__1::tuple<ROOT::Internal::RDF::RColumnValue<double> >&, TTreeReader*, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, ROOT::Internal::RDF::RBookedCustomColumns const&, std::__1::integer_sequence<unsigned long, 0ul>, std::__1::array<bool, sizeof...(0ul)> const&) (no debug info)
[<unknown binary>] (no debug info)
[<unknown binary>] (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libROOTDataFrame.so] ROOT::Internal::RDF::RJittedAction::InitSlot(TTreeReader*, unsigned int) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libROOTDataFrame.so] ROOT::Detail::RDF::RLoopManager::InitNodeSlots(TTreeReader*, unsigned int) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libROOTDataFrame.so] ROOT::Detail::RDF::RLoopManager::RunTreeReader() (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libROOTDataFrame.so] ROOT::Detail::RDF::RLoopManager::Run() (no debug info)
[/Users/harada/SingleBeta/Fitting_with_BG/kaiseki_cpp.so] ROOT::RDF::RResultPtr<TH1D>::TriggerRun() (no debug info)
[/Users/harada/SingleBeta/Fitting_with_BG/kaiseki_cpp.so] ROOT::RDF::RResultPtr<TH1D>::Get() (no debug info)
[/Users/harada/SingleBeta/Fitting_with_BG/kaiseki_cpp.so] ROOT::RDF::RResultPtr<TH1D>::operator->() (no debug info)
[/Users/harada/SingleBeta/Fitting_with_BG/kaiseki_cpp.so] kaiseki() (no debug info)
[<unknown binary>] (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCling.so] cling::IncrementalExecutor::executeWrapper(llvm::StringRef, cling::Value*) const (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCling.so] cling::Interpreter::RunFunction(clang::FunctionDecl const*, cling::Value*) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCling.so] cling::Interpreter::EvaluateInternal(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, cling::CompilationOptions, cling::Value*, cling::Transaction**, unsigned long) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCling.so] cling::Interpreter::process(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, cling::Value*, cling::Transaction**, bool) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCling.so] cling::MetaProcessor::process(llvm::StringRef, cling::Interpreter::CompilationResult&, cling::Value*, bool) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCling.so] HandleInterpreterException(cling::MetaProcessor*, char const*, cling::Interpreter::CompilationResult&, cling::Value*) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCling.so] TCling::ProcessLine(char const*, TInterpreter::EErrorCode*) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCling.so] TCling::ProcessLineSynch(char const*, TInterpreter::EErrorCode*) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCore.so] TApplication::ExecuteFile(char const*, int*, bool) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCore.so] TApplication::ProcessFile(char const*, int*, bool) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libCore.so] TApplication::ProcessLine(char const*, bool, int*) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libRint.so] TRint::ProcessLineNr(char const*, char const*, int*) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/lib/root/libRint.so] TRint::Run(bool) (no debug info)
[/opt/homebrew/Cellar/root/6.22.08_1/bin/root.exe] main (no debug info)
[/usr/lib/system/libdyld.dylib] start (no debug info)

Hi @haltack ,
that’s terrible, something is going wrong in RDataFrame’s internals (the h_noCut->Draw call is where the event loop is run, because of RDF’s lazy execution).

You are the first to see this problem as far as I know. Could you please try this out with the latest ROOT version, 6.24, and/or provide a reproducer I can run (e.g. with a small dataset with a few events that I can use to reproduce the crash)?


Hi @eguiraud ,
I found that the cause may be somewhere around ACLiC.
I executed gen_tree.cpp to generate the root tile and then executed test.cpp .
If I run test.cpp as root test.cpp, ROOT doesn’t crash. But if run it as root test.cpp+, ROOT crashes.

I’m sorry, but I’m not familiar with installing root not via homebrew. The latest version of ROOT available on homebrew is ver. 6.22.08_1, which I’m using now.

gen_tree.cpp (504 Bytes)
test.cpp (732 Bytes)

Hi @haltack ,
ok, that indicates this might be an interpreter/compiler ABI incompatibility, which would also explain why you are affected by it while other users are not: it depends on the combination of ROOT version and compiler (and the contents of the script, and the phase of the moon, …).
What is your compiler and compiler version?

Thank you for the reproducer, I will take a look as soon as possible.

I attach the information of my compiler.

❯ clang --version
Apple clang version 12.0.5 (clang-1205.0.22.9)
Target: arm64-apple-darwin20.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Hi @haltack ,
I tried 6.22.08, 6.24 and master. Of course “it works on my machine”. But my machine is not a Mac with an ARM processor, so I’ll see what I can do to try the reproducer on that hardware.

Hi @haltack ,
I ran root gen_tree.cpp followed by root test.cpp+ on a Mac node with ARM CPUs after compiling v6.24.00 from source, and it ran correctly.
I cannot try homebrew on that machine, and I’m afraid I cannot reproduce the crash you see.
Do you happen to know whether the crash is reproducible on other Mac + ARM machines?

Pinging @henryiii as this seems to be a hombrew-related issue.


If you want to compile 6.24, you can use the recipe in root 6.24.00 by chenrui333 · Pull Request #75166 · Homebrew/homebrew-core · GitHub - you can even type brew edit root to bring up the file, or you can checkout this repo/branch. It’s broken on 10.14/10.15 until we (@vvassilev and I) can work it out, but should be fine on macOS 11. Use brew install root --build-from-source to force a recompilation once you’ve edited the file.

I’ll try this on my M1, and report what I find.

1 Like

I was able to reproduce. In a little bit I’ll try recompiling ROOT with 6.24.

Thanks @henryiii , then this really looks like a homebrew-specific issue. I can’t think of any workaround besides trying out another ROOT package (see https://root.cern/install ) while this is being resolved.

Henry is there maybe a homebrew issue tracker where we can follow this?

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.