microsoft
Segfault on Google Chrome
OS: Arch Linux
google-chromefrom AUR repo, version113.0.5672.126-1mimallocfrom Extra repo, version2.1.2-1
output of MIMALLOC_VERBOSE=1 LD_PRELOAD=/usr/lib/libmimalloc.so google-chrome-stable 2> verbose.log
[1] 18329 segmentation fault (core dumped) MIMALLOC_VERBOSE=1 LD_PRELOAD=/usr/lib/libmimalloc.so google-chrome-stable 2>
Verbose output: verbose.log
What could be done here? Could mimalloc somehow handle the fact that some projects have their own malloc impls? eg. chromium uses PartitionAlloc and as far as I remember, hardened_malloc from GrapheneOS project works fine LD_PRELOAD'd with Chromium/Electron/Google Chrome.
@thestinger don't want to bother, but does hardened_malloc have some compatibility workarounds or is it simply compatible with what Chromium expects?
We don't have any compatibility workarounds at the moment. We have occasionally had to work around camera HAL memory corruption bugs on certain Pixel phones. Chromium works fine with hardened_malloc but it doesn't use malloc very much so it doesn't actually provide much hardening for it.
We recently added hardware memory tagging in hardened_malloc which is enabled by default on GrapheneOS. However, we need to also get it working via Chromium's support for it since having it only in hardened_malloc would accomplish very little for Chromium.
Crash on webview2 if #include mimalloc-new-delete.h
ImageLab.exe (1940): Loaded 'C:\Windows\System32\DataExchange.dll'.
mimalloc: warning: mi_free_size: pointer might not point to a valid heap region: 0x026A6F31CF10
(this may still be a valid very large allocation (over 64MiB))
ImageLab.exe (1940): Loaded 'C:\Windows\System32\edputil.dll'.
mimalloc: error: mi_free_size: pointer does not point to a valid heap space: 0x026A6F31CF10
mimalloc: assertion failed: at "E:\vcpkg\buildtrees\mimalloc\src\v2.2.3-60419d716e.clean\src\free.c":351, mi_free_size
assertion: "p == NULL || size <= _mi_usable_size(p,"mi_free_size")"
Debug Error!
Program: D:\Projects\ImageLab\build\x64-windows-debug\bin\ImageLab.exe
abort() has been called
(Press Retry to debug the application)
ImageLab.exe (1940): Loaded 'C:\Windows\System32\TextShaping.dll'.
ImageLab.exe (1940): Loaded 'C:\Windows\System32\apphelp.dll'.
ImageLab.exe (1940): Loaded 'C:\Windows\System32\TextInputFramework.dll'.
mimalloc: warning: mi_free_size: pointer might not point to a valid heap region: 0x026A6F34A160
(this may still be a valid very large allocation (over 64MiB))
mimalloc: error: mi_free_size: pointer does not point to a valid heap space: 0x026A6F34A160
mimalloc: assertion failed: at "E:\vcpkg\buildtrees\mimalloc\src\v2.2.3-60419d716e.clean\src\free.c":351, mi_free_size
assertion: "p == NULL || size <= _mi_usable_size(p,"mi_free_size")"
Debug Error!
Program: D:\Projects\ImageLab\build\x64-windows-debug\bin\ImageLab.exe
abort() has been called
(Press Retry to debug the application)
ImageLab.exe (1940): Loaded 'C:\Windows\System32\CoreMessaging.dll'.
ImageLab.exe (1940): Loaded 'C:\Windows\System32\CoreUIComponents.dll'.
[0413/200102.078:ERROR:window_impl.cc(122)] Failed to unregister class Chrome_WidgetWin_0. Error = 1412
The program '[1940] ImageLab.exe' has exited with code 3 (0x3).
Ah, that crash is due to the assertion failure -- we should really check the validity of the pointer before the assertion in debug mode. I will fix this. For now, I think it should work if you use release mode? (not sure, since of course using mi_free on pointers that were allocated by a different allocator is never a good sign)
Ah, that crash is due to the assertion failure -- we should really check the validity of the pointer before the assertion in debug mode. I will fix this. For now, I think it should work if you use release mode? (not sure, since of course using
mi_freeon pointers that were allocated by a different allocator is never a good sign)
In Release mode, mimalloc works fine after adjusting the import tables using the minject.exe tool. However, it consistently fails to run in Debug mode.
Even though it functions in Release mode and delivers better performance than tbbmalloc_proxy, I remain hesitant to fully trust it. Additionally, when linking with TBB(first in target_link_libraries), the generated program always loads libtbbmalloc_proxy.dll first by default, but mimalloc doesn't behave the same way.
