Why I see so much strange ruff segfaults?

[qarmin]

When I run checking with ruff . --fix a lot of files, then I nothing special happens.

When I do this in parallel, then results are still "good"(sometimes ruff exits with status 1, because it found bugs in code) and nothing else is printed into output - no panic/crashes etc, but in system journal I see such messages

wrz 22 22:15:25 H87M-D3H kernel: ruff[454275]: segfault at 7fe96be038d8 ip 000055b80919d69a sp 00007fe9719fd6a0 error 6 likely on CPU 4 (core 0, socket 0)
wrz 22 22:15:25 H87M-D3H kernel: Code: 00 00 66 0f ef c0 31 c9 48 8d b8 a8 28 00 00 c7 40 04 00 00 00 00 48 c7 40 10 00 00 00 00 ba 0f 00 00 00 48 8d 35 cd 0b 2e 00 <0f> 11 80 98 28 00 00 e8 da 5f 05 00 84 c0 0f 85 ea 00 00 00 e8 bd
wrz 22 22:15:28 H87M-D3H kernel: ruff[460385]: segfault at 7fa648dfcfe8 ip 00007fa64a28eeac sp 00007fa648dfcfe0 error 6 likely on CPU 5 (core 1, socket 0)
wrz 22 22:15:28 H87M-D3H kernel: Code: 35 77 72 12 00 48 8d 3d 81 72 12 00 e8 ed 4a fa ff 45 31 ed e9 5c fe ff ff 0f 1f 44 00 00 f3 0f 1e fa 41 54 55 53 48 83 c4 80 <48> 89 7c 24 08 64 48 8b 04 25 28 00 00 00 48 89 44 24 78 31 c0 80

I tried to use both valgrind and asan with ruff, but I did not find anything

[MichaReiser]

I'm not sure what's going on. Could you share some more details about your OS, OS, CPU architecture etc...

[MichaReiser]

It's hard to tell without more output or access to the test files. It could be a real issue in ruff. Do you have a narrowed-down list of files for which this is happening? Does ruff segfault when calling it manually (without your wrapper script) or does it only happen when running in parallel?

[qarmin]

Example of file

"""LRU cache.

Copyright: (c) 2019 by Vasyl Paliy.
License: MIT, see LICENSE for more details.
"""

63.py.zip

I just created 600 copies, to be sure that there will be enough work to do this in parallel

With

find /home/rafal/test/DOWNLOADED/py_files4 -type f | parallel -j+0 ruff format {} --check

I have exactly same problem

[MichaReiser]

I wonder if it is because of the broken pipe error

rust-lang/rust#46016

The way to fix this is to not use println and instead use writeln everywhere

[qarmin]

I commented every single one occurence of print!, println! and eprintiln! and still have same errors

With thread, address sanitizer and valgrind I don't see such errors, probably because they works too slow to trigger it,
but with memory sanitizer I have similar messages in journal.

With this tools I don't see any memory/thread errors, that could cause problem

[MichaReiser]

Interesting. I'm out for the next two weeks but that sounds like an interesting puzzle to solve.