Reproducible crash in realloc with libcurl and libopenssl

[HSNB]

The following code will always crash in realloc().

Specifically, in _mi_theap_realloc_zero() on this line:

void curl_get_url()
{
	if (const auto curl = curl_easy_init()) {
		curl_easy_setopt(curl, CURLOPT_URL, "https://example.com");
		curl_easy_perform(curl);
		curl_easy_cleanup(curl);
	}
}

void main()
{
	curl_global_init(CURL_GLOBAL_ALL);

	std::list<std::future<void>> futures;

	for (int i = 0; i < 1024; ++i)
		futures.emplace_back(std::async(std::launch::async, curl_get_url));

	futures.clear();

	curl_global_cleanup();
}

The crash may occur inside OpenSSL, but sometimes also in libcurl. It's always crashing in this realloc function on this specific line in mimalloc though. Which makes me think it's mimallocs fault. The code does not crash without mimalloc.

Environment:

• Visual Studio 2026
• mimalloc version 3.3.2 static library (mimalloc-override-static-lib project in the given mimalloc.sln). linking to mimalloc-static.lib. Retargeted the project to v145 Platform Toolset on first open.
• /MT build
• mimalloc-static.lib is the first in the list of "Additional Dependencies"
• mi_version is specified in "Force Symbol References"
• mi_malloc is linked correctly, I've tested with mi_is_in_heap_region()
• curl: static library (/MT)
• openssl: static library (/MT)

From my observations while trying to understand why it's crashing, it seems mimalloc's realloc is not handling (expired?) threads well.

I checked some other issues and tried the dev3 branch. It also crashes.

[will-extrahop]

https://linux.die.net/man/3/curl_easy_init says:

If you did not already call curl_global_init(3), curl_easy_init(3) does it automatically. This may be lethal in multi-threaded cases, since curl_global_init(3) is not thread-safe, and it may result in resource problems because there is no corresponding cleanup.

You are strongly advised to not allow this automatic behaviour, by calling curl_global_init(3) yourself properly. See the description in libcurl(3) of global environment requirements for details of how to use this function.

Am I missing something or is that likely the problem?

[HSNB]

New observations:

1. No crash when I remove MI_GUARDED=1 from the Preprocessor Definitions (which is there by default in the mimalloc-override-static-lib project that comes in the mimalloc.sln).
2. No crash when I add MI_DEBUG=1 (alongside MI_GUARDED=1).

(at least it doesn't crash immediately like it does with default settings. I haven't tested longer-duration processes)

So maybe there are bugs in the latest version of libcurl and openssl instead? AI says MI_GUARDED is to detect use-after-free and writing outside bounds.. so that could mean it's actually libcurl AND openssl having such bugs. Crazy!

[HSNB]

https://linux.die.net/man/3/curl_easy_init says:

If you did not already call curl_global_init(3), curl_easy_init(3) does it automatically. This may be lethal in multi-threaded cases, since curl_global_init(3) is not thread-safe, and it may result in resource problems because there is no corresponding cleanup.
You are strongly advised to not allow this automatic behaviour, by calling curl_global_init(3) yourself properly. See the description in libcurl(3) of global environment requirements for details of how to use this function.

Am I missing something or is that likely the problem?

Ah my bad I left out an initializing function that calls the curl init function in the code piece. I've added it now.