This is an archive of the discontinued LLVM Phabricator instance.

Remove std::shared_ptr::make_shared and std::shared_ptr::allocate_shared
ClosedPublic

Authored by zoecarver on Aug 13 2019, 3:33 PM.

Details

Summary

This patch removes std::shared_ptr::make_shared and std::shared_ptr::allocate_shared as they are not part of the standard. This is a change originally created in D62233. This patch also adds __create_with_cntrl_block, which is a help function for std::allocate_shared and std::make_shared.

Event Timeline

zoecarver created this revision.Aug 13 2019, 3:33 PM
ldionne accepted this revision.Aug 14 2019, 8:55 AM

I checked that the variadic versions of std::allocate_shared and std::make_shared were good. If you did the same mechanical transformation for the non-variadic ones (which it looks like you did), this LGTM.

The next step would be to remove the C++03 non-variadic versions of std::make_shared and std::allocate_shared.

This revision is now accepted and ready to land.Aug 14 2019, 8:55 AM

Please make sure this passes tests in C++03, C++11, C++14, and C++17.

zoecarver closed this revision.Aug 14 2019, 10:19 AM

Tests pass in all versions. Committed as rL368885.

phosek added a subscriber: phosek.Aug 19 2019, 12:37 AM

I started seeing segfaults in some of our tests after the latests Clang roll and bisecting narrowed it down to this change. I also tried reverting this change locally and the segfaults no longer occur so I'm pretty confident it's this change. What's confusing is that it's not happening in regular Clang builds, it's only affecting GCC builds (we're using GCC 8.3) that are using libc++ and ASan builds. It's also don't see any of the modified functions on the stack which makes it even more confusing but I'm suspecting memory corruption that's happens earlier.

Here's one of the symbolized logs:

