Segmentation fault in PyROOT + Pythia8

chof · May 5, 2023, 6:18am

I’m using the ROOT version 6.26.10 that is installed from conda-forge. Pythia 8.307 is also installed as a dependency.

(Case PyRoot) A segmentation violation message occurs when I run the following Python code.

from ROOT import Pythia8

pythia = Pythia8.Pythia()
pythia.init()
pythia.info.weight()

(Case Root) However, no segmentation violation message with ROOT.

#include "Pythia8/Pythia.h"

void test() {
  Pythia8::Pythia pythia = Pythia8::Pythia();
  pythia.init();
  pythia.info.weight();
}

(Case Pythia) Interestingly, no segmentation violation message if I run the same Python code with the pythia8 package installed as a dependency from conda-forge. Notice that Pythia offers Pythia.infoPython() instead of Pythia.info.

import pythia8

pythia = pythia8.Pythia()
pythia.init()
pythia.infoPython().weight()

Is there any solution to resolve this segmentation violation? Any comment is welcome.

ROOT Version: 6.26.10
Platform: Linux
Compiler: Installed root package from conda-forge

jalopezg · May 8, 2023, 11:45am

Hi @chof,

Do you have access to the stack trace? If so, for reference and to make it possible for us to help in diagnosing the problem, you could attach it here.

ROOT and any other dependencies must be built for the same Python version and using the same C++ language standard.
Given that it works in the last case that you describe, the problem is most likely related to a mismatch either in the Python version or C++ standard used by any of the packages.

(Also CC’ing @vpadulan)

Cheers,
J.

chof · May 8, 2023, 3:15pm

Thanks for the reply, @jalopezg.

I installed ROOT and Pythia8 under the conda environment in AlmaLinux 9 and the ROOT configuration is as follows:

$ conda create -n pyroot -c conda-forge python=3.11 root=6.26.10
$ conda activate pyroot
(pyroot) $ root-config --version
6.26/10
(pyroot) $ root-config --arch
linuxx8664gcc
(pyroot) $ root-config --platform
linux
(pyroot) $ root-config --python3-version
3.11.0
(pyroot) $ root-config --cc
x86_64-conda-linux-gnu-cc
(pyroot) $ root-config --cxx
x86_64-conda-linux-gnu-c++
(pyroot) $ root-config --f77
CMAKE_Fortran_COMPILER-NOTFOUND
(pyroot) $ root-config --ld
x86_64-conda-linux-gnu-c++

I do not agree your opinion that the problem is related to a mismatch either in the Python version of C++ standard. In my opinion, there might be some reason why the authors of Pythia8 introduce Pythia.infoPython() instead of Pythia.info.
Here is the stack trace of (Case PyRoot). [I could not attach the stack trace because I’m a new user so that I copy the contents here.]

 *** Break *** segmentation violation



===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================

Thread 2 (Thread 0x7fe537a4d640 (LWP 4833) "python"):
#0  0x00007fe55500b39a in __futex_abstimed_wait_common () from /lib64/libc.so.6
#1  0x00007fe55500dea4 in pthread_cond_timedwait

