Segmentation violations in RooStats / RooFit, related to variable range?

Dear experts,

I am experiencing several segmentation violations, in a context that I will try to describe. I am working with a version of ROOT that I compiled last week after pulling the code from git (6.07/07).

The context is that I’m trying to compute limits, using the RooStats tutorial macro StandardHypoTestInvDemo.C and using the asymptotic calculator. The input workspace contains a combined dataset with two categories (indexed with a RooCategory).

When I run this macro, I get a segmentation violation with the following trace:

Interestingly, I notice another (probably related) crash, when I try to fit the data myself. The fits converges without error only if I provide at least one of the following options to RooAbsPdf::fitTo(): Range(“MassWindow”), or NumCPU(2). If I don’t, most of the time (but not always?) I get a segmentation violation with a trace like the following one:

The second trace in particular makes me think that it is something related to the ranges of my observable (invariant mass, named “invMass”). Indeed, we start from a wide mass window and then reduce the dataset to a narrower one (with a range that we call “MassWindow”). I wonder if it could be that the invMass “version” has different ranges / binnings (different number of them or different names) in the dataset, the pdf, or the different components of them. In any case, I have tried a few things following this assumption, but without success.

Thanks a lot in advance for your help.

Émilien Chapon


Can you please post your workspace and a minimal macro fitting your model, so I can reproduce the crash ?Otherwise it is difficult to understand the cause of your problem

Best Regards


Hi Lorenzo,

Unfortunately my workspace contains CMS data which is not public and that I would rather not release freely on a forum. I have sent you a private message pointing you to an archive with some macros and workspaces to reproduce the issue. If anyone else would want to have a look, I can point them privately to the same archive. I will try to reproduce the issue with dummy data, so that I can make it public.


I have generated pseudo-data, so that the crash can be reproduced without using CMS data. The archive is accessible at the address

If I summarize our workflow: we consider fits of the invariant mass of two dimuons, separately in pp and PbPb collisions, and then combine these two workspaces into one (using the combinedWorkspace.C macro – the connection between pp and PbPb is that we express the yield of psi prime meson in PbPb as a function as the one in pp). At last we want to derive Feldman-Cousins intervals on our observable (the double ratio [N(psi’)/N(J/psi)]_PbPb / [N(psi’)/N(J/psi)]_pp, named RFrac2Svs1S_PbPbvsPP in the workspace) using runLimit_RaaNS_Workspace.C.

You can reproduce the first crash with the following:

You may also reproduce the second crash with the following:

Despite further investigation on my side, I haven’t found yet why I get this crash. I thought I’d share one of my findings though: it looks like the crash happens when the program encounters a pointer of the form 0x3ff0000000000000 (which is of course far beyond the range for the memory I have), either for _htableName in RooLinkedList::~RooLinkedList(), or for elem in void RooLinkedList::Delete(Option_t *). But I have no idea how this address gets corrupted…

Always try to precompile your macro using ACLiC, in order to find source code problems, e.g. try something like (inspect all reported warnings and errors):
root [0] .L YourRootMacro.cxx++

You can “debug” many problems using “valgrind”. See, for example: Segmentation Fault depending on linux distribution