Zuming Jiang

@ismaell Thanks for your response. It may be a little strange. At least, my fuzzer actually finds that conn_setup() and reactivate_connection() run concurrently. I review the code of axel_do(), and...

> Well, I can't claim there's no bugs in the code, but setup_thread is called only after joining the thread, so the thread should not be running. For example, in...

> *Shouldn't* be possible, the idea is that the connection will be reactivated only when the thread finised; reactivate_connection has a guard to prevent touching an active cconnection. Do you...

> And now looking at it again, the lock is correctly taken when reaching this function... I can't find any problem with that specific variable. There is however concurrency bugs...

Maybe the impact of this race is not serious. Anyway, I think it is good discussion. Thanks for your response. And I'm sorry for disturbing you.

The race is still alive. I think the problem is that `reactivate_connection()` can access other `axel->conn`, while it doesn't need to acquire their coresponding locks. For example, `reactivate_connection()` can access...

> I was hoping to ignore all this until I had time to rewrite the thing to use async I/O instead of threads, as there are too many problems with...

@alexey-milovidov Thank you very much for your recognition to my new tool! I am happy it could help you. However, TxCheck is not the tool I used to test ClickHouse....

Dear @alexey-milovidov, We are very happy to share with you the news that our paper on the tool we used to test ClickHouse has been accepted by OSDI 2024! The...

@xiaofan-luan Yes, so [log.testcase.16k.py.txt](https://github.com/user-attachments/files/20709532/log.testcase.16k.py.txt) triggers the bug, as its search results are not empty