[230.404] 01385.01538> <== fatal exception: process /boot/test/sys/fit-test[563923] thread initial-thread[563937]
[230.404] 01385.01538> <== read not-present page fault, PC at 0x74f079c4d197
[230.404] 01385.01538>  CS:                   0 RIP:     0x74f079c4d197 EFL:            0x10202 CR2:               0x20
[230.404] 01385.01538>  RAX:               0x20 RBX:     0x74f079cff2e0 RCX:     0x3c5ec54ec8f0 RDX:                  0
[230.404] 01385.01538>  RSI:     0x324048b387c0 RDI:               0x30 RBP:     0x3c5ec54ecdb0 RSP:     0x3c5ec54ec7e8
[230.404] 01385.01538>   R8:                  0  R9: 0xfffff00000ffffff R10:     0x24f17e394991 R11:     0x324048b38780
[230.404] 01385.01538>  R12:     0x696b9aa4a040 R13:     0x3c5ec54ec870 R14:     0x74f079d00ba0 R15:     0x3c5ec54ec900
[230.404] 01385.01538>  fs.base:     0x36bebfd9cb38 gs.base:                  0
[230.404] 01385.01538>  errc:               0x4
[230.404] 01385.01538> bottom of user stack:
[230.404] 01385.01538> 0x00003c5ec54ec7e8: 79c71b5e 000074f0 c54ecbe0 00003c5e |^..y.t....N.^<..|
[230.405] 01385.01538> 0x00003c5ec54ec7f8: c54ec810 00003c5e c54ec8d0 00003c5e |..N.^<....N.^<..|
[230.405] 01385.01538> 0x00003c5ec54ec808: c54ec8b0 00003c5e 20202020 20202020 |..N.^<..        |
[230.405] 01385.01538> 0x00003c5ec54ec818: 20202020 20202020 20202020 20202020 |                |
[230.405] 01385.01538> 0x00003c5ec54ec828: 20202020 20202020 20202020 20202020 |                |
[230.405] 01385.01538> 0x00003c5ec54ec838: 20202020 00000000 00000000 00000000 |    ............|
[230.405] 01385.01538> 0x00003c5ec54ec848: c54ec910 00003c5e c54ec890 00003c5e |..N.^<....N.^<..|
[230.405] 01385.01538> 0x00003c5ec54ec858: c54ec8f0 00003c5e 00000001 00000000 |..N.^<..........|
[230.405] 01385.01538> 0x00003c5ec54ec868: 00000000 00000000 79cff2e0 000074f0 |...........y.t..|
[230.405] 01385.01538> 0x00003c5ec54ec878: 00000000 00000000 00000000 00000000 |................|
[230.405] 01385.01538> 0x00003c5ec54ec888: 00000000 00000000 79cff2e0 000074f0 |...........y.t..|
[230.405] 01385.01538> 0x00003c5ec54ec898: 00000000 00000000 00000000 00000000 |................|
[230.405] 01385.01538> 0x00003c5ec54ec8a8: 00000000 00000000 79cff2e0 000074f0 |...........y.t..|
[230.405] 01385.01538> 0x00003c5ec54ec8b8: 00000000 00000000 00000000 00000000 |................|
[230.405] 01385.01538> 0x00003c5ec54ec8c8: 00000000 00000000 79cff2e0 000074f0 |...........y.t..|
[230.405] 01385.01538> 0x00003c5ec54ec8d8: 00000000 00000000 00000000 00000000 |................|
[230.405] 01385.01538> arch: x86_64
[230.405] 01385.01538> dso: id=c2d8143ea2273b1ffed2fb43f0047a8dcc93f14a base=0x74f079bfd000 name=app:/boot/test/sys/fit-test
[230.405] 01385.01538> dso: id=917cbd24458d8ac1421a04344846e76fcd0bf4c4 base=0x6d7b61144000 name=<vDSO>
[230.405] 01385.01538> dso: id=aa81cd39e8cca017198bdb628a513a94e296acae base=0x696b9aa43000 name=libunittest.so
[230.405] 01385.01538> dso: id=8a80a62e95a4ced9ca0480796662a90104c505cd base=0x5e934f165000 name=libfdio.so
[230.405] 01385.01538> dso: id=09aee3d7f0e1245e8a304de42f0f45cbac1a25ee base=0x4437b334a000 name=libc.so
[230.405] 01385.01538> dso: id=0bb8728bb0bbaa3b base=0x2ab900e61000 name=libc++abi.so.1
[230.405] 01385.01538> dso: id=b216543249a796e8 base=0x292be29b5000 name=libc++.so.2
[230.405] 01385.01538> dso: id=6635fc5124abcdd4 base=0x1b1d07b59000 name=libunwind.so.1
[230.406] 01385.01538>    #1.1  0x000074f079c4d197 in fit::function_impl<16ul, false, void ()>* fit::internal::function_base<16ul, false, void ()>::target<fit::function_impl<16ul, false, void ()> >(bool) ../../out/default.zircon/../../zircon/system/ulib/fit/include/lib/fit/function_internal.h:227 <<VMO#563915=/boot/test/sys/fit->+0x50197 sp 0x3c5ec54ec7e8
[230.406] 01385.01538>    #1    0x000074f079c4d197 in fit::internal::target<fit::function_impl<16ul, false, void ()>, false, true, void>::get(void*) ../../out/default.zircon/../../zircon/system/ulib/fit/include/lib/fit/function_internal.h:153 <<VMO#563915=/boot/test/sys/fit->+0x50197 sp 0x3c5ec54ec7e8
[230.406] 01385.01538>    #2.2  0x000074f079c71b5e in void fit::internal::function_base<16ul, false, void ()>::share_with<fit::function_impl<16ul, false, void ()> >(fit::function_impl<16ul, false, void ()>&) ../../out/default.zircon/../../zircon/system/ulib/fit/include/lib/fit/function_internal.h:263 <<VMO#563915=/boot/test/sys/fit->+0x74b5e sp 0x3c5ec54ec7f0
[230.406] 01385.01538>    #2.1  0x000074f079c71b5e in fit::function_impl<16ul, false, void ()>::share() ../../out/default.zircon/../../zircon/system/ulib/fit/include/lib/fit/function.h:283 <<VMO#563915=/boot/test/sys/fit->+0x74b5e sp 0x3c5ec54ec7f0
[230.406] 01385.01538>    #2    0x000074f079c71b5e in (anonymous namespace)::sharing() ../../out/default.zircon/../../zircon/system/utest/fit/function_tests.cc:617 <<VMO#563915=/boot/test/sys/fit->+0x74b5e sp 0x3c5ec54ec7f0
[230.407] 01385.01538>    #3    0x0000696b9aa45157 in unittest_run_test(char const*, bool (*)(), test_info**, bool*) ../../out/default.zircon/../../zircon/system/ulib/unittest/unittest.cc:268 <<VMO#563950=libunittest.so>>+0x2157 sp 0x3c5ec54ecdc0
[230.407] 01385.01538>    #4.2  0x0000696b9aa45792 in operator() ../../out/default.zircon/../../zircon/system/ulib/unittest/unittest.cc:296 <<VMO#563950=libunittest.so>>+0x2792 sp 0x3c5ec54ece00
[230.407] 01385.01538>    #4.1  0x0000696b9aa45792 in run_with_watchdog<unittest_run_named_test(char const*, bool (*)(), test_type_t, test_info**, bool*)::<lambda()> > ../../out/default.zircon/../../zircon/system/ulib/unittest/unittest.cc:285 <<VMO#563950=libunittest.so>>+0x2792 sp 0x3c5ec54ece00
[230.407] 01385.01538>    #4    0x0000696b9aa45792 in unittest_run_named_test ../../out/default.zircon/../../zircon/system/ulib/unittest/unittest.cc:295 <<VMO#563950=libunittest.so>>+0x2792 sp 0x3c5ec54ece00
[230.407] 01385.01538>    #5    0x000074f079c4e32a in function_tests(bool, char const*) ../../out/default.zircon/../../zircon/system/utest/fit/function_tests.cc:945 <<VMO#563915=/boot/test/sys/fit->+0x5132a sp 0x3c5ec54ece40
[230.408] 01385.01538>    #6.1  0x0000696b9aa44dc0 in unittest_run_all_tests_etc ../../out/default.zircon/../../zircon/system/ulib/unittest/all-tests.cc:46 <<VMO#563950=libunittest.so>>+0x1dc0 sp 0x3c5ec54ece80
[230.408] 01385.01538>    #6    0x0000696b9aa44dc0 in unittest_run_all_tests ../../out/default.zircon/../../zircon/system/ulib/unittest/all-tests.cc:207 <<VMO#563950=libunittest.so>>+0x1dc0 sp 0x3c5ec54ece80
[230.409] 01385.01538>    #7    0x0000696b9aa44ac9 in main ../../out/default.zircon/../../zircon/system/ulib/unittest/unittest-main.cc:15 <<VMO#563950=libunittest.so>>+0x1ac9 sp 0x3c5ec54ecef0
[230.409] 01385.01538>    #8    0x00004437b337274c in start_main ../../out/default.zircon/../../zircon/third_party/ulib/musl/src/env/__libc_start_main.c:93 <<VMO#563929=ld.so.1>>+0x2874c sp 0x3c5ec54ecf00
[230.409] 01385.01538>    #9    0x0000000000000000 in <>+0x0 sp 0x3c5ec54ed000

