root-project / root Goto Github PK
View Code? Open in Web Editor NEWThe official repository for ROOT: analyzing, storing and visualizing big data, scientifically
Home Page: https://root.cern
License: Other
root's People
Contributors
Stargazers
Watchers
Forkers
axel-naumann svenkreiss cristinacristescu cranmer daneeq spmohanty gganis agheorghiu utdiscant lmoneta davidlt sudheesh001 cheatiiit gordonwatts mnowakgit dr15jones cms-sw nsmayer zmukwa javirufo adevress beniz rpatkennyiii programdev benni0815 aurelie-flandi tc3t leonidbl91 wesleyklewerton buuck blipp pablodecm kreczko thomaskeck ffelsner cpulvermacher dfunke devkale bbockelm nsmith- krafczyk etejedor zukhaimira akaramaoun pspe swaggerink asmagina jrtomps cirkovic hajduakos pcanal alja alisw ancapopescu13 vukasinmilosevic souvik1982 eguiraud sbinet freesciencecommunity iguinn zhaomr13 oprojects perovic zzxuanyuan duraznos remenska zonemo bbbloyyer ellert daivdoux evgeny-boger nilqed simabaymani behrenhoff osschar wajidalikhan kepingxie neuroidss jakemurphy0118 holzman qgp le-voyeur troiganto wenliwen64 hageboeck lihe8811 pseyfert thomashauth rassel1304 fablequentin efraintorlo olegjakushkin y-- xvallspl rohinarora mehulsr amoudgl geektoni mgheata rsmith54root's Issues
Debug builds in nightlies (and releases)
Problem
It is more efficient to debug applications relying on ROOT having a debug ROOT build.
Solution I would like
Provide debug builds for nightlies (and optionally for releases).
Alternatives
-
Debug on Linux with released ROOT works perfectly for standard RedHat distros ( the others are less relevant ).
This is a very good alternative (thanks to Mattias!), but Linux-only and release-only. -
Building from the sources is a very-very bad alternative, as the created builds cannot be transferred elsewhere, i.e. shared with collaborators. Another reason why this is a bad alternative: building with the full configuration on Mac in a reasonable time requires a lot of CPU power, much more than a single user laptop can provide.
Add documentation for ROOT::RDF::RunGraphs
We are missing further documentation for ROOT::RDF::RunGraphs. Most important, we should explain the feature in the main doxygen docs of RDataFrame. Further, we could probably add a tutorial or just add it to the ATLAS Open Data tutorials in df10*.py.
[ntuple] Off-by-one-byte error when deserializing arrays as RVecs
Reading RVecs with RNTuple incurs in an off-by-one-byte error, because all RVec<T> are deserialized as std::vector<char>, but the position of the data buffer is different for RVecs:
>>> p ((ROOT::VecOps::RVec<int>*)0x5555596c72a0)->data()
$983 = (int *) 0x5555581b2918
>>> p ((std::vector<char, std::allocator<char> > *)0x5555596c72a0)->data()
$984 = 0x5555581b2910
I think the problematic logic is here.
A second issue related to RVecs is that at RField.cxx:638 we use RVectorField for reading RVecs, but this means that the parent RField will have type name std::vector<...> even if it should (probably?) be RVec<...>.
#6336 contains a reproducer.
Failed compilation leaves cling in a "bad state"
To Reproduce
The first line executed is invalid C++ code, and cling rightly complains. The second line is valid code, but cling does not seem to be able to compile it after the previous compilation failure. Opening a new ROOT prompt and directly inserting the valid code works fine.
~ root -l
root [0] ROOT::RDataFrame(10).Define("x", [] { return 42; }).Snapshot<int>("t", "f.root");
ROOT_prompt_0:1:53: error: no matching member function for call to 'Snapshot'
/*** snip ***/
root [1] ROOT::RDataFrame(10).Define("x", [] { return 42; }).Snapshot<int>("t", "f.root", {"x"});
IncrementalExecutor::executeFunction: symbol '_ZStanSt12memory_orderSt23__memory_order_modifier' unresolved while linking [cling interface function]!
You are probably missing the definition of std::operator&(std::memory_order, std::__memory_order_modifier)
Maybe you need to load the corresponding shared library?
Setup
ROOT master@3ae45ea5f9, RelWithDebInfo.
I could not reproduce with master@dcac6e1bf0, Debug build type.
The 6.22.02 conda package also seems to be affected.
Floating point exception in TCanvas
Describe the bug
Crash.
[host@hermes Desktop]$ g++ canvas.cxx $(root-config --glibs --cflags --libs) -o canvas -g
[host@hermes Desktop]$ ./canvas
*** Break *** floating point exception
===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
gdb.printing.register_pretty_printer(gdb.current_objfile(),
#0 0x00007f481d5d946c in __libc_waitpid (pid=1478152, stat_loc=stat_loc
entry=0x7ffe12925160, options=options
entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:31
#1 0x00007f481d556f62 in do_system (line=<optimized out>) at ../sysdeps/posix/system.c:148
#2 0x00007f4821f685dc in TUnixSystem::StackTrace (this=0x244d980) at /usr/src/debug/root-6.22.02/core/unix/src/TUnixSystem.cxx:2408
#3 0x00007f4821f6b06a in TUnixSystem::DispatchSignals (this=0x244d980, sig=kSigFloatingException) at /usr/src/debug/root-6.22.02/core/unix/src/TUnixSystem.cxx:3646
#4 <signal handler called>
#5 TPad::ResizePad (this=0x2503ca0, option=0x7f4820490bae "") at /usr/src/debug/root-6.22.02/graf2d/gpad/src/TPad.cxx:5490
#6 0x00007f4820448f84 in TCanvas::Build (this=0x2503ca0) at /usr/src/debug/root-6.22.02/graf2d/gpad/src/TCanvas.cxx:637
#7 0x00007f482044969e in TCanvas::Constructor (this=this
entry=0x2503ca0, name=name
entry=0x400cc3 "canvas", title=title
entry=0x400cc3 "canvas", ww=4, ww
entry=-4, wh=wh
entry=-28) at /usr/src/debug/root-6.22.02/graf2d/gpad/src/TCanvas.cxx:425
#8 0x00007f482044c88c in TCanvas::TCanvas (this=0x2503ca0, name=0x400cc3 "canvas", title=0x400cc3 "canvas", ww=-4, wh=-28) at /usr/src/debug/root-6.22.02/graf2d/gpad/src/TCanvas.cxx:366
#9 0x0000000000400ba3 in main (argc=1, argv=0x7ffe12927dc8) at canvas.cxx:5
===========================================================
The lines below might hint at the cause of the crash.
You may get help by asking at the ROOT forum http://root.cern.ch/forum
Only if you are really convinced it is a bug in ROOT then please submit a
report at http://root.cern.ch/bugs Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5 TPad::ResizePad (this=0x2503ca0, option=0x7f4820490bae "") at /usr/src/debug/root-6.22.02/graf2d/gpad/src/TPad.cxx:5490
#6 0x00007f4820448f84 in TCanvas::Build (this=0x2503ca0) at /usr/src/debug/root-6.22.02/graf2d/gpad/src/TCanvas.cxx:637
#7 0x00007f482044969e in TCanvas::Constructor (this=this
entry=0x2503ca0, name=name
entry=0x400cc3 "canvas", title=title
entry=0x400cc3 "canvas", ww=4, ww
entry=-4, wh=wh
entry=-28) at /usr/src/debug/root-6.22.02/graf2d/gpad/src/TCanvas.cxx:425
#8 0x00007f482044c88c in TCanvas::TCanvas (this=0x2503ca0, name=0x400cc3 "canvas", title=0x400cc3 "canvas", ww=-4, wh=-28) at /usr/src/debug/root-6.22.02/graf2d/gpad/src/TCanvas.cxx:366
#9 0x0000000000400ba3 in main (argc=1, argv=0x7ffe12927dc8) at canvas.cxx:5
===========================================================
Expected behavior
No FPE.
To Reproduce
Code
#include <TCanvas.h>
#include <fenv.h>
int main(int argc, char **argv) {
feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW);
TCanvas* C= new TCanvas("canvas","canvas",-4,-28);
return 0;
}
Compile
g++ canvas.cxx $(root-config --glibs --cflags --libs) -o canvas -g
run
./canvas
Setup
CentOS7 x86_64 with root-6.22.02 from EPEL
(Same as on lxplus)
Additional context
This is a continuation of #6344
Problem with "using namespace std" in generated dictionary files
In the autogenerated dictionary sources I see
// Since CINT ignores the std namespace, we need to do so in this file.
namespace std {} using namespace std;
(this is from 6.14.08. 6.22.02 has a slightly different comment of The generated code does not explicitly qualifies STL entities (sic), but still does the using...)
This is placed very early on, even before the include of the header files passed as arguments.
Unfortunately, this causes problems, specifically when one of those header files pulls in Kokkos core headers, and there's a name clash with rank which is a free function in the kokkos namespace, and std::rank.
/opt/kokkos/cuda/3.2-shlib/include/Kokkos_View.hpp:1896:30: error: return type specified for deduction guide
KOKKOS_INLINE_FUNCTION constexpr unsigned rank(const View<D, P...>& V) {
^
/opt/kokkos/cuda/3.2-shlib/include/Kokkos_View.hpp:1895:42: error: decl-specifier in declaration of deduction guide
template <typename D, class... P>
^
/opt/kokkos/cuda/3.2-shlib/include/Kokkos_View.hpp:1895:32: error: decl-specifier in declaration of deduction guide
template <typename D, class... P>
^~
/opt/kokkos/cuda/3.2-shlib/include/Kokkos_View.hpp:1896:30: error: 'signed' or 'unsigned' invalid for '__dguide_rank'
KOKKOS_INLINE_FUNCTION constexpr unsigned rank(const View<D, P...>& V) {
^
/opt/kokkos/cuda/3.2-shlib/include/Kokkos_View.hpp:1896:1: error: deduction guide for 'std::rank< <template-parameter-1-1> >' must have trailing return type
KOKKOS_INLINE_FUNCTION constexpr unsigned rank(const View<D, P...>& V) {
^~~~
/bld4/opt/gcc/8.4.0/include/c++/8.4.0/type_traits:1251:8: note: 'template<class> struct std::rank' declared here
struct rank
^~~~
Is there any way to make the using namespace appear AFTER the include of the user header files instead of before?
If I manually edit the generated file, and move the using namespace to after the includes, it compiles fine.
FWIW, the actual compilation is done with nvcc 11, and c++17.
thanks, Charles.
PyROOT cannot call templated ctors on Windows
Describe the bug
Templated ctors cannot be called on Windows because demangling of the constructor template (!) fails - likely because there is no mangling standard for the template. See https://github.com/root-project/root/blob/master/bindings/pyroot/cppyy/cppyy-backend/clingwrapper/src/clingwrapper.cxx#L1693
Expected behavior
Template ctor should be called.
To Reproduce
@hageboeck has it.
Setup
Master, with MSVC.
Additional context
Instead of demangling and looking for '<' we could add a new interface: TFunction::-is-this-a-template.
`\brief`s have disappeared from the tutorials
Describe the bug
Listings in the tutorials groups were showing \briefs in the past. Compare
https://root.cern/doc/master/group__tutorial__roofit.html
https://root.cern/doc/v622/group__tutorial__roofit.html
with
https://root.cern/doc/v620/group__tutorial__roofit.html
Fedora 32 test failures
After https://sft.its.cern.ch/jira/browse/ROOT-10849 is fixed, we are now left with three test failures:
- projectroot.roottest.root.io.uniquePointer.roottest_root_io_uniquePointer_simpleWriteRead
- projectroot.roottest.root.io.uniquePointer.roottest_root_io_uniquePointer_simpleRead
- projectroot.roottest.root.meta.ROOT-7462.roottest_root_meta_ROOT_7462_make
[DF] Jitted Min method breaks with RVec columns
Describe the bug
Jitted Min calls break with RVec columns, although they work fine with scalars and if the RVec type is passed explicitly as a template parameter. Max is not affected.
To Reproduce
#include <ROOT/RDataFrame.hxx>
#include <ROOT/RVec.hxx>
int main() {
auto df = ROOT::RDataFrame(1).Define("x", [] { return ROOT::RVec<float>{1,2,3}; });
df.Max<ROOT::RVec<float>>("x").GetValue();
df.Min<ROOT::RVec<float>>("x").GetValue();
df.Max("x").GetValue();
df.Min("x").GetValue(); // this one breaks at runtime
return 0;
} Setup
ROOT 6.22.02
Additional context
First reported on the forum.
Build performance does not scale to many cores/threads
Explain what you would like to see improved
I know that this is a very first world problem, but it has been bugging me since a while. The build of ROOT using its CMake setup is not scaling well to many core systems at all. 😦
This is a snapshot of how ROOT 6.20/08 used my system's resources during its build:
The build starts "pretty much" at the left hand side of the timeline, and lasts until "pretty much" the right hand side of it.
As you can see, the build starts out very well. Building LLVM scales perfectly to 64 threads. And I believe it would scale well to even beyond that. But once the LLVM build is done, many bottlenecks show up. First there is a big bottleneck with building libCling and rootcling, but after that the build of libRIO is also taking a surprising amount of time. And the build is stuck waiting for all of these.
Towards the end things improve a bit once more, as many libraries / source files can build in parallel once more. But even then, very rarely does the build manage to make use of all of the available cores.
Optional: share how it could be improved
From a quick glance it seems that ROOT's CMake configuration sets up way too many unnecessary dependencies between its build targets. Most of the issues seem to arise from how the dictionary generation is set up as far as I can see.
In ATLAS I use the following code to set up the generation of dictionary source files:
And that provides a much better behaviour. Mainly because in ATLAS's setup dictionary generations do not need to wait for anything. Even if the library that a dictionary is being produced for depends on a number of upstream libraries, the dictionary for that library can be generated before all the upstream libraries would have finished building. In practice this actually means that the start of any ATLAS software build is dominated by running dictionary generation. As GNU Make and Ninja both prefer running those build steps first. (As they do not have any dependencies themselves.)
The reason I blame the dictionary generation code is that regular C(++) code building with Ninja scales very well to many cores. Even when one has many small libraries in a project, Ninja can start the build of object files before all of the libraries that they depend on would've finished building. (In ATLAS's offline software the very end of a build is taken up purely by library/executable linking steps.)
To Reproduce
Unfortunately you need a pretty powerful machine to do so... But once you do, just do something similar to what I did:
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD=17 \
-Dall=ON -Dbuiltin_gsl=ON -Dbuiltin_freetype=ON -Dbuiltin_lzma=ON -Dbuiltin_veccore=ON \
-DXROOTD_ROOT_DIR=~/software/xrootd/4.12.2/x86_64-ubuntu2004-gcc9-opt \
-DTBB_ROOT_DIR=~/software/oneTBB/2020.2/x86_64-ubuntu2004-gcc9-opt \
-DCMAKE_INSTALL_PREFIX=~/software/root/6.20.08/x86_64-ubuntu2004-gcc9-opt ../root-6.20.08/
ninja
Setup
As mentioned earlier, I used ROOT 6.20/08 for this particular test. But the behaviour has been like this since forever. I performed the build on Ubuntu 20.04 with GCC 9, but that should make little difference to the overall behaviour.
Additional context
N/A
[Hist] TGraph::Sort when already sorted
Currently, TGraph::Sort does not check if the data is already sorted (stored in bit TGraph::kIsSortedX). For the implemented quicksort, sorting already sorted data is the worst case performance scenario, so I believe a check would be helpful.
Since the user can supply a custom greaterfunc, a check similar to
Line 2394 in 1dba738
TBulkRead fails with "fExtraBasket should have been set to nullptr by GetFreshBasket"
Describe the bug
I am trying to use the new TBulkRead API. I have a set of branches that I read with (updated with full reproducer):
#include <TBufferFile.h>
#include <TFile.h>
#include <TTree.h>
#include <iostream>
void foo() {
auto f = TFile::Open("http://hyperloop.cern.ch/train-workdir/testdata/LFN/alice/data/2015/LHC15o/000245064/pass5_lowIR/PWGZZ/Run3_Conversion/71_20200915-2255_child_1/0935/AO2D.root");
auto t = (TTree*)f->Get("O2track");
auto e = t->GetEntries();
auto b = t->GetBranch("fAlpha");
assert(b);
int pos = 0;
while (pos < e) {
TBufferFile buf(TBuffer::EMode::kWrite, 32*1024);
auto &r = b->GetBulkRead();
auto s = r.GetBulkEntries(pos, buf);
pos += s;
std::cout << "Read " << s << " elements " << std::endl;
b->Print();
}
}however when I get to read the last but one buffer, I get:
Read 1000 elements
*Br 3398 :fAlpha : fAlpha/F *
*Entries : 3399743 : Total Size= 13939349 bytes File Size = 11798760 *
*Baskets : 3399 : Basket Size= 1000 bytes Compression= 1.17 *
*............................................................................*
Fatal: fExtraBasket == nullptr && "fExtraBasket should have been set to nullptr by GetFreshBasket" violated at line 1474 of `/Users/ktf/src/sw/SOURCES/ROOT/v6-20-02-alice7/v6-20-02-alice7/tree/tree/src/TBranch.cxx'
abortingExpected behavior
Reading all the baskets, with the last one returning the appropriate number of entries.
To Reproduce
Setup
6.20.0
Additional context
TFile with a few TTree in it, all the branches have basic types or arrays of basic types.
TH1 Integral incorrectly returns nan
Dear ROOT experts
I have produced some neural network output score, which I exported to ROOT histograms using uproot (as I am more familiar with that than pyROOT), so that I could set limits using the Higgs Combine tool. However in the Higgs Combine tool I encountered errors due to these histograms having nan integral. I presumed this problem may just have been caused by me outputting the histogram incorrectly, however when I investigated one of these histograms I found it had the property that hist.Integral(100, 100) gives nan, but hist.GetBinContent(100) gives 0.0, when I would assume these should always give the same result. What is the difference between these, please, and can anyone advise on where I might be going wrong?
Thank you
Dominic Stafford
TBulkRead does not work when TFile is missing
Standalone TTree does not allow for TBulkRead
I created a standalone TTree, without a backing TFile, for test purposes. While using TTreeReader works just fine, using TBulkRead does not work.
Expected behavior
Given the API to request a TBulkRead does not involve a TFile, I would have expected it to work without.
Setup
6.20.0
Floating point exceptions in TColor class.
Describe the bug
Floating point exception on OSX 10.15 with XCode11 (and others).
317.486847 427.758362 53.922855
212.467392 0.529984 94.476196
*** Break *** floating point exception
[/usr/lib/system/libsystem_platform.dylib] _sigtramp (no debug info)
[<unknown binary>] (no debug info)
[/Users/user/Projects/xxx/root/lib/libCore.6.22.so] TColor::SetRGB(float, float, float) (no debug info)
[/Users/user/./color] main /Users/user/color.cxx:89
[/usr/lib/system/libdyld.dylib] start (no debug info)
[<unknown binary>] (no debug info)
Expected behavior
No FPEs
To Reproduce
Code:
//
// main.cxx
#include <iostream>
#include <stdlib.h>
#include <TColor.h>
#include <TRandom.h>
#include <fenv.h>
#ifndef HAVE_FEENABLEEXCEPT
#if defined(__APPLE__) && defined(__MACH__)
// Public domain polyfill for feenableexcept on OS X
// http://www-personal.umich.edu/~williams/archive/computation/fe-handling-example.c
inline int feenableexcept(unsigned int excepts)
{
static fenv_t fenv;
unsigned int new_excepts = excepts & FE_ALL_EXCEPT;
// previous masks
unsigned int old_excepts;
if (fegetenv(&fenv)) {
return -1;
}
old_excepts = fenv.__control & FE_ALL_EXCEPT;
// unmask
fenv.__control &= ~new_excepts;
fenv.__mxcsr &= ~(new_excepts << 7);
return fesetenv(&fenv) ? -1 : old_excepts;
}
inline int fedisableexcept(unsigned int excepts)
{<!--
static fenv_t fenv;
unsigned int new_excepts = excepts & FE_ALL_EXCEPT;
// all previous masks
unsigned int old_excepts;
if (fegetenv(&fenv)) {
return -1;
}
old_excepts = fenv.__control & FE_ALL_EXCEPT;
// mask
fenv.__control |= new_excepts;
fenv.__mxcsr |= new_excepts << 7;
return fesetenv(&fenv) ? -1 : old_excepts;
}
#else
inline int feenableexcept(unsigned int excepts)
{
#pragma STDC FENV_ACCESS ON
fexcept_t flags;
/* Save current exception flags. */
fegetexceptflag(&flags, FE_ALL_EXCEPT);
feclearexcept(FE_ALL_EXCEPT); /* clear all fp exception conditions */
return fesetexceptflag(&flags, excepts) != 0 ? -1 : flags; /* set new flags */
}
inline int fedisableexcept(unsigned int excepts)
{
#pragma STDC FENV_ACCESS ON
fexcept_t flags;
/* Save current exception flags. */
fegetexceptflag(&flags, FE_ALL_EXCEPT);
feclearexcept(FE_ALL_EXCEPT); /* clear all fp exception conditions */
return fesetexceptflag(&flags, ~excepts) != 0 ? -1 : flags; /* set new flags */
}
#endif
#endif
int main(int argc, char **argv) {
feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW);
TColor* c= new TColor();
TRandom* r= new TRandom();
float rgb[3];
//c->SetRGB(212.467392, 0.529984, 94.476196);
for (size_t i=0; i<1000000;i++)
{
rgb[0]=512*(1.0-r->Rndm());
rgb[1]=512*(1.0-r->Rndm());
rgb[2]=512*(1.0-r->Rndm());
printf("%f %f %f\n",rgb[0],rgb[1],rgb[2]);
c->SetRGB(rgb[0],rgb[1],rgb[2]);
}
delete c;
delete r;
return 0;
}
Compile
clang++ color.cxx $(root-config --glibs --cflags --libs) -o color
Run
./color
Setup
- ROOT 6.22.02 from the official site that matches XCode.
Additional context
This is similar to #6344 but seen only on Mac.
Floating point exception in TPad
Describe the bug
Crash.
user@lxplus733 ~]$ g++ pad.cxx $(root-config --glibs --cflags --libs) -o pad -g
[user@lxplus733 ~]$ ./pad
Warning in <UnknownClass::SetDisplay>: DISPLAY not set, setting it to pcatlas18.mppmu.mpg.de:0.0
*** Break *** floating point exception
===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
gdb.printing.register_pretty_printer(gdb.current_objfile(),
gdb.printing.register_pretty_printer(gdb.current_objfile(),
#0 0x00007f73109b046c in waitpid () from /lib64/libc.so.6
#1 0x00007f731092df62 in do_system () from /lib64/libc.so.6
#2 0x00007f731533f5dc in TUnixSystem::StackTrace() () from /usr/lib64/root/libCore.so.6.22
#3 0x00007f731534206a in TUnixSystem::DispatchSignals(ESignals) () from /usr/lib64/root/libCore.so.6.22
#4 <signal handler called>
#5 0x00007f7313841eee in TPad::ResizePad(char const*) () from /usr/lib64/root/libGpad.so.6.22
#6 0x00007f731384743a in TPad::TPad(char const*, char const*, double, double, double, double, short, short, short) () from /usr/lib64/root/libGpad.so.6.22
#7 0x0000000000400c6d in main (argc=1, argv=0x7ffd71ee3b98) at pad.cxx:9
===========================================================
The lines below might hint at the cause of the crash.
You may get help by asking at the ROOT forum http://root.cern.ch/forum
Only if you are really convinced it is a bug in ROOT then please submit a
report at http://root.cern.ch/bugs Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5 0x00007f7313841eee in TPad::ResizePad(char const*) () from /usr/lib64/root/libGpad.so.6.22
#6 0x00007f731384743a in TPad::TPad(char const*, char const*, double, double, double, double, short, short, short) () from /usr/lib64/root/libGpad.so.6.22
#7 0x0000000000400c6d in main (argc=1, argv=0x7ffd71ee3b98) at pad.cxx:9
===========================================================
[user@lxplus733 ~]$
Expected behavior
No FPE.
To Reproduce
Code
#include <TCanvas.h>
#include <TPad.h>
#include <fenv.h>
int main(int argc, char **argv) {
feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW);
TCanvas* C= new TCanvas("canvas","canvas",1024,768);
C->cd();
TPad* c= new TPad("my","my",0,1,0,1);
delete c;
delete C;
return 0;
}
compile
g++ pad.cxx $(root-config --glibs --cflags --libs) -o pad -g
run
./pad
Setup
ROOT 6.22.02 and gcc as installed on lxplus machines.
Additional context
A piece of #6344
Windows CI runs roottest despite build failure
roottest / testing should not be done if the build failed.
Floating point exception in TPad (version 2)
Describe the bug
Crash.
[averbyts@lxplus701 test]$ ./pad2.exe
Warning in <UnknownClass::SetDisplay>: DISPLAY not set, setting it to 91.114.73.210:0.0
*** Break *** segmentation violation
===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0 0x00007fe989ecb46c in waitpid () from /lib64/libc.so.6
#1 0x00007fe989e48f62 in do_system () from /lib64/libc.so.6
#2 0x00007fe98ba740bc in TUnixSystem::StackTrace() () from /cvmfs/sft-nightlies.cern.ch/lcg/views/dev3python3/Wed/x86_64-centos7-gcc10-opt/lib/libCore.so
#3 0x00007fe98ba716d5 in TUnixSystem::DispatchSignals(ESignals) () from /cvmfs/sft-nightlies.cern.ch/lcg/views/dev3python3/Wed/x86_64-centos7-gcc10-opt/lib/libCore.so
#4 <signal handler called>
#5 0x00007fe98b1ddee9 in TPad::FillCollideGrid(TObject*) () from /cvmfs/sft-nightlies.cern.ch/lcg/views/dev3python3/Wed/x86_64-centos7-gcc10-opt/lib/libGpad.so
#6 0x00007fe98b1de2eb in TPad::PlaceBox(TObject*, double, double, double&, double&) () from /cvmfs/sft-nightlies.cern.ch/lcg/views/dev3python3/Wed/x86_64-centos7-gcc10-opt/lib/libGpad.so
#7 0x0000000000401293 in main (argc=<optimized out>, argv=<optimized out>) at /afs/cern.ch/user/a/averbyts/Projects/zevis/test/pad2.cxx:84
===========================================================
The lines below might hint at the cause of the crash.
You may get help by asking at the ROOT forum http://root.cern.ch/forum
Only if you are really convinced it is a bug in ROOT then please submit a
report at http://root.cern.ch/bugs Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5 0x00007fe98b1ddee9 in TPad::FillCollideGrid(TObject*) () from /cvmfs/sft-nightlies.cern.ch/lcg/views/dev3python3/Wed/x86_64-centos7-gcc10-opt/lib/libGpad.so
#6 0x00007fe98b1de2eb in TPad::PlaceBox(TObject*, double, double, double&, double&) () from /cvmfs/sft-nightlies.cern.ch/lcg/views/dev3python3/Wed/x86_64-centos7-gcc10-opt/lib/libGpad.so
#7 0x0000000000401293 in main (argc=<optimized out>, argv=<optimized out>) at /afs/cern.ch/user/a/averbyts/Projects/zevis/test/pad2.cxx:84
===========================================================
[averbyts@lxplus701 test]$
Expected behavior
No FPE.
To Reproduce
Code:
#include <TCanvas.h>
#include <TPad.h>
#include <TH1D.h>
#include <fenv.h>
#ifndef HAVE_FEENABLEEXCEPT
#if defined(__APPLE__) && defined(__MACH__)
// Public domain polyfill for feenableexcept on OS X
// http://www-personal.umich.edu/~williams/archive/computation/fe-handling-example.c
inline int feenableexcept(unsigned int excepts)
{
static fenv_t fenv;
unsigned int new_excepts = excepts & FE_ALL_EXCEPT;
// previous masks
unsigned int old_excepts;
if (fegetenv(&fenv)) {
return -1;
}
old_excepts = fenv.__control & FE_ALL_EXCEPT;
// unmask
fenv.__control &= ~new_excepts;
fenv.__mxcsr &= ~(new_excepts << 7);
return fesetenv(&fenv) ? -1 : old_excepts;
}
inline int fedisableexcept(unsigned int excepts)
{
static fenv_t fenv;
unsigned int new_excepts = excepts & FE_ALL_EXCEPT;
// all previous masks
unsigned int old_excepts;
if (fegetenv(&fenv)) {
return -1;
}
old_excepts = fenv.__control & FE_ALL_EXCEPT;
// mask
fenv.__control |= new_excepts;
fenv.__mxcsr |= new_excepts << 7;
return fesetenv(&fenv) ? -1 : old_excepts;
}
#else
inline int feenableexcept(unsigned int excepts)
{
#pragma STDC FENV_ACCESS ON
fexcept_t flags;
/* Save current exception flags. */
fegetexceptflag(&flags, FE_ALL_EXCEPT);
feclearexcept(FE_ALL_EXCEPT); /* clear all fp exception conditions */
return fesetexceptflag(&flags, excepts) != 0 ? -1 : flags; /* set new flags */
}
inline int fedisableexcept(unsigned int excepts)
{
#pragma STDC FENV_ACCESS ON
fexcept_t flags;
/* Save current exception flags. */
fegetexceptflag(&flags, FE_ALL_EXCEPT);
feclearexcept(FE_ALL_EXCEPT); /* clear all fp exception conditions */
return fesetexceptflag(&flags, ~excepts) != 0 ? -1 : flags; /* set new flags */
}
#endif
#endif
int main(int argc, char **argv) {
feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW);
TCanvas* C= new TCanvas("canvas","canvas",1024,768);
C->cd();
Double_t w=0, h=0, xl=0, yb=0;
TH1D* o=new TH1D();
TPad* c= new TPad();
c->PlaceBox(o,w,h,xl,yb);
delete c;
delete C;
return 0;
}
compile
g++ pad2.cxx $(root-config --glibs --cflags --libs) -o pad2 -g
run
./pad2
Setup
ROOT 6.22.02 CentOS7 gcc4.8.5
and
lxplus with
source /cvmfs/sft.cern.ch/lcg/views/dev3python3/latest/x86_64-centos7-gcc10-opt/setup.sh
Should also work with mac (not tested).
Additional context
Hopefully this will be the last one.
6.22.02 build failure with -Dx11=OFF
Describe the bug
When building 6.22.02 with x11 disabled, there's a build error:
CMakeFiles/RGL.dir/src/TGLFormat.cxx.o: In function `TGLFormat::InitAvailableSamples()':
TGLFormat.cxx:(.text+0x35c): undefined reference to `XGetVisualInfo'
TGLFormat.cxx:(.text+0x476): undefined reference to `XFree'
CMakeFiles/RGL.dir/src/TGLWidget.cxx.o: In function `TGLWidget::CreateWindow(TGWindow const*, TGLFormat const&, unsigned int, unsigned int, std::pair<void*, void*>&)':
TGLWidget.cxx:(.text+0xcd5): undefined reference to `XCreateColormap'
TGLWidget.cxx:(.text+0xd28): undefined reference to `XCreateWindow'
CMakeFiles/RGL.dir/src/TGLWidget.cxx.o: In function `TGLWidget::~TGLWidget()':
TGLWidget.cxx:(.text+0x1765): undefined reference to `XFree'
collect2: error: ld returned 1 exit status
make[2]: *** [lib/libRGL.so] Error 1
make[1]: *** [graf3d/gl/CMakeFiles/RGL.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Expected behavior
a clean build
To Reproduce
setup gcc 9.2.0
> export CXX=g++
> export CC=gcc
> cmake -Dx11=OFF -DCMAKE_CXX_STANDARD=17 -DCMAKE_CXX_EXTENSIONS=Off ../src
> make -j30
Setup
version: v6.22.02
OS: RHEL7
root built from git source (tag v6-22-02)
gcc: 9.2.0
rootcp and rootmv should allow compression level change.
Especially for TTree, to change the compression level (for example from 0 to something :) ), one must use hadd (which copies the whole file), so we should add an option to rootcp and rootmv to allow for the compression change. See for example https://root-forum.cern.ch/t/ttree-compression-factor-1-00/31850
TH3 missing labels
Describe the bug
the attached TH3 has two missing labels. Note that changing the diction to "not optimise" makes them appear.
Expected behavior
The two missing labels should be displayed.
To Reproduce
{
f = new TFile("th3_label.root”);
h3->Draw();
cout << h3->GetXaxis()->GetNbins() << endl;
h3->GetXaxis()->GetLabels()->ls();
}
The root file is th3_label.log (renamed . log to be able to attach it).
Proposal to unify logging in Minuit2
Probably due to historical reasons, the Minuit2 code uses several systems to report errors, warnings, and debug info. Some of these only work when certain compile flags are set (WARNINGMSG and DEBUG). I would like to unify these systems and use the MnPrint facilities consistently everywhere. This would have the advantage that debug info can be turned on at any time without recompiling and it has additional advantages for frontends to Minuit2, like iminuit.
I would like to work on this, but need some feedback before I invest time.
Proposed changes
Currently, there are three systems to report info, errors, warnings, and debug messages. The latter two need to be enabled with compile flags (WARNINGMSG and DEBUG).
Examples from VariableMetricBuilder.cxx:
Direct use of the MnPrint facilities (this is the "proper" way)
if (PrintLevel() > 1) {
MnPrint::PrintState(std::cout, result.back(), "VariableMetric: Iteration # ",result.size()-1);
}Use of MnPrint macros for info messages that are only enabled when WARNINGMSG is set
#ifdef WARNINGMSG
MN_INFO_MSG("VariableMetricBuilder: initial matrix not pos.def.");
#endifUse of DEBUG and std::cout
#ifdef DEBUG
std::cout<<"VariableMetricBuilder convergence when edm < "<<edmval<<std::endl;
#endifThe latter two need to be enabled at compile-time. If they are enabled, there is no fine-grained run-time control, because the MnPrint system only distinguishes two verbosity levels 0 and 1. On level 0, only errors are reported. On level 1, errors and "info" are reported.
I propose to enhance this by two more levels
- level 0: report errors
- level 1: all of level 0 + warnings
- level 2: all of level 1 + info
- level 3: all of level 2 + debug
and add the corresponding macros
MN_WARN_MSG
MN_WARN_MSG2
MN_WARN_VAL
MN_WARN_VAL2
MN_DEBUG_MSG
MN_DEBUG_MSG2
MN_DEBUG_VAL
MN_DEBUG_VAL2in addition to the existing MN_INFO_* and MN_DEBUG_* macros.
Level 1 would enable the warning messages that are currently only available when the compiler flag WARNINGMSG is defined. Level 3 would enable the debug messages that are currently only available when the compiler flag DEBUG is defined.
In my experience, trouble with minimizing some function is common so it would be a great asset to enable more debug output at anytime by just increasing the print level without recompiling ROOT.
The DEBUG messages are particularly problematic in the current system, because they use std::cout while MnPrint uses the compile-time configurable MNLOG (which defaults to std::cerr).
Possible negative side-effects
Breaking changes?
This proposal does not change the output for print level 0, but there is a minor change for print level 1.
It changes the output of scripts/software that uses print level 1, because previously level 1 meant "print errors and info" while in the new hierarchy it means "print errors and warnings". I think this is a minor effect, which has to be documented in the next changelog but it cannot cause backward incompatibilities or breakage.
Reduced performance?
The impact on performance is expected to be negligible.
I propose to place additional calls into the compiled code for everyone, but these calls are not executed unless the user picks a high print level. For a low print level, there is just the minor additional cost of a branch, which moreover can be predicted very well by the CPU, so the added cost should be almost zero. Furthermore, these branches do not happen in hot code paths. Hot paths are inside the cost function (which are unaffected) and in the linear algebra routines that Minuit2 uses (which are not instrumented with debug messages).
Positive side-effects for wrappers and frontends
An important positive side effect for wrappers like iminuit is that we could show our users debug messages, too. Right now, we cannot, because DEBUG messages can only be enabled at compile-time, not at run-time.
The DEBUG messages are also problematic in the current system, because they use std::cout while MnPrint uses the compile-time configurable MNLOG (which defaults to std::cerr). For wrappers like iminuit, it is important to redirect the log to its own streams that can be readout and displayed in Python, for example in a Jupyter notebook session (std::cerr and std::cout always go to the terminal and are invisible in a Jupyter notebook).
[DF] Display doesn't work with non-top-level TTree branches
Describe the bug
RDF::Display does not search non-top-level TTree branches for regex matches, so Display("a.b") throw a "column not found" exception. The problem is at
root/tree/dataframe/src/RDFInterfaceUtils.cxx
Line 383 in 8c8cefe
[JupyROOT][roottest] New nbconvert versions break notebook comparisons
Describe the bug
The problem is visible in the conda nightly builds, e.g. here.
JupyROOT tests are red because a new json field "execution" is added to the .ipynb file.
To Reproduce
It should be enough to install the ROOT conda nightlies, build roottest against them and run one of the JupyROOT tests via ctest.
Additional context
I think the reason this problem cropped up is that the version of nbconvert installed by conda (conda-forge channel) was recently bumped from 5.6.1 to 6.0.2. nbformat documents that new "execution" field in notebooks as of 8 months ago.
The nbdiff.py steering script already filters some lines from the notebooks before diff'ing them, but the introduction of a new json field also changes the surrounding lines, e.g. a closed brace becomes a comma, an extra closing brace is added, and the current filtering mechanism is not able to deal with this, so I am not sure what the best way to proceed would be.
[IMT] ROOT::GetThreadPoolSize does not reflect tbb::global_control settings
Describe the bug
Calling tbb::global_control c(tbb::global_control::max_allowed_parallelism, 3); followed by ROOT::GetThreadPoolSize() or TThreadExecutor::GetPoolSize() results in the incorrect number of threads reported (hardware concurrency rather than what was set via tbb::global_control.
Expected behavior
ROOT::GetThreadPoolSize should report the real TBB thread pool size or the real number of threads that ROOT will use.
To Reproduce
This code prints 8 two times on my 8-core workstation, but CPU usage is actually 300%, i.e. TBB's thread pool has size 3 but we ROOT reports 8.
#include <ROOT/TThreadExecutor.hxx>
#include <tbb/global_control.h>
#include <tbb/task_scheduler_init.h>
#include <iostream>
#include <TROOT.h>
int main() {
tbb::global_control c(tbb::global_control::max_allowed_parallelism, 3);
ROOT::EnableImplicitMT();
std::cout << ROOT::GetThreadPoolSize() << std::endl;
ROOT::TThreadExecutor pool;
std::cout << pool.GetPoolSize() << std::endl;
auto busyLoop = [](int x) { int i = 0; for (; i < 1000000000+x; ++i); return i; };
pool.Foreach(busyLoop, {1,2,3,4,5,6,7,8});
return 0;
}Issues should be either in JIRA or here
Hi,
I am not sure if having both the JIRA and github issue trackers is a good idea. It might create confusion, make it more work to follow developments, and might make historic investigations harder/impossible.
cxx-standard should not be in CMAKE_CXX_FLAGS
Describe the bug
CMAKE_CXX_FLAGS, set by hand in ROOTUseFile.cmake, includes a specification on cxx standard, which should be specified rather by CMAKE_CXX_STANDARD variable.
In a projects using ROOT, the inclusion causes doubly-specified cxx-standard in their compile procedure, and the maintainer transferred me here; see the thread here:
Expected behavior
--std= options should be set in CMAKE_CXX_STANDARD, rather than CMAKE_CXX_FLAGS.
To Reproduce
see iLCSoft/LCIO#109 (comment)
Setup
ROOT Docker images: docker pull rootproject/root:6.22.02-ubuntu20.04, ran on docker on WSL2.
Segmentation violation in TPaveLabel class
Describe the bug
Crash.
[user@lxplus733 ~]$ g++ pavelabel.cxx $(root-config --glibs --cflags --libs) -o pavelabel -g
[user@lxplus733 ~]$ ./pavelabel
Warning in <UnknownClass::SetDisplay>: DISPLAY not set, setting it to hostname:0.0
*** Break *** segmentation violation
===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
gdb.printing.register_pretty_printer(gdb.current_objfile(),
gdb.printing.register_pretty_printer(gdb.current_objfile(),
#0 0x00007f4b1f57246c in waitpid () from /lib64/libc.so.6
#1 0x00007f4b1f4eff62 in do_system () from /lib64/libc.so.6
#2 0x00007f4b23f015dc in TUnixSystem::StackTrace() () from /usr/lib64/root/libCore.so.6.22
#3 0x00007f4b23f0406a in TUnixSystem::DispatchSignals(ESignals) () from /usr/lib64/root/libCore.so.6.22
#4 <signal handler called>
#5 0x00007f4b22407674 in TPad::PaintBox(double, double, double, double, char const*) () from /usr/lib64/root/libGpad.so.6.22
#6 0x00007f4b229661a3 in TBox::PaintBox(double, double, double, double, char const*) () from /usr/lib64/root/libGraf.so.6.22
#7 0x00007f4b229a7570 in TPave::PaintPave(double, double, double, double, int, char const*) () from /usr/lib64/root/libGraf.so.6.22
#8 0x00007f4b229aa009 in TPaveLabel::PaintPaveLabel(double, double, double, double, char const*, char const*) () from /usr/lib64/root/libGraf.so.6.22
#9 0x0000000000400d05 in main (argc=1, argv=0x7fff9bced0c8) at pavelabel.cxx:13
===========================================================
The lines below might hint at the cause of the crash.
You may get help by asking at the ROOT forum http://root.cern.ch/forum
Only if you are really convinced it is a bug in ROOT then please submit a
report at http://root.cern.ch/bugs Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5 0x00007f4b22407674 in TPad::PaintBox(double, double, double, double, char const*) () from /usr/lib64/root/libGpad.so.6.22
#6 0x00007f4b229661a3 in TBox::PaintBox(double, double, double, double, char const*) () from /usr/lib64/root/libGraf.so.6.22
#7 0x00007f4b229a7570 in TPave::PaintPave(double, double, double, double, int, char const*) () from /usr/lib64/root/libGraf.so.6.22
#8 0x00007f4b229aa009 in TPaveLabel::PaintPaveLabel(double, double, double, double, char const*, char const*) () from /usr/lib64/root/libGraf.so.6.22
#9 0x0000000000400d05 in main (argc=1, argv=0x7fff9bced0c8) at pavelabel.cxx:13
===========================================================
[user@lxplus733 ~]$
Expected behavior
No segmentation violation.
To Reproduce
Code:
#include <TCanvas.h>
#include <TPaveLabel.h>
#include <TPad.h>
#include <fenv.h>
int main(int argc, char **argv) {
feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW);
TCanvas* C= new TCanvas("canvas","canvas",2000,10);
C->cd();
TPad* p= new TPad();
p->cd();
TPaveLabel* l= new TPaveLabel(0,1,0,1,"I hope not crash");
l->Paint();//Crash here
return 0;
}
Compile
g++ pavelabel.cxx $(root-config --glibs --cflags --libs) -o pavelabel -g
Run
./pavelabel
Setup
ROOT 6.22.02 as installed on lxplus.
Additional context
This is a piece of #6344 (hopefully the last one)
root7 is turned off by default even if the default C++ standard of the compiler is C++14 or above
Describe the bug
With ROOT-10692 fixed, ROOT now, by default, uses the default C++ standard of the compiler rather than always using C++11. However, due to how our cmake logic is structured, root7 is still turned off by default, even if the default C++ standard used by the compiler was detected to be C++14 or higher.
Expected behavior
With a compiler that defaults to -std=C++14 or above, a vanilla cmake path/to/root should have root7 turned on.
Additional context
I think the root cause is that, at the following lines in our main CMakeLists.txt, we first include RootBuildOptions (which sets root7 to OFF by default because it doesn't detect a high-enough C++ standard) and then we include CheckCompiler, which sets our default CMAKE_CXX_STANDARD to the compiler default.
Lines 128 to 134 in 33458dc
Moving include(CheckCompiler) above include(RootBuildOptions) fixes this issue but breaks Windows, because some cmake variable that CheckCompiler needs in the case of windows were defined earlier.
Divisions by zero and other FPE
Hi all,
recently I've tried to recompile an older code with ROOT GUI and to debug some crashes.
I've found that in many places the crashes occurred not in the code, but in the ROOT.
More specifically in the GUI library graf2d.
The backtrace looks typically like this
#5 0x00007fc5a101e282 in TPad::ExecuteEvent(int, int, int) (this=0x5960390, event=21, px=1031, py=120) at /usr/src/debug/root-6.22.02/graf2d/gpad/src/TPad.cxx:2149
#6 0x00007fc5a100442d in TCanvas::HandleInput(EEventType, int, int) (this=0x3566d70, event=kButton1Motion, px=637, py=120) at /usr/src/debug/root-6.22.02/graf2d/gpad/src/TCanvas.cxx:1291
#7 0x00007fc5a156c04b in TRootEmbeddedCanvas::HandleContainerMotion(Event_t*) (this=0x3565110, event=0x7ffe06062550) at /usr/src/debug/root-6.22.02/gui/gui/src/TRootEmbeddedCanvas.cxx:387
#8 0x00007fc5a14a19f1 in TGFrame::HandleEvent(Event_t*) (this=0x35665d0, event=0x7ffe06062550) at /usr/src/debug/root-6.22.02/gui/gui/src/TGFrame.cxx:531
#9 0x00007fc5a1458a48 in TGClient::HandleEvent(Event_t*) (this=0x2e17e80, event=0x7ffe06062550) at /usr/src/debug/root-6.22.02/gui/gui/src/TGClient.cxx:843
#10 0x00007fc5a1458f85 in TGClient::ProcessOneEvent() (this=this
I was able to trace the problem to the math operations performed in the TPad.cxx and TPavelabel.cxx and it looks in many cases there are simply divisions by zero.
e.g. in TPaveLabel.cxx instead of
Double_t wh = (Double_t)gPad->XtoPixel(gPad->GetX2());
Double_t hh = (Double_t)gPad->YtoPixel(gPad->GetY1());
Double_t labelsize, textsize = GetTextSize();
Int_t automat = 0;
if (GetTextFont()%10 > 2) { // fixed size font specified in pixels
labelsize = GetTextSize();
} else {
if (TMath::Abs(textsize -0.99) < 0.001) automat = 1;
if (textsize == 0) { textsize = 0.99; automat = 1;}
Int_t ypixel = TMath::Abs(gPad->YtoPixel(y1) - gPad->YtoPixel(y2));
labelsize = textsize*ypixel/hh;
if (wh < hh) labelsize *= hh/wh;
}
One can have
Double_t wh = gPad->XtoPixel(gPad->GetX2())==0?1.0:(Double_t)gPad->XtoPixel(gPad->GetX2());
Double_t hh = gPad->YtoPixel(gPad->GetY1())==0?1.0:(Double_t)gPad->YtoPixel(gPad->GetY1());
....
In the TPad.cxx there are many unsafe operations in the TPad::ExecuteEvent and TPad::Resize, e.g.
// Compute new pad positions in the NDC space of parent
fXlowNDC = Double_t(apx1 - parentpx1)/Double_t(parentpx2 - parentpx1);
fYlowNDC = Double_t(apy1 - parentpy1)/Double_t(parentpy2 - parentpy1);
fWNDC = Double_t(apx2 - apx1)/Double_t(parentpx2 - parentpx1);
fHNDC = Double_t(apy2 - apy1)/Double_t(parentpy2 - parentpy1);
Would someone from developers be interested to look there ?
Best regards,
Andrii
When in-memory TTree are written, they are not compressed.
As reported in https://root-forum.cern.ch/t/ttree-compression-factor-1-00/31850, when in-memory TTree are written, they are not compressed.
With:
{
// create a new file
TFile *f_new = TFile::Open("f_new.root", "recreate", "", 101);
#if 1 /* 0 or 1 */
gROOT->cd(); // switch to RAM
#else /* 0 or 1 */
// open some old file
TFile *f_old = TFile::Open("f_old.root");
// retrieve any objects
delete f_old;
#endif /* 0 or 1 */
// Uncommenting the next line will lead to a compress TTree data
// f_new->cd();
TTree *t = new TTree("t", "t"); // create a new DISK RESIDENT tree
// Alternatively uncommenting the next line will lead to a compress TTree data
// t->SetDirectory(f_new);
// fill the tree
Float_t v; t->Branch("v", &v, "v/F");
for (Int_t i = 0; i < 999999; i++) { v = gRandom->Gaus(0., 1.); t->Fill(); }
// save the tree to a file
f_new->cd(); // just a precaution
t->Write();
delete f_new; // automatically deletes "t", too
}
the resulting file (f_new.root) contains an uncompressed TTree.
[Hist] Bugs in Tprofile,TProfile2D::LabelsOption
Ordering of labels in TProfile is not correct when:
- Profile have weights. The array containing the weight square,
fBinSumw2is not updated in TProfileHelper::LabelsOption - Labels have different order than bin numbers. This was same bug present in
TH1::LabelsOptionand fixed by #6217
6.22.02 build error on macOS 10.15
6.22.02 build error on mac OS 10.15
Building 6.22.02 from source on macOS fails. Note I maintain the ROOT6 port in MacPorts, and my ultimate aim here is to update that build to 6.22.02 (currently 6.22.00). We use a number additional options and dependencies, hence the cmake configure command is a bit long (apologies).
6.22.00 builds just fine using the exact same configuration, so the issue is new to 6.22.02.
I have attached the output from the configure and build steps (as outlined below).
Unfortunately the build log error messages aren't hugely helpful (at least to me) in pointing to the issue, so I am hoping someone can offer suggestions as to where to look
First indication of a problem is
[ 74%] Linking CXX shared library ../lib/libCore.so
<snip>
make[1]: *** read jobs pipe: Resource temporarily unavailable. Stop.
make[1]: *** Waiting for unfinished jobs....[ 74%] Linking CXX shared library ../lib/libCore.so
Expected behavior
Builds OK.
To Reproduce
git clone [email protected]:root-project/root.git
cd root
git checkout v6-22-02
cd ..
mkdir install build
cd build
cmake -G "CodeBlocks - Unix Makefiles" -DCMAKE_BUILD_TYPE=MacPorts -DCMAKE_INSTALL_PREFIX="/opt/local" -DCMAKE_INSTALL_NAME_DIR="/opt/local/lib" -DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr" -DCMAKE_C_COMPILER="$CC" -DCMAKE_CXX_COMPILER="$CXX" -DCMAKE_POLICY_DEFAULT_CMP0025=NEW -DCMAKE_POLICY_DEFAULT_CMP0060=NEW -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_MAKE_PROGRAM=/usr/bin/make -DCMAKE_MODULE_PATH="/opt/local/share/cmake/Modules" -DCMAKE_PREFIX_PATH="/opt/local/share/cmake/Modules" -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON -DCMAKE_INSTALL_RPATH="/opt/local/lib" -Wno-dev -Dgnuinstall=ON -Drpath=ON -DCMAKE_INSTALL_PREFIX="/opt/local/libexec/root6" -DCMAKE_INSTALL_SYSCONFDIR="/opt/local/libexec/root6/etc/root" -DCMAKE_INSTALL_NAME_DIR="/opt/local/libexec/root6/lib/root" -Dfortran=ON -Dbuiltin_davix=OFF -Dbuiltin_freetype=ON -Dbuiltin_glew=ON -Dbuiltin_pcre=OFF -Dbuiltin_zlib=ON -Dbuiltin_lzma=OFF -Dbuiltin_tbb=OFF -Dbuiltin_afterimage=ON -Ddavix=ON -Dfftw3=OFF -Dkrb5=OFF -Dmysql=OFF -Dsqlite=OFF -Dodbc=OFF -Dopengl=ON -Dpythia6=OFF -Dpythia8=OFF -Droofit=ON -Dssl=ON -Dxml=ON -Dpyroot=ON -Dfitsio=OFF -Dgsl_shared=ON -Dbuiltin_gsl=OFF -Dpgsql=OFF -Ddcache=OFF -Dchirp=OFF -Dhdfs=OFF -Druby=OFF -Dminuit2=ON -Dtmva=ON -Dqt=OFF -Dqtgsi=OFF -Dgviz=ON -Dsoversion=ON -Dcxx11=ON -Dcxx14=OFF -Dcxx17=ON -Dlibcxx=ON -Dxrootd=ON -Dbuiltin_ftgl=ON -Dmathmore=ON -Dgenvector=ON -Dmemstat=ON -Dunuran=ON -Dgdml=ON -Dhttp=ON -Dvc=OFF -Dastiff=ON -Dgeocad=OFF -Dr=OFF -Droot7=ON -Dbuiltin_veccore=OFF -DPNG_LIBRARY=/opt/local/lib/libpng.dylib -DPNG_PNG_INCLUDE_DIR=/opt/local/include -Druntime_cxxmodules=OFF -DPYTHON_INCLUDE_DIR="/opt/local/Library/Frameworks/Python.framework/Versions/3.8/Headers" -DPYTHON_EXECUTABLE="/opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8" -DPYTHON_LIBRARY="/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/libpython3.8.dylib" -DXROOTD_INCLUDE_DIR="/opt/local/include/xrootd" -DGRAPHVIZ_INCLUDE_DIR="/opt/local/include" -DGSL_CONFIG_EXECUTABLE="/opt/local/bin/gsl-config" -DLIBXML2_INCLUDE_DIR="/opt/local/include/libxml2" -DLIBXML2_LIBRARIES="/opt/local/lib/libxml2.dylib" -DLIBXML2_LIBRARY="/opt/local/lib/libxml2.dylib" -DLIBXML2_XMLLINT_EXECUTABLE="/opt/local/bin/xmllint" -Dcocoa=ON -Dx11=OFF -DCMAKE_OSX_ARCHITECTURES="x86_64" -DCMAKE_OSX_DEPLOYMENT_TARGET="10.15" -DCMAKE_OSX_SYSROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk" -DCMAKE_INSTALL_PREFIX=/Users/chris/Projects/ROOT/install ../root 2>&1 | tee ../configure.log
cmake --build . -- -j8 2>&1 | tee ../build.log
Setup
Additional context
[Test Issue]
Describe the bug
Expected behavior
To Reproduce
Setup
Additional context
TTreeFormula `Alt$` gives (silently) wrong result when used by itself.
Describe the bug
With Event.root (from test\Event) we get:
root [12] T->Scan("Alt$(fMeasures,-1)")
************************
* Row * Alt$(fMea *
************************
* 0 * 1 *
* 1 * 0 *
* 2 * 2 *
Expected behavior
****************************************
* Row * Instance * Alt$(fMeasures) *
****************************************
* 0 * 0 * 1 *
* 0 * 1 * 0 *
* 0 * 2 * 1 *
* 0 * 3 * 1 *
* 0 * 4 * 3 *
* 0 * 5 * 16 *
* 0 * 6 * 4 *
* 0 * 7 * 22 *
* 0 * 8 * 8 *
* 0 * 9 * 4 *
* 1 * 0 * 0 *
* 1 * 1 * 1 *
* 1 * 2 * 5 *
* 1 * 3 * -1 *
* 1 * 4 * 5 *
* 1 * 5 * 9 *
* 1 * 6 * 6 *
* 1 * 7 * 6 *
* 1 * 8 * 3 *
* 1 * 9 * 20 *
Note that when used as intended (i.e. with another array, even itself, it works properly:
root [13] T->Scan("Alt$(fMeasures,-1):fMeasures")
***********************************************
* Row * Instance * Alt$(fMea * fMeasures *
***********************************************
* 0 * 0 * 1 * 1 *
* 0 * 1 * 0 * 0 *
* 0 * 2 * 1 * 1 *
* 0 * 3 * 1 * 1 *
or
root [11] T->Scan("Alt$(fMeasures,-1):fMatrix")
***********************************************
* Row * Instance * Alt$(fMea * fMatrix *
***********************************************
* 0 * 0 * 1 * 1.5405316 *
* 0 * 1 * 0 * 0.0947428 *
* 0 * 2 * 1 * 1.5246920 *
* 0 * 3 * 1 * 0 *
* 0 * 4 * 3 * -0.136309 *
* 0 * 5 * 16 * 0.8007842 *
* 0 * 6 * 4 * 1.7062356 *
* 0 * 7 * 22 * 0 *
* 0 * 8 * 8 * -1.160293 *
* 0 * 9 * 4 * 2.012362 *
* 0 * 10 * -1 * 4.0220642 *
* 0 * 11 * -1 * 0 *
* 0 * 12 * -1 * 0 *
* 0 * 13 * -1 * 0 *
* 0 * 14 * -1 * 0 *
* 0 * 15 * -1 * 0 *
roit
Code generated by TFile::MakeProject should not rely on std namespace import
Explain what you would like to see improved
As discussed in the ROOT forum: the code generated by TFile::MakeProject currently contains the following lines at the beginning
namespace std {} using namespace std;
which is necessary because the header files to not qualify std names (e.g., vector instead of std::vector).
@Wile.E.Coyote provided the following comment in the forum:
Actually, it seems to me that the origin of the problem is that the “std::” was removed at the TTree creation time (i.e. if you try “tree->Print();”, you will see that it is not there). It seems to me that this is a long-standing problem which should be fixed (i.e. “std::” should be preserved).
Optional: share how it could be improved
It would be nicer if header files did qualify names from the std namespace so that they can be easier included in other projects.
To Reproduce
Use TFile::MakeProject on a ROOT file with a non-trivial tree.
Setup
- Master
- Arch Linux
- Built from sources
io: streamer for std::bitset appears to be relying on endian-ness
this is a repeat of https://root-forum.cern.ch/t/std-bitset-streamer-endianness-issue/41529
hi there,
I was adding support for reading/writing std::bitset<N> to groot when I noticed the following behaviour:
$> cat ./Event.h
#ifndef MYEVT_H
#define MYEVT_H 1
#include <bitset>
struct Event {
std::bitset<16> Bs;
};
#endif // MYEVT_H
$> cat ./run.C
#include "Event.h"
void run() {
gSystem->Load("./libEvent.so");
auto f = TFile::Open("std-bitset.root", "RECREATE");
auto t = new TTree("tree", "tree");
int bufsize = 32000;
int splitlvl = 99;
Event e;
e.Bs = std::bitset<16>("0001010111101010");
t->Branch("evt", &e, bufsize, splitlvl);
t->Fill();
f->Write();
f->Close();
exit(0);
}
$> root -b -q ./run.C
reading back the file with groot, I see the following bit patterns:
$> root-dump testdata/std-bitset.root
>>> file[testdata/std-bitset.root]
key[000]: tree;1 "tree" (TTree)
[000][evt]: {[0 1 0 1 0 1 1 1 1 0 1 0 1 0 0 0]}
ie: it seems endianness of the bitset isn't handled when writing the bitset (and it's whatever it happens to be on the writing machine).
(I was expecting: [0 0 0 1 0 1 0 1 1 1 1 0 1 0 1 0] as the on-disk bytes)
or are bitset<N> values always little-endian encoded?
I was also a bit surprised to see a std::bitset<N> to take (N+4)bytes on disk (instead of "just" Nbits +4bytes, or, even, just Nbits).
is there an underlying reason I am missing here? (it's also quite possible I am completely mistaken, of course)
thx,
-s
Please read tips for efficient and successful posting and posting code
ROOT Version: 6.22/02
Built for linuxx8664gcc on Aug 17 2020, 12:46:52
From tags/v6-22-02@v6-22-02
[Hist] Wrong Statistics after subtraction of TProfile
After subtracting TProfile objects using TProfile::Add(p1,p2,1,-1) the statistics in y (MeanY, StdDevY) are not correct.
ResetStats() needs to be called
See https://root-forum.cern.ch/t/how-does-the-add-function-work/41448
6.22.00 pyroot regression: Can't derive from TProfile.
With root 6.22.00, the following fragment
import ROOT
class Foo (ROOT.TProfile): pass
gives errors:
>>> import ROOT
>>> class Foo (ROOT.TProfile): pass
...
input_line_38:8:19: error: redeclaration of using declaration
using TProfile::BufferFill;
~~~~~~~~~~^
input_line_38:7:19: note: previous using declaration
using TProfile::BufferFill;
^
input_line_38:9:19: error: 'SetBins' is a private member of 'TProfile'
using TProfile::SetBins;
^
/cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/include/TProfile.h:67:9: note: declared private here
void SetBins(Int_t, Double_t, Double_t, Int_t, Double_t, Double_t)
^
input_line_38:9:19: error: 'SetBins' is a private member of 'TProfile'
using TProfile::SetBins;
^
/cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/include/TProfile.h:69:9: note: declared private here
void SetBins(Int_t, const Double_t*, Int_t, const Double_t*)
^
input_line_38:9:19: error: 'SetBins' is a private member of 'TProfile'
using TProfile::SetBins;
^
/cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/include/TProfile.h:71:9: note: declared private here
void SetBins(Int_t, Double_t, Double_t, Int_t, Double_t, Double_t, In...
^
input_line_38:9:19: error: 'SetBins' is a private member of 'TProfile'
using TProfile::SetBins;
^
/cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/include/TProfile.h:73:9: note: declared private here
void SetBins(Int_t, const Double_t *, Int_t, const Double_t *, Int_t...
^
input_line_38:10:19: error: 'Fill' is a private member of 'TProfile'
using TProfile::Fill;
^
/cvmfs/sft.cern.ch/lcg/releases/ROOT/v6.22.00-be0a0/x86_64-centos7-gcc8-opt/include/TProfile.h:61:10: note: declared private here
Int_t Fill(Double_t) { MayNotUse("Fill(Double_t)"); return -1;}
^
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: no python-side overrides supported (failed to compile the dispatcher code)
It works ok with either TH1F or TH2F. It also worked with root 6.20.06.
This is low priority. It showed up in ATLAS code, but the code in question is long obsolete and probably
best just removed. Submitting it now just to document the issue.
ROOT
vtable corruption in Python specialization of C++ classes
Describe the bug
Using cppyy in ROOT master (51eb56e), I have a Python class that inherits from a C++ class (with two abstract classes) and I need to pass an instance of the Python class to a C++ function that accepts a pointer to one of the base classes.
When the C++ function tries to call a method from the instance, I get a segmentation fault (actually I enter in an infinite segfault loop, where ROOT segfault handler segfaults too).
Expected behavior
Just that called the C++ function can use the passed instance.
To Reproduce
From a directory containing the file:
import cppyy
cppyy.gbl.gInterpreter.Declare("""
#include <array>
#include <iostream>
struct Interface1 {
virtual void do_1() = 0;
virtual ~Interface1() = default;
};
struct Interface2 {
virtual void do_2() = 0;
virtual ~Interface2() = default;
};
struct Base : virtual public Interface1, virtual public Interface2 {
Base() {
std::cout << std::hex << "Base* " << this << "\nInt1* " << static_cast<Interface1*>( this ) << "\nInt2* "
<< static_cast<Interface2*>( this ) << '\n';
}
};
struct Derived : Base, virtual public Interface2 {
void do_1() override { std::cout << std::hex << this << "->do_1\n"; }
void do_2() override { std::cout << std::hex << this << "->do_2\n"; }
};
void my_func( Interface2* i ) { i->do_2(); }
""")
class PyDerived(cppyy.gbl.Derived):
pass
i = PyDerived()
i.do_1()
i.do_2()
cppyy.gbl.my_func(i)call
python reproducer.py
Setup
- ROOT version: 51eb56e
- OS: CentOS7
- arch: x86_64
- compiler: gcc 9.2.0
Additional context
I'm using the nightly builds by CERN SFT.
Typo in void TEnv::SetValue(const char *name, double value) implementation
Branch: v6-22-00-patches (I checked master has the same issue)
On file:
root_src/core/base/src/TEnv.cxx
in the implementation of the function: TEnv::SetValue
line#: 784
void TEnv::SetValue(const char *name, double value)
{
SetValue(name, Form("%g", value));
}
the argument value should be Double_t as declared in the correspoinding TEnv.h file.
Regards,
Danilo.
python: /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/interpreter/llvm/src/include/llvm/Support/Casting.h:106: static bool llvm::isa_impl_cl<To, const From*>::doit(const From*) [with To = clang::UsingDecl; From = clang::Decl]: Assertion `Val && "isa<> used on a null pointer"' failed.
Hi, I am running nightly tests of COOL which is built using PyROOT, and since the 10th September, one test is failing when using ROOT master branch on all the platforms we test (slc6 with gcc8 and centos7 with gcc8-10 and clang10).
I suspect one commit from Sep 9, 2020 to be responsible for this change of behaviour.
Here is the error and backtrace:
python: /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/interpreter/llvm/src/include/llvm/Support/Casting.h:106: static bool llvm::isa_impl_cl<To, const From*>::doit(const From*) [with To = clang::UsingDecl; From = clang::Decl]: Assertion `Val && "isa<> used on a null pointer"' failed.
*** Break *** abort
===========================================================
There was a crash (#7 0x00007facdfe876c8 in SigHandler(ESignals) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/core/unix/src/TUnixSystem.cxx:407).
This is the entire stack trace of all threads:
===========================================================
#0 0x00007facdeaa889e in waitpid () from /lib64/libc.so.6
#1 0x00007facdea3a4e9 in do_system () from /lib64/libc.so.6
#2 0x00007facdfe8b434 in TUnixSystem::Exec(char const*) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/core/unix/src/TUnixSystem.cxx:2120
#3 0x00007facdfe8bc6a in TUnixSystem::StackTrace() () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/core/unix/src/TUnixSystem.cxx:2411
#4 0x00007facdc599248 in (anonymous namespace)::do_trace(int) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/bindings/pyroot/cppyy/cppyy-backend/clingwrapper/src/clingwrapper.cxx:182
#5 0x00007facdc5992c1 in (anonymous namespace)::TExceptionHandlerImp::HandleException(int) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/bindings/pyroot/cppyy/cppyy-backend/clingwrapper/src/clingwrapper.cxx:195
#6 0x00007facdfe8f519 in TUnixSystem::DispatchSignals(ESignals) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/core/unix/src/TUnixSystem.cxx:3644
#7 0x00007facdfe876c8 in SigHandler(ESignals) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/core/unix/src/TUnixSystem.cxx:407
#8 0x00007facdfe8f474 in sighandler(int) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/core/unix/src/TUnixSystem.cxx:3620
#9 <signal handler called>
#10 0x00007facdea2e4f5 in raise () from /lib64/libc.so.6
#11 0x00007facdea2fcd5 in abort () from /lib64/libc.so.6
#12 0x00007facdea2766e in __assert_fail_base () from /lib64/libc.so.6
#13 0x00007facdea27730 in __assert_fail () from /lib64/libc.so.6
#14 0x00007facd7a7438f in llvm::isa_impl_cl<clang::UsingDecl, clang::Decl const*>::doit(clang::Decl const*) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/interpreter/llvm/src/include/llvm/Support/Casting.h:106
#15 0x00007facd7a74211 in llvm::isa_impl_wrap<clang::UsingDecl, clang::Decl const*, clang::Decl const*>::doit(clang::Decl const* const&) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/interpreter/llvm/src/include/llvm/Support/Casting.h:133
#16 0x00007facd7a7407a in llvm::isa_impl_wrap<clang::UsingDecl, clang::Decl const* const, clang::Decl const*>::doit(clang::Decl const* const&) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/interpreter/llvm/src/include/llvm/Support/Casting.h:124
#17 0x00007facd7a73d65 in bool llvm::isa<clang::UsingDecl, clang::Decl const*>(clang::Decl const* const&) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/interpreter/llvm/src/include/llvm/Support/Casting.h:144
#18 0x00007facd7a73b0c in llvm::cast_retty<clang::UsingDecl, clang::Decl const*>::ret_type llvm::dyn_cast<clang::UsingDecl, clang::Decl const>(clang::Decl const*) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/interpreter/llvm/src/include/llvm/Support/Casting.h:334
#19 0x00007facd7a73536 in TClingMemberIter::Advance() () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/core/metacling/src/TClingMemberIter.cxx:128
#20 0x00007facd7a780e9 in TClingMemberIter::Init() () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/core/metacling/src/TClingMemberIter.h:152
#21 0x00007facd7a763a5 in TClingMethodInfo::TClingMethodInfo(cling::Interpreter*, TClingClassInfo*) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/core/metacling/src/TClingMethodInfo.cxx:276
#22 0x00007facd79333fe in TCling::MethodInfo_Factory(ClassInfo_t*) const () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/core/metacling/src/TCling.cxx:8863
#23 0x00007facdfe45a3a in TListOfFunctions::Load() () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/core/meta/src/TListOfFunctions.cxx:390
#24 0x00007facdfe18843 in TClass::GetListOfMethods(bool) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/core/meta/src/TClass.cxx:3721
#25 0x00007facdc59f206 in Cppyy::GetNumMethods(unsigned long) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/bindings/pyroot/cppyy/cppyy-backend/clingwrapper/src/clingwrapper.cxx:1323
#26 0x00007facdc8effb9 in CPyCppyy::BuildScopeProxyDict(unsigned long, _object*) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/bindings/pyroot/cppyy/CPyCppyy/src/ProxyWrappers.cxx:166
#27 0x00007facdc8f2654 in CPyCppyy::CreateScopeProxy () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/bindings/pyroot/cppyy/CPyCppyy/src/ProxyWrappers.cxx:673
#28 0x00007facdc8cbbe2 in CPyCppyy::meta_getattro(_object*, _object*) () at /workspace/build/projects/ROOT-HEAD/src/ROOT/HEAD/bindings/pyroot/cppyy/CPyCppyy/src/CPPScope.cxx:323
#29 0x00007facdf52e1cc in PyEval_EvalFrameEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#30 0x00007facdf5342fb in PyEval_EvalFrameEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#31 0x00007facdf534aa2 in PyEval_EvalCodeEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#32 0x00007facdf4adf96 in function_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#33 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#34 0x00007facdf52bead in PyEval_EvalFrameEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#35 0x00007facdf534aa2 in PyEval_EvalCodeEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#36 0x00007facdf4adedc in function_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#37 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#38 0x00007facdf49253c in instancemethod_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#39 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#40 0x00007facdf4e8a6a in slot_tp_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#41 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#42 0x00007facdf52fd57 in PyEval_EvalFrameEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#43 0x00007facdf534aa2 in PyEval_EvalCodeEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#44 0x00007facdf4adf96 in function_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#45 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#46 0x00007facdf52bead in PyEval_EvalFrameEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#47 0x00007facdf534aa2 in PyEval_EvalCodeEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#48 0x00007facdf4adedc in function_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#49 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#50 0x00007facdf49253c in instancemethod_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#51 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#52 0x00007facdf4e8a6a in slot_tp_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#53 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#54 0x00007facdf52fd57 in PyEval_EvalFrameEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#55 0x00007facdf534aa2 in PyEval_EvalCodeEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#56 0x00007facdf4adf96 in function_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#57 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#58 0x00007facdf52bead in PyEval_EvalFrameEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#59 0x00007facdf534aa2 in PyEval_EvalCodeEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#60 0x00007facdf4adedc in function_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#61 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#62 0x00007facdf49253c in instancemethod_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#63 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#64 0x00007facdf4e8a6a in slot_tp_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#65 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#66 0x00007facdf52fd57 in PyEval_EvalFrameEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#67 0x00007facdf5342fb in PyEval_EvalFrameEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#68 0x00007facdf5342fb in PyEval_EvalFrameEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#69 0x00007facdf534aa2 in PyEval_EvalCodeEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#70 0x00007facdf4adf96 in function_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#71 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#72 0x00007facdf49253c in instancemethod_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#73 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#74 0x00007facdf4e8fd2 in slot_tp_init () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#75 0x00007facdf4e51fa in type_call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#76 0x00007facdf4845e3 in PyObject_Call () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#77 0x00007facdf52fd57 in PyEval_EvalFrameEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#78 0x00007facdf534aa2 in PyEval_EvalCodeEx () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#79 0x00007facdf534d39 in PyEval_EvalCode () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#80 0x00007facdf5597a8 in PyRun_FileExFlags () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#81 0x00007facdf55a723 in PyRun_SimpleFileExFlags () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#82 0x00007facdf56e3da in Py_Main () from /cvmfs/sft-nightlies.cern.ch/lcg/latest/Python/2.7.16-3adfa/x86_64-slc6-gcc8-dbg/bin/../lib/libpython2.7.so.1.0
#83 0x00007facdea1ad20 in __libc_start_main () from /lib64/libc.so.6
#84 0x00000000004006a1 in _start ()
Let me know if I can provide more related details,
Cheers,
Charles
[Docs] Missing figures in RDF tutorials 10[5,6,7] on doxygen
You can find the doxygen pages with the missing figures here:
https://root.cern/doc/master/df105__WBosonAnalysis_8py.html
https://root.cern/doc/master/df106__HiggsToFourLeptons_8py.html
https://root.cern/doc/master/df107__SingleTopAnalysis_8py.html
hadd --help prints wrong usage info
Describe the bug
hadd --help prints the following:
usage: hadd [-a A] [-k K] [-T T] [-O O] [-v V] [-j J] [-dbg DBG] [-d D] [-n N]
[-cachesize CACHESIZE]
[-experimental-io-features EXPERIMENTAL_IO_FEATURES] [-f F]
[-fk FK] [-ff FF] [-f0 F0] [-f6 F6]
TARGET SOURCES
OPTIONS:
-a Append to the output
-k Skip corrupt or non-existent files, do not exit
-T Do not merge Trees
-O Re-optimize basket size when merging TTree
-v Explicitly set the verbosity level: 0 request no output, 99 is the default
-j Parallelize the execution in multiple processes
-dbg Parallelize the execution in multiple processes in debug mode (Does not delete partial files stored inside working directory)
-d Carry out the partial multiprocess execution in the specified directory
-n Open at most 'maxopenedfiles' at once (use 0 to request to use the system maximum)
-cachesize Resize the prefetching cache use to speed up I/O operations(use 0 to disable)
-experimental-io-features Used with an argument provided, enables the corresponding experimental feature for output trees
-f Gives the ability to specify the compression level of the target file(by default 4)
-fk Sets the target file to contain the baskets with the same compression
as the input files (unless -O is specified). Compresses the meta data
using the compression level specified in the first input or the
compression setting after fk (for example 206 when using -fk206)
-ff The compression level use is the one specified in the first input
-f0 Do not compress the target file
-f6 Use compression level 6. (See TFile::SetCompressionSettings for the support range of value.)
TARGET Target file
SOURCES Source files
The options -fk, -ff and -f0 are listed in the short usage overview as [-fk FK] [-ff FF] [-f0 F0] , but they do not accept a parameter.
The docs mention that -f controls the compression level of the target file (e.g. 4), but it's actually possible to specify the full compressoin algorithm (e.g. 404).
Without memstat support, `root -memstat` should not be available
Describe the bug
As discussed in the ROOT forum:
WIthout the memstat feature, root.exe still offers the -memstat option but produced failures like
input_line_11:2:6: error: unknown type name 'TMemStat'
new TMemStat("",100000,5000000);
Expected behavior
If memstat is not part of the build, the memstat option should not be offered or there should be a clearer error message.
To Reproduce
Steps to reproduce the behavior:
- Compile with
cmake -Dmemstat=off - Run
root -l
Setup
- Master
- Arch Linux
- Built from sources
[RF] Creating RooDataSet causes SegFault
Describe the bug
The following code works fine with 6.20.04, but segfaults with 6.22.02.
#include "RooDataSet.h"
#include "RooRealVar.h"
#include "TFile.h"
#include "TTree.h"
int main(int argc, char* argv[]) {
TTree* tree = new TTree("tree", "tree");
double var = 1;
tree->Branch("var", &var, "var/D");
tree->Fill();
RooRealVar* roovar = new RooRealVar("var", "var", 0, 10);
TFile* output_file = new TFile("test.root", "RECREATE", "output_file");
output_file->Print();
RooDataSet* data_set = new RooDataSet("data_set", "data_set", tree, RooArgSet(*roovar));
output_file->Print();
return 0;
}The segfault happens on the last output_file->Print(); line - it seems the creation of the RooDataSet somehow destroys the object pointed to by output_file.
Expected behavior
I expect the code to run without segfaulting.
To Reproduce
- Save the quoted code to
mwe_tfile.cc - Build with
g++ mwe_tfile.cc -o mwe_tfile $(root-config --cflags --glibs) -lRooFitCore - Run
./mwe_tfile
Setup
Ubuntu 18.04
Binary ROOT installs
Works with 6.20.04
Doesn't work with 6.22.02
Broken serialization of ROOT objects in python3 with dill
Describe the bug
Serialization of ROOT objects in python using dill is broken for python3, but it works ok for python2.
( dill serialization is vital for the proper paralllel and distributive python calculations using pathos suite. The functionality of
regular paralell python pp and multiprocessing module is very limited due to limitations of pickle`` serialization, and it is a moment when dill/pathos` enters the game, significantly extending the functionality
Expected behavior
Similar behaviour for python2 and python3 is expected
b ut it works for python2 and fails for python3
To Reproduce
to reproduce see this very simple gist
https://gist.github.com/VanyaBelyaev/278074969f2f940f180885be35f04db9
It has been tested with different LCG releases from LCG_94 to LCG_97a
and it always works for pytjon2 and fails for python3
for python3 one gets an error
Traceback (most recent call last):
File "./test_dill.py", line 13, in <module>
hh = dill.loads ( dill.dumps ( h ) )
File "/cvmfs/sft.cern.ch/lcg/views/LCG_97python3/x86_64-centos7-gcc9-opt/lib/python3.7/site-packages/dill/_dill.py", line 294, in dumps
dump(obj, file, protocol, byref, fmode, recurse)#, strictio)
File "/cvmfs/sft.cern.ch/lcg/views/LCG_97python3/x86_64-centos7-gcc9-opt/lib/python3.7/site-packages/dill/_dill.py", line 287, in dump
pik.dump(obj)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 437, in dump
self.save(obj)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 549, in save
self.save_reduce(obj=obj, *rv)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 637, in save_reduce
save(func)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 504, in save
f(self, obj) # Call unbound method with explicit self
File "/cvmfs/sft.cern.ch/lcg/views/LCG_97python3/x86_64-centos7-gcc9-opt/lib/python3.7/site-packages/dill/_dill.py", line 1064, in save_builtin_method
pickler.save_reduce(_get_attr, (module, obj.__name__), obj=obj)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 638, in save_reduce
save(args)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 504, in save
f(self, obj) # Call unbound method with explicit self
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 774, in save_tuple
save(element)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 504, in save
f(self, obj) # Call unbound method with explicit self
File "/cvmfs/sft.cern.ch/lcg/views/LCG_97python3/x86_64-centos7-gcc9-opt/lib/python3.7/site-packages/dill/_dill.py", line 1269, in save_module
state=_main_dict)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 662, in save_reduce
save(state)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 504, in save
f(self, obj) # Call unbound method with explicit self
File "/cvmfs/sft.cern.ch/lcg/views/LCG_97python3/x86_64-centos7-gcc9-opt/lib/python3.7/site-packages/dill/_dill.py", line 902, in save_module_dict
StockPickler.save_dict(pickler, obj)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 859, in save_dict
self._batch_setitems(obj.items())
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 885, in _batch_setitems
save(v)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 504, in save
f(self, obj) # Call unbound method with explicit self
File "/cvmfs/sft.cern.ch/lcg/views/LCG_97python3/x86_64-centos7-gcc9-opt/lib/python3.7/site-packages/dill/_dill.py", line 902, in save_module_dict
StockPickler.save_dict(pickler, obj)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 859, in save_dict
self._batch_setitems(obj.items())
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 890, in _batch_setitems
save(v)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 504, in save
f(self, obj) # Call unbound method with explicit self
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 819, in save_list
self._batch_appends(obj)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 846, in _batch_appends
save(tmp[0])
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 549, in save
self.save_reduce(obj=obj, *rv)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 633, in save_reduce
save(cls)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 504, in save
f(self, obj) # Call unbound method with explicit self
File "/cvmfs/sft.cern.ch/lcg/views/LCG_97python3/x86_64-centos7-gcc9-opt/lib/python3.7/site-packages/dill/_dill.py", line 1330, in save_type
StockPickler.save_global(pickler, obj)
File "/cvmfs/sft.cern.ch/lcg/releases/LCG_97python3/Python/3.7.6/x86_64-centos7-gcc9-opt/lib/python3.7/pickle.py", line 960, in save_global
(obj, module_name, name)) from None
_pickle.PicklingError: Can't pickle <class '_pythonization.compose_method.<locals>.composition_pythonizor'>: it's not found as _pythonization.compose_method.<locals>.composition_pythonizor
Setup
- ROOT versions from LCG_94 to LCG_97a
- centos7, lxplus7.cern.ch
- LCG-releases via cvmfs
Additional context
I've opened the issue also for dill project: uqfoundation/dill#356
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.