-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build(deps): Bump lodash.mergewith from 4.6.1 to 4.6.2 in /peridot/web/cloud_dashboard #3
base: main
Are you sure you want to change the base?
Conversation
Bumps [lodash.mergewith](https://github.com/lodash/lodash) from 4.6.1 to 4.6.2. - [Release notes](https://github.com/lodash/lodash/releases) - [Commits](https://github.com/lodash/lodash/commits) Signed-off-by: dependabot[bot] <[email protected]>
Currently FVM tests use the following sequence: 1. block rebind fidl api which will call device_rebind libdriver api. 2. device_rebind schedules unbind on all the children but does not guarantee whether the device is actually unbound and bound again. 3. The FVM tests, use Bind device controller api to bind the driver again. In the current scenario, depending on the timing of these operations, #3 will fail with ZX_ERR_ALREADY_BOUND if #2 is still in the process of unbinding. In the case where #2 actually completes unbind #3 will succeed. This change does the following. 1. It uses the new rebind device controller api, which takes care of unbind and bind synchronously. 2. Because we are using the rebind api, we do not need the additional bind 3. The Rebind api has a strict requirement of clients closing the children before callign the rebind on the parent. FVM tests are modified to do this. Test: while /system/test/fs/blobfs-integration-test; do true; done; while /boot/test/fs/fs-management-test; do true; done; Bug:35617,Bug:39460 Change-Id: Ib0ce3e9ef77a871f522f449630c23609f457d4ba
Currently the Rebind api in zxcrypt tests use the following sequence: 1. block rebind fidl api which will call device_rebind libdriver api. 2. device_rebind schedules unbind on all the children but does not guarantee whether the device is actually unbound and bound again. 3. The tests then issue the Bind device controller api to bind the driver again. In the current scenario, depending on the timing of these operations, #3 will fail with ZX_ERR_ALREADY_BOUND if #2 is still in the process of unbinding. In the case where #2 actually completes unbind #3 will succeed. This change does the following. 1. It uses the new rebind device controller api, which takes care of unbind and bind synchronously. see https://fuchsia-review.googlesource.com/c/fuchsia/+/334253 2. Because we are using the rebind api, we do not need the additional bind 3. The Rebind api has a strict requirement of clients closing the children before callign the rebind on the parent. Made sure about that before calling the rebind api. Test: /system/test/sys/zxcrypt-test Bug:40740 Change-Id: Ic1a610697343be71889f4e053f34ca0b098ddefa
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
11 similar comments
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
This reverts commit a84ed3e. Reason for revert: Appears to be causing kernel panics in CI/CQ on bringup.x64-asan-qemu_kvm bot: *** KERNEL PANIC (caller pc: 0xffffffff00250abf, stack frame: 0xffffff97deeb4e90): *** ASSERT FAILED at (../../zircon/kernel/vm/vm_object_paged.cc:2612): status == ZX_OK Tried to unpin an uncommitted page platform_halt suggested_action 0 reason 4 Halting... zx_system_get_version_string git-2642c26148d2c2339a2002f46e3127d2095eae14-dirty [[[ELF module #0x0 "kernel" BuildID=ce232edbed693ebc 0xffffffff00100000]]] dso: id=ce232edbed693ebc base=0xffffffff00100000 name=zircon.elf #0 0xffffffff001bb2a7 in platform_specific_halt ../../out/default.zircon/../../zircon/kernel/platform/pc/power.cc:147 <kernel>+0xffffffff801bb2a7 #1 0xffffffff002913b6 in platform_halt ../../out/default.zircon/../../zircon/kernel/platform/power.cc:59 <kernel>+0xffffffff802913b6 #2 0xffffffff00101297 in panic ../../out/default.zircon/../../zircon/kernel/top/debug.cc:59 <kernel>+0xffffffff80101297 #3 0xffffffff00250abf in VmObjectPaged::UnpinLocked(unsigned long, unsigned long) ../../out/default.zircon/../../zircon/kernel/vm/vm_object_paged.cc:2612 <kernel>+0xffffffff80250abf #4 0xffffffff00250ce7 in VmObjectPaged::Unpin(unsigned long, unsigned long) ../../out/default.zircon/../../zircon/kernel/vm/vm_object_paged.cc:2579 <kernel>+0xffffffff80250ce7 #5 0xffffffff0025b0bb in vmo_multiple_pin_test() ../../out/default.zircon/../../zircon/kernel/vm/vm_unittest.cc:1103 <kernel>+0xffffffff8025b0bb #6.1 0xffffffff001397de in run_unittest(unitest_testcase_registration const*) ../../out/default.zircon/../../zircon/kernel/lib/unittest/unittest.cc:140 <kernel>+0xffffffff801397de #6 0xffffffff001397de in run_unittest_thread_entry(void*) ../../out/default.zircon/../../zircon/kernel/lib/unittest/unittest.cc:166 <kernel>+0xffffffff801397de #7 0xffffffff002838c9 in initial_thread_func() ../../out/default.zircon/../../zircon/kernel/kernel/thread.cc:0 <kernel>+0xffffffff802838c9 #8 0x0000000000000000 in <>+0x0 Original change's description: > [kernel] Enable zero page scanning as default > > Zero page scanning is a useful memory saving tool across almost all of > our targets. The exception being when running microbenchmarks, which > explicitly disables the scanner. > > Default values are now: > kernel.page-scanner.start-at-boot=true > kernel.page-scanner.zero-page-scans-per-second=20000 > > Having the scanner be enabled by default allows for consistent behavior > and expectations across configurations, although any configuration is > still able to tune, or completely turn off, scanning. > > Bug: 49773 > > Change-Id: Id742f7729c6101a662c9330150ed20188528f890 > Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/385894 > Commit-Queue: Adrian Danis <[email protected]> > Testability-Review: Adrian Danis <[email protected]> > Reviewed-by: James Robinson <[email protected]> > Reviewed-by: Carlos Pizano <[email protected]> [email protected],[email protected],[email protected] Change-Id: I348cb623627be3d6161d1c225d3fc85d933bfd9c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 49773 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/387033 Commit-Queue: David Greenaway <[email protected]> Reviewed-by: David Greenaway <[email protected]>
This change splits kContinue into kResolveAndContinue and kForwardAndContinue which, apart from continuing, respectively give the directives to mark an exception as 'handled' and mark it as second-chance. The protocol version is revved. Bug: 48767 Change-Id: I246ea20b49558f32b7963a99adae50db64e70dd0 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/382682 Commit-Queue: Joshua Seaton <[email protected]> Reviewed-by: Brett Wilson <[email protected]> Testability-Review: Brett Wilson <[email protected]>
Change-Id: I17fd31e617e8791ec90c66286f3b7a76f5cd0bc3 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/420302 Reviewed-by: Justin Mattson <[email protected]> Reviewed-by: Miguel Flores <[email protected]> Testability-Review: Gary Bressler <[email protected]> Testability-Review: Miguel Flores <[email protected]> Commit-Queue: Gary Bressler <[email protected]>
Sidestep a limitation in the ktrace importer implementation where it fails to associate a thread id with its name and process id if the importer encounters a record referencing the thread id before encountering the name/process records for that thread. This is caused by the importer adding a default record to its thread map whenever it encounters an unknown thread id. The map is not updated later when the name/process records are encountered. This issue manifests in Chromium Trace Viewer as numbered swimlanes showing up in the "kernel" process, as the default process id the importer uses is 0 when encountering unknown thread ids. This issue could be addressed in the importer by either: 1. Updating the thread map whenever the name/process records are encountered. 2. Changing the importer to process the event buffer for name/ process records before other events. 3. Changing the kernel to emit the live thread/process records before enabling tracing. This patch takes option #3, as it is the simplest and has no artifacts. Option #1 would still produce swimlanes in the kernel process for as many records are emitted before the name/process records are emitted. Option #2 is much more involved. Test: Take 10 traces and observe no artifacts in Trace Viewer. Change-Id: Ib6531d725278aa5bf0e41014a349fbdf648da319 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/480359 Reviewed-by: Nick Maniscalco <[email protected]> Commit-Queue: Corey Tabaka <[email protected]>
Uses custom dimension key #3 for this field. Fixed: 67267 Change-Id: Ibe5bd63aa075aab079ac167bb70f522237dd3318 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/480841 Commit-Queue: Gabe Schine <[email protected]> Reviewed-by: Yegor Pomortsev <[email protected]> Reviewed-by: Bob Evans <[email protected]>
This change fixes a race condition in component destruction where the following occurs: 1. Component is created and added to parent as child. 2. Component is destroyed. 3. Discover action is run for component. In this sequence of operations, the Discover action in #3 will no-op (and error) because the component is in a Destroyed state. This means a Discovered event is never dispatched for the component, even though Destroyed is. This is hypothesized to trigger the crash in the bug. Usually, #2 and #3 happen in the other order, which gives the expected behavior: Discovered event followed by Purged. Fix by forcing the Purge action to register a Discover action. Bug: 78289 Change-Id: Ibd15f8f9fb1b6e7f44b07b9ac04cdfb1ad427e60 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/540483 Commit-Queue: Gary Bressler <[email protected]> Reviewed-by: Fady Samuel <[email protected]>
Before this change a guest that exits before its console is obtained would cause the test runner to crash on teardown: ``` ../../src/virtualization/tests/enclosed_guest.cc:328:38: runtime error: member call on null pointer of type 'GuestConsole' #0 0x00002119c0bdd87f in ZirconEnclosedGuest::ShutdownAndWait(ZirconEnclosedGuest*, zx::time) ../../src/virtualization/tests/enclosed_guest.cc:328 <<application>>+0x7a087f #1.2 0x000020e6040f1e37 in ubsan_GetStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:55 <libclang_rt.asan.so>+0x3be37 #1.1 0x000020e6040f1e37 in MaybePrintStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:53 <libclang_rt.asan.so>+0x3be37 #1 0x000020e6040f1e37 in ~ScopedReport() compiler-rt/lib/ubsan/ubsan_diag.cpp:389 <libclang_rt.asan.so>+0x3be37 #2 0x000020e6040f2acb in handleTypeMismatchImpl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:137 <libclang_rt.asan.so>+0x3cacb #3 0x000020e6040f25dd in compiler-rt/lib/ubsan/ubsan_handlers.cpp:142 <libclang_rt.asan.so>+0x3c5dd #4 0x00002119c0bdd87f in ZirconEnclosedGuest::ShutdownAndWait(ZirconEnclosedGuest*, zx::time) ../../src/virtualization/tests/enclosed_guest.cc:328 <<application>>+0x7a087f #5 0x00002119c0bdb5f9 in EnclosedGuest::Stop(EnclosedGuest*, zx::time) ../../src/virtualization/tests/enclosed_guest.cc:271 <<application>>+0x79e5f9 #6 0x00002119c0b5be24 in GuestTest<VirtioNetMultipleInterfacesZirconGuest>::TearDownTestSuite() ../../src/virtualization/tests/guest_test.h:28 <<application>>+0x71ee24 ``` Bug: 50820 Change-Id: Idb8d99e52173f57b74e291bf000bae3007e83a5b Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/573428 Commit-Queue: Auto-Submit <[email protected]> Fuchsia-Auto-Submit: Tamir Duberstein <[email protected]> Reviewed-by: Abdulla Kamar <[email protected]>
It is not legal to `freeaddrinfo` while the addresses are in use. Before this change ASAN caught the invalid read: ``` ERROR: AddressSanitizer: heap-use-after-free on address 0x27ff68360450 at pc 0x22439fedc5d4 bp 0x228708e27390 sp 0x2287 08e27388 READ of size 2 at 0x27ff68360450 thread T0 (initial-thread) #0 0x000022439fedc5d3 in $anon::BaseSocket<fidl::WireSyncClient<fuchsia_posix_socket::StreamSocket>, void>::connect($anon::BaseSocket<fidl::WireSyncClient<fuchsia_posix_socket::StreamSocket>, void>*, const sockaddr*, socklen_t, int16_t*) ../../sdk/lib/fdio/socket.cc:657 <libfdio.so>+0x3995d3 #1 0x000020f8c8dd05d2 in UnwindImpl() compiler-rt/lib/asan/asan_thread.h:125 <libclang_rt.asan.so>+0x5e5d2 #2.1 0x000020f8c8dbea2a in Unwind() compiler-rt/lib/sanitizer_common/sanitizer_stacktrace.h:131 <libclang_rt.asan.so>+0x4ca2a #2 0x000020f8c8dbea2a in Print() compiler-rt/lib/asan/asan_errors.cpp:586 <libclang_rt.asan.so>+0x4ca2a #3 0x000020f8c8dcad5b in ~ScopedInErrorReport() compiler-rt/lib/asan/asan_report.cpp:141 <libclang_rt.asan.so>+0x58d5b #4 0x000020f8c8dcdfa6 in ReportGenericError() compiler-rt/lib/asan/asan_report.cpp:478 <libclang_rt.asan.so>+0x5bfa6 #5 0x000020f8c8dceb17 in compiler-rt/lib/asan/asan_rtl.cpp:121 <libclang_rt.asan.so>+0x5cb17 #6 0x000022439fedc5d3 in $anon::BaseSocket<fidl::WireSyncClient<fuchsia_posix_socket::StreamSocket>, void>::connect($anon::BaseSocket<fidl::WireSyncClient<fuchsia_posix_socket::StreamSocket>, void>*, const sockaddr*, socklen_t, int16_t*) ../../sdk/lib/fdio/socket.cc:657 <libfdio.so>+0x3995d3 #7 0x000022439fece367 in fdio_internal::stream_socket::connect(fdio_internal::stream_socket*, const sockaddr*, socklen_t, int16_t*) ../../sdk/lib/fdio/socket.cc:1949 <libfdio.so>+0x38b367 #8 0x000022439fcd19ff in connect(int, const sockaddr*, socklen_t) ../../sdk/lib/fdio/bsdsocket.cc:189 <libfdio.so>+0x18e9ff #9 0x000023b4ac424db5 in tracing::ConnectToTraceSaver(std::__2::string_view const&) ../../garnet/bin/trace/utils.cc:119 <<application>>+0x202db5 ``` Bug: 52590 Change-Id: I267398d4973de917b9517bece7dc3fe41da6d860 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/573430 Reviewed-by: Brian Hamrick <[email protected]> Reviewed-by: Fadi Meawad <[email protected]> Commit-Queue: Auto-Submit <[email protected]> Fuchsia-Auto-Submit: Tamir Duberstein <[email protected]>
Before this change UBSAN caught a misaligned pointer: ``` ../../src/virtualization/bin/vmm/device/virtio_magma.cc:430:7: runtime error: reference binding to misaligned address 0x200b5fbb5114 for type 'const std::unordered_map<unsigned long, ImageInfoWithToken>::key_type' (aka 'const unsigned long'), which requires 8 byte alignment 0x200b5fbb5114: note: pointer points here 00 00 00 00 00 39 70 06 a9 26 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ #0 0x0000230cbdba2eeb in VirtioMagma::Handle_virt_create_image(VirtioMagma*, virtio_magma_virt_create_image_ctrl_t const*, virtio_magma_virt_create_image_resp_t*) ../../src/virtualization/bin/vmm/device/virtio_magma.cc:430 <<application>>+0xa6eeb #1.2 0x000021fbe7871e37 in ubsan_GetStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:55 <libclang_rt.asan.so>+0x3be37 #1.1 0x000021fbe7871e37 in MaybePrintStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:53 <libclang_rt.asan.so>+0x3be37 #1 0x000021fbe7871e37 in ~ScopedReport() compiler-rt/lib/ubsan/ubsan_diag.cpp:389 <libclang_rt.asan.so>+0x3be37 #2 0x000021fbe7872acb in handleTypeMismatchImpl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:137 <libclang_rt.asan.so>+0x3cacb #3 0x000021fbe78725dd in compiler-rt/lib/ubsan/ubsan_handlers.cpp:142 <libclang_rt.asan.so>+0x3c5dd #4 0x0000230cbdba2eeb in VirtioMagma::Handle_virt_create_image(VirtioMagma*, virtio_magma_virt_create_image_ctrl_t const*, virtio_magma_virt_create_image_resp_t*) ../../src/virtualization/bin/vmm/device/virtio_magma.cc:430 <<application>>+0xa6eeb #5 0x0000230cbdb949ed in VirtioMagmaGeneric::HandleCommand(VirtioMagmaGeneric*, VirtioChain) x64-asan-ubsan/gen/src/virtualization/bin/vmm/device/virtio_magma_generic.h:2144 <<application>>+0x989ed #6 0x0000230cbdb89ba5 in VirtioMagma::NotifyQueue(VirtioMagma*, uint16_t) ../../src/virtualization/bin/vmm/device/virtio_magma.cc:131 <<application>>+0x8dba5 ``` and ``` ../../src/virtualization/bin/vmm/device/virtio_magma.cc:276:41: runtime error: reference binding to misaligned address 0x23b84e025134 for type 'const uint64_t' (aka 'const unsigned long'), which requires 8 byte alignment 0x23b84e025134: note: pointer points here 48 27 00 00 00 39 4a bb b8 26 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ #0 0x000021c24790cea7 in VirtioMagma::Handle_export(VirtioMagma*, virtio_magma_export_ctrl_t const*, virtio_magma_export_resp_t*) ../../src/virtualization/bin/vmm/device/virtio_magma.cc:276 <<application>>+0xa4ea7 #1.2 0x0000208e12627e37 in ubsan_GetStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:55 <libclang_rt.asan.so>+0x3be37 #1.1 0x0000208e12627e37 in MaybePrintStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:53 <libclang_rt.asan.so>+0x3be37 #1 0x0000208e12627e37 in ~ScopedReport() compiler-rt/lib/ubsan/ubsan_diag.cpp:389 <libclang_rt.asan.so>+0x3be37 #2 0x0000208e12628acb in handleTypeMismatchImpl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:137 <libclang_rt.asan.so>+0x3cacb #3 0x0000208e126285dd in compiler-rt/lib/ubsan/ubsan_handlers.cpp:142 <libclang_rt.asan.so>+0x3c5dd #4 0x000021c24790cea7 in VirtioMagma::Handle_export(VirtioMagma*, virtio_magma_export_ctrl_t const*, virtio_magma_export_resp_t*) ../../src/virtualization/bin/vmm/device/virtio_magma.cc:276 <<application>>+0xa4ea7 #5 0x000021c2478ff537 in VirtioMagmaGeneric::HandleCommand(VirtioMagmaGeneric*, VirtioChain) x64-asan-ubsan/gen/src/virtualization/bin/vmm/device/virtio_magma_generic.h:1148 <<application>>+0x97537 #6 0x000021c2478f5ba5 in VirtioMagma::NotifyQueue(VirtioMagma*, uint16_t) ../../src/virtualization/bin/vmm/device/virtio_magma.cc:128 <<application>>+0x8dba5 ``` Avoid this by stack-allocating the response type and copying it into the destination buffer, and by making stack copies of request members before passing them by reference. Multiply: fuchsia.com/vmm_tests#meta/device_tests Fixed: 66436 Change-Id: I414c2ddec2c508b28c02b8514be2482ffbc54ec3 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/573744 Commit-Queue: Tamir Duberstein <[email protected]> Reviewed-by: Abdulla Kamar <[email protected]>
``` ../../zircon/system/utest/trace/event_tests_common.h:105:3: runtime error: load of value 170, which is not a valid value for type 'bool' #0 0x00004010760a3204 in event_tests_c_test_enabled_fn() ../../zircon/system/utest/trace/event_tests_common.h:105 <<application>>+0xdc204 #1.2 0x000041717c6473c0 in ubsan_GetStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:43 <libclang_rt.asan.so>+0x363c0 #1.1 0x000041717c6473c0 in MaybePrintStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:53 <libclang_rt.asan.so>+0x363c0 #1 0x000041717c6473c0 in ~ScopedReport() compiler-rt/lib/ubsan/ubsan_diag.cpp:389 <libclang_rt.asan.so>+0x363c0 #2 0x000041717c6497c0 in handleLoadInvalidValue() compiler-rt/lib/ubsan/ubsan_handlers.cpp:540 <libclang_rt.asan.so>+0x387c0 #3 0x000041717c649680 in compiler-rt/lib/ubsan/ubsan_handlers.cpp:545 <libclang_rt.asan.so>+0x38680 #4 0x00004010760a3204 in event_tests_c_test_enabled_fn() ../../zircon/system/utest/trace/event_tests_common.h:105 <<application>>+0xdc204 ``` Fixed: 41900 Change-Id: I09582b4139b866fc56aefede4c4553f3bbb6fcc2 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/574301 Commit-Queue: Auto-Submit <[email protected]> Fuchsia-Auto-Submit: Tamir Duberstein <[email protected]> Reviewed-by: Fadi Meawad <[email protected]>
``` ../../zircon/system/ulib/trace-reader/reader.cc:766:16: runtime error: applying non-zero offset 8 to null pointer #0 0x0000425cf320f4bc in trace::Chunk::ReadString(trace::Chunk*, size_t, std::__2::string_view*) ../../zircon/system/ulib/trace-reader/reader.cc:766 <<application>>+0x1044bc #1.2 0x00004377ab0103c0 in ubsan_GetStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:43 <libclang_rt.asan.so>+0x363c0 #1.1 0x00004377ab0103c0 in MaybePrintStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:53 <libclang_rt.asan.so>+0x363c0 #1 0x00004377ab0103c0 in ~ScopedReport() compiler-rt/lib/ubsan/ubsan_diag.cpp:389 <libclang_rt.asan.so>+0x363c0 #2 0x00004377ab0137c8 in handlePointerOverflowImpl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x397c8 #3 0x00004377ab01343c in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x3943c #4 0x0000425cf320f4bc in trace::Chunk::ReadString(trace::Chunk*, size_t, std::__2::string_view*) ../../zircon/system/ulib/trace-reader/reader.cc:766 <<application>>+0x1044bc #5 0x0000425cf316b31c in trace::$anon::TraceReader_EmptyChunk_Class::TestBody(trace::$anon::TraceReader_EmptyChunk_Class*) ../../zircon/system/ulib/trace-reader/test/reader_tests.cc:39 <<application>>+0x6031c #6 0x0000425cf322b564 in zxtest::Test::Run(zxtest::Test*) ../../zircon/system/ulib/zxtest/test.cc:18 <<application>>+0x120564 #7 0x0000425cf3229d6c in zxtest::TestCase::Run(zxtest::TestCase*, zxtest::LifecycleObserver*, zxtest::internal::TestDriver*) ../../zircon/system/ulib/zxtest/test-case.cc:106 <<application>>+0x11ed6c #8 0x0000425cf321e8f0 in zxtest::Runner::Run(zxtest::Runner*, const zxtest::Runner::Options&) ../../zircon/system/ulib/zxtest/runner.cc:121 <<application>>+0x1138f0 #9 0x0000425cf32204e0 in zxtest::RunAllTests(int, char**) ../../zircon/system/ulib/zxtest/runner.cc:217 <<application>>+0x1154e0 #10 0x0000425cf322b648 in main(int, char**) ../../zircon/system/ulib/zxtest/zxtest-main.cc:14 <<application>>+0x120648 #11 0x0000827600fbc654 in start_main(const start_params*) ../../zircon/third_party/ulib/musl/src/env/__libc_start_main.c:139 <libc.so>+0xcc654 #12 0x0000827600fbcf24 in __libc_start_main(zx_handle_t, int (*)(int, char**, char**)) ../../zircon/third_party/ulib/musl/src/env/__libc_start_main.c:256 <libc.so>+0xccf24 #13 0x0000425cf320a510 in _start(zx_handle_t) ../../zircon/system/ulib/c/Scrt1.cc:7 <<application>>+0xff510 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior #0 0x0000000000000000 is not covered by any module ``` It is impossible to use empty chunks without triggering UB. Delete the default constructor and change surrounding APIs to avoid the need. Fixed: 41892 Change-Id: Ia340d4e99d4f709d4f58dd85a7bc241918115e7e Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/574302 Commit-Queue: Auto-Submit <[email protected]> Fuchsia-Auto-Submit: Tamir Duberstein <[email protected]> Reviewed-by: Fadi Meawad <[email protected]>
...where possible. Where not possible, document and disable UBSAN. ``` ../../src/connectivity/bluetooth/core/bt-host/common/uuid.cc:156:13: runtime error: load of misaligned address 0x2245cfa44021 for type 'const size_t' (aka 'const unsigned long'), which requires 8 byte alignment 0x2245cfa44021: note: pointer points here 21 00 00 00 fb 34 9b 5f 80 00 00 80 00 10 00 00 0b 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ #0 0x000023c091753454 in bt::UUID::Hash(const bt::UUID*) ../../src/connectivity/bluetooth/core/bt-host/common/uuid.cc:156 <<application>>+0x859454 #1.2 0x0000238c80708e37 in ubsan_GetStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:55 <libclang_rt.asan.so>+0x3be37 #1.1 0x0000238c80708e37 in MaybePrintStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:53 <libclang_rt.asan.so>+0x3be37 #1 0x0000238c80708e37 in ~ScopedReport() compiler-rt/lib/ubsan/ubsan_diag.cpp:389 <libclang_rt.asan.so>+0x3be37 #2 0x0000238c80709acb in handleTypeMismatchImpl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:137 <libclang_rt.asan.so>+0x3cacb #3 0x0000238c807095dd in compiler-rt/lib/ubsan/ubsan_handlers.cpp:142 <libclang_rt.asan.so>+0x3c5dd #4 0x000023c091753454 in bt::UUID::Hash(const bt::UUID*) ../../src/connectivity/bluetooth/core/bt-host/common/uuid.cc:156 <<application>>+0x859454 #5.1 0x000023c09132b809 in std::__2::hash<bt::UUID>::operator()(const std::__2::hash<bt::UUID>*, const bt::UUID&) ../../src/connectivity/bluetooth/core/bt-host/common/uuid.h:212 <<application>>+0x431809 #5 0x000023c09132b809 in std::__2::__hash_table<bt::UUID, std::__2::hash<bt::UUID>, std::__2::equal_to<bt::UUID>, std::__2::allocator<bt::UUID>>::__emplace_unique_key_args<bt::UUID, const bt::UUID&>(std::__2::__hash_table<bt::UUID, std::__2::hash<bt::UUID>, std::__2::equal_to<bt::UUID>, std::__2::allocator<bt::UUID> >*, const bt::UUID&, const bt::UUID&) ../../prebuilt/third_party/clang/linux-x64/include/c++/v1/__hash_table:2072 <<application>>+0x431809 #6 0x000023c09132b61b in std::__2::__hash_table<bt::UUID, std::__2::hash<bt::UUID>, std::__2::equal_to<bt::UUID>, std::__2::allocator<bt::UUID>>::__insert_unique(std::__2::__hash_table<bt::UUID, std::__2::hash<bt::UUID>, std::__2::equal_to<bt::UUID>, std::__2::allocator<bt::UUID> >*, std::__2::__hash_table<bt::UUID, std::__2::hash<bt::UUID>, std::__2::equal_to<bt::UUID>, std::__2::allocator<bt::UUID> >::__container_value_type const&) ../../prebuilt/third_party/clang/linux-x64/include/c++/v1/__hash_table:1154 <<application>>+0x43161b #7 0x000023c09172df94 in std::__2::unordered_set<bt::UUID, std::__2::hash<bt::UUID>, std::__2::equal_to<bt::UUID>, std::__2::allocator<bt::UUID>>::insert(std::__2::unordered_set<bt::UUID, std::__2::hash<bt::UUID>, std::__2::equal_to<bt::UUID>, std::__2::allocator<bt::UUID> >*, std::__2::unordered_set<bt::UUID, std::__2::hash<bt::UUID>, std::__2::equal_to<bt::UUID>, std::__2::allocator<bt::UUID> >::value_type const&) ../../prebuilt/third_party/clang/linux-x64/include/c++/v1/unordered_set:604 <<application>>+0x833f94 #8 0x000023c09196ec33 in bt::gap::Peer::BrEdrData::AddService(bt::gap::Peer::BrEdrData*, bt::UUID) ../../src/connectivity/bluetooth/core/bt-host/gap/peer.cc:303 <<application>>+0xa74c33 #9 0x000023c09139d1f3 in bt::gap::$anon::BrEdrConnectionManagerTest_PeerServicesAddedBySearchAndRetainedIfNotSearchedFor_Test::TestBody(bt::gap::$anon::BrEdrConnectionManagerTest_PeerServicesAddedBySearchAndRetainedIfNotSearchedFor_Test*) ../../src/connectivity/bluetooth/core/bt-host/gap/bredr_connection_manager_unittest.cc:1471 <<application>>+0x4a31f3 #10 0x000023c091c06180 in testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(testing::Test*), const char*) ../../third_party/googletest/src/googletest/src/gtest.cc:2667 <<application>>+0xd0c180 #11 0x000023c091c05f4b in testing::Test::Run(testing::Test*) ../../third_party/googletest/src/googletest/src/gtest.cc:2682 <<application>>+0xd0bf4b #12 0x000023c091c07a10 in testing::TestInfo::Run(testing::TestInfo*) ../../third_party/googletest/src/googletest/src/gtest.cc:2861 <<application>>+0xd0da10 #13 0x000023c091c09cfb in testing::TestSuite::Run(testing::TestSuite*) ../../third_party/googletest/src/googletest/src/gtest.cc:3015 <<application>>+0xd0fcfb #14 0x000023c091c257fc in testing::internal::UnitTestImpl::RunAllTests(testing::internal::UnitTestImpl*) ../../third_party/googletest/src/googletest/src/gtest.cc:5855 <<application>>+0xd2b7fc #15 0x000023c091c24a00 in testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl*), const char*) ../../third_party/googletest/src/googletest/src/gtest.cc:2667 <<application>>+0xd2aa00 #16 0x000023c091c246b5 in testing::UnitTest::Run(testing::UnitTest*) ../../third_party/googletest/src/googletest/src/gtest.cc:5438 <<application>>+0xd2a6b5 #17.1 0x000023c091727f44 in RUN_ALL_TESTS() ../../third_party/googletest/src/googletest/include/gtest/gtest.h:2490 <<application>>+0x82df44 #17 0x000023c091727f44 in main(int, char**) ../../src/connectivity/bluetooth/core/bt-host/testing/run_all_unittests.cc:62 <<application>>+0x82df44 #18 0x000041ecbacc31d9 in start_main(const start_params*) ../../zircon/third_party/ulib/musl/src/env/__libc_start_main.c:139 <libc.so>+0xc11d9 #19 0x000041ecbacc3be1 in __libc_start_main(zx_handle_t, int (*)(int, char**, char**)) ../../zircon/third_party/ulib/musl/src/env/__libc_start_main.c:214 <libc.so>+0xc1be1 #20 0x000023c091860ef0 in _start(zx_handle_t) ../../zircon/system/ulib/c/Scrt1.cc:7 <<application>>+0x966ef0 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior #0 0x0000000000000000 is not covered by any module ``` ``` ../../src/connectivity/bluetooth/core/bt-host/common/uuid.cc:65:24: runtime error: load of misaligned address 0x2641a99e1d77 for type 'const uint16_t' (aka 'const unsigned short'), which requires 2 byte alignment 0x2641a99e1d77: note: pointer points here ff ff 00 28 01 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ #0 0x0000221bf67d735c in bt::UUID::FromBytes(const bt::ByteBuffer&, bt::UUID*) ../../src/connectivity/bluetooth/core/bt-host/common/uuid.cc:65 <bt-hci-emulator.so>+0x1d035c #1.2 0x000020e8faa6de37 in ubsan_GetStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:55 <libclang_rt.asan.so>+0x3be37 #1.1 0x000020e8faa6de37 in MaybePrintStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:53 <libclang_rt.asan.so>+0x3be37 #1 0x000020e8faa6de37 in ~ScopedReport() compiler-rt/lib/ubsan/ubsan_diag.cpp:389 <libclang_rt.asan.so>+0x3be37 #2 0x000020e8faa6eacb in handleTypeMismatchImpl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:137 <libclang_rt.asan.so>+0x3cacb #3 0x000020e8faa6e5dd in compiler-rt/lib/ubsan/ubsan_handlers.cpp:142 <libclang_rt.asan.so>+0x3c5dd #4 0x0000221bf67d735c in bt::UUID::FromBytes(const bt::ByteBuffer&, bt::UUID*) ../../src/connectivity/bluetooth/core/bt-host/common/uuid.cc:65 <bt-hci-emulator.so>+0x1d035c #5 0x0000221bf6749547 in bt::testing::FakeGattServer::HandleFindByTypeValue(bt::testing::FakeGattServer*, bt::hci::ConnectionHandle, const bt::ByteBuffer&) ../../src/connectivity/bluetooth/core/bt-host/testing/fake_gatt_server.cc:124 <bt-hci-emulator.so>+0x142547 21bf674872c in bt::testing::FakeGattServer::HandlePdu(bt::testing::FakeGattServer*, bt::hci::ConnectionHandle, const bt::ByteBuffer&) ../../src/connectivity/bluetooth/core/bt-host/testing/fake_gatt_server.cc:48 <bt-hci-emulator.so>+0x14172c #6 0x0000221bf674872c in bt::testing::FakeGattServer::HandlePdu(bt::testing::FakeGattServer*, bt::hci::ConnectionHandle, const bt::ByteBuffer&) ../../src/connectivity/bluetooth/core/bt-host/testing/fake_gatt_server.cc:48 <bt-hci-emulator.so>+0x14172c #7.1 0x0000221bf674eebd in λ(const (anon class)*, unsigned short, const bt::ByteBuffer&) ../../sdk/lib/fit/include/lib/fit/function.h:488 <bt-hci-emulator.so>+0x147ebd #7 0x0000221bf674eebd in fit::internal::target<(lambda at../../sdk/lib/fit/include/lib/fit/function.h:488:10), false, false, void, unsigned short, const bt::ByteBuffer&>::invoke(void*, unsigned short, const bt::ByteBuffer&) ../../sdk/lib/fit/include/lib/fit/function_internal.h:106 <bt-hci-emulator.so>+0x147ebd #8 0x0000221bf6760372 in fit::internal::function_base<16, false, void(unsigned short, const bt::ByteBuffer&)>::invoke(const fit::internal::function_base<16, false, void (unsigned short, const bt::ByteBuffer &)>*, unsigned short, const bt::ByteBuffer&) ../../sdk/lib/fit/include/lib/fit/function_internal.h:280 <bt-hci-emulator.so>+0x159372 #9 0x0000221bf67537b8 in fit::function_impl<16, false, void(unsigned short, const bt::ByteBuffer&)>::operator()(const fit::function_impl<16, false, void (unsigned short, const bt::ByteBuffer &)>*, unsigned short, const bt::ByteBuffer&) ../../sdk/lib/fit/include/lib/fit/function.h:287 <bt-hci-emulator.so>+0x14c7b8 #10 0x0000221bf675351a in bt::testing::FakeL2cap::HandlePdu(bt::testing::FakeL2cap*, bt::hci::ConnectionHandle, const bt::ByteBuffer&) ../../src/connectivity/bluetooth/core/bt-host/testing/fake_l2cap.cc:173 <bt-hci-emulator.so>+0x14c51a #11 0x0000221bf67630f1 in bt::testing::FakePeer::OnRxL2CAP(bt::testing::FakePeer*, bt::hci::ConnectionHandle, const bt::ByteBuffer&) ../../src/connectivity/bluetooth/core/bt-host/testing/fake_peer.cc:227 <bt-hci-emulator.so>+0x15c0f1 #12 0x0000221bf6731d02 in bt::testing::FakeController::OnACLDataPacketReceived(bt::testing::FakeController*, const bt::ByteBuffer&) ../../src/connectivity/bluetooth/core/bt-host/testing/fake_controller.cc:2437 <bt-hci-emulator.so>+0x12ad02 #13 0x0000221bf6717217 in bt::testing::ControllerTestDoubleBase::HandleACLPacket(bt::testing::ControllerTestDoubleBase*, async_dispatcher_t*, async::WaitBase*, zx_status_t, zx_packet_signal_t const*) ../../src/connectivity/bluetooth/core/bt-host/testing/controller_test_double_base.cc:195 <bt-hci-emulator.so>+0x110217 #14 0x0000221bf6717686 in async::WaitMethod<bt::testing::ControllerTestDoubleBase, &bt::testing::ControllerTestDoubleBase::HandleACLPacket>::CallHandler(async_dispatcher_t*, async_wait_t*, zx_status_t, zx_packet_signal_t const*) ../../zircon/system/ulib/async/include/lib/async/cpp/wait.h:201 <bt-hci-emulator.so>+0x110686 #15.1 0x0000221bf6848c0d in async_loop_run_once(async_loop_t*, zx_time_t) ../../zircon/system/ulib/async-loop/loop.c:387 <bt-hci-emulator.so>+0x241c0d #15 0x0000221bf6848c0d in async_loop_run(async_loop_t*, zx_time_t, _Bool) ../../zircon/system/ulib/async-loop/loop.c:260 <bt-hci-emulator.so>+0x241c0d #16 0x0000221bf6849f8d in async_loop_run_thread(void*) ../../zircon/system/ulib/async-loop/loop.c:812 <bt-hci-emulator.so>+0x242f8d #17 0x000043b5bffe8b9a in start_c11(void*) ../../zircon/third_party/ulib/musl/pthread/pthread_create.c:45 <libc.so>+0xbbb9a #18 0x000043b5c00f9cdd in thread_trampoline(uintptr_t, uintptr_t) ../../zircon/system/ulib/runtime/thread.c:94 <libc.so>+0x1cccdd SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior #0 0x0000000000000000 is not covered by any module ``` Bug: 46637 Change-Id: I94c8ed930f12fb06e162c95baa5c207f9e900310 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/574661 Fuchsia-Auto-Submit: Tamir Duberstein <[email protected]> Fuchsia-Auto-Submit: Zac Bowling <[email protected]> Commit-Queue: Zac Bowling <[email protected]> Reviewed-by: Zac Bowling <[email protected]> Reviewed-by: Faraaz Sareshwala <[email protected]> Reviewed-by: Leonard Chan <[email protected]>
Dart FIDL lists were made unmodifiable in https://fuchsia-review.googlesource.com/c/fuchsia/+/665177/ which seems to be making this logic crash at runtime. Fixes this error from some logs I saw in an unrelated bug fxb/101341: ``` [00020.831] [30826][60673][flutter_aot_product_runner.cm] ERROR: [flutter/runtime/dart_vm_initializer.cc:41] Unhandled Exception: Unsupported operation: Cannot remove from an unmodifiable list #0 UnmodifiableListMixin.removeAt (dart:_internal/list.dart:164) #1 new SettingsStateImpl.<anonymous closure>.<anonymous closure> (package:ermine/src/states/settings_state_impl.dart:325) #2 Function._apply (dart:core-patch/function_patch.dart:11) #3 Function.apply (dart:core-patch/function_patch.dart:34) #4 Action.call (package:mobx/src/core/action.dart:53) #5 runInAction (package:mobx/src/api/action.dart:11) #6 new SettingsStateImpl.<anonymous closure> (package:ermine/src/states/settings_state_impl.dart:313) #7 ChannelService.start (package:ermine/src/services/settings/channel_service.dart:39) <asynchronous suspension> #8 Future.wait.<anonymous closure> (dart:async/future.dart:522) <asynchronous suspension> #9 SettingsStateImpl.start (package:ermine/src/states/settings_state_impl.dart:387) <asynchronous suspension> ``` Change-Id: I5adffdec4e64beafc2cc97da5e23197e4ec2e298 Reviewed-on: https://fuchsia-review.googlesource.com/c/experiences/+/684597 Reviewed-by: Sanjay Chouksey <[email protected]> Reviewed-by: Charles Whitten <[email protected]> Commit-Queue: Alexander Biggs <[email protected]>
If you make any changes to it yourself then they will take precedence over the rebase.
Bumps lodash.mergewith from 4.6.1 to 4.6.2.
Commits
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase
.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase
will rebase this PR@dependabot recreate
will recreate this PR, overwriting any edits that have been made to it@dependabot merge
will merge this PR after your CI passes on it@dependabot squash and merge
will squash and merge this PR after your CI passes on it@dependabot cancel merge
will cancel a previously requested merge and block automerging@dependabot reopen
will reopen this PR if it is closed@dependabot ignore this [patch|minor|major] version
will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependency
will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)@dependabot use these labels
will set the current labels as the default for future PRs for this repo and language@dependabot use these reviewers
will set the current reviewers as the default for future PRs for this repo and language@dependabot use these assignees
will set the current assignees as the default for future PRs for this repo and language@dependabot use this milestone
will set the current milestone as the default for future PRs for this repo and languageYou can disable automated security fix PRs for this repo from the Security Alerts page.