Skip to content
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 js-yaml from 3.12.0 to 3.13.1 in /peridot/web/cloud_dashboard #2

Conversation

dependabot[bot]
Copy link

@dependabot dependabot bot commented on behalf of github Oct 30, 2019

Bumps js-yaml from 3.12.0 to 3.13.1.

Changelog

Sourced from js-yaml's changelog.

3.13.1 / 2019-04-05

  • Fix possible code execution in (already unsafe) .load(), #480.

3.13.0 / 2019-03-20

  • Security fix: safeLoad() can hang when arrays with nested refs
    used as key. Now throws exception for nested arrays. #475.

3.12.2 / 2019-02-26

  • Fix noArrayIndent option for root level, #468.

3.12.1 / 2019-01-05

  • Added noArrayIndent option, #432.
Commits

Dependabot compatibility score

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 language

You can disable automated security fix PRs for this repo from the Security Alerts page.

@dependabot dependabot bot added the dependencies Pull requests that update a dependency file label Oct 30, 2019
vsrinivas pushed a commit that referenced this pull request Oct 31, 2019
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
vsrinivas pushed a commit that referenced this pull request Nov 9, 2019
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 @github
Copy link
Author

dependabot bot commented on behalf of github Dec 4, 2019

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 rebase.

8 similar comments
@dependabot @github
Copy link
Author

dependabot bot commented on behalf of github Dec 13, 2019

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 rebase.

@dependabot @github
Copy link
Author

dependabot bot commented on behalf of github Dec 14, 2019

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 rebase.

@dependabot @github
Copy link
Author

dependabot bot commented on behalf of github Dec 19, 2019

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 rebase.

@dependabot @github
Copy link
Author

dependabot bot commented on behalf of github Dec 28, 2019

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 rebase.

@dependabot @github
Copy link
Author

dependabot bot commented on behalf of github Jan 1, 2020

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 rebase.

@dependabot @github
Copy link
Author

dependabot bot commented on behalf of github Jan 5, 2020

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 rebase.

@dependabot @github
Copy link
Author

dependabot bot commented on behalf of github Jan 7, 2020

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 rebase.

@dependabot @github
Copy link
Author

dependabot bot commented on behalf of github Jan 10, 2020

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 rebase.

@vsrinivas vsrinivas closed this in f699c6b Jan 16, 2020
@dependabot @github
Copy link
Author

dependabot bot commented on behalf of github Jan 16, 2020

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

@dependabot dependabot bot deleted the dependabot/npm_and_yarn/peridot/web/cloud_dashboard/js-yaml-3.13.1 branch January 16, 2020 01:01
vsrinivas pushed a commit that referenced this pull request Apr 15, 2020
The name "WithMaxRetries" left some ambiguity as to the number of times
the operation would be retried. The "max retries" could mean either:
1. how many times the operation is attempted
2. OR how many times the operation is retried after the first attempt
  fails

The retry library actually used approach #2, but based on some of the
usages of WithMaxRetries, it seems that that wasn't obvious to people
using the library.

Additionally, setting maxRetries to zero caused some confusing behavior:
the library interpeted maxRetries==0 as "infinite retries". This means
the only way to turn retries off is to set maxRetries=-1, which is not
documented and is far from intuitive.

