Repository navigation
str() segfaults on objects of classes that have no operator<< #119
Copy link
Copy link
Open
Description
Hi, hit this issue while testing my Cppyy based code with Cppjit. Not completely sure if it is intended or not, so reporting it.
import cppjit
cppjit.cppdef("struct Id {};")
x = cppjit.gbl.Id()
print(repr(x)) # OK: <cppjit.gbl.Id object at 0x...>
print(str(x)) # crashes the interpreter Current behavior
The process crashes inside PyObject_Str:
3 python PyObject_GetAttrString + 4
4 libcppjit.so 0x...
5 python PyObject_Str + 325
6 python PyFile_WriteObject + 66
...
**************************************************
CppInterOp CRASH DETECTED
**************************************************
PyObject_GetAttrString looks like it's being called with a NULL object, maybe in the path that falls back when no operator<< is found.
Expected behavior
Fall back to repr(), like cppyy does. With cppyy 3.5.0 (CPython 3.12), the same snippet prints <cppyy.gbl.Id object at 0x...>.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels
Activity
Gabrielcarvfer commentedon Sep 29, 2026
Maybe this is fixed in fe202d8?
aaronj0 commentedon Oct 6, 2026
Indeed, that commit prevents the crash. We should have more coverage on the value printing of C++ entities in Python as the developments in clang-repl improve but the current support in LLVM 22 should cover most cases. Specific to strings, ROOT goes with always converting a returned std::string to a Python string unless explicitly
cppjit.gbl.std.string(see 5b0c948, cc @guitargeek). That hasn't landed that in main yet since a few things need to be revisted in that context. In the mean time we will need #121 tha addresses the assumption that the returned entity is always an instance (the prior causes a crash)