curl / Mailing Lists / curl-library / Single Mail

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: Tue, 26 Mar 2024 18:04:23 +0100

> 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

> --
> 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

Received on 2024-03-26

Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]