SIGSEGV at end thrown in v1.5.2 but not in previous version

[petrushy]

Hi,

I have quite little info yet, but in the tests we have in the project orekit the new 1.5.2 is throwing a SIGSEV at the end of tests while it works with 1.5.1, 1.5.0.

It comes at the very end after tests are (successfully) concluded, so I guess it has to do with the shutdown of the JVM.

It happens when pytest itself discovers the tests, if i run them one by one it does not appear.

The MR for orekit is at https://gitlab.orekit.org/orekit/orekit_jpype/-/merge_requests/26

I can reproduce this outside the CI by running "uv run python3 -m pytest" in the test dir.

Sorry for the fragmented information but in case it gives some hints it would be good.

[Thrameos]

There was some code changed on shutdown. Perhaps it is a race condition that got introduced with the non-ansi cleanup.

If you gat get me a reduced example I can look at it.

[Thrameos]

On hold pending more info.

[petrushy]

Will try to collect some info, but seems to be some race condition yes.

When running "uv run pytest ."

Apr 28 07:58:46 P14sG3 systemd-coredump[47736]: Process 47632 (python3) of user 1000 dumped core.

                                            Found module libnss_mdns4_minimal.so.2 with build-id: a976800e191c9353f1e93a5b436c126f2d672ffb
                                            Found module libnet.so with build-id: b6371aaf4fad42a7a39e1b9d27e4ea8f574f3a42
                                            Found module libnio.so with build-id: b8df8ee414b99a6e61141f34dec2ef36930eea6f
                                            Found module libjsvml.so with build-id: 68d3aaba9fed1755aaf011296cedf1b555e444b5
                                            Found module libz.so.1 with build-id: 30840b79ac329ecbf1dec0bb60180eed256d319f
                                            Found module libzip.so with build-id: 341f4fc4da677b1f690ec2e7ebd554b4cdbde16e
                                            Found module libjava.so with build-id: d149afa6bd288c4e9ae4b26d70b64a62199fbf16
                                            Found module libjimage.so with build-id: d22021f4afac7c67866a2534567fc2ee4e3d91eb
                                            Found module libjvm.so with build-id: 61915200f7fabd1be10a53a6dd6d974dd4248b3b
                                            Found module libgcc_s.so.1 with build-id: e3a44e0da9c6e835d293ed8fd2882b4c4a87130c
                                            Found module libstdc++.so.6 with build-id: e37fe1a879783838de78cbc8c80621fa685d58a2
                                            Found module ld-linux-x86-64.so.2 with build-id: e4de036b19e4768e7591b596c4be9f9015f2d28a
                                            Found module libc.so.6 with build-id: cd410b710f0f094c6832edd95931006d883af48e
                                            Found module librt.so.1 with build-id: c3e9022a22e9f071f3ee0abfa52f1b6d33f3c19b
                                            Found module libm.so.6 with build-id: 7d8778fca8ea4621b268cc03662855d0cd983439
                                            Found module libutil.so.1 with build-id: 518cbe5d428789f966c67ff2f816757a792529b1
                                            Found module libdl.so.2 with build-id: 17bf32e2613dc600b367d0f8a341669c80ad790e
                                            Found module libpthread.so.0 with build-id: 81f46d553e2f7c999e43c3eede73a822bc8d5d93
                                            Stack trace of thread 47734:
                                            #0  0x00007467c7e31acd n/a (n/a + 0x0)
                                            #1  0x00007467c7279cb6 n/a (n/a + 0x0)
                                            #2  0x00007467c7279cb6 n/a (n/a + 0x0)
                                            #3  0x00007467c7279cb6 n/a (n/a + 0x0)
                                            #4  0x00007467c7279cb6 n/a (n/a + 0x0)
                                            #5  0x00007467c727a112 n/a (n/a + 0x0)
                                            #6  0x00007467c725fcc6 n/a (n/a + 0x0)
                                            #7  0x00007467d7a9a82b n/a (libjvm.so + 0x89a82b)
                                            #8  0x00007467d7a9b1d5 n/a (libjvm.so + 0x89b1d5)
                                            #9  0x00007467d7b8984e n/a (libjvm.so + 0x98984e)
                                            #10 0x00007467d7fb2f88 n/a (libjvm.so + 0xdb2f88)
                                            #11 0x00007467d7dd2207 n/a (libjvm.so + 0xbd2207)
                                            #12 0x00007467da894ac3 start_thread (libc.so.6 + 0x94ac3)
                                            #13 0x00007467da926850 __clone3 (libc.so.6 + 0x126850)
                                            
                                            Stack trace of thread 47632:
                                            #0  0x00007467da891117 __futex_abstimed_wait_common64 (libc.so.6 + 0x91117)
                                            #1  0x00007467da893a41 __pthread_cond_wait_common (libc.so.6 + 0x93a41)
                                            #2  0x00007467d7dc507b n/a (libjvm.so + 0xbc507b)
                                            #3  0x00007467d7dba8e5 n/a (libjvm.so + 0xbba8e5)
                                            #4  0x00007467d7b8090e JVM_MonitorWait (libjvm.so + 0x98090e)
                                            #5  0x00007467c727e051 n/a (n/a + 0x0)
                                            #6  0x00007467c7279cb6 n/a (n/a + 0x0)
                                            #7  0x00007467c7279cb6 n/a (n/a + 0x0)
                                            #8  0x00007467c7279cb6 n/a (n/a + 0x0)
                                            #9  0x00007467c7279cb6 n/a (n/a + 0x0)
                                            #10 0x00007467c7279cb6 n/a (n/a + 0x0)
                                            #11 0x00007467c727a112 n/a (n/a + 0x0)
                                            #12 0x00007467c7279cb6 n/a (n/a + 0x0)
                                            #13 0x00007467c725fcc6 n/a (n/a + 0x0)
                                            #14 0x00007467d7a9a82b n/a (libjvm.so + 0x89a82b)
                                            #15 0x00007467d7a9bfbd n/a (libjvm.so + 0x89bfbd)
                                            #16 0x00007467d7b229f0 n/a (libjvm.so + 0x9229f0)
                                            #17 0x00007467daab20e2 n/a (n/a + 0x0)
                                            #18 0x00007467db008be6 n/a (n/a + 0x0)

