`test_examples.test_ictf2017_javaisnotfun` intermittently crashes with SIGSEGV in CI

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

`tests/test_examples.py::test_ictf2017_javaisnotfun` fails intermittently in the angr `ci` workflow with a segmentation fault. It has appeared twice in ten days on unrelated commits, and the second occurrence passed on a plain re-run with no code change.

## Signature

Both occurrences end the same way, quoting the 2026-08-28 log:

```
Fatal Python error: Segmentation fault
...
FAILED src/angr-examples/tests/test_examples.py::test_ictf2017_javaisnotfun - /__w/angr/angr/build/src/angr-examples/tests/test_examples.py:251: running the test CRASHED with signal 11 (SIGSEGV)
```

`Extension modules:` on both crash reports lists `_jpype` among the loaded natives.

## Occurrences

| Date | Run | Job | Branch | Head |
| --- | --- | --- | --- | --- |
| 2026-08-18 | [32122851256](https://github.com/angr/angr/actions/runs/32122851256) | 95673009076 (`ci / Test (7)`) | `master`, push | `3425b2371f76804b54ba1fa7013181da86c7faeb` |
| 2026-08-28 | [33160351711](https://github.com/angr/angr/actions/runs/33160351711) | 98814490897 (`ci / Test (7)`) | pull request [angr/angr#7007](https://github.com/angr/angr/pull/7007) | `e0e78fdaee342cb698ae09accb23d43ed31514db` |

The second was re-run with `gh run rerun --failed` against the same commit, with nothing pushed in between; job 98821617241 passed the identical shard in 6m11s. The same tree failing and then passing untouched is what makes this a flake rather than a break.

## The two stacks agree below claripy and differ above it

This is worth stating precisely, because "same crash" would be too strong.

The bottom of both stacks is identical — the same example, the same step loop, entered through the Soot engine:

```
angr/sim_manager.py:473 in step
angr/sim_manager.py:514 in step_state
angr/sim_manager.py:564 in successors
angr/engines/soot/engine.py in process_successors
examples/ictf2017_javaisnotfun/solve.py:149 in solve_given_numbers_angr
examples/ictf2017_javaisnotfun/solve.py:178 in test_t2
tests/test_examples.py:253 in test_ictf2017_javaisnotfun
```

Above that they diverge, and both fault inside libz3 reached through claripy's Z3 backend.

2026-08-28 — a single thread, in `Z3_simplify` under a memory store while setting up a native callsite:

```
z3/z3core.py:3289 in Z3_simplify
claripy/backends/backend_z3.py:1011 in simplify
angr/state_plugins/solver.py:1085 in _claripy_simplify
angr/storage/memory_mixins/simplification_mixin.py:12 in store
angr/calling_conventions.py:1002 in setup_callsite
angr/simos/javavm.py:274 in state_call
angr/engines/soot/engine.py:407 in _setup_native_callsite
```

2026-08-18 — two threads. The current thread is in `Z3_solver_check_assumptions` and is marked `Garbage-collecting`, while a second thread is inside `Z3_solver_dec_ref`, called from `z3.Solver.__del__`:

```
Thread 0x00007fa388f1c6c0 (most recent call first):
z3/z3core.py:4101 in Z3_solver_dec_ref
z3/z3.py:6964 in __del__

Current thread 0x00007fa3bd285080 (most recent call first):
Garbage-collecting
z3/z3core.py:4235 in Z3_solver_check_assumptions
claripy/backends/backend_z3.py:265 in z3_solver_sat
...
angr/sim_state.py:506 in satisfiable
angr/engines/successors.py:229 in _categorize_successor
angr/sim_procedure.py:531 in ret
```

Same test, same signal, same Soot-driven example; different Z3 entry point.

## How often

Over the last 100 `ci` runs on `master`, spanning 2026-07-29 to 2026-08-28: 66 succeeded, 16 failed, 17 were cancelled, 1 was still in flight. Of the 16 failures, 11 were `ci / Lint` and 6 carried a failing `ci / Test (N)` job. Exactly one of those 6 was this signature; the other five were `angr/tests/exploration_techniques/test_tracer.py` (four runs) and `rex/tests/test_explore.py::test_write_what_where_shadowstack` (one run), unrelated to this.

Roughly one occurrence per 100 `master` runs, plus the pull-request one above. Pull requests were not sampled, so treat that as a floor rather than a rate.

## Not diagnosed

We did not find a root cause. What is established is that the failure is intermittent, that it clears on re-run without a code change, and that it has now recurred on an unrelated commit. No native backtrace was collected and nothing below the Python frames above was measured, so this report makes no claim about JVM, JPype, or Z3 internals — including about the two-thread arrangement in the 2026-08-18 stack, which is quoted because it is in the log, not because we traced its significance.

## Where the cost lands

One observation about the arrangement, offered as information rather than a request.

`ci / Test (N)` runs the suites of ten repositories in sequence inside a single job: angr, angr-examples, angr-management, angr-platforms, angrop, driller, heaphopper, patcherex, rex, and tracer. A crash in any of them fails the whole job under one name.

In the 2026-08-28 occurrence, angr's own shard passed cleanly — `252 passed, 3 skipped, 2 xfailed` — and the job still went red on the `angr-examples` crash. On a pull request the contributor sees `ci / Test (7)` failing and reasonably starts with their own diff. Establishing that a decompiler-only change was unrelated to a Soot symbolic-execution example took a log fetch, a search back through `master` for a precedent, and a full re-run cycle. That cost recurs for whoever meets this next, and it is separate from the flake itself.

session: crazybins