GLIBC_2.3.2 () from /lib64/libc.so.6
#2  0x0000565179b44889 in PyCOND_TIMEDWAIT (us=<optimized out>, mut=<optimized out>, cond=0x565179ed7088 <_PyRuntime+392>) at /usr/local/src/conda/python-3.11.3/Python/condvar.h:73
#3  take_gil (tstate=0x56517f154090) at /usr/local/src/conda/python-3.11.3/Python/ceval_gil.h:250
#4  0x0000565179b66022 in PyEval_RestoreThread (tstate=0x56517f154090) at /usr/local/src/conda/python-3.11.3/Python/ceval.c:535
#5  0x0000565179ca25c2 in pysleep (timeout=<optimized out>) at /usr/local/src/conda/python-3.11.3/Modules/timemodule.c:2171
#6  time_sleep (self=<optimized out>, timeout_obj=<optimized out>) at /usr/local/src/conda/python-3.11.3/Modules/timemodule.c:383
#7  0x0000565179b7e7db in cfunction_vectorcall_O (func=0x7fe554ed7240, args=0x7fe542bd21e8, nargsf=<optimized out>, kwnames=<optimized out>) at /usr/local/src/conda/python-3.11.3/Include/cpython/methodobject.h:52
#8  0x0000565179b76651 in _PyObject_VectorcallTstate (kwnames=<optimized out>, nargsf=<optimized out>, args=<optimized out>, callable=0x7fe554ed7240, tstate=0x56517f154090) at /usr/local/src/conda/python-3.11.3/Include/internal/pycore_call.h:92
#9  PyObject_Vectorcall (callable=0x7fe554ed7240, args=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at /usr/local/src/conda/python-3.11.3/Objects/call.c:299
#10 0x0000565179b69386 in _PyEval_EvalFrameDefault (tstate=<optimized out>, frame=<optimized out>, throwflag=<optimized out>) at /usr/local/src/conda/python-3.11.3/Python/ceval.c:4773
#11 0x0000565179b8fcd3 in _PyEval_EvalFrame (throwflag=0, frame=0x7fe542bd2188, tstate=0x56517f154090) at /usr/local/src/conda/python-3.11.3/Include/internal/pycore_ceval.h:73
#12 _PyEval_Vector (kwnames=<optimized out>, argcount=1, args=0x7fe554e22ba8, locals=0x0, func=<optimized out>, tstate=0x56517f154090) at /usr/local/src/conda/python-3.11.3/Python/ceval.c:6438
#13 _PyFunction_Vectorcall (func=<optimized out>, stack=0x7fe554e22ba8, nargsf=<optimized out>, kwnames=<optimized out>) at /usr/local/src/conda/python-3.11.3/Objects/call.c:393
#14 0x0000565179b6d099 in do_call_core (use_tracing=<optimized out>, kwdict=0x7fe554cb6cc0, callargs=0x7fe554e22b90, func=0x7fe554cc9440, tstate=<optimized out>) at /usr/local/src/conda/python-3.11.3/Python/ceval.c:7356
#15 _PyEval_EvalFrameDefault (tstate=<optimized out>, frame=<optimized out>, throwflag=<optimized out>) at /usr/local/src/conda/python-3.11.3/Python/ceval.c:5380
#16 0x0000565179baf8ed in _PyEval_EvalFrame (throwflag=0, frame=0x7fe542bd2020, tstate=0x56517f154090) at /usr/local/src/conda/python-3.11.3/Include/internal/pycore_ceval.h:73
#17 _PyEval_Vector (kwnames=<optimized out>, argcount=<optimized out>, args=<optimized out>, locals=0x0, func=0x7fe538700040, tstate=0x56517f154090) at /usr/local/src/conda/python-3.11.3/Python/ceval.c:6438
#18 _PyFunction_Vectorcall (kwnames=<optimized out>, nargsf=<optimized out>, stack=<optimized out>, func=0x7fe538700040) at /usr/local/src/conda/python-3.11.3/Objects/call.c:393
#19 _PyObject_VectorcallTstate (tstate=0x56517f154090, callable=0x7fe538700040, args=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at /usr/local/src/conda/python-3.11.3/Include/internal/pycore_call.h:92
#20 0x0000565179baf6b8 in method_vectorcall (method=<optimized out>, args=0x565179ee5530 <_PyRuntime+58928>, nargsf=<optimized out>, kwnames=0x0) at /usr/local/src/conda/python-3.11.3/Objects/classobject.c:67
#21 0x0000565179c894af in thread_run (boot_raw=0x7fe537ace250) at /usr/local/src/conda/python-3.11.3/Modules/_threadmodule.c:1092
#22 0x0000565179c54494 in pythread_wrapper (arg=<optimized out>) at /usr/local/src/conda/python-3.11.3/Python/thread_pthread.h:241
#23 0x00007fe55500e802 in start_thread () from /lib64/libc.so.6
#24 0x00007fe554fae450 in clone3 () from /lib64/libc.so.6

Thread 1 (Thread 0x7fe554f6c740 (LWP 4811) "python"):
#0  0x00007fe5550871df in wait4 () from /lib64/libc.so.6
#1  0x00007fe554fd08fb in do_system () from /lib64/libc.so.6
#2  0x00007fe554a15d6d in TUnixSystem::StackTrace() () from /home/chof/mambaforge/envs/pyroot/bin/../lib/libCore.so.6.26
#3  0x00007fe554bcbe8f in (anonymous namespace)::TExceptionHandlerImp::HandleException(int) () from /home/chof/mambaforge/envs/pyroot/bin/../lib/libcppyy_backend3_11.so.6.26
#4  0x00007fe554a12ed1 in TUnixSystem::DispatchSignals(ESignals) () from /home/chof/mambaforge/envs/pyroot/bin/../lib/libCore.so.6.26
#5  <signal handler called>
#6  0x00007fe536b12e67 in Pythia8::Info::weight(int) const () from /home/chof/mambaforge/envs/pyroot/lib/./libpythia8.so
#7  0x00007fe535c5c041 in ?? ()
#8  0x0000000000000000 in ?? ()
===========================================================