[petrushy]

Running in test dir:
PYTHONFAULTHANDLER=1 uv run python3 -m pytest -ra .
...
Fatal Python error: Segmentation fault
Thread 0x0000754385716740 (most recent call first):
File "XXXXX/orekit_jpype/.venv/lib/python3.12/site-packages/jpype/_core.py", line 490 in _JTerminate
Extension modules: _jpype, numpy._core._multiarray_umath, numpy.linalg._umath_linalg (total: 3)

Will continue to log "application specific" troubleshooting the application library issue https://gitlab.orekit.org/orekit/orekit_jpype/-/issues/15

[Thrameos]

Does it fail on 1.5.2 and 1.5.0 and was fixed in 1.5.1 or did it start in 1.5.2?

(For context 1.5.1 was an odd beast that introduced agents, and 1.5.2 was mostly a roll back with the exception of non-ascii paths. If I can delta from 1.5.0 rather than 1.51 it will make isolation easier due to the roll back.)

[petrushy]

Hi,

It works on 1.5.0 and 1.5.1,
It crashes on 1.5.2.

I have tried some different python versions but not systematically, but all has shown so far same behavior.

[Thrameos]

That limits the place for errors to two candidates.

1. Changes to handle non-ascii paths which involve check for clean up (unlikely because your JVM isn't on non-ascii path)
2. Changes to PyJPValue required because Python still doesn't have a stable memory layout for objects which requires us to build a dummy type using a mutex, then mutating the memory allocated to our desired layout.

(a very remote chance that it could be the Jar loader simplification, but that is a startup issue not termination)

The latter is most likely source of a race condition in the mutex creating types. However, that only happens when objects are born not having anything to due with shutdown. However, it is very likely that the mutex is trying to clean itself up in C++.

Here is my recommendation. Change the mutex in pyjp_value to a mutex* and allocate in the pyjp_module init function at the start of module load. This would ensure the mutex exists when we need it and would guarantee it never gets cleaned up off the heap. If it works submit the PR. If not, report back and we can devise a new plan (most likely using a selective roll back)

[Christopher-Chianelli]

I think I might have hit the same issue; in my case, it is limited to Java 24 and C2 (i.e. crash does not occur if Java is 23 or below, or if C2 is disabled).

[Christopher-Chianelli]

Can confirm I have the same issue, and can report the follow characteristics apply to this bug:

• Only affects Java 24 when C2 is enabled
• Java 23 and below are unaffected