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 17:07:48 +0100
> Am 26.03.2024 um 16:57 schrieb Aleksander Mazur via curl-library <curl-library_at_lists.haxx.se>:
>
> Dnia 2024-03-25, o godz. 22:33:13 Jeffrey Walton <noloader_at_gmail.com>
> napisał(a):
>
>> You have to build your application and cURL with -O0 or -O1. Valgrind
>> becomes inaccurate at -O2 and above, and sometimes incorrectly reports
>> uninitialized memory. Also see
>> <https://valgrind.org/docs/manual/quick-start.html>.
>
> Yes, I had built both my application and cURL with -O0.
>
> BTW. the error reported by Valgrind is not about uninitialized memory, but
> out-of-bounds memory access due to using wrong union member:
> 1. allocated sizeof(struct SMTP) and put into SingleRequest.p.smtp;
> 2. cast to (struct HTTP *) and trying to access h2_ctx.
>
> Anyway, I reproduced the problem under gdb (segfault):
>
> #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"
>
> extract_if_dead() is called with HTTPS connection and SMTPS transfer.
> How it is supposed to handle this situation?
> It seems that extract_if_dead() briefly attaches and detaches them.
> Detaching includes calling Curl_conn_ev_data_detach() what involves passing
> this SMTPS transfer to all HTTPS-specific connection filters.
> This way http2_data_done() gets called with a transfer initialized by
> smtp_init() so libcurl crashes trying to evaluate H2_STREAM_CTX(data) on it.
Ah, that's a good explanation. I think we need more protocol information when accessing `data->req.p.*`.
> --
> Aleksander Mazur
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
Date: Tue, 26 Mar 2024 17:07:48 +0100
> Am 26.03.2024 um 16:57 schrieb Aleksander Mazur via curl-library <curl-library_at_lists.haxx.se>:
>
> Dnia 2024-03-25, o godz. 22:33:13 Jeffrey Walton <noloader_at_gmail.com>
> napisał(a):
>
>> You have to build your application and cURL with -O0 or -O1. Valgrind
>> becomes inaccurate at -O2 and above, and sometimes incorrectly reports
>> uninitialized memory. Also see
>> <https://valgrind.org/docs/manual/quick-start.html>.
>
> Yes, I had built both my application and cURL with -O0.
>
> BTW. the error reported by Valgrind is not about uninitialized memory, but
> out-of-bounds memory access due to using wrong union member:
> 1. allocated sizeof(struct SMTP) and put into SingleRequest.p.smtp;
> 2. cast to (struct HTTP *) and trying to access h2_ctx.
>
> Anyway, I reproduced the problem under gdb (segfault):
>
> #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"
>
> extract_if_dead() is called with HTTPS connection and SMTPS transfer.
> How it is supposed to handle this situation?
> It seems that extract_if_dead() briefly attaches and detaches them.
> Detaching includes calling Curl_conn_ev_data_detach() what involves passing
> this SMTPS transfer to all HTTPS-specific connection filters.
> This way http2_data_done() gets called with a transfer initialized by
> smtp_init() so libcurl crashes trying to evaluate H2_STREAM_CTX(data) on it.
Ah, that's a good explanation. I think we need more protocol information when accessing `data->req.p.*`.
> --
> 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.htmlReceived on 2024-03-26