I started seeing segfaults in some of our tests after the latests Clang roll and bisecting narrowed it down to this change. I also tried reverting this change locally and the segfaults no longer occur so I'm pretty confident it's this change.

Thanks a lot for the heads up. Do you think you'd be able to get us a reproducer?

@zoecarver We should revert this patch until we can find what the problem is.

What's confusing is that it's not happening in regular Clang builds, it's only affecting GCC builds (we're using GCC 8.3) that are using libc++ and ASan builds. It's also don't see any of the modified functions on the stack which makes it even more confusing but I'm suspecting memory corruption that's happens earlier.

Here's one of the symbolized logs:
...

Yeah, the stack trace isn't too helpful.

zoecarver reopened this revision.Aug 19 2019, 8:48 AM

Reverted as rL369270.

This revision is now accepted and ready to land.Aug 19 2019, 8:48 AM

@phosek I looked around a bit. Seems like this is probably where the issue is. Still debugging and trying to find what caused the segmentation fault. Any more information is welcome. A reproducer would be fantastic.

@phosek I spent some more time trying to reproduce the segfault. I still haven't been able to reproduce the issue. Any more information you could share would be great (even, at least, the failing build so I can try to reproduce with that). I would really like to get this re-committed.

In order to make progress on this, we could split this patch. I suggest roughly three patches:

  1. Remove the faux-variadics for C++03 but still use the static member functions
  2. Remove std::shared_ptr<T>::allocate_shared
  3. Remove std::shared_ptr<T>::make_shared (I suspect this is what triggers the segfault).

By doing it in steps, we should be able to make some progress, and when we hit the segfault again, it might be clearer what the problem is.

zoecarver edited the summary of this revision. (Show Details)
  • Remove std::shared_ptr::allocate_shared
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptFeb 21 2020, 10:11 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
  • Remove std::shared_ptr::allocate_shared
Harbormaster completed remote builds in B47022: Diff 245908.
  • Use __create_with_control_block in allocate_shared

@ldionne friendly ping. This patch now only removes std::shared_ptr::allocate_shared. Should be an easy change. And I think we fixed @phosek's issue by breaking __hold2.get()->get() into a variable so that compilers that parse args backwards still work here.

ldionne accepted this revision.Feb 25 2020, 4:02 PM

Thanks!

This revision was automatically updated to reflect the committed changes.