I think a decent way to address both of these issues is by renaming the
function to WithMaxAttempts, and changing the parameter to actually mean
"max attempts" (meaning #1) rather than "max retries" (meaning #2). This
also lets us disable retries by setting maxAttempts=1, which is pretty
intuitive. maxAttempts=0 will cause the library to retry infinitely.

To avoid any behavior changes, I incremented the max parameter for all
usages of WithMaxAttempts, except where `maxRetries` was intended to be
be a max number of attempts.

Change-Id: Ie7712f1fe2a28ca4c820b1e5db9e9e050d9244f7
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/380091
Commit-Queue: Oliver Newman <olivernewman@google.com>
Reviewed-by: Joshua Seaton <joshuaseaton@google.com>
Testability-Review: Joshua Seaton <joshuaseaton@google.com>
vsrinivas pushed a commit that referenced this pull request Apr 21, 2020
This change is to be used for steps #1 & #2 in fxb/50308.
Also sort src/security/policy/BUILD.gn to aid in maintenance and a11y.

Bug: 50308
Change-Id: Ied98f6ab87ab456711616967a5be61871e6cad43
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/381331
Reviewed-by: Benjamin Wright <benwright@google.com>
Testability-Review: Shai Barack <shayba@google.com>
Commit-Queue: Shai Barack <shayba@google.com>
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 <adanis@google.com>
> Testability-Review: Adrian Danis <adanis@google.com>
> Reviewed-by: James Robinson <jamesr@google.com>
> Reviewed-by: Carlos Pizano <cpu@google.com>

TBR=jamesr@google.com,cpu@google.com,adanis@google.com

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 <dgreenaway@google.com>
Reviewed-by: David Greenaway <dgreenaway@google.com>
vsrinivas pushed a commit that referenced this pull request Jul 16, 2020
This change ensures that debug_agent populates second-chance information
to the client.

Bug: 48767
Change-Id: I75026d5ce35bb8d66adfca09e81a49310a26c967
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/381742
Commit-Queue: Joshua Seaton <joshuaseaton@google.com>
Reviewed-by: Brett Wilson <brettw@google.com>
Testability-Review: Brett Wilson <brettw@google.com>
vsrinivas pushed a commit that referenced this pull request Aug 26, 2020
Bug: 56604
Change-Id: Ib951e506f9744bbf9488c526931bbfcf9ca5c535
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/419757
Reviewed-by: Justin Mattson <jmatt@google.com>
Reviewed-by: Miguel Flores <miguelfrde@google.com>
Testability-Review: Miguel Flores <miguelfrde@google.com>
API-Review: Gary Bressler <geb@google.com>
Commit-Queue: Gary Bressler <geb@google.com>
vsrinivas pushed a commit that referenced this pull request Sep 25, 2020
To fix these:
1. Remove the -Wno-conversion-generated config
2. Add `cflags = ["-Wconversion"]` instead
3. Build to receive hundreds of implicit conversion issues from across
the source tree (or just build the examples for faster feedback)
4. Fix srcgen to not generate C++ code with implicit conversion issues
5. Remove the flag from #2
6. Submit

Bug: 58162
Change-Id: Ifd571cfeb6b6fcfc93c19ccbbce74649160ca933
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/430702
Reviewed-by: Benjamin Prosnitz <bprosnitz@google.com>
Reviewed-by: Pascal Perez <pascallouis@google.com>
Commit-Queue: Shai Barack <shayba@google.com>
vsrinivas pushed a commit that referenced this pull request Oct 29, 2020
This updates argh to 0.1.4, which includes the following changes:

* 66e44a7 - Add myself to more authors lists (6 minutes ago) <Erick Tryzelaar>
* ce8ce29 - Add Cargo.lock to .gitignore (9 minutes ago) <Erick Tryzelaar>
* 567dc18 - Adding myself to the authors list (10 minutes ago) <Erick Tryzelaar>
* c2fc87d - Bump versions to 0.1.4 (10 minutes ago) <Erick Tryzelaar>
* 83785d1 - Use command base name not full path. (#44) (4 hours ago) <Matt Boetger>
*   d6abe82 - Merge pull request #64 from erickt/parse-errors (2 weeks ago) <Erick Tryzelaar>
|\
| * c728c85 - Fix quoting in errors when parsing arguments (2 weeks ago) <Erick Tryzelaar>
* |   14fc76d - Merge pull request #66 from erickt/remove-lock (2 weeks ago) <Erick Tryzelaar>
|\ \
| |/
|/|
| * e91274f - Remove lockfile (2 weeks ago) <Erick Tryzelaar>
|/
*   f3da6ae - Merge pull request #60 from elipsitz/support-option-delimiter (2 weeks ago) <Erick Tryzelaar>
|\
| * 9022148 - Add support for option delimiter "--" (3 weeks ago) <Eli Lipsitz>
| * 2517d3f - Run rustfmt to fix a pre-existing formatting issue (3 weeks ago) <Eli Lipsitz>
* | 8d9a82f - Merge pull request #49 from siyopao/fix-issue-45 (3 months ago) <Benjamin Brittain>
|\|
| * ee6521e - Add missing newline to error message (3 months ago) <Craig Pastro>
|/
*   507087f - Merge pull request #41 from benbrittain/kebab-case (4 months ago) <Benjamin Brittain>
|\
| * 5b0c45f - Allow kebab-case in long names (4 months ago) <Ben Brittain>
| * ae57b5c - update lockfile (4 months ago) <Ben Brittain>
|/
* e59f2c8 - fix default value error message (4 months ago) <Ben Brittain>
*   aae704e - Merge pull request #24 from foresterre/docs/fix-docsrs-badge-link (6 months ago) <Benjamin Brittain>
|\
| * 1fddf5a - Fix the source of the docs.rs badge link (6 months ago) <Martijn M.W. Gribnau>
|/
*   68e7363 - Merge pull request #23 from Atul9/add-cargo-fmt-to-github-actions (7 months ago) <Benjamin Brittain>
|\
| * 1f8930c - Add cargo fmt to github-actions config (7 months ago) <Atul Bhosale>
|/
*   bf49ee6 - Merge pull request #17 from fadeevab/docs-about-default (7 months ago) <Benjamin Brittain>
|\
| * 7d6cc74 - Update package docs from README (about default args) (7 months ago) <Alexander Fadeev>
|/
*   c1079ba - Merge pull request #16 from fadeevab/readme-examples-default-optional (7 months ago) <Benjamin Brittain>
|\
| * 1adb4e8 - Example and explanation about default and optional (7 months ago) <Alexander Fadeev>
|/
*   dad549b - Merge pull request #10 from MRedies/patch-1 (9 months ago) <Benjamin Brittain>
|\
| * 276fa2b - Confusing syntax highlighting in README.md (9 months ago) <Matthias Redies>
|/
*   737d298 - Merge pull request #8 from Atul9/cargo-fmt (9 months ago) <Ben Brittain>
|\
| * 7515ada - Format code using 'cargo fmt' (9 months ago) <Atul Bhosale>
|/
* 6e8c8f5 - Add rustfmt used for this project (9 months ago) <Benjamin Brittain>
* 154e4fe - Add badges to README (9 months ago) <Ben Brittain>
* 775c6bc - Update rust.yml (9 months ago) <Ben Brittain>
* f587921 - Update rust.yml (9 months ago) <Ben Brittain>
* 3ab931f - Add basic CI/CQ with GitHub actions (9 months ago) <Ben Brittain>
* 9bd8f0f - Add keywords (9 months ago) <Ben Brittain>
* e8a6b13 - Remove duplicate section in README (9 months ago) <Ben Brittain>
*   bac15ab - Merge pull request #5 from tshepang/patch-1 (9 months ago) <Ben Brittain>
|\
| * e5e0d6f - readme: highlight code, and reduce density, for 1 example (9 months ago) <Tshepang Lekhonkhobe>
|/
* ebfaa78 - Merge pull request #2 from jeremyBanks/patch-1 (9 months ago) <Ben Brittain>
* 5e702a1 - Link crates.io badge to crates.io page (9 months ago) <Jeremy Banks>

Change-Id: Iec1b6164fe477c7e7f0583273a405be1a87064f4
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/443703
Reviewed-by: George Kulakowski <kulakowski@google.com>
Testability-Review: George Kulakowski <kulakowski@google.com>
Commit-Queue: Erick Tryzelaar <etryzelaar@google.com>
vsrinivas pushed a commit that referenced this pull request Feb 5, 2021
Context: After the A2DP component merge, the a2dp source integration
tests started to flake. The exact flake is seen in the attempt to
connect to the cobalt.LoggerFactory service. Occasionally, tests that
were run in parallel would fail to connect to the LoggerFactory service, resulting
in an ERROR severity log and therefore failing the test. From an initial
investigation, it looks like test #1 is able to connect to the service,
but when test #2 tries shortly after, it fails due to a PEER_CLOSED on
it's ClientEnd of the FIDL channel. This could be because the ServerEnd
is getting dropped somehow. The mock_cobalt component is capable of
supporting multiple clients, so the parallelism in that regard should be
ok.

- Update manifest to use the new system services.

- As a temporary measure to re-enable the tests, limit the parallelism
of the tests to one thread. This eliminates the flakes mentioned above.
fxbug.dev/69212 tracks the work around debugging why concurrent service
accesses are failing. The net benefit of re-enabling the integration
tests outweighs the decreased performance of the tests when limiting its
parallelism.

Fixed: 67823
Test: fx test bt-a2dp-source-integration-tests

Multiply: bt-a2dp-source-integration-tests
Change-Id: Ib1151e516883bb01c3d3a2080e7ef186f25d0ee6
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/480658
Reviewed-by: Nick Pollard <nickpollard@google.com>
Commit-Queue: Ani Ramakrishnan <aniramakri@google.com>
vsrinivas pushed a commit that referenced this pull request Feb 5, 2021
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 <maniscalco@google.com>
Commit-Queue: Corey Tabaka <eieio@google.com>
vsrinivas pushed a commit that referenced this pull request Apr 8, 2021
When changing the return type of BindServer as per fxbug.dev/67062 and
fxbug.dev/56754, I performed a survey of existing usage of BindServer.
It turns out, because BindServer could both synchronously fail (via
return value) and asynchronously fail (via on_unbound callback), it has
led to duplicated error handling paths [1], or led to users ignoring one
of the error paths [2]. With some effort, it is possible to centralize
all error cases to the asynchronous path, e.g. BindServer will now
always return a `fidl::ServerBindingRef`.

There are only two ways BindServer could synchronously fail:

1: If the channel does not have the |ZX_RIGHT_WAIT| right.
2: If the dispatcher does not support waiting, or is shutting down.

For #1, that is similar in spirit to if the channel's peer was closed
(i.e. both are factors controlled by a foreign component), which is
currently asynchronously handled. So it makes sense to move this error
condition to the asynchronous path.

For #2, we would have to make a trade-off. We could either synchronously
invoke the |on_unbound| handler and report the dispatcher error, or
trigger a panic. There is no way to asynchronously report the error
because the dispatcher is already in an unusable state. Existing
|on_unbound| handler implementations were already written with the
assumption that they would be asynchronously invoked (e.g. the code
assumes it is safe to synchronously setup some state right after the
BindServer call, which would be always ordered before any asynchronous
"on_unbound" callback invocations); therefore, synchronously invoking
the handler would break those assumptions, so this CL picks the
panicking option.

Some user code (in audio drivers and libraries in particular) were
binding new FIDL connections to a dispatcher while also simultaneously
shutting down the dispatcher; they were adjusted to no longer bind new
connections once shutdown is in progress, hence avoiding the panic.

A similar change is made on the client side (with much less user code
fallout).

[1]: https://fuchsia-review.googlesource.com/c/fuchsia/+/511040/6/src/graphics/drivers/misc/goldfish_sync/sync_device.cc#319
[2]: https://fuchsia-review.googlesource.com/c/fuchsia/+/511040/6/src/media/audio/drivers/usb-audio/usb-audio-stream.cc#b251

MULTIPLY: fuchsia-pkg://fuchsia.com/aml-g12-tdm-test#meta/stream-test-package.cmx
MULTIPLY: fuchsia-pkg://fuchsia.com/sa-unittest#meta/test-package.cmx
MULTIPLY: fuchsia-pkg://fuchsia.com/usb-audio-test#meta/usb-audio-test-package.cmx
MULTIPLY: fidl_llcpp_dispatcher_tests

Fixed: 67062
Fixed: 56754
Test: fx test fidl_llcpp_dispatcher_tests
Change-Id: Icf15a563aab86f5667d93033b75cd205b8125483
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/511040
Fuchsia-Auto-Submit: Yifei Teng <yifeit@google.com>
Commit-Queue: Yifei Teng <yifeit@google.com>
Reviewed-by: Ian McKellar <ianloic@google.com>
Reviewed-by: Tamir Duberstein <tamird@google.com>
vsrinivas pushed a commit that referenced this pull request Apr 15, 2021
This fixes a bug in component manager that can cause a created component
to be incorrectly deleted if it was created just after another component
with the same name was deleted.

To be precise, the race is as follows:
1) Client calls DestroyChild.
2) component_manager schedules a DeleteChild action
3) DestroyChild returns.
4) Client calls CreateChild, with the same instance name.
5) Instance is created.
6) The DeleteChild action from #2 executes. It starts by scheduling a
   MarkDeleted action, which incorrectly marks the new instance deleted.

