Steps to reproduce: $ export DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib $ run-webkit-tests ... DumpRenderTree was not found at GuardMalloc[perl-40086]: Allocations will be placed on 16 byte boundaries./DumpRenderTree Build check failed Looks like the tool gets confused between stderr and stdout output.
Hm. On SnowLeopard, I actually got a total different error, where we failed while checking what source control system we were using ( run_webkit_tests.py:483 host._initialize_scm() ) which would've been before we even start to check the build. I suspect there are several things that get confused by the libgmalloc logging (not to mention that this slows everything down). As a workaround you can add a line in Tools/Scripts/webkitpy/layout_tests/port/webkit.py:479 or thereabouts that sets the value you want. You can also create a wrapper script that sets this variable and then use the --wrapper command line arg, e.g.: $ cat > gmalloc_wrapper #!/bin/bash DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib $* $ run-webkit-tests --wrapper=$PWD/gmalloc_wrapper ... Conceivably we could also add a command line switch that allows you to push variables only into DRT's environment (without affecting the rest of the script), but maybe the wrapper approach is good enough.
We already have this switch. run-webkit-tests -g This was ported over from ORWT long ago. :)
Right. This is more about when you just happen to have this set in your session environment, or want to test one of other tools that run-webkit-tests spawns. And general correctness, of course - parsing tool output should differentiate between stderr and stdout, assuming that's indeed the problem.
I expect lots of things will break if you have libgmalloc set in your session environment, but it's not an unreasonable request for NRWT to not break. I suspect you are correct that it's a question of separating stderr vs. stdout.
The error I get now whenever there is a crash is: "Last character read from DRT stdout line was not a newline! This indicates either a NRWT or DRT bug. [19767/33339] fast/table/table-create-tbody-multiple-tbody.html failed unexpectedly (WebProcess crashed [pid=39206])" Which suggests it's a stderr vs. stdout thing.