Currently to run WebKit under valgrind, we have to manually disable bmalloc with Malloc=1, or else: * The Gigacage breaks everything, because valgrind shadows the entire address space in resident memory, and it just can't handle that much address space * Even with GIGACAGE_ENABLED=0, diagnostics are worse because bmalloc does not use valgrind's annotations Using valgrind.h, we can automatically disable bmalloc when running under valgrind to avoid needing to use the environment variable. Additionally, WebKitGTK and WPE WebKit users also have to set the WEBKIT_FORCE_SANDBOX=0 environment variable, because the web process sandbox breaks valgrind for some reason I never attempted to understand. If we have bmalloc expose valgrind.h as a public header, then we can check for valgrind in higher layers and make this work automatically too.
Created attachment 438597 [details] Patch
Q: valgrind.h is complicated we only need RUNNING_ON_VALGRIND. Do we really need the whole thing? A: RUNNING_ON_VALGRIND is also really complicated. :P The header is designed to be a copylib and it's normal for projects that implement their own memory allocators to just include the whole thing (e.g. GLib has its own copy). Q: What is up with Source/bmalloc/bmalloc.xcodeproj/project.pbxproj? A: I don't know. Perhaps webkit-patch sorts it automatically?
Ping bmalloc reviewers!
<rdar://problem/83549100>
(In reply to Michael Catanzaro from comment #3) > Ping bmalloc reviewers! Final ping before I ask for GTK/WPE reviewers
Ping GTK/WPE reviewers
Tools/Scripts/svn-apply failed to apply attachment 438597 [details] to trunk. Please resolve the conflicts and upload a new patch.
(In reply to EWS from comment #7) > Tools/Scripts/svn-apply failed to apply attachment 438597 [details] to trunk. > Please resolve the conflicts and upload a new patch. The patch will need a rebase before it can land. Michael, could you take a stab at that when you have some spare cycles? Thanks!
Created attachment 444277 [details] Patch
Committed r285819 (244261@main): <https://commits.webkit.org/244261@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 444277 [details].