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.
Crash libCurl 7.76.1 32-bit build in H3 transfers
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dmitry Karpov via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 6 May 2021 20:10:06 +0000
Hello,
I stepped on a crash in libCurl 7.76.1 32-bit in H3 transfers (MSVC, Win32).
It occurred on any direct H3 transfers from public H3 servers referred on Curl web page (https://bagder.github.io/HTTP3-test/)
I debugged the issue and it seems to be related to 32-bit builds and not Windows/MSVC-specific.
Here is the issue.
The file \lib\vquic\ngtcp2.c, line 605 in libCurl declares "cb_acked_stream_data_offset" function as follows:
static int
cb_acked_stream_data_offset(ngtcp2_conn *tconn, int64_t stream_id,
uint64_t offset, size_t datalen, void *user_data,
void *stream_user_data)
But the ngtcp2 library declares the callback slightly differently:
typedef int (*ngtcp2_acked_stream_data_offset)(
ngtcp2_conn *conn, int64_t stream_id, uint64_t offset, uint64_t datalen, void *user_data, void *stream_user_data);
So "size_t datalen" in libCurl is different from "uint64_t datalen" in the ngtcp2 library.
This is not an issue for 64-bit builds because size_t is equal to uint64_t, but for 32-bit builds it creates tricky problems because size_t is uint32_t for such builds,
and libCurl crashes because the cb_acked_stream_data_offset() function gets wrong pointers from 'user_data' and 'stream_user_data' params.
The obvious type correction seemed to fix the issue, and I was able to get H3 transfers working (although I didn't go beyond simple experiments).
The crash was so obvious, so it was a bit surprising how it was able to escape pre-release testing.
Maybe H3, as experimental feature, wasn't tested enough on 32-builds?
32-bit builds are still widely used on embedded devices, so it will help a lot if you guys look at this issue and look for other potential pitfalls like this when switching from 64-bit builds to 32-bit builds.
Thanks,
Dmitry Karpov
Roku Software Engineer
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-05-06
Date: Thu, 6 May 2021 20:10:06 +0000
Hello,
I stepped on a crash in libCurl 7.76.1 32-bit in H3 transfers (MSVC, Win32).
It occurred on any direct H3 transfers from public H3 servers referred on Curl web page (https://bagder.github.io/HTTP3-test/)
I debugged the issue and it seems to be related to 32-bit builds and not Windows/MSVC-specific.
Here is the issue.
The file \lib\vquic\ngtcp2.c, line 605 in libCurl declares "cb_acked_stream_data_offset" function as follows:
static int
cb_acked_stream_data_offset(ngtcp2_conn *tconn, int64_t stream_id,
uint64_t offset, size_t datalen, void *user_data,
void *stream_user_data)
But the ngtcp2 library declares the callback slightly differently:
typedef int (*ngtcp2_acked_stream_data_offset)(
ngtcp2_conn *conn, int64_t stream_id, uint64_t offset, uint64_t datalen, void *user_data, void *stream_user_data);
So "size_t datalen" in libCurl is different from "uint64_t datalen" in the ngtcp2 library.
This is not an issue for 64-bit builds because size_t is equal to uint64_t, but for 32-bit builds it creates tricky problems because size_t is uint32_t for such builds,
and libCurl crashes because the cb_acked_stream_data_offset() function gets wrong pointers from 'user_data' and 'stream_user_data' params.
The obvious type correction seemed to fix the issue, and I was able to get H3 transfers working (although I didn't go beyond simple experiments).
The crash was so obvious, so it was a bit surprising how it was able to escape pre-release testing.
Maybe H3, as experimental feature, wasn't tested enough on 32-builds?
32-bit builds are still widely used on embedded devices, so it will help a lot if you guys look at this issue and look for other potential pitfalls like this when switching from 64-bit builds to 32-bit builds.
Thanks,
Dmitry Karpov
Roku Software Engineer
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-05-06