ROOT crash without error msg accessing factory edit pdf ws saved in another file

[RongkunWang]

Hello ROOT and RooStat experts,

I’m wondering if RooWorkspace::Write is a bit deprecated after factory is used to modify pdf in the workspace? Because the modified RooWorkspace is not accessible after written to a new file. The input workspace is produced from HistFactory. This does not happen if I try to setup a slc6 version of root with the same version, same compiler.

Here’s the env I used
source /cvmfs/sft.cern.ch/lcg/views/LCG_96b/x86_64-centos7-gcc8-opt/setup.sh
source /cvmfs/sft.cern.ch/lcg/releases/LCG_96b/ROOT/6.18.04/x86_64-centos7-gcc8-opt/bin/thisroot.sh

Reproductive snippet.

TFile *file = TFile::Open("/afs/cern.ch/user/r/rowang/public/WS_toy.root", "read");
RooWorkspace* w = (RooWorkspace*)file->Get("combined");
w->factory("mu[1, 0, 10]");
w->factory("EDIT::simPdf_kappa(simPdf,  mu_ggF=mu, mu_VBF=mu, mu_VH=mu, mu_ttH=mu)");
w->writeToFile("test_output.root");

Afterwards, I do those below. Then it crashes without messages.

root -l test_output.root
root [1] combined->Print()
rowang@lxplus783 ~/public

Thanks!

---

ROOT Version: 6.18.04
Platform: lxplus7
Compiler: x86_64-centos7-gcc8-opt

---

– RK

[StephanH]

Hi @RongkunWang,

it’s not supposed to be deprecated, but mistakes happen. I’ll try to open it.

Update:
I suspect a bug, so I opened a bug report.
https://sft.its.cern.ch/jira/browse/ROOT-10564

[StephanH]

Hello @RongkunWang,

it’s not a bug, but it’s a nasty problem. Your setup doesn’t allow for enough stack space, but the workspace requires a lot of stack space to read it. See
ulimit -s for the amount of stack space, and e.g. double it. After I did this, the workspace was read fine, I could write it according to your example, and after adding
file->Close()
the file was written. That file I could also read back. That was on ROOT’s master, though, so please check with your version.

[RongkunWang]

Hello @StephanH,

Thanks for your reply. Very interesting issue! I tried ulimit -s unlimited on lxplus and it works.

Instead of always having to call “ulimit -s XXX” for this kind of work, is there a cleaner way to treat it at the workspace production step? I see that after a new pdf is created, the old pdf is still there. Does removing that old pdf help?

[StephanH]

No, it is unlikely that this will help. Or if it helps, it may help for one PDF, but not for three etc. What you can do is to set up your bashrc such that it automatically increases the stack size whenever you log in. Don’t use unlimited, though, because programming errors might exhaust all the stack memory. It’s better if your process gets killed in that case.

[RongkunWang]

Hi StephanH

ok thanks. It would just a bit confusing for people to find out that suddenly their ws is unreadable in the default setting in lxplus.

[StephanH]

I totally agree. It’s unfortunate that ulimit doesn’t give you any message when the process gets killed.