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: Thu, 21 Mar 2024 09:59:32 +0100
> Am 21.03.2024 um 09:28 schrieb Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>:
>
> On Wed, 20 Mar 2024, Aleksander Mazur via curl-library wrote:
>
>> Recently I observe my program crashing (sometimes) during system startup. (During system startup internet connection is down so a few first https/HTTP2 requests fail with CURLE_COULDNT_RESOLVE_HOST. Then internet connection goes up.) Then the program is restarted by supervisor and works fine.
>
> The stack trace does however seem to imply that there is an existing connection in the pool to kill off so this cannot be the first connection done after starting up, right?
Right. This code patch is only taken if there are connections in the cache, meaning there has been at least 1 successful transfer before.
>
> I presume you have a hard time to reproduce this reliably? Does it happen against random hosts or does it typically happen against the same server? I presume you only see this with h2?
>
> Or in other words: if you would try an updated libcurl, what would it take for you to know that it fixes the issue?
>
>> ... what most probably matches accessing stream->id in lib/http2.c:288:
>>> (void)nghttp2_session_set_stream_user_data(ctx->h2, stream->id, NULL);
>> meaning that stream must have been not NULL but held an invalid pointer.
>
>> Are you aware of a scenario in which a stale pointer to Curl_easy.req.p.http is kept in connection cache and then reused?
>
> Nothing in the Curl_easy struct is kept in the connection cache. Only connections are kept there and they are 'struct connectdata'.
>
> But no, I can't recall us having a case where we had a bad connection struct in the cache.
The `stream` at which the SEGV seems to occur (unless we are suspecting `ctx` or `ctx->h2` to be a bad pointer) is from the easy handle passed. In the code path, that easy handle is the "new" transfer for which a connection is searched in the cache.
Do you use a new easy handle for each transfer or reuse the previous one? Does the problem persist if you switched to using new ones?
As bagder said: the fastest way to isolate the problem - given that you can reproduce this - is to add some extensive logging at the location so that we can see what the different pointers are and if the passed transfer is healthy.
>
>> Do you think https://github.com/curl/curl/pull/13096 may be related to this issue?
>
> Hm, I think I need Stefan's input for that, but I certainly can't rule it out.
I don't think that change is related to this.
>
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
Date: Thu, 21 Mar 2024 09:59:32 +0100
> Am 21.03.2024 um 09:28 schrieb Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>:
>
> On Wed, 20 Mar 2024, Aleksander Mazur via curl-library wrote:
>
>> Recently I observe my program crashing (sometimes) during system startup. (During system startup internet connection is down so a few first https/HTTP2 requests fail with CURLE_COULDNT_RESOLVE_HOST. Then internet connection goes up.) Then the program is restarted by supervisor and works fine.
>
> The stack trace does however seem to imply that there is an existing connection in the pool to kill off so this cannot be the first connection done after starting up, right?
Right. This code patch is only taken if there are connections in the cache, meaning there has been at least 1 successful transfer before.
>
> I presume you have a hard time to reproduce this reliably? Does it happen against random hosts or does it typically happen against the same server? I presume you only see this with h2?
>
> Or in other words: if you would try an updated libcurl, what would it take for you to know that it fixes the issue?
>
>> ... what most probably matches accessing stream->id in lib/http2.c:288:
>>> (void)nghttp2_session_set_stream_user_data(ctx->h2, stream->id, NULL);
>> meaning that stream must have been not NULL but held an invalid pointer.
>
>> Are you aware of a scenario in which a stale pointer to Curl_easy.req.p.http is kept in connection cache and then reused?
>
> Nothing in the Curl_easy struct is kept in the connection cache. Only connections are kept there and they are 'struct connectdata'.
>
> But no, I can't recall us having a case where we had a bad connection struct in the cache.
The `stream` at which the SEGV seems to occur (unless we are suspecting `ctx` or `ctx->h2` to be a bad pointer) is from the easy handle passed. In the code path, that easy handle is the "new" transfer for which a connection is searched in the cache.
Do you use a new easy handle for each transfer or reuse the previous one? Does the problem persist if you switched to using new ones?
As bagder said: the fastest way to isolate the problem - given that you can reproduce this - is to add some extensive logging at the location so that we can see what the different pointers are and if the passed transfer is healthy.
>
>> Do you think https://github.com/curl/curl/pull/13096 may be related to this issue?
>
> Hm, I think I need Stefan's input for that, but I certainly can't rule it out.
I don't think that change is related to this.
>
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.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-21