[Python] Fix crash unpickling a ROOT object without importing cppyy - #22968
Merged
Conversation
guitargeek
requested review from
aaronj0,
bellenot and
vepadulano
as code owners
July 31, 2026 07:24
Member
|
Note that I already described this behaviour at #22749 |
vepadulano
reviewed
Jul 31, 2026
vepadulano
left a comment
vepadulano
left a comment
Member
There was a problem hiding this comment.
Thanks! The changes look good per se but I wanted to ask two clarifications first
Unpickling a ROOT object resolves its reduce callable `ROOT.libROOTPythonizations._CPPInstance__expand__`, which only imports the ROOT pythonizations extension and not the cppyy backend. It then enters CPyCppyy through the public API (Instance_FromVoidPtr) to rebuild the object. In that state, `CPyCppyy::Initialize()` only imported the cppyy module in the branch taken when Python was not yet initialized. When Python is already running (the normal unpickling case), that branch is skipped and `Initialize()` returned success without ever importing cppyy, leaving gThisModule null. `CreateScopeProxy()` then dereferenced it as a fake scope and crashed with a segmentation violation. Ensure the cppyy extension module is imported whenever `gThisModule` is still null, so the public API is usable regardless of how CPyCppyy was entered. Add a regression test that pickles a ROOT object and reads it back in a fresh interpreter where cppyy has not been imported yet. 🤖 Done with the help of AI.
Test Results 23 files 23 suites 3d 14h 25m 24s ⏱️ Results for commit 5de287b. |
Contributor
Author
|
/backport to 6.40 |
|
Preparing to backport PR #22968 to branch 6.40 requested by guitargeek |
|
Something went wrong with the creation of the PR to backport to 6.40: @guitargeek please see the logs |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Unpickling a ROOT object resolves its reduce callable
ROOT.libROOTPythonizations._CPPInstance__expand__, which only imports the ROOT pythonizations extension and not the cppyy backend. It then enters CPyCppyy through the public API (Instance_FromVoidPtr) to rebuild the object.In that state,
CPyCppyy::Initialize()only imported the cppyy module in the branch taken when Python was not yet initialized. When Python is already running (the normal unpickling case), that branch is skipped andInitialize()returned success without ever importing cppyy, leaving gThisModule null.CreateScopeProxy()then dereferenced it as a fake scope and crashed with a segmentation violation.Ensure the cppyy extension module is imported whenever
gThisModuleis still null, so the public API is usable regardless of how CPyCppyy was entered.Add a regression test that pickles a ROOT object and reads it back in a fresh interpreter where cppyy has not been imported yet.
🤖 Done with the help of AI.
Addresses a problem described on the forum: