[fix] Null-guard the cling.printValue lookup in op_str by conrade-ctc · Pull Request #56 · compiler-research/cppjit

conrade-ctc · 2026-08-31T17:38:24Z

str() on any instance without an ostream inserter segfaults on current
main. Commit 5a33027 dropped the faked cling::runtime::gCling, and the
pretty-print fallback in op_str then dereferenced the failed
cppjit.gbl.cling lookup. This guards both lookups, clears the
AttributeError, and falls back to the generic repr.

Repro:

import cppjit
cppjit.cppdef("struct Bare { int x; };")
str(cppjit.gbl.Bare())      # SIGSEGV

A regression test is included. The crash kills the interpreter, so the test
asserts the fixed behaviour rather than the crash.

aaronj0 · 2026-08-31T20:13:02Z

-      PyObject* cl = PyObject_GetAttrString(gbl, (char*)"cling");
-      printValue = PyObject_GetAttrString(cl, (char*)"printValue");
-      Py_DECREF(cl);
+      // no cling namespace exists unless user code declares one


Perhaps we can just short-circuit this path completely if we know the interpreter is clang-repl, since that lookup would always return null. We could use the compile-time definition CPPJIT_USE_CLING, or a runtime check like in test/support.py

Good call — done. The whole pretty-printing block now sits behind #ifdef CPPJIT_USE_CLING, so clang-repl builds compile it out and str() falls straight through to the generic repr; strings on the clang-repl libcppjit.so shows the printValue lookup gone, and the object shrinks slightly. One thing the gate needed: CPPJIT_USE_CLING was only ever a CMake option and never reached the sources, so I added the matching target_compile_definitions entry — without it the #ifdef would have been false on the cling build too. The null-guards stay inside the cling branch, in case an odd cling state leaves the lookup empty. Worth naming the trade-off: a user-declared namespace cling { printValue } is no longer honored on clang-repl, which I think is right given the native value-printing direction in compiler-research/CppInterOp#1100.

The in-process test52 crashed the llvm22 and cling CI lanes with a SIGSEGV, hiding the rest of the suite. Match compiler-research#56's head: the cling pretty-print path in op_str now compiles out entirely behind CPPJIT_USE_CLING on clang-repl, with the matching CMake compile-definition wiring, and the regression test runs its repro in a subprocess so a crash fails the assertion instead of the runner. Co-developed-with-the-help-of: Claude Code (Sonnet 5, human in the loop)

vgvassilev · 2026-09-01T04:52:39Z

-  // reasons)
+  // reasons). Cling only: clang-repl has no cling namespace to look up, so the
+  // whole path compiles out and str() falls through to the generic repr.
+#ifdef CPPJIT_USE_CLING


This should probably be required to CppInterOp’s toString interface which will still crash for clang-repl but this time we can fix it there.

Happy to make that change here: route str() through Cpp::ObjToString and drop the cling-only block. clang-repl would then keep failing in toString until compiler-research/CppInterOp#1100 lands the fix there. Do you want that in this PR, or should we keep the short-circuit and switch once #1100 is fixed?

vgvassilev

Lgtm!

aaronj0

LGTM % the comments

aaronj0 · 2026-09-10T13:12:13Z

    CPPINTEROP_INCLUDE_DIR="${CPPJIT_INTEROP_RUNTIME_INCLUDES}"
    CPPJIT_CLANG_MAJOR="${CPPJIT_INTEROP_CLANG_MAJOR}"
    CPPJIT_CLANG_INCLUDE_DIR="${CPPJIT_INTEROP_CLANG_DIR}"
+    # cling-only code paths need the flavor at compile time, not just in cmake


We can probably drop this comment here.

aaronj0 · 2026-09-10T13:13:15Z

        with raises(TypeError):
            cppjit.gbl.std.vector[object()]
+
+    def test53_str_fallback_without_ostream_insertion(self):


We do have existing tests that are marked crashing with clang-repl due to ToString. I am not sure if adding a Python test that spawns a process guaranteed to crash is a good idea, especially since this does not live on the API surface, and this test suite is meant to be user-facing. Imo this can be moved into a CppInterOp only reproducer. If compat::GetClingPrintValue() returns null, can we prevent the crash and gracefully error out instead?