The lines below might hint at the cause of the crash.
You may get help by asking at the ROOT forum https://root.cern/forum
Only if you are really convinced it is a bug in ROOT then please submit a
report at https://root.cern/bugs Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#6  0x00007fe536b12e67 in Pythia8::Info::weight(int) const () from /home/chof/mambaforge/envs/pyroot/lib/./libpythia8.so
#7  0x00007fe535c5c041 in ?? ()
#8  0x0000000000000000 in ?? ()
===========================================================


Traceback (most recent call last):
  File "/home/chof/test.py", line 5, in <module>
    pythia.info.weight()
cppyy.ll.SegmentationViolation: double Pythia8::Info::weight(int i = 0) =>
    SegmentationViolation: segfault in C++; program state was reset

Cheers, ChoF.

Wile_E_Coyote · May 8, 2023, 4:06pm

root-config --cxx --cflags

$(root-config --cxx) --version

grep CXX $(find $(pythia8-config --prefix) -name Makefile.inc | grep -i pythia)

chof · May 9, 2023, 12:44am

I did’t compile ROOT and Pythia8 by myself. I just installed the compiled ones distributed by the conda-forge channel.

Anyway, here is the result what @Wile_E_Coyote want to know.

(pyroot) $ root-config --cxx --cflags
x86_64-conda-linux-gnu-c++ -pthread -std=c++17 -m64 -I/home/chof/mambaforge/envs/pyroot/include
(pyroot) $ $(root-config --cxx) --version
x86_64-conda-linux-gnu-c++ (conda-forge gcc 10.4.0-19) 10.4.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

(pyroot) $ grep CXX $(find $(pythia8-config --prefix) -name Makefile.inc | grep -i pythia)
CXX=/home/conda/feedstock_root/build_artifacts/pythia8_1666873128456/_build_env/bin/x86_64-conda-linux-gnu-c++
CXX_COMMON=-O2 -std=c++11 -pedantic -W -Wall -Wshadow -fPIC -pthread
CXX_SHARED=-shared
CXX_SONAME=-Wl,-soname,

chof · May 9, 2023, 12:57am

@Wile_E_Coyote, you can find the conda-forge build script of ROOT and Pythia8 from GitHub:

github://conda-forge/root-feedstock/recipe/build.sh
github://conda-forge/pythia8-feedstock/recipe/build.sh

Cheers, ChoF.

Wile_E_Coyote · May 9, 2023, 6:57am

So, your ROOT uses C++17 while your Pythia 8(.307?) uses C++11 (the default setting in Pythia 8.3).
@Axel, Has such a setup ever been verified?

@chof Verify that the C++ compiler used by ROOT is the same as the one used by Pythia 8, e.g.:
ls -al $(which x86_64-conda-linux-gnu-c++)
/home/conda/feedstock_root/build_artifacts/pythia8_1666873128456/_build_env/bin/x86_64-conda-linux-gnu-c++ --version

chof · May 9, 2023, 11:23am

I could see that root-config --cxx and Pythia8’s Makefile.inc give the same compiler name x86_64-conda-linux-gnu-c++.
However, $(root-config --cxx) --version shows the version of the compiler that is installed in my current computer.
Therefore, it is not possible to know exact version of the compiler at the time when the conda package was made for distribution.

Let me know if you know how to get the exact version at the packaging time.

Wile_E_Coyote · May 9, 2023, 11:31am

O.K. I get it … the “CXX=” entry in the “Makefile.inc” is bogus (I guess the compiler is correct anyway).

Before we get a reply from the ROOT Team (if they tested the new Pythia 8.3 or not), maybe you could try to play with:

${ROOTSYS}/tutorials/pythia/pythia8.C

chof · May 9, 2023, 1:02pm

Thanks @Wile_E_Coyote.

The source of Pythia8 may give a solution. They used the following trick in the line #181-182 of pythia8307/plugins/python/generate.

    sed -i.sed 's/\(const  *Info\& *info  *=  *infoPrivate;\)/\1\n  '\
'Info infoPython() {return Info(infoPrivate);}/g' $BINDER_INCLUDE/$DIR/*.h

Cheers, ChoF.

system · May 23, 2023, 1:03pm

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