Buy commercial curl support from
WolfSSL. 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 himself.
Re: SIGSEGV in curl-8.6.0/lib/http2.c:288 (curl_multi_perform->extract_if_dead->http2_data_done)
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 27 Mar 2024 15:14:04 +0100
> Am 26.03.2024 um 18:04 schrieb Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>:
>
>
>
>> Am 26.03.2024 um 17:09 schrieb Aleksander Mazur via curl-library <curl-library_at_lists.haxx.se>:
>>
>> Sorry for garbled gdb output, I hope this time it will look better:
>>
>> #0 0x00007ffff7e4a6ba in http2_data_done (cf=0x794698, data=0x490878, premature=true) at http2.c:288
>> #1 0x00007ffff7e4f1e9 in cf_h2_cntrl (cf=0x794698, data=0x490878, event=2, arg1=0, arg2=0x0) at http2.c:2513
>> #2 0x00007ffff7e2ad14 in Curl_conn_cf_cntrl (cf=0x794698, data=0x490878, ignore_result=true, event=2, arg1=0, arg2=0x0) at cfilters.c:501
>> #3 0x00007ffff7e2af39 in cf_cntrl_all (conn=0x79bf28, data=0x490878, ignore_result=true, event=2, arg1=0, arg2=0x0) at cfilters.c:551
>> #4 0x00007ffff7e2afd0 in Curl_conn_ev_data_detach (conn=0x79bf28, data=0x490878) at cfilters.c:568
>> #5 0x00007ffff7e5ad86 in Curl_detach_connection (data=0x490878) at multi.c:973
>> #6 0x00007ffff7e79dc4 in extract_if_dead (conn=0x79bf28, data=0x490878) at url.c:828
>> #7 0x00007ffff7e79e1f in call_extract_if_dead (data=0x490878, conn=0x79bf28, param=0x7fffffffda80) at url.c:854
>> #8 0x00007ffff7e2c72d in Curl_conncache_foreach (data=0x490878, connc=0x464288, param=0x7fffffffda80, func=0x7ffff7e79df0 <call_extract_if_dead>) at conncache.c:332
>> #9 0x00007ffff7e7a00a in prune_dead_connections (data=0x490878) at url.c:883
>> #10 0x00007ffff7e7e72d in create_conn (data=0x490878, in_connect=0x7fffffffdb60, async=0x7fffffffdbce) at url.c:3635
>> #11 0x00007ffff7e7ed0e in Curl_connect (data=0x490878, asyncp=0x7fffffffdbce, protocol_done=0x7fffffffdbcf) at url.c:3873
>> #12 0x00007ffff7e5cb9f in multi_runsingle (multi=0x464178, nowp=0x7fffffffdcf0, data=0x490878) at multi.c:2002
>> #13 0x00007ffff7e5e5b8 in curl_multi_perform (multi=0x464178, running_handles=0x7fffffffdd54) at multi.c:2780
>> #14 0x000000000041b6d3 in main (argc=2, argv=0x7fffffffde98) at main.c:239
>> (gdb) fr 6
>> #6 0x00007ffff7e79dc4 in extract_if_dead (conn=0x79bf28, data=0x490878) at url.c:828
>> 828 Curl_detach_connection(data);
>> (gdb) p data.state.url
>> $33 = 0x49f9b8 "smtps://poczta.interia.pl/"
>> (gdb) print conn.handler
>> $34 = (const struct Curl_handler *) 0x7ffff7eca0e0 <Curl_handler_https>
>> (gdb) print conn.host.name
>> $35 = 0x61ced8 "securetoken.googleapis.com"
>>
>> My point is that Curl_cft_nghttp2 assumes it gets only pointers to HTTP transfers
>> while prune_dead_connections() doesn't seem to guarantee that.
>>
>
> Sorry for not being more clear. I understand the problem from your data. Curl's connection filters need to know which protocol is involved in a request to access `data->req.p.*` structs. So, the http2 connection filter would only access `data->req.p.http` when there is actually a HTTP protocol handling `data`.
>
> Like in https://github.com/curl/curl/pull/13193
Superseeded by https://github.com/curl/curl/pull/13204
>
>> --
>> Aleksander Mazur
>> --
>> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
>> Etiquette: https://curl.se/mail/etiquette.html
>
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
Date: Wed, 27 Mar 2024 15:14:04 +0100
> Am 26.03.2024 um 18:04 schrieb Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>:
>
>
>
>> Am 26.03.2024 um 17:09 schrieb Aleksander Mazur via curl-library <curl-library_at_lists.haxx.se>:
>>
>> Sorry for garbled gdb output, I hope this time it will look better:
>>
>> #0 0x00007ffff7e4a6ba in http2_data_done (cf=0x794698, data=0x490878, premature=true) at http2.c:288
>> #1 0x00007ffff7e4f1e9 in cf_h2_cntrl (cf=0x794698, data=0x490878, event=2, arg1=0, arg2=0x0) at http2.c:2513
>> #2 0x00007ffff7e2ad14 in Curl_conn_cf_cntrl (cf=0x794698, data=0x490878, ignore_result=true, event=2, arg1=0, arg2=0x0) at cfilters.c:501
>> #3 0x00007ffff7e2af39 in cf_cntrl_all (conn=0x79bf28, data=0x490878, ignore_result=true, event=2, arg1=0, arg2=0x0) at cfilters.c:551
>> #4 0x00007ffff7e2afd0 in Curl_conn_ev_data_detach (conn=0x79bf28, data=0x490878) at cfilters.c:568
>> #5 0x00007ffff7e5ad86 in Curl_detach_connection (data=0x490878) at multi.c:973
>> #6 0x00007ffff7e79dc4 in extract_if_dead (conn=0x79bf28, data=0x490878) at url.c:828
>> #7 0x00007ffff7e79e1f in call_extract_if_dead (data=0x490878, conn=0x79bf28, param=0x7fffffffda80) at url.c:854
>> #8 0x00007ffff7e2c72d in Curl_conncache_foreach (data=0x490878, connc=0x464288, param=0x7fffffffda80, func=0x7ffff7e79df0 <call_extract_if_dead>) at conncache.c:332
>> #9 0x00007ffff7e7a00a in prune_dead_connections (data=0x490878) at url.c:883
>> #10 0x00007ffff7e7e72d in create_conn (data=0x490878, in_connect=0x7fffffffdb60, async=0x7fffffffdbce) at url.c:3635
>> #11 0x00007ffff7e7ed0e in Curl_connect (data=0x490878, asyncp=0x7fffffffdbce, protocol_done=0x7fffffffdbcf) at url.c:3873
>> #12 0x00007ffff7e5cb9f in multi_runsingle (multi=0x464178, nowp=0x7fffffffdcf0, data=0x490878) at multi.c:2002
>> #13 0x00007ffff7e5e5b8 in curl_multi_perform (multi=0x464178, running_handles=0x7fffffffdd54) at multi.c:2780
>> #14 0x000000000041b6d3 in main (argc=2, argv=0x7fffffffde98) at main.c:239
>> (gdb) fr 6
>> #6 0x00007ffff7e79dc4 in extract_if_dead (conn=0x79bf28, data=0x490878) at url.c:828
>> 828 Curl_detach_connection(data);
>> (gdb) p data.state.url
>> $33 = 0x49f9b8 "smtps://poczta.interia.pl/"
>> (gdb) print conn.handler
>> $34 = (const struct Curl_handler *) 0x7ffff7eca0e0 <Curl_handler_https>
>> (gdb) print conn.host.name
>> $35 = 0x61ced8 "securetoken.googleapis.com"
>>
>> My point is that Curl_cft_nghttp2 assumes it gets only pointers to HTTP transfers
>> while prune_dead_connections() doesn't seem to guarantee that.
>>
>
> Sorry for not being more clear. I understand the problem from your data. Curl's connection filters need to know which protocol is involved in a request to access `data->req.p.*` structs. So, the http2 connection filter would only access `data->req.p.http` when there is actually a HTTP protocol handling `data`.
>
> Like in https://github.com/curl/curl/pull/13193
Superseeded by https://github.com/curl/curl/pull/13204
>
>> --
>> Aleksander Mazur
>> --
>> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
>> Etiquette: https://curl.se/mail/etiquette.html
>
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-03-27