SecurityTest.NewOverflow test crashes under Fuchsia |
||||
Issue descriptionThe most recent SDK roll seems to have changed the behaviour of new[] to abort the process on a failed allocation: [00069.566] 01201.01236> <== fatal exception: process base_unittests__exec[34635] thread initial-thread[34725] [00069.566] 01201.01236> <== undefined instruction, PC at 0x69a9bc59f620 [00069.566] 01201.01236> CS: 0 RIP: 0x69a9bc59f620 EFL: 0x10246 CR2: 0 [00069.567] 01201.01236> RAX: 0 RBX: 0x5f9f202d7f70 RCX: 0x1 RDX: 0x69a9bc65d28c [00069.568] 01201.01236> RSI: 0 RDI: 0x69a9bc65d200 RBP: 0x5277693b6ea0 RSP: 0x5277693b6e48 [00069.568] 01201.01236> R8: 0 R9: 0 R10: 0 R11: 0x212 [00069.568] 01201.01236> R12: 0x5ead38d7 R13: 0x5f9f202d7c50 R14: 0x17 R15: 0x16 [00069.568] 01201.01236> errc: 0 [00069.569] 01201.01236> bottom of user stack: [00069.569] 01201.01236> 0x00005277693b6e48: f6fac240 0000671e aec84d88 00005618 |@....g...M...V..| [00069.569] 01201.01236> 0x00005277693b6e58: 661b8bf1 00001146 aec84d58 00005618 |...fF...XM...V..| [00069.569] 01201.01236> 0x00005277693b6e68: aec84d58 00005618 aec84d38 00005618 |XM...V..8M...V..| [00069.569] 01201.01236> 0x00005277693b6e78: aec84d38 00005618 aec84d20 00005618 |8M...V.. M...V..| [00069.569] 01201.01236> 0x00005277693b6e88: 00000000 00000000 660814c1 00001146 |...........fF...| [00069.569] 01201.01236> 0x00005277693b6e98: ffffffff ffffffff 693b70b0 00005277 |.........p;iwR..| [00069.569] 01201.01236> 0x00005277693b6ea8: 602b93c3 00004a62 aec84ce0 00005618 |..+`bJ...L...V..| [00069.569] 01201.01236> 0x00005277693b6eb8: aec84ce0 00005618 aec84ce8 00005618 |.L...V...L...V..| [00069.569] 01201.01236> 0x00005277693b6ec8: aec84ce8 00005618 aec84ce8 00005618 |.L...V...L...V..| [00069.570] 01201.01236> 0x00005277693b6ed8: aec84ce8 00005618 aec84ce8 01005618 |.L...V...L...V..| [00069.570] 01201.01236> 0x00005277693b6ee8: 00000001 00000003 aec84ce8 00005618 |.........L...V..| [00069.570] 01201.01236> 0x00005277693b6ef8: 00000009 00100000 00000009 00100000 |................| [00069.570] 01201.01236> 0x00005277693b6f08: ffffffff ffffffff 00001000 00000000 |................| [00069.570] 01201.01236> 0x00005277693b6f18: 00001000 00000000 aec639d0 00005618 |.........9...V..| [00069.570] 01201.01236> 0x00005277693b6f28: aec84d88 00005618 aec84d88 00005618 |.M...V...M...V..| [00069.570] 01201.01236> 0x00005277693b6f38: 00000000 00000003 aec84d88 00005618 |.........M...V..| [00069.570] 01201.01236> arch: x86_64 [00069.571] 01201.01236> dso: id=fbc06b971bbf2628 base=0x7a9836961000 name=libbase.so [00069.571] 01201.01236> dso: id=876d37eb452d7368 base=0x752f1ca4c000 name=libicui18n_cr.so [00069.571] 01201.01236> dso: id=efc5ad7b528058b1d918a0ca2c6a4b70dabfacd8 base=0x70b67803b000 name=liblaunchpad.so [00069.571] 01201.01236> dso: id=60571e835c203c0a9eade691452051f39374af71 base=0x69a9bc584000 name=libc.so [00069.571] 01201.01236> dso: id=7d23a41425a325d86ec035a3935fd5a9e66c1553 base=0x671ef6f92000 name=libfdio.so [00069.571] 01201.01236> dso: id=24f3f6b2f191db626640b68e884299f722c0a6b5 base=0x4b4abed35000 name=<vDSO> [00069.571] 01201.01236> dso: id=5cd85455e2d0a679 base=0x4a625f58b000 name=app:base_unittests__exec [00069.571] 01201.01236> dso: id=7e1d96f81eaf3503 base=0x2015ad903000 name=libbase_i18n.so [00069.571] 01201.01236> dso: id=2db262216b6212e8 base=0x11466607a000 name=libc++.so [00069.571] 01201.01236> dso: id=abbf2580f57ea69e base=0x8638678d000 name=libicuuc_cr.so #01: pc 0x69a9bc59f620 sp 0x5277693b6e48 (libc.so,0x1b620) #02: pc 0x671ef6fac240 sp 0x5277693b6e50 (libfdio.so,0x1a240) #03: operator new[](unsigned long, std::nothrow_t const&) at ??:? #04: (anonymous namespace)::SecurityTest_NewOverflow_Test::TestBody() at ??:? #05: void testing::internal::InvokeHelper<void, std::__1::tuple<> >::InvokeMethod<base::RunLoop, void (base::RunLoop::*)()>(base::RunLoop*, void (base::RunLoop::*)(), std::__1::tuple<> const&) at ??:? #06: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) at ??:? #07: testing::Test::Run() at ??:? #08: testing::TestInfo::Run() at ??:? #09: testing::TestCase::Run() at ??:? #10: testing::internal::UnitTestImpl::RunAllTests() at ??:? #11: bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) at ??:? #12: bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) at ??:? #13: testing::UnitTest::Run() at ??:? #14: RUN_ALL_TESTS() at ??:? #15: base::TestSuite::Run() at ??:? #16: void base::internal::FunctorTraits<void (base::WaitableEvent::*)(), void>::Invoke<base::WaitableEvent*>(void (base::WaitableEvent::*)(), base::WaitableEvent*&&) at ??:? #17: void base::internal::InvokeHelper<false, void>::MakeItSo<void (base::WaitableEvent::*)(), base::WaitableEvent*>(void (base::WaitableEvent::*&&)(), base::WaitableEvent*&&) at ??:? #18: int base::internal::Invoker<base::internal::BindState<int (base::MockCallback<base::OnceCallback<int ()> >::*)(), base::internal::UnretainedWrapper<base::MockCallback<base::OnceCallback<int ()> > > >, int ()>::RunImpl<int (base::MockCallback<base::OnceCallback<int ()> >::*)(), std::__1::tuple<base::internal::UnretainedWrapper<base::MockCallback<base::OnceCallback<int ()> > > >, 0ul>(int (base::MockCallback<base::OnceCallback<int ()> >::*&&)(), std::__1::tuple<base::internal::UnretainedWrapper<base::MockCallback<base::OnceCallback<int ()> > > >&&, std::__1::integer_sequence<unsigned long, 0ul>) at ??:? #19: base::internal::Invoker<base::internal::BindState<int (base::MockCallback<base::RepeatingCallback<int ()> >::*)(), base::internal::UnretainedWrapper<base::MockCallback<base::RepeatingCallback<int ()> > > >, int ()>::Run(base::internal::BindStateBase*) at ??:? #20: base::OnceCallback<int ()>::Run() && at ??:? #21: base::(anonymous namespace)::LaunchUnitTestsInternal(base::OnceCallback<int ()>, unsigned long, int, bool, base::OnceCallback<void ()>) at ??:? #22: base::LaunchUnitTests(int, char**, base::OnceCallback<int ()>) at ??:? #23: main at ??:? #24: pc 0x69a9bc59eb2e sp 0x5277693b7fe0 (libc.so,0x1ab2e) #25: pc 0 sp 0x5277693b8000
,
Apr 3 2018
https://fuchsia-review.googlesource.com/c/zircon/+/127894 is why I suggested ccing Mark. We recently talk a lot about this, for the zircon kernel's operator new[].
,
Apr 3 2018
It looks like libfdio.so has a statically linked copy of zxcpp inside it, which is what frame #1 is. Everything thereafter tailcalls straight into abort(), so it's hard to know exactly what value malloc() was called with. This probably changed when zxcpp was added as a dependency into fdio, for fidl.cpp
,
Apr 3 2018
I believe I understand what's going on. The zxcpp `operator new[] nothrow` just calls malloc and then aborts(). The libcxx `operator new[] nowthrow` calls, eventually, `operator new`, catching the exception that is thrown and returning nullptr. I believe there are two bugs here. First, we need to fix the zxcpp `operator new[] nothrow`. Second, I do not believe that .so files we publish can contain operator new etc. overloads.
,
Apr 3 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/195beedfda5d3271d053eddfeea929e399229a03 commit 195beedfda5d3271d053eddfeea929e399229a03 Author: Wez <wez@chromium.org> Date: Tue Apr 03 03:47:05 2018 Revert "Fuchsia: extend the size of the blobstore FVM at build time." This reverts commit 2a112566cae8f0bbf4fc96d78d0b3d96c1a0dc5a. Reason for revert: Unfortunately the SDK this CL rolled us to is subtley but badly broken. The CL fell narrowly short of Breaking All The Things, because some of the Things just don't touch the broken bits. :( Original change's description: > Fuchsia: extend the size of the blobstore FVM at build time. > > This CL grows Fuchsia blobstore by a specified amount, large enough to > accommodate packaged executables installed at machine (QEMU) runtime. > > Roll SDK from 32a56ad5 to de50ae25 for "fvm extend" and the inclusion > of fvm.blk. > > Bug: 798851 , 707030 > Change-Id: I5a6b6be21cc443e6ad46271918a2f40e191a26f6 > Reviewed-on: https://chromium-review.googlesource.com/987012 > Commit-Queue: Kevin Marshall <kmarshall@chromium.org> > Reviewed-by: Wez <wez@chromium.org> > Cr-Commit-Position: refs/heads/master@{#547568} TBR=wez@chromium.org,kmarshall@chromium.org Bug: 828232 , 828229 , 798851 , 707030 Change-Id: I3ac0d1586c1a70700fbbd88d9f5762728bedc868 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/991672 Reviewed-by: Wez <wez@chromium.org> Commit-Queue: Wez <wez@chromium.org> Cr-Commit-Position: refs/heads/master@{#547618} [modify] https://crrev.com/195beedfda5d3271d053eddfeea929e399229a03/build/config/fuchsia/BUILD.gn [delete] https://crrev.com/eb800e136bad107db6edd0976283d13e68377fdc/build/config/fuchsia/extend_fvm.py [modify] https://crrev.com/195beedfda5d3271d053eddfeea929e399229a03/build/config/fuchsia/rules.gni [modify] https://crrev.com/195beedfda5d3271d053eddfeea929e399229a03/build/fuchsia/runner_v2/qemu_target.py [modify] https://crrev.com/195beedfda5d3271d053eddfeea929e399229a03/build/fuchsia/sdk.sha1
,
Apr 4 2018
This has started failing again, following the subsequent SDK re-roll.
,
Apr 7 2018
readelf -S of libfdio.so reveals that it is still exporting an operator new[]. ToT zircon's does not.
,
Apr 10 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9ea3e3cf0148a0685ebf8f7af4979e31735d94e5 commit 9ea3e3cf0148a0685ebf8f7af4979e31735d94e5 Author: Wez <wez@chromium.org> Date: Tue Apr 10 22:29:58 2018 Disable or filter some more tests which often flake under Fuchsia. - Disable ProcessUtilTest.LaunchWithHandleTransfer under Debug builds, since launching the child process is currently too time consuming. - Modifies that test to distinguish the child process failing to send data from the timeout case. - Disable SecurityTest.NewOverflow, which fails under Fuchsia/Debug builds due to the SDK exporting the wrong new[]. - Disable RTCRtpSenderTest.GetStats, which is part of a suite of tests which appear to be inherently flaky, but fail most often under Fuchsia. - Filter DataPipeTest.SendConsumerAndCloseProducer Bug: 793412 , 828229 , 827450 , 831024 Change-Id: Icb655ca91881c3ff7059f333f0e22d9bf2d92468 Reviewed-on: https://chromium-review.googlesource.com/1003996 Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Yuri Wiitala <miu@chromium.org> Reviewed-by: Scott Graham <scottmg@chromium.org> Commit-Queue: Wez <wez@chromium.org> Cr-Commit-Position: refs/heads/master@{#549663} [modify] https://crrev.com/9ea3e3cf0148a0685ebf8f7af4979e31735d94e5/base/process/process_util_unittest.cc [modify] https://crrev.com/9ea3e3cf0148a0685ebf8f7af4979e31735d94e5/base/security_unittest.cc [modify] https://crrev.com/9ea3e3cf0148a0685ebf8f7af4979e31735d94e5/content/renderer/media/webrtc/rtc_rtp_sender_unittest.cc [modify] https://crrev.com/9ea3e3cf0148a0685ebf8f7af4979e31735d94e5/testing/buildbot/filters/fuchsia.mojo_unittests.filter
,
May 1 2018
|
||||
►
Sign in to add a comment |
||||
Comment 1 by w...@chromium.org
, Apr 3 2018