Bug 230460 – Make valgrind work properly without extra environment variables

• Component: bmalloc
• Status: RESOLVED FIXED

[Michael Catanzaro]

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.

[Michael Catanzaro]

Created attachment 438597 [details]
Patch

[Michael Catanzaro]

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?

[Michael Catanzaro]

Ping bmalloc reviewers!

[Radar WebKit Bug Importer]

<rdar://problem/83549100>

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #3)
> Ping bmalloc reviewers!

Final ping before I ask for GTK/WPE reviewers

[Michael Catanzaro]

Ping GTK/WPE reviewers

[EWS]

Tools/Scripts/svn-apply failed to apply attachment 438597 [details] to trunk.
Please resolve the conflicts and upload a new patch.

[Adrian Perez]

(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!

[Michael Catanzaro]

Created attachment 444277 [details]
Patch

[EWS]

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].