The solution is for DeleteChild not to call MarkDeleted. Instead, code
that handles instance destruction must explicitly call MarkDeleted
first.

This bug was causing `ffx session restart` to sometimes error with
CreateComponentFailed (which actually was an error of failing to bind to
the session component).

Tested: Manually verified the fix works with `session_control`. Added an
integration test which should flake if the issue is present. Unit test
checks that MarkDeleted is not rescheduled.

Multiply: destruction_integration_test: 200
Fixed: 41967
Change-Id: I1f19811b0afff0533a2721b45fe7cc07bde072ce
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/511284
Commit-Queue: Gary Bressler <geb@google.com>
Reviewed-by: Fady Samuel <fsamuel@google.com>
vsrinivas pushed a commit that referenced this pull request Jun 20, 2021
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 <geb@google.com>
Reviewed-by: Fady Samuel <fsamuel@google.com>
vsrinivas pushed a commit that referenced this pull request Aug 6, 2021
This CL migrates usages of fuchsia.sys2.Realm/BindChild
to fuchsia.sys2.Realm/OpenExposedDir. The former has
been deprecated.

CL 1 of Batch #2

Change-Id: I7c451b868beb8db6e884c9a304bdbeb927b2f676
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/564661
Reviewed-by: Mukesh Agrawal <quiche@google.com>
Commit-Queue: Yaneury Fermin <yaneury@google.com>
vsrinivas pushed a commit that referenced this pull request Aug 12, 2021
… set_mic_mute(args); test verifies that set_mic_mute successfully changes the state of the device mic; added method to commands.rs, types.rs, facade.rs

