On Mon, Nov 18, 2024 at 10:18:58PM -0500, Scott Talbert via curl-library wrote: > Starting around curl 8.10.0, we started to see intermittent segfaults while > running pycurl's unit > tests. The stacktraces generally all look like this: > > Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > Core was generated by `python3 -m pytest -v'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 __pthread_kill_implementation (threadid=<optimized out>, > signo=signo@entry=11, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 > > warning: 44 ./nptl/pthread_kill.c: No such file or directory > [Current thread is 1 (Thread 0x7fdf4910e080 (LWP 3532))] > (gdb) bt > #0 __pthread_kill_implementation (threadid=<optimized out>, > signo=signo@entry=11, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 > #1 0x00007fdf491a2ebf in __pthread_kill_internal (threadid=<optimized out>, > signo=11) at ./nptl/pthread_kill.c:78 > #2 0x00007fdf4914ec82 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26 > #3 <signal handler called> > #4 Curl_llist_insert_next (list=list@entry=0xd1d4180, e=0x0, > p=p@entry=0xd1b09a0, ne=ne@entry=0xd1b09c0) > at ./debian/build/lib/llist.c:102
Crashes here are almost always the result of using libcurl in a multithreading manner without taking the precautions listed in https://curl.se/libcurl/c/threadsafe.html The biggest one that's still left in recent libcurl versions is that handles may not ever be accessed in more than one thread at the same time, but another is to set CURLOPT_NOSIGNAL to 1. I don't know what your test code looks like or how you're distributing tests across threads, but those would be the first two to look at. For example, if the test class creates a single handle that each test method then uses, running those test methods in parallel could easily result in this kind of chaos. Dan -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
