Re: SIGSEGV in curl-8.6.0/lib/http2.c:288 (curl_multi_perform->extract_if_dead->http2_data_done)

[Stefan Eissing via curl-library]

> Am 21.03.2024 um 09:28 schrieb Daniel Stenberg via curl-library 
> <curl-library@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.html