Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Debugging segfaults during pycurl tests
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Scott Talbert via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 18 Nov 2024 22:18:58 -0500 (EST)
Hello curl folks,
I've been the defacto maintainer for pycurl over the past year or two.
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_at_entry=11, no_tid=no_tid_at_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_at_entry=11, no_tid=no_tid_at_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_at_entry=0xd1d4180, e=0x0,
p=p_at_entry=0xd1b09a0, ne=ne_at_entry=0xd1b09c0)
at ./debian/build/lib/llist.c:102
#5 0x00007fdf469509b3 in Curl_llist_append (list=list_at_entry=0xd1d4180,
p=p_at_entry=0xd1b09a0, ne=ne_at_entry=0xd1b09c0)
at ./debian/build/lib/llist.c:134
#6 0x00007fdf4695c384 in multi_runsingle (multi=multi_at_entry=0xd1d4110,
nowp=nowp_at_entry=0x7fff2510d870, data=data_at_entry=0xd1b09a0)
at ./debian/build/lib/multi.c:2973
#7 0x00007fdf4695d809 in curl_multi_perform (m=0xd1d4110,
running_handles=running_handles_at_entry=0x7fff2510d97c)
at ./debian/build/lib/multi.c:3013
#8 0x00007fdf481bc786 in do_multi_perform (self=0x7fdf3eee49a0,
_unused_ignored=<optimized out>) at src/multi.c:604
#9 0x0000000000579fc3 in ?? ()
#10 0x0000000000543a24 in PyObject_Vectorcall ()
#11 0x00000000005cee43 in _PyEval_EvalFrameDefault ()
I'm not able to reproduce the issue when running the tests individually,
only when running them all at the same time (in the same process). Thus,
it seems most likely to me that some test(s) are not properly cleaning up
some libcurl global state after running. That, or perhaps there is some
sort of race in teardown/cleanup that breaks something.
Thus, do you all have any advice for how to debug or otherwise resolve
this issue?
1) Should I be calling curl_global_cleanup() after every test, and is
that sufficient to ensure libcurl is in a good state for the next test?
2) Or should I be running each test in a separate process?
3) Any other ideas?
Thanks a lot,
Scott Talbert
Date: Mon, 18 Nov 2024 22:18:58 -0500 (EST)
Hello curl folks,
I've been the defacto maintainer for pycurl over the past year or two.
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_at_entry=11, no_tid=no_tid_at_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_at_entry=11, no_tid=no_tid_at_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_at_entry=0xd1d4180, e=0x0,
p=p_at_entry=0xd1b09a0, ne=ne_at_entry=0xd1b09c0)
at ./debian/build/lib/llist.c:102
#5 0x00007fdf469509b3 in Curl_llist_append (list=list_at_entry=0xd1d4180,
p=p_at_entry=0xd1b09a0, ne=ne_at_entry=0xd1b09c0)
at ./debian/build/lib/llist.c:134
#6 0x00007fdf4695c384 in multi_runsingle (multi=multi_at_entry=0xd1d4110,
nowp=nowp_at_entry=0x7fff2510d870, data=data_at_entry=0xd1b09a0)
at ./debian/build/lib/multi.c:2973
#7 0x00007fdf4695d809 in curl_multi_perform (m=0xd1d4110,
running_handles=running_handles_at_entry=0x7fff2510d97c)
at ./debian/build/lib/multi.c:3013
#8 0x00007fdf481bc786 in do_multi_perform (self=0x7fdf3eee49a0,
_unused_ignored=<optimized out>) at src/multi.c:604
#9 0x0000000000579fc3 in ?? ()
#10 0x0000000000543a24 in PyObject_Vectorcall ()
#11 0x00000000005cee43 in _PyEval_EvalFrameDefault ()
I'm not able to reproduce the issue when running the tests individually,
only when running them all at the same time (in the same process). Thus,
it seems most likely to me that some test(s) are not properly cleaning up
some libcurl global state after running. That, or perhaps there is some
sort of race in teardown/cleanup that breaks something.
Thus, do you all have any advice for how to debug or otherwise resolve
this issue?
1) Should I be calling curl_global_cleanup() after every test, and is
that sufficient to ensure libcurl is in a good state for the next test?
2) Or should I be running each test in a separate process?
3) Any other ideas?
Thanks a lot,
Scott Talbert
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-11-19