The null return was already safe. op_str falls through to the generic repr there.

The crash the test caught happens one step earlier. op_str calls Cpp::ObjToString, and Interpreter::toString is an assert(0) stub. It aborts with assertions on and returns "" without them. The stub is not backend specific, so the existing markers say "and on Cling".

I moved that call behind the same compatibility header and made it return the empty string on every build, so op_str reaches the generic repr everywhere. #1100 turns the helper back into a one-line forward.

The subprocess test is gone. The new test53 runs in process and checks that str(obj) equals repr(obj). The three xfail markers that named this crash now pass on an assertions-on build, so I removed them.

Prevent a null dereference when str() cannot find cling.printValue. Keep the interpreter check and cached lookup in Compatibility.h. The helper returns nullptr on clang-repl and preserves the Cling fallback. Pass CPPJIT_USE_CLING from CMake to the sources. Skip the CppInterOp ObjToString call. Its toString is an assert(0) stub, so the call aborts with assertions on and returns "" without them. op_str now falls back to the generic repr on every build. Test the repr fallback in process. The earlier subprocess test is no longer necessary, because the path does not crash. Retire the three xfail markers that named the toString crash. Co-developed-with-the-help-of: Claude Code (Fable 5, human in the loop) Co-developed-with-the-help-of: Claude Code (Opus 5, human in the loop) Co-developed-with-the-help-of: OpenAI Codex (GPT-6, human in the loop)

conrade-ctc force-pushed the opstr-null-guard branch 4 times, most recently from cc6b1ab to 06c8899 Compare August 31, 2026 19:54

aaronj0 reviewed Aug 31, 2026

View reviewed changes

conrade-ctc force-pushed the opstr-null-guard branch from 06c8899 to 40e8086 Compare August 31, 2026 21:27

conrade-ctc mentioned this pull request Aug 31, 2026

Port the op_str short-circuit and subprocess test52 from #56 chicagotrading/cppjit#3

Merged

conrade-ctc force-pushed the opstr-null-guard branch from 40e8086 to e043129 Compare August 31, 2026 23:13

vgvassilev reviewed Sep 1, 2026

View reviewed changes

aaronj0 force-pushed the main branch from b101e1c to 1213c8c Compare September 6, 2026 08:43

conrade-ctc force-pushed the opstr-null-guard branch from e043129 to e5f3418 Compare September 8, 2026 14:16

vgvassilev reviewed Sep 8, 2026

View reviewed changes

Comment thread src/cpyrt/CPPInstance.cxx Outdated

conrade-ctc force-pushed the opstr-null-guard branch from e5f3418 to 53ae578 Compare September 9, 2026 19:05

vgvassilev previously approved these changes Sep 10, 2026

View reviewed changes

aaronj0 previously approved these changes Sep 10, 2026

View reviewed changes

conrade-ctc dismissed stale reviews from aaronj0 and vgvassilev via 0697f8d September 10, 2026 17:56

conrade-ctc force-pushed the opstr-null-guard branch from 53ae578 to 0697f8d Compare September 10, 2026 17:56

Navigation Menu

Uh oh!

[fix] Null-guard the cling.printValue lookup in op_str - #56

[fix] Null-guard the cling.printValue lookup in op_str#56
conrade-ctc wants to merge 1 commit into
compiler-research:mainfrom
chicagotrading:opstr-null-guard

conrade-ctc commented Aug 31, 2026

Uh oh!

aaronj0 Aug 31, 2026

Uh oh!

conrade-ctc Aug 31, 2026

Uh oh!

vgvassilev Sep 1, 2026

Uh oh!

conrade-ctc Sep 1, 2026

Uh oh!

Uh oh!

vgvassilev left a comment

Uh oh!

aaronj0 left a comment

Uh oh!

aaronj0 Sep 10, 2026

Uh oh!

conrade-ctc Sep 10, 2026

Uh oh!

aaronj0 Sep 10, 2026

Uh oh!

conrade-ctc Sep 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

conrade-ctc commented Aug 31, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

vgvassilev left a comment

Choose a reason for hiding this comment

Uh oh!

aaronj0 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants