Issue metadata
Sign in to add a comment
|
Log output leading up to LOG_FATAL "crashes" (e.g. DCHECKs) is not visible in TestLauncher |
||||||||||||||||||||||
Issue descriptionRepro steps: 1a. Add a test which uses IMMEDIATE_CRASH() to crash. 1b. Add a test which uses CHECK to crash. 1c. Add a test which uses EXPECT_TRUE to log a failure, including stack, without crashing. 1d. Add a test which uses DCHECK to crash. 1e. Add a test which uses LOG(FATAL) to crash. 1f. Add a test which uses ASSERT_TRUE to log a failure and crash. 2. Run the tests individually, under TestLauncher. 3. Run the tests individually, with --single-process-tests. 1a crashes with a full stack printout, via crash_analyzer. 1b will crash, with no stack in Debug, and with stack in Release. 1c & 1f will report the failure and log a stack. 1d & 1e will always crash with no stack. This broke recently, possibly during an SDK roll to add a default debug handler..?
,
Aug 18
,
Aug 18
There are two issues: 1. stderr is completely missing from the test output, under TestLauncher, if a test fails (e.g. via ADD_FAILURE or EXPECT_TRUE(false)). 2. stdout is logged if the process IMMEDIATE_CRASH()es, but _not_ if we BreakDebugger().
,
Aug 18
This is issue 751253 ; we are redirecting both stderr and stdout of the batch sub-process to the same output file, but there are two bugs in FDIO that cause us to lose output from one or other stream as a result: 1. If a file description (i.e. the same fd, or dup()s of an fd) is mapped to multiple fds in the recieving process then each receives a distinct file-description. 2. Since we open the |output_file| using CreateAndOpenTemporaryFile(), it is opened with absolute (rather than append) mode, so since the two descriptors have their own descriptions, each has its own seek position, and writes through them overwrite one another. We will need to temporarily re-instate the open-O_APPEND hack.
,
Aug 18
,
Aug 18
Looks like the O_APPEND hack doesn't work, because the new version of the /tmp filesystem (memfs, I think) doesn't seem to respect the O_APPEND flag.
,
Aug 18
Even uglier temporary work-around is up for review at https://chromium-review.googlesource.com/c/chromium/src/+/1180599
,
Aug 20
,
Aug 20
smklein has resolved the underlying platform regression in the "append" bit on file handles (tracked as ZX-2519), so this will be fixed when we roll a fresh SDK, in the next couple of hours - thanks Sean!
,
Aug 21
Should be fixed by https://chromium-review.googlesource.com/c/chromium/src/+/1182444 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by w...@chromium.org
, Aug 17