[Webkit-unassigned] [Bug 37342] new-run-webkit-tests no long prints out stack traces

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=37342


Dirk Pranke <dpranke at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|webkit-unassigned at lists.web |dpranke at chromium.org
                   |kit.org                     |




--- Comment #1 from Dirk Pranke <dpranke at chromium.org>  2010-04-11 16:25:52 PST ---
Okay, there seem to be several different issues here. 

The behavior is different on different ports, and differs between Debug and
Release builds, and differs between a CHECK() firing and an actual crash. We
also differ as to whether or not we get the assert string, the backtrace, or
both.

I tested this all by instrumenting test_shell with a CHECK(false) and an
explicit write to 0x0, and then fed tests to test_shell on the command line
like so:

% echo "/src/third_party/WebKit/LayoutTests/fast/html/article-element.html" |
test_shell --layout-tests

First, let's look at handling of CHECK()s firing. 

1) On Mac and Linux, when you pass --layout-tests to test_shell, CHECK() is not
treated as fatal - the test shell continues, in both debug and release builds.
On Windows, CHECK() is fatal in both configurations.

2) On all platforms, in Release builds, we don't ever get a stack trace for a
CHECK(). In Debug builds, in all situations, we get both the assert string and
the stack trace.

Second, for "actual crashes" (a write to 0x0):

1) We get a stack trace to stderr, but nothing to stdout.

Note that if we call abort() instead of writing to 0x0, we get nothing (no
stack trace). I think this is actually okay.

Now, I believe the new-run-webkit-tests code doesn't handle reading from stderr
on Chromium ports well at all, so whatever is getting logged to stderr in a
crash is getting discarded.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.