New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 713794 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 713442
Owner:
Last visit > 30 days ago
Closed: Apr 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

LoggingTest.NestedLogAssertHandlers fails on 'LTO Linux' bot

Project Member Reported by krasin@chromium.org, Apr 20 2017

Issue description

Chrome Version: tip
OS: Linux x86-64

What steps will reproduce the problem?
(1) Build official base_unittests with or without LTO enabled. Below are the flags for non-LTO build (faster to link):

$ gn gen out/off '--args=is_chrome_branded=false is_official_build=true is_debug=false is_cfi=false use_thin_lto=false allow_posix_link_time_opt=false use_lld=false use_goma=true' --check

(2) Run base_unittests and observe the failure:

$ ./out/off/base_unittests
...
Retrying 1 test (retry #1)
[ RUN      ] LoggingTest.NestedLogAssertHandlers
[2505/2505] LoggingTest.NestedLogAssertHandlers (CRASHED)
Retrying 1 test (retry #2)
[ RUN      ] LoggingTest.NestedLogAssertHandlers
[2506/2506] LoggingTest.NestedLogAssertHandlers (CRASHED)
Retrying 1 test (retry #3)
[ RUN      ] LoggingTest.NestedLogAssertHandlers
[2507/2507] LoggingTest.NestedLogAssertHandlers (CRASHED)
1 test crashed:
    LoggingTest.NestedLogAssertHandlers (../../base/logging_unittest.cc:515)

Under GDB:
[ RUN      ] LoggingTest.NestedLogAssertHandlers

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000000401e5a in logging::(anonymous namespace)::LoggingTest_NestedLogAssertHandlers_Test::TestBody (this=<optimized out>) at ../../base/logging_unittest.cc:542
542       CHECK(false) << "First assert must be catched by handler_a";
(gdb) bt
#0  0x0000000000401e5a in logging::(anonymous namespace)::LoggingTest_NestedLogAssertHandlers_Test::TestBody (this=<optimized out>) at ../../base/logging_unittest.cc:542
#1  0x0000000000ce5ea5 in HandleExceptionsInMethodIfSupported<testing::Test, void> (object=<optimized out>, method=&virtual testing::Test::TestBody(), location=<optimized out>) at ../../testing/gtest/src/gtest.cc:2458
#2  Run (this=<optimized out>) at ../../testing/gtest/src/gtest.cc:2474
#3  Run (this=<optimized out>) at ../../testing/gtest/src/gtest.cc:2656
#4  Run (this=<optimized out>) at ../../testing/gtest/src/gtest.cc:2774
#5  testing::internal::UnitTestImpl::RunAllTests (this=<optimized out>) at ../../testing/gtest/src/gtest.cc:4647
#6  0x0000000000ce4c40 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (object=0x21a0ecb0ae00, method=<optimized out>, location=<optimized out>) at ../../testing/gtest/src/gtest.cc:2458
#7  testing::UnitTest::Run (this=<optimized out>) at ../../testing/gtest/src/gtest.cc:4255
#8  0x0000000000caba4b in RUN_ALL_TESTS () at ../../testing/gtest/include/gtest/gtest.h:2237
#9  base::TestSuite::Run (this=0x7fffffffd908) at ../../base/test/test_suite.cc:271
#10 0x0000000000cb60e0 in Run (this=<optimized out>) at ../../base/callback.h:80
#11 base::(anonymous namespace)::LaunchUnitTestsInternal(base::Callback<int (), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&, int, int, bool, base::Callback<void (), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&) (run_test_suite=..., default_jobs=48, default_batch_limit=10, use_job_objects=<error reading variable: access outside bounds of object referenced via synthetic pointer>, gtest_init=...) at ../../base/test/launcher/unit_test_launcher.cc:211
#12 0x0000000000cb5efb in base::LaunchUnitTests(int, char**, base::Callback<int (), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&) (argc=<optimized out>, argv=0x7fffffffda48, run_test_suite=...) at ../../base/test/launcher/unit_test_launcher.cc:453
#13 0x0000000000ca03ef in main (argc=3, argv=0x7fffffffda48) at ../../base/test/run_all_base_unittests.cc:22

This test was introduced just recently, in https://codereview.chromium.org/2606153003/
Reverting the CL failed because the patch won't apply anymore.

 

Comment 1 by krasin@chromium.org, Apr 20 2017

Status: Fixed (was: Untriaged)
Turns out, the revert failed because a proper fix was submitted right before I initiated the rollback. Nice!

For the record, the fix was https://codereview.chromium.org/2831073002

Verified that it no longer fails for me locally.

Comment 2 by thakis@chromium.org, Apr 20 2017

Mergedinto: 713442
Status: Duplicate (was: Fixed)

Comment 3 by krasin@chromium.org, Apr 20 2017

Thank you, Alex for the prompt fix!

Sign in to add a comment