Crash in mi_free during string encoding conversion (mimalloc 2.1.2)

[DuShijun]

We have recently received two crash reports from our application, both occurring within mimalloc during string encoding conversion operations. The details are as follows:

1. Windows 7 SP1: Crash triggered during setlocale, which appears identical to the issue #170 (closed in 2019). This issue was supposed to be fixed in mimalloc 2.1.2, but it seems to have resurfaced.

2. Windows 10 (10.0.22621): Stack trace provided below.

Neither crash could be reproduced locally, and we are unable to contact the affected users for further details. Currently, only the stack trace information is available.

Could you please review these cases and advise if: There are known regressions in 2.1.2 related to locale handling or mi_free? Additional diagnostics (e.g., debug symbols, logs) would help investigate this further?

[daanx]

My guess is that mimalloc-override.dll is not loaded early enough and that the CRT allocates some locale structure using the standard allocator before mimalloc is redirected. Later on, it is realloc'd or free'd with mimalloc leading to the error.

Try to use minject --list <myexe> to see how early mimalloc-override.dll occurs in the imports -- if it is not near the top, try to either link with mimalloc in a different place on the command line arguments, or use minject to rewrite the imports in-place. (see https://github.com/microsoft/mimalloc/tree/dev/bin).

Another option is to try to use the latest dev3 (v3) release -- this has an accurate map of the heap memory and may avoid a crash in these cases (note: the current mimalloc versions renamed mimalloc-override.dll to mimalloc.dll)

[DuShijun]

My guess is that mimalloc-override.dll is not loaded early enough and that the CRT allocates some locale structure using the standard allocator before mimalloc is redirected. Later on, it is realloc'd or free'd with mimalloc leading to the error.

Based on the module loading sequence of CR, there appears to be no issue.

Another option is to try to use the latest dev3 (v3) release -- this has an accurate map of the heap memory and may avoid a crash in these cases (note: the current mimalloc versions renamed mimalloc-override.dll to mimalloc.dll)

We have recently updated to v2.2.2. Is this feature only available in the v3 version? I noticed that v3.0.3 is still in beta. Could you advise when it will be officially released? Eagerly anticipating it.

[DuShijun]

It appears that certain internal functions in the ucrtbase version 10.0.10586 (e.g., _wsetlocale_get_all) directly invoke HeapAlloc. I suspect this behavior could bypass mimalloc's memory allocation hooks. If paired with mi_free for deallocation, this mismatch could cause crashes.This seems to be due to imperfections in the early versions of the C runtime library itself. Does mimalloc v3 include mitigations for such edge cases?

[DuShijun]

My guess is that mimalloc-override.dll is not loaded early enough and that the CRT allocates some locale structure using the standard allocator before mimalloc is redirected. Later on, it is realloc'd or free'd with mimalloc leading to the error.

I reproduced the issue with a minimal demo program. The function crashes when running with ucrtbase version 10.0.10586.0. The problem persists even after trying mimalloc 3.0.3.

int main()
{
	setlocale(LC_CTYPE, "");
	setlocale(LC_TIME, "");

	std::stringstream binStream;
	binStream << mi_version();

	return 0;
}

[daanx]

Thanks -- I'll try to repro and see.

[DuShijun]

@daanx Simpler way to reproduce the issue:

int main()
{
        mi_version(); //Ensure linking against the mimalloc.
	setlocale(LC_CTYPE, "");
	setlocale(LC_ALL, NULL);
	setlocale(LC_ALL, "");

	return 0;
}

ucrtbase.zip