> Am 26.03.2024 um 16:57 schrieb Aleksander Mazur via curl-library > <curl-library@lists.haxx.se>: > > Dnia 2024-03-25, o godz. 22:33:13 Jeffrey Walton <noloa...@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.html