unit test #2 https://fuchsia-review.googlesource.com/c/fuchsia/+/567582

Change-Id: Ia510b77dfc0c1aafdc716d73961c9cddc48c2bf1
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/562911
Reviewed-by: Yuan Zhi <yuanzhi@google.com>
Reviewed-by: Cole Alban <colealban@google.com>
Reviewed-by: Muthu Palaniappan <mpalaniappan@google.com>
Commit-Queue: Isabelle Goralsky <igoralsky@google.com>
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 <auto-submit@fuchsia-infra.iam.gserviceaccount.com>
Fuchsia-Auto-Submit: Tamir Duberstein <tamird@google.com>
Reviewed-by: Abdulla Kamar <abdulla@google.com>
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 <bhamrick@google.com>
Reviewed-by: Fadi Meawad <fmeawad@google.com>
Commit-Queue: Auto-Submit <auto-submit@fuchsia-infra.iam.gserviceaccount.com>
Fuchsia-Auto-Submit: Tamir Duberstein <tamird@google.com>
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 <tamird@google.com>
Reviewed-by: Abdulla Kamar <abdulla@google.com>
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 <auto-submit@fuchsia-infra.iam.gserviceaccount.com>
Fuchsia-Auto-Submit: Tamir Duberstein <tamird@google.com>
Reviewed-by: Fadi Meawad <fmeawad@google.com>
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 <auto-submit@fuchsia-infra.iam.gserviceaccount.com>
Fuchsia-Auto-Submit: Tamir Duberstein <tamird@google.com>
Reviewed-by: Fadi Meawad <fmeawad@google.com>
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 <tamird@google.com>
Fuchsia-Auto-Submit: Zac Bowling <zbowling@google.com>
Commit-Queue: Zac Bowling <zbowling@google.com>
Reviewed-by: Zac Bowling <zbowling@google.com>
Reviewed-by: Faraaz Sareshwala <fsareshwala@google.com>
Reviewed-by: Leonard Chan <leonardchan@google.com>
vsrinivas pushed a commit that referenced this pull request Apr 8, 2022
I checked the static_check recipe: it provides two arguments:
* gn_path (which check_licenses doesn't use in this case, because a notice file is not generated during static-checks)
* config (which points to the wrong file currently, and isn't even needed anymore since the path to the default config is baked into the code)

I have updated the code to ignore the config arg for the time being.
After this is submitted, I'll update static-checks to remove that flag,
and then re-update this code to use the arg again.

============

This deletes a bunch of files in the root check-licenses dir that are
no longer being used.

Updates config.go to use the v2 fields / structs

Updates cmd/main.go to only use the args that we use (or are being used
elsewhere currently so can't be removed in this CL).

Runtime is about 3.5 minutes. I verified that it detects malformed
headers in the root Fuchsia project, so there shouldn't be any
disruption in functionality.

-> fx check-licenses
Initializing... Done. [1.304883669s]
Discovering files and folders... Done. [3.540097747s]
Searching for license texts [1241 projects]... Done. [2m35.292414502s]
Saving results... Done. [53.155829402s]

Total runtime: 3m33.29343529s
============

License Metrics:
  Number of Unique License Patterns: 211
  Number of Unused Patterns: 72

Project Metrics:
  Duplicate README.fuchsia Files: 38
  Initialized Custom Project Count: 421
  Initialized Custom Project Retrieval Count: 419
  Project Count: 1241
  Projects Missing License Files: 67
  Projects Missing Names: 24
  Unexpected Line Found In README.fuchsia File: 284

File Metrics:
  All Files: 241654
  Files that may have license information: 130724
  Files that were access multiple times during traversal: 8312

Filetree Metrics:
  File Count: 254779
  Files Missing Projects: 14194
  Folder Count: 33185
  Folders Missing Projects: 1008
  Skipped Items: 1175

Result Metrics:
  Number of initialized templates: 8

Filtering projects to the entire workspace using `gn gen`
724 projects remain (filtered out 517 from the full list of 1241 projects).

 ⦿ Executed template -> /tmp/check-licenses/out/summary.csv (+ *.gz)
 ⦿ Executed template -> /tmp/check-licenses/out/summary_diff.csv (+ *.gz)
 ⦿ Executed template -> /tmp/check-licenses/out/license_texts_grouped_by_project.txt (+ *.gz)
 ⦿ Executed template -> /tmp/check-licenses/out/license_texts_grouped_by_project_deduped.txt (+ *.gz)
 ⦿ Executed template -> /tmp/check-licenses/out/license_all_grouped_by_license_pattern_deduped.txt (+ *.gz)
 ⦿ Executed template -> /tmp/check-licenses/out/license_meta_grouped_by_license_pattern_deduped.txt (+ *.gz)
 ⦿ Executed template -> /tmp/check-licenses/out/license_texts_grouped_by_license_pattern_deduped.txt (+ *.gz)
 ⦿ Executed template -> /tmp/check-licenses/out/license_texts_grouped_by_license_pattern_deduped.html (+ *.gz)

Full summary and output files -> /tmp/check-licenses

Bug: 95548, 94409, 94506, 94517

Change-Id: I73edeeb8c2cd13f85b55f3b425f4e410a65d1b70
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/667506
Reviewed-by: Sean Cuff <seancuff@google.com>
Commit-Queue: Jerry Belton <jcecil@google.com>
vsrinivas pushed a commit that referenced this pull request Apr 27, 2022
    This addresses the issue in fxbug.dev/98529 which reports
    issues when downloading the packages for the terminal.qemu-arm64
    product.

    This change adds handling the other product.board combinations,
    previously only qemu-arm64 was handled.

    Bug: 98529

Change-Id: I3e96a06136af7e31f1814dfb8482c1525a87b94a
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/673063
Fuchsia-Auto-Submit: Clayton Wilkinson <wilkinsonclay@google.com>
Commit-Queue: Clayton Wilkinson <wilkinsonclay@google.com>
Reviewed-by: Dave Schuyler <dschuyler@google.com>
vsrinivas pushed a commit that referenced this pull request Oct 13, 2022
For the cherry-pick, there are a handful of small changes to this branch
that don't exist at TOT:

There is a test file in zircon that does not have proper license header
information: zircon/system/ulib/utf_conversion/test/utf_conversion-fuzzer.cc
It doesn't have this problem at TOT. I've added this file to the
skiplist in this branch.

There are a few license texts that exist here that do not exist at TOT:
antlr, lite and vmac patterns in
//tools/check-licenses/license/pattern/approved/ToCategorize/.*

There is a typo in the VP9 coefficient project name, so I updated it's
readme.fuchsia file. I will do the same at TOT in a future CL.

Otherwise, all other changes are exactly the same as TOT

============

I checked the static_check recipe: it provides two arguments:
* gn_path (which check_licenses doesn't use in this case, because a notice file is not generated during static-checks)
* config (which points to the wrong file currently, and isn't even needed anymore since the path to the default config is baked into the code)

I have updated the code to ignore the config arg for the time being.
After this is submitted, I'll update static-checks to remove that flag,
and then re-update this code to use the arg again.

============

This deletes a bunch of files in the root check-licenses dir that are
no longer being used.

Updates config.go to use the v2 fields / structs

Updates cmd/main.go to only use the args that we use (or are being used
elsewhere currently so can't be removed in this CL).

Runtime is about 3.5 minutes. I verified that it detects malformed
headers in the root Fuchsia project, so there shouldn't be any
disruption in functionality.

-> fx check-licenses
Initializing... Done. [1.304883669s]
Discovering files and folders... Done. [3.540097747s]
Searching for license texts [1241 projects]... Done. [2m35.292414502s]
Saving results... Done. [53.155829402s]

Total runtime: 3m33.29343529s
============

License Metrics:
  Number of Unique License Patterns: 211
  Number of Unused Patterns: 72

Project Metrics:
  Duplicate README.fuchsia Files: 38
  Initialized Custom Project Count: 421
  Initialized Custom Project Retrieval Count: 419
  Project Count: 1241
  Projects Missing License Files: 67
  Projects Missing Names: 24
  Unexpected Line Found In README.fuchsia File: 284

File Metrics:
  All Files: 241654
  Files that may have license information: 130724
  Files that were access multiple times during traversal: 8312

Filetree Metrics:
  File Count: 254779
  Files Missing Projects: 14194
  Folder Count: 33185
  Folders Missing Projects: 1008
  Skipped Items: 1175

Result Metrics:
  Number of initialized templates: 8

Filtering projects to the entire workspace using `gn gen`
724 projects remain (filtered out 517 from the full list of 1241 projects).

 ⦿ Executed template -> /tmp/check-licenses/out/summary.csv (+ *.gz)
 ⦿ Executed template -> /tmp/check-licenses/out/summary_diff.csv (+ *.gz)
 ⦿ Executed template -> /tmp/check-licenses/out/license_texts_grouped_by_project.txt (+ *.gz)
 ⦿ Executed template -> /tmp/check-licenses/out/license_texts_grouped_by_project_deduped.txt (+ *.gz)
 ⦿ Executed template -> /tmp/check-licenses/out/license_all_grouped_by_license_pattern_deduped.txt (+ *.gz)
 ⦿ Executed template -> /tmp/check-licenses/out/license_meta_grouped_by_license_pattern_deduped.txt (+ *.gz)
 ⦿ Executed template -> /tmp/check-licenses/out/license_texts_grouped_by_license_pattern_deduped.txt (+ *.gz)
 ⦿ Executed template -> /tmp/check-licenses/out/license_texts_grouped_by_license_pattern_deduped.html (+ *.gz)

Full summary and output files -> /tmp/check-licenses

Bug: 95548, 94409, 94506, 94517

Change-Id: I73edeeb8c2cd13f85b55f3b425f4e410a65d1b70
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/667506
Reviewed-by: Sean Cuff <seancuff@google.com>
Commit-Queue: Jerry Belton <jcecil@google.com>
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 <sanjayc@google.com>
Reviewed-by: Charles Whitten <cwhitten@google.com>
Commit-Queue: Alexander Biggs <akbiggs@google.com>
vsrinivas pushed a commit that referenced this pull request Nov 23, 2022
This CL makes fidlc consider a versioned table or union member as being
reserved outside its availability, i.e. before it was added and after it
was removed.

For context, FIDL requires listing reserved fields explicitly:

    type Foo = table {
        1: reserved; // used to be `b bool`, then we removed it
        2: string s;
    };

There are two reasons for this:

1. We require ordinals to be dense (for performance reasons for tables,
   and stylistic reasons for unions). If you remove the first field, you
   need some way of filling the gap so that it's still dense.

2. It's a visual reminder not to reuse a field after removing it, since
   that would break ABI for old clients still expecting the old type.

Because the density check happens after decomposition, you ended up
having to write this when using versioning:

    type Foo = table {
        @available(removed=5) 1: b bool;  // line A
        @available(added=5) 1: reserved;  // line B
        2: string s;
    };

In other words, the Foo[5,+inf) table doesn't know about line A and
complains that you must add line B to fill the gap. But line A already
serves purposes #1 and #2 above, so we shouldn't need to do this. This
CL implements that, so that line B is implied and you can omit it.

(Note for posterity: reserved fields were designed and implemented
before versioning. They're part of the older, less formal evolution
features of FIDL that are being partly superseded by versioning. If we
were designing tables and unions today, we might not introduce the
concept of reserved fields at all.)

Fixed: 112059
Test: fx test fidlc-test
Change-Id: I75e0a513f24625174b4a097fc6e1fb2f93ceaada
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/740430
Reviewed-by: Yifei Teng <yifeit@google.com>
Commit-Queue: Mitchell Kember <mkember@google.com>
Reviewed-by: Ian McKellar <ianloic@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants