Benjamin Lorenz

I have a preliminary fix for the crash I reported (`jl_object_id__cold`) here: https://github.com/oscar-system/Singular.jl/pull/749. This adds a missing GC protection in the `libsingular_julia` code for passing data from a `sleftv` back...

The original error (`GC error (probable corruption)`) also happens on macos, observed during my flint 2.9 backport testing: https://github.com/benlorenz/Oscar.jl/actions/runs/7583365592/job/20655088309#step:9:4981 (but even less often than on ubuntu)

I can add the message, but I would like to hold off a bit with adding something like an explicit GC now since we just started doing the tests with...

It still happens with the new libsingular and even with the explicit GC call it happens within the IPC.jl tests: https://github.com/oscar-system/Oscar.jl/actions/runs/7638814195/job/20810486432?pr=3229#step:8:4959 Unfortunately I haven't been able to reproduce this crash...

The workers should be less memory starved now, they were recently upgraded to have 4 CPUs and 16 GB of memory.

I have opened a PR to disable the IPC test for now while I try to debug this further: https://github.com/oscar-system/Oscar.jl/pull/3246

Thanks for noticing. That is interesting, it turns out that the effect of doing `GC.gc()` before the IPC.jl tests seems to increase the rate at which the error occurs. (But...

Our CI looks a lot better now without the IPC.jl tests, which should help with development. But I am continuing to look into this. Please post any further errors you...

After some more debugging I found that the error will quite surely be gone once 1.10.1 is released, fixed via [JuliaLang/julia@`8a04df0` (#52755)](https://github.com/JuliaLang/julia/pull/52755/commits/8a04df087c1e77cc080936ac6e023cbb67feefdd). I don't really now why this happens so...

Regarding option 1: I just did exactly such an update for libpolymake_julia, rebuilding it (with a new version due to the compat) to adapt to the new `libcxxwrap_julia` version for...