build(deps): Bump handlebars from 4.0.11 to 4.5.1 in /peridot/web/cloud_dashboard #4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
Bumps [handlebars](https://github.com/wycats/handlebars.js) from 4.0.11 to 4.5.1. - [Release notes](https://github.com/wycats/handlebars.js/releases) - [Changelog](https://github.com/wycats/handlebars.js/blob/v4.5.1/release-notes.md) - [Commits](handlebars-lang/handlebars.js@v4.0.11...v4.5.1) Signed-off-by: dependabot[bot] <[email protected]>
dependabot
bot
added
the
dependencies
|
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 |
vsrinivas
pushed a commit
that referenced
this pull request
May 6, 2020
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]>
vsrinivas
pushed a commit
that referenced
this pull request
Jul 18, 2020
This change adds logic to have a DebuggedThread::run_mode_ of kForwardAndContinue result in the held exception being marked as second-chance (and not handled). Bug: 48767 Change-Id: Ic21156814caae6a14bccf615ab9ae3ee232f6249 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/382683 Reviewed-by: Brett Wilson <[email protected]> Commit-Queue: Joshua Seaton <[email protected]> Testability-Review: Brett Wilson <[email protected]>
vsrinivas
pushed a commit
that referenced
this pull request
Oct 6, 2020
Currently, every use of fbl::AllocChecker compiles into a large amount
of code. Consider the following trivial example, which allocates a new
`int` object:
int* do_test_alloc() {
fbl::AllocChecker ac;
int* result = new (&ac) int(0);
if (!ac.check()) {
return nullptr;
}
return result;
}
Today, on a release ARM build, this generates the following assembly:
0: sub sp, sp, #48 // Stack frame (48 bytes)
4: str x30, [x18], #8
8: stp x29, x30, [sp, #16]
c: add x29, sp, #16
10: stp x20, x19, [sp, #32] // Stack protector set up.
14: mrs x20, TPIDR_EL1
18: mov w9, #-1431655766 // Set uninitialised variable to 0xaaaaaaaa.
1c: ldur x8, [x20, #-16]
20: mov x0, sp // Create AllocChecker object.
24: str x8, [sp, #8]
28: str w9, [sp]
2c: bl fbl::AllocChecker::AllocChecker()
30: mov x1, sp // Allocate 4 bytes of memory
34: mov w0, #4
38: bl operator new(unsigned long, fbl::AllocChecker*)
3c: mov x19, x0
40: cbz x0, 0x48 <do_alloc()+0x48> // Allocate memory.
44: str wzr, [x19]
48: mov x0, sp
4c: bl fbl::AllocChecker::check()
// Get alloc success/fail result.
50: tst w0, #0x1
54: mov x0, sp
58: csel x19, x19, xzr, ne
5c: bl fbl::AllocChecker::~AllocChecker()
// Ensure check() was called.
60: ldur x8, [x20, #-16] // Safe stack verification.
64: ldr x9, [sp, #8]
68: cmp x8, x9
6c: b.ne 0x88 <do_alloc()+0x88>
70: ldp x29, x30, [sp, #16] // Stack restore.
74: mov x0, x19
78: ldp x20, x19, [sp, #32]
7c: ldr x30, [x18, #-8]!
80: add sp, sp, #48
84: ret
88: bl __stack_chk_fail
This requires 92 bytes of code and 48 bytes of stack. Taking a pointer
to the stack-allocated AllocChecker object additionally causes the
compiler to emit stack protector code (to check the stack hasn't been
overrun), which adds additional complexity to the code.
This CL inlines most of the AllocChecker implementation, allowing the
compiler to see that most operations are trivial and compiler them away.
We replace the use of bit flags with simple boolean flags to help the
compiler to optimise away code.
We additionally replace calls to:
malloc_debug_caller(..., __GET_CALLER())
with just `malloc`, as because the calls are now inlined, malloc's
internal use of __GET_CALLER() produces the correct result.
After this CL, the above code generates the following assembly:
0: str x30, [x18], #8 // Stack frame (8 bytes)
4: stp x29, x30, [sp, #-16]!
8: mov x29, sp
c: mov w0, #4 // We want to malloc 4 bytes.
10: bl malloc // Call malloc.
14: cbz x0, 0x1c <do_alloc()+0x1c>
// If we got the memory, set to 0.
18: str wzr, [x0]
1c: ldp x29, x30, [sp], #16 // Stack restore.
20: ldr x30, [x18, #-8]!
24: ret
Happily, this code is the same as what would be generated if we were not
using a AllocChecker object at all, like the following:
int* do_alloc() {
int* result = malloc(sizeof(int));
if (result != nullptr) {
*result = 0;
}
return result;
}
This CL removes about ~10kiB of code from the kernel on an ARM release
build:
text data bss total filename
1170788 333318 536584 2040690 kernel.before.elf
1161108 333350 536584 2031042 kernel.after.elf
Userspace doesn't tend to use AllocChecker as often, but on a release
build on the "core" product, the following binaries have a change in
code size:
code size (bytes)
binary before after diff
------ ------ ----- ----
appmgr: 695752 695508 -244
biotime: 18256 18060 -196
blktest: 95992 95452 -540
blobfs: 991888 990324 -1564
blobfs-load-generator: 24552 24084 -468
bootsvc: 149280 148508 -772
bootsvc-integration-test: 57980 57588 -392
console: 119544 119300 -244
core-standalone-test: 2853684 2852868 -816
device-name-provider: 92108 91864 -244
display-test: 82080 81564 -516
driver_host: 240828 240348 -480
driver_manager: 321304 320224 -1080
factory_reset: 95436 95240 -196
fshost: 468724 467208 -1516
fuchsia_microbenchmarks: 208160 207380 -780
fvm-check: 10296 10068 -228
gpt: 26696 26520 -176
isolated_devmgr: 88136 87920 -216
kstress: 34612 34156 -456
loadgen: 2452 2220 -232
lspwr: 10124 9952 -172
memfs: 90368 90124 -244
minfs: 292744 292088 -656
nand-util: 29408 29400 -8
ptysvc: 99036 98792 -244
pwrbtn-monitor: 22952 21992 -960
runtests: 127832 127304 -528
shutdown-shim: 109556 109312 -244
trace: 199372 199204 -168
wlanstack: 854852 854724 -128
zbi-parent-test: 23596 23080 -516
That is, all affected userspace binaries benefit from a reduction in
code size.
Change-Id: If2277bbaa5288175037667f50552d92c2509a2a5
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/433015
Commit-Queue: David Greenaway <[email protected]>
Testability-Review: David Greenaway <[email protected]>
Testability-Review: George Kulakowski <[email protected]>
Testability-Review: Roland McGrath <[email protected]>
Testability-Review: Corey Tabaka <[email protected]>
Reviewed-by: George Kulakowski <[email protected]>
Reviewed-by: Roland McGrath <[email protected]>
Reviewed-by: Corey Tabaka <[email protected]>
vsrinivas
pushed a commit
that referenced
this pull request
Nov 13, 2020
Fix an issue with basic PI testing which is prone to flake. The test code is attempting to do the following: 1) Create two threads, A and B, and one OwnedWaitQueue Q. 2) Block thread A on an event. 3) Block thread B with a timeout on Q while declaring A to be the owner of Q. 4) Observe the PI effects of B on A transmitted through Q. 5) Allow B to timeout. 6) Observe that the PI effects in step #4 go away. The problem with this test is that it is technically possible for thread B to timeout before the observing thread has a chance to observe the new effective priority of A. To help avoid this, we both increase the timeout from 50mSec to 200mSec, but we also verify that the effective priority that we observe was observed while thread B was still blocked. If it has unblocked during the test, we try again instead of failing the test. Fixed: 63552 Change-Id: I5e148db77df509f643d6f4f9adac9ffc78af0a1e Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/448614 Commit-Queue: Auto-Submit <[email protected]> Fuchsia-Auto-Submit: John Grossman <[email protected]> Reviewed-by: Nick Maniscalco <[email protected]> Testability-Review: Nick Maniscalco <[email protected]>
vsrinivas
pushed a commit
that referenced
this pull request
Dec 9, 2020
A fair amount of the printf machinery is now using C++, and relying on the fact that global/static classes used in the stack have trivial constructors. For the most part, this is working out (although it could, in theory, break at any time), but there is at least one edge case which is failing. If ENABLE_KERNEL_LL_DEBUG is defined, it will initialize the global dlog_bypass_ boolean to true, telling the system to go directly out the serial port instead of going to the debuglog's internal buffer. During the first printf in top/main.cc (the "printing enabled" banner), we end up calling... 1) dprintf 2) printf 3) vprintf 4) vfprintf 5) File::Write (thunks to stdout_'s lambda) 6) stdout_write_buffered 7) Linebuffer::Write 8) stdout_write 9) console_write The vfprintf call (#4) takes a global FILE instance (stdout_), but this is currently "ok" as this instance is successfully data-segment-only initialized (currently, at least). The trouble starts when we get to console_write, which grabs a spinlock, and then attempts to enumerate the callbacks stored in the global print_callbacks list. The print_callbacks list is a fbl DLL whose head pointer is still 0, it has not been updated to the sentinel pointer value yet. This trips an assert very early on in boot which leads to a never ending double fault on x64. So, for now, make sure that global ctors are finished before we perform our very first printf. Change-Id: Ic8bf3a59055aa8aded8fff9380561e5cea281af6 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/459506 Reviewed-by: Nick Maniscalco <[email protected]> Testability-Review: Nick Maniscalco <[email protected]> Fuchsia-Auto-Submit: John Grossman <[email protected]> Commit-Queue: Auto-Submit <[email protected]>
vsrinivas
pushed a commit
that referenced
this pull request
Aug 30, 2021
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]>
vsrinivas
pushed a commit
that referenced
this pull request
Aug 30, 2021
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]>
vsrinivas
pushed a commit
that referenced
this pull request
Aug 30, 2021
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]>
vsrinivas
pushed a commit
that referenced
this pull request
Aug 30, 2021
``` ../../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]>
vsrinivas
pushed a commit
that referenced
this pull request
Aug 30, 2021
``` ../../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]>
vsrinivas
pushed a commit
that referenced
this pull request
Aug 30, 2021
...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]>
vsrinivas
pushed a commit
that referenced
this pull request
Oct 13, 2022
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]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If you make any changes to it yourself then they will take precedence over the rebase.
Bumps handlebars from 4.0.11 to 4.5.1.
Changelog
Sourced from handlebars's changelog.
Commits
7ef8617v4.5.1b75e3e1Update release notes5e9d17ffix: move "eslint-plugin-compat" to devDependenciesb24797dv4.5.0a243067Update release notes088e618chore: add eslint-plugin-compat and eslint-plugin-es57052e88Resolve deprecation warning message from eslint while running eslint (#1586)b8913fcAdd missing types for the Exception class properties (#1583)62ed3c2Add Handlebars.parseWithoutProcessing (#1584)7fcf9d2Use objects for hash value trackingDependabot 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 rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot ignore this [patch|minor|major] versionwill 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 dependencywill 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 labelswill set the current labels as the default for future PRs for this repo and language@dependabot use these reviewerswill set the current reviewers as the default for future PRs for this repo and language@dependabot use these assigneeswill set the current assignees as the default for future PRs for this repo and language@dependabot use this milestonewill 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.