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

Bump urllib3 from 1.9.1 to 1.26.5 in /testing/mozharness #5

Closed

Conversation

dependabot[bot]
Copy link

@dependabot dependabot bot commented on behalf of github Jun 1, 2021

Bumps urllib3 from 1.9.1 to 1.26.5.

Release notes

Sourced from urllib3's releases.

1.26.5

⚠️ IMPORTANT: urllib3 v2.0 will drop support for Python 2: Read more in the v2.0 Roadmap

  • Fixed deprecation warnings emitted in Python 3.10.
  • Updated vendored six library to 1.16.0.
  • Improved performance of URL parser when splitting the authority component.

If you or your organization rely on urllib3 consider supporting us via GitHub Sponsors

1.26.4

⚠️ IMPORTANT: urllib3 v2.0 will drop support for Python 2: Read more in the v2.0 Roadmap

  • Changed behavior of the default SSLContext when connecting to HTTPS proxy during HTTPS requests. The default SSLContext now sets check_hostname=True.

If you or your organization rely on urllib3 consider supporting us via GitHub Sponsors

1.26.3

⚠️ IMPORTANT: urllib3 v2.0 will drop support for Python 2: Read more in the v2.0 Roadmap

  • Fixed bytes and string comparison issue with headers (Pull #2141)

  • Changed ProxySchemeUnknown error message to be more actionable if the user supplies a proxy URL without a scheme (Pull #2107)

If you or your organization rely on urllib3 consider supporting us via GitHub Sponsors

1.26.2

⚠️ IMPORTANT: urllib3 v2.0 will drop support for Python 2: Read more in the v2.0 Roadmap

  • Fixed an issue where wrap_socket and CERT_REQUIRED wouldn't be imported properly on Python 2.7.8 and earlier (Pull #2052)

1.26.1

⚠️ IMPORTANT: urllib3 v2.0 will drop support for Python 2: Read more in the v2.0 Roadmap

  • Fixed an issue where two User-Agent headers would be sent if a User-Agent header key is passed as bytes (Pull #2047)

1.26.0

⚠️ IMPORTANT: urllib3 v2.0 will drop support for Python 2: Read more in the v2.0 Roadmap

  • Added support for HTTPS proxies contacting HTTPS servers (Pull #1923, Pull #1806)

  • Deprecated negotiating TLSv1 and TLSv1.1 by default. Users that still wish to use TLS earlier than 1.2 without a deprecation warning should opt-in explicitly by setting ssl_version=ssl.PROTOCOL_TLSv1_1 (Pull #2002) Starting in urllib3 v2.0: Connections that receive a DeprecationWarning will fail

  • Deprecated Retry options Retry.DEFAULT_METHOD_WHITELIST, Retry.DEFAULT_REDIRECT_HEADERS_BLACKLIST and Retry(method_whitelist=...) in favor of Retry.DEFAULT_ALLOWED_METHODS, Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT, and Retry(allowed_methods=...) (Pull #2000) Starting in urllib3 v2.0: Deprecated options will be removed

... (truncated)

Changelog

Sourced from urllib3's changelog.

1.26.5 (2021-05-26)

  • Fixed deprecation warnings emitted in Python 3.10.
  • Updated vendored six library to 1.16.0.
  • Improved performance of URL parser when splitting the authority component.

1.26.4 (2021-03-15)

  • Changed behavior of the default SSLContext when connecting to HTTPS proxy during HTTPS requests. The default SSLContext now sets check_hostname=True.

1.26.3 (2021-01-26)

  • Fixed bytes and string comparison issue with headers (Pull #2141)

  • Changed ProxySchemeUnknown error message to be more actionable if the user supplies a proxy URL without a scheme. (Pull #2107)

1.26.2 (2020-11-12)

  • Fixed an issue where wrap_socket and CERT_REQUIRED wouldn't be imported properly on Python 2.7.8 and earlier (Pull #2052)

1.26.1 (2020-11-11)

  • Fixed an issue where two User-Agent headers would be sent if a User-Agent header key is passed as bytes (Pull #2047)

1.26.0 (2020-11-10)

  • NOTE: urllib3 v2.0 will drop support for Python 2. Read more in the v2.0 Roadmap <https://urllib3.readthedocs.io/en/latest/v2-roadmap.html>_.

  • Added support for HTTPS proxies contacting HTTPS servers (Pull #1923, Pull #1806)

  • Deprecated negotiating TLSv1 and TLSv1.1 by default. Users that still wish to use TLS earlier than 1.2 without a deprecation warning

... (truncated)

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 close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor 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.

Bumps [urllib3](https://github.com/urllib3/urllib3) from 1.9.1 to 1.26.5.
- [Release notes](https://github.com/urllib3/urllib3/releases)
- [Changelog](https://github.com/urllib3/urllib3/blob/main/CHANGES.rst)
- [Commits](urllib3/urllib3@1.9.1...1.26.5)

---
updated-dependencies:
- dependency-name: urllib3
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot bot added dependencies Pull requests that update a dependency file python Pull requests that update Python code labels Jun 1, 2021
jamienicol pushed a commit that referenced this pull request Jun 9, 2021
Here's what's going on (relevant browser is browser 36).

[rr 502130 274898]RestoreDocShellState(browser=36, bc=94, )
[rr 502130 274902]RemoteWebNavigation.currentURI browser=36 bc=94 http://mochi.test:8888/#1
[rr 502130 274906]BrowsingContext::LoadURI(browser=36, bc=94, about:blank)

  From a previous restore we correctly wait for:

    0 _restoreTabContent(    <Failed to get argument while inspecting stack frame>
      <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":5984:30]
        <failed to get 'this' value>
    1 _sendRestoreTabContent(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":6002:11]
        <failed to get 'this' value>
    2 restoreTabContent(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4684:9]
        <failed to get 'this' value>
    3 restoreTab(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4565:13]
        <failed to get 'this' value>
    4 restoreTabs(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    aSelectTab = "1") ["resource:///modules/sessionstore/SessionStore.jsm":4413:11]
        <failed to get 'this' value>
    5 ssi_restoreWindow(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4189:11]
        <failed to get 'this' value>
    6 _restoreWindowsFeaturesAndTabs(    <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4275:11]
        <failed to get 'this' value>
    7 _restoreWindowsInReversedZOrder(    <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4299:9]
        <failed to get 'this' value>
    8 ssi_restoreWindows/<(    <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4359:11]

[rr 502506 275264]BrowsingContext::LoadURI(browser=36, bc=94, about:blank)
[rr 502506 275268]DocumentChannelChild::AsyncOpen(browser=36, bc=94, about:blank)
[rr 502130 275388]RemoteWebNavigation.currentURI browser=36 bc=94 http://mochi.test:8888/#1
[rr 502506 275629]BrowserChild::OnLocationChange(browser=36, bc=94, about:blank)
[rr 502130 276944]updateForLocationChange browser=36 bc=94 - about:blank
[rr 502130 277084]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 277358]RestoreDocShellState(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502506 277378]BrowserChild::OnLocationChange(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502130 277390]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 277554]BrowserParent::LoadURL(browser=36, bc=94, about:blank)

From:

    #18 0x00007ff0bdb1efcc in mozilla::dom::BrowserParent::LoadURL(nsDocShellLoadState*) (this=0x7ff08f2b9800, aLoadState=0x7ff094e1d580) at /home/emilio/src/moz/gecko/dom/ipc/BrowserParent.cpp:861
    #19 0x00007ff0bc1117f9 in nsFrameLoader::ReallyStartLoadingInternal() (this=0x7ff08f283400) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoader.cpp:718
    #20 0x00007ff0bc11129f in nsFrameLoader::ReallyStartLoading() (this=0x7ff08f283400) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoader.cpp:640
    #21 0x00007ff0bc0002f5 in mozilla::dom::Document::MaybeInitializeFinalizeFrameLoaders() (this=0x7ff0a17e2000) at /home/emilio/src/moz/gecko/dom/base/Document.cpp:9008
    #22 0x00007ff0bc057891 in mozilla::detail::RunnableMethodArguments<>::applyImpl<mozilla::dom::Document, void (mozilla::dom::Document::*)()>(mozilla::dom::Document*, void (mozilla::dom::Document::*)(), mozilla::Tuple<>&, std::integer_sequence<unsigned long>) (o=<optimized out>, m=<optimized out>, args=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1150
    #23 mozilla::detail::RunnableMethodArguments<>::apply<mozilla::dom::Document, void (mozilla::dom::Document::*)()>(mozilla::dom::Document*, void (mozilla::dom::Document::*)()) (this=<optimized out>, o=<optimized out>, m=<optimized out>)
        at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1156
    #24 mozilla::detail::RunnableMethodImpl<mozilla::dom::Document*, void (mozilla::dom::Document::*)(), true, (mozilla::RunnableKind)0>::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1203
    #25 0x00007ff0bbef8209 in nsContentUtils::RemoveScriptBlocker() () at /home/emilio/src/moz/gecko/dom/base/nsContentUtils.cpp:5696
    #26 0x00007ff0bc11c427 in nsAutoScriptBlocker::~nsAutoScriptBlocker() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsContentUtils.h:3499
    #27 nsFrameLoaderOwner::ChangeRemotenessCommon(nsFrameLoaderOwner::ChangeRemotenessContextType const&, mozilla::dom::RemotenessChangeOptions const&, bool, bool, mozilla::dom::BrowsingContextGroup*, std::function<void ()>&, mozilla::ErrorResult&) (this=<optimized out>, this@entry=0x7ff0a041b608, aContextType=@0x7ffe238847fc: nsFrameLoaderOwner::ChangeRemotenessContextType::PRESERVE, aOptions=
        ..., aSwitchingInProgressLoad=false, aIsRemote=<optimized out>, aGroup=<optimized out>, aGroup@entry=0x0, aFrameLoaderInit=..., aRv=...) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoaderOwner.cpp:191
    #28 0x00007ff0bc11c81f in nsFrameLoaderOwner::ChangeRemoteness(mozilla::dom::RemotenessOptions const&, mozilla::ErrorResult&) (this=0x7ff0a041b608, aOptions=..., rv=...) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoaderOwner.cpp:250
    #29 0x00007ff0bcb59003 in mozilla::dom::XULFrameElement_Binding::changeRemoteness(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&)Traceback (most recent call last):
      File "/home/emilio/src/moz/gecko/js/src/gdb/mozilla/Root.py", line 55, in to_string
        ptr = ptr.dereference()
    gdb.error: value has been optimized out
     (cx_=<optimized out>, obj=
    , void_self=<optimized out>, args=...) at XULFrameElementBinding.cpp:513
    #30 0x00007ff0bcecc02a in mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) (cx=0x1,
        cx@entry=0x7ff0a871b000, argc=<optimized out>, vp=<optimized out>) at /home/emilio/src/moz/gecko/dom/bindings/BindingUtils.cpp:3297
    #31 0x00007ff0bf67b1f1 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)

From:

    0 updateBrowserRemoteness(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["chrome://browser/content/tabbrowser.js":1937:15]
        <failed to get 'this' value>
    1 updateBrowserRemotenessByURL(    <Failed to get argument while inspecting stack frame>
    aURL = ""http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html"") ["chrome://browser/content/tabbrowser.js":2052:20]
        <failed to get 'this' value>
    2 restoreTabContent(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4662:38]
        <failed to get 'this' value>
    3 restoreTab(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4565:13]
        <failed to get 'this' value>
    4 restoreTabs(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    aSelectTab = "2") ["resource:///modules/sessionstore/SessionStore.jsm":4413:11]
        <failed to get 'this' value>
    5 ssi_restoreWindow(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4189:11]
        <failed to get 'this' value>
    6 _restoreWindowsFeaturesAndTabs(    <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4275:11]
        <failed to get 'this' value>
    7 _restoreWindowsInReversedZOrder(    <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4299:9]
        <failed to get 'this' value>
    8 ssi_restoreWindows/<(    <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4359:11]

This load triggers a remoteness change.

[rr 502130 277558]RemoteWebNavigation.currentURI browser=36 bc=94 undefined
[rr 502130 277561]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 277564]RestoreDocShellState(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502130 277568]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 277572]BrowsingContext::LoadURI(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)

This is the load that should actually end up in the browsing context.

[rr 502578 280053]DocumentChannelChild::AsyncOpen(browser=36, bc=94, about:blank)

From the previous remoteness update.

[rr 502130 280138]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 280141]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 280143]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 280146]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank

At this point, we try to use the BFCache, and end up replacing the
browsing context:

    #0  mozilla::dom::CanonicalBrowsingContext::AllowedInBFCache(mozilla::Maybe<unsigned long> const&) (this=0x7ff08f2b5800, aChannelId=...) at /home/emilio/src/moz/gecko/docshell/base/CanonicalBrowsingContext.cpp:2158
    #1  0x00007ff0bb3157c1 in mozilla::net::DocumentLoadListener::MaybeTriggerProcessSwitch(bool*) (this=this@entry=0x7ff093b74090, aWillSwitchToRemote=aWillSwitchToRemote@entry=0x7ffe23887838)
        at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:1723
    #2  0x00007ff0bb317feb in mozilla::net::DocumentLoadListener::OnStartRequest(nsIRequest*) (this=0x7ff093b74090, aRequest=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:2263
    #3  0x00007ff0bb238a0c in mozilla::net::ParentChannelListener::OnStartRequest(nsIRequest*) (this=0x7ff08d5c4ee0, aRequest=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/protocol/http/ParentChannelListener.cpp:91
    #4  0x00007ff0bb9abec2 in nsDocumentOpenInfo::OnStartRequest(nsIRequest*) (this=<optimized out>, request=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:166
    #5  0x00007ff0bb32baf0 in mozilla::net::ParentProcessDocumentOpenInfo::OnDocumentStartRequest(nsIRequest*) (this=0x7ff093bc5b80, request=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:292
    #6  0x00007ff0bae6446c in nsBaseChannel::OnStartRequest(nsIRequest*) (this=<optimized out>, request=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/base/nsBaseChannel.cpp:833
    #7  0x00007ff0bae82bdd in nsInputStreamPump::OnStateStart() (this=this@entry=0x7ff08f2593c0) at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:481
    #8  0x00007ff0bae828d9 in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (this=0x7ff08f2593c0, stream=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:390
    #9  0x00007ff0bae8339b in non-virtual thunk to nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) () at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:632
    #10 0x00007ff0bacd29d5 in mozilla::NonBlockingAsyncInputStream::RunAsyncWaitCallback(mozilla::NonBlockingAsyncInputStream::AsyncWaitRunnable*, already_AddRefed<nsIInputStreamCallback>)
        (this=this@entry=0x7ff094eb5a50, aRunnable=aRunnable@entry=0x7ff08f228560, aCallback=...) at /home/emilio/src/moz/gecko/xpcom/io/NonBlockingAsyncInputStream.cpp:397
    #11 0x00007ff0bacdf2ec in mozilla::NonBlockingAsyncInputStream::AsyncWaitRunnable::Run() (this=0x7ff08f228560) at /home/emilio/src/moz/gecko/xpcom/io/NonBlockingAsyncInputStream.cpp:33
    #12 0x00007ff0bad48d04 in mozilla::RunnableTask::Run() (this=0x7ff093bc5980) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:482
    #13 0x00007ff0bad316d4 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (this=<optimized out>, this@entry=0x7ff0c54f2400, aProofOfLock=...)
        at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:766
    #14 0x00007ff0bad3091d in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (this=this@entry=0x7ff0c54f2400, aProofOfLock=...)
        at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:621
    #15 0x00007ff0bad30a83 in mozilla::TaskController::ProcessPendingMTTask(bool) (this=0x7ff0c54f2400, aMayWait=false) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:405
    #16 0x00007ff0bad4388f in mozilla::TaskController::InitializeInternal()::$_0::operator()() const (this=<optimized out>) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:138
    #17 mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_0>::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:534
    #18 0x00007ff0bad3b7f6 in nsThread::ProcessNextEvent(bool, bool*) (this=0x7ff0c541d680, aMayWait=false, aResult=0x7ffe23888437) at /home/emilio/src/moz/gecko/xpcom/threads/nsThread.cpp:1159
    #19 0x00007ff0bad3f384 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x7ff08f2b5800, aThread@entry=0x7ff0c541d680, aMayWait=false) at /home/emilio/src/moz/gecko/xpcom/threads/nsThreadUtils.cpp:548
    #20 0x00007ff0bb43dfe0 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7ff0c54d12c0, aDelegate=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/glue/MessagePump.cpp:85
    #21 0x00007ff0bb3be7b7 in MessageLoop::RunInternal() (this=this@entry=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:335
    #22 0x00007ff0bb3be707 in MessageLoop::RunHandler() (this=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:328
    #23 MessageLoop::Run() (this=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:310
    #24 0x00007ff0bded2bdb in nsBaseAppShell::Run() (this=0x7ff0a880c580) at /home/emilio/src/moz/gecko/widget/nsBaseAppShell.cpp:137
    #25 0x00007ff0bf449d85 in nsAppStartup::Run() (this=0x7ff0a883de20) at /home/emilio/src/moz/gecko/toolkit/components/startup/nsAppStartup.cpp:273
    #26 0x00007ff0bf5428b6 in XREMain::XRE_mainRun() (this=<optimized out>, this@entry=0x7ffe238887c0) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5239
    #27 0x00007ff0bf5433ef in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (this=this@entry=0x7ffe238887c0, argc=argc@entry=5, argv=argv@entry=0x7ffe23889a68, aConfig=<optimized out>)
        at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5437
    #28 0x00007ff0bf54385e in XRE_main(int, char**, mozilla::BootstrapConfig const&) (argc=-1816706824, argv=0x7ff0c56441a0, aConfig=...) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5496
    #29 0x0000562d08f8e415 in do_main(int, char**, char**) (argc=-1816706824, argv=0x7ffe23889a68, envp=<optimized out>) at /home/emilio/src/moz/gecko/browser/app/nsBrowserApp.cpp:224

[rr 502130 280199]CanonicalBrowsingContext::ReplacedBy(94 -> 104)
[rr 502130 280344]didChangeRemoteness browser=36, bc=104
[rr 502130 280348]RemoteWebNavigation.currentURI browser=36 bc=104 undefined
[rr 502130 280625]RedirectToRealChannel(36, about:blank)
[rr 502578 280695]BrowserChild::OnLocationChange(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502578 280699]BrowsingContext::LoadURI(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502578 280703]DocumentChannelChild::AsyncOpen(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)

    This is the LoadURI call for the "final" load, however it went to
    the wrong browsing context, as we just replaced this!

[rr 502130 280803]updateForLocationChange browser=36 bc=104 - http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html
[rr 502130 280807]RemoteWebNavigation.currentURI browser=36 bc=104 http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html
[rr 502578 281334]BrowserChild::OnLocationChange(browser=36, bc=104, about:blank)

    And this one is from the process switch.

[rr 502130 281461]updateForLocationChange browser=36 bc=104 - about:blank
[rr 502130 281465]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank
[rr 502130 282028]
ⰲ겿{"action":"test_status","time":1621467211822,"thread":null,"pid":null,"source":"mochitest","test":"chrome://mochitests/content/browser/browser/base/content/test/tabs/browser_new_tab_insert_position.js","subtest":"tab pos 0 matched http://mochi.test:8888/#0","status":"PASS","message":"","js_source":"TestRunner.js"}ⰲ겿
[rr 502130 282031]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank
[rr 502130 282033]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank
[rr 502130 282117]

So this is certainly the easy fix, but I think we should generally try
to deal with this better, somehow?

Differential Revision: https://phabricator.services.mozilla.com/D115560
jamienicol pushed a commit that referenced this pull request Nov 24, 2021
…login manager marks an focus field. r=tgiles

In nsAutocompleteController::HandleKeyNavigation, we might trigger a search operation (or open the popup)
However, when we find there is already a search result received previously, and the search string is the same
as the current one, we won't trigger a new search[1] because the result should be the same.
This might be true for most of the cases, but not true when clients that perform the search is differnt.
As far as I know, there are at least 3 different autocomplete clients: form history, CC/Address autocomplete, and login manager.
For example, the same search string might return a different result when it is searched by the login manager
and by the form history component.

Here is how the intermittent occurs:
1. The page is loaded
2. Password field is detected so the login manager fetches the login data from the parent asynchronously
3. The testcase continues to run. The username field is focused
4. Autocomplete search for the focus field is triggered. Since the login manager has not yet told FormFillController
   this is a field we care, we search the form history and get an empty result.
5. Login data is sent from parent to child, _fillForm is called. The LoginManagerChild calls `MarkAsLoginManagerField`
6. Key event occurs on the field. Autocomplete search is triggered again. However, the search is not executed because
   [1]
7. Popup is not shown. Testcase timeout.

When #5 occurs before #3, the autocomplete search in #4 will be processed by the login manager, and we will get the result
and open the popup in this case

In the current architecture, I don't see an easy way that we can distinguish whether the autocomplete client is different
in nsAutocompleteController. So instead of doing it in nsAutocompleteController, this patch fixes this issue in FormFillController.

In FormFillController, when we call `MarkAsLoginManagerField` on a focus field, we call ResetInternalState() to
tell nsAutocompleteController to clear previous search result.

[1] https://searchfox.org/mozilla-central/rev/fb8d77331582639ea6848a61dd8ee812fac31b77/toolkit/components/autocomplete/nsAutoCompleteController.cpp#516-521

Differential Revision: https://phabricator.services.mozilla.com/D131237
@jamienicol jamienicol closed this Mar 4, 2022
@jamienicol jamienicol deleted the dependabot/pip/testing/mozharness/urllib3-1.26.5 branch March 4, 2022 16:37
@dependabot @github
Copy link
Author

dependabot bot commented on behalf of github Mar 4, 2022

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.

jamienicol pushed a commit that referenced this pull request Jan 3, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/6ced79beecdf6ec669840f3ca9d9695cfdbf9376
    Add additional checks in case of early portal error

    In case ScreenCast portal fails right at the beginning, we need to check
    the response before trying to get session handle to avoid accessing
    non-existing portal data.

    Also on early failure do not continue making source request if we failed
    before and don't have session handle.

    (cherry picked from commit 65a9a515b51be1050bbb6fcb1edfbdff706434bf)

    Bug: webrtc:13429, chromium:1363783
    Change-Id: I2bfbd2c6e96e3cda1e62aa9dc07f66d4c7496b53
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272400
    Reviewed-by: Alexander Cooper <alcooper@chromium.org>
    Reviewed-by: Mark Foltz <mfoltz@chromium.org>
    Commit-Queue: Mark Foltz <mfoltz@chromium.org>
    Cr-Original-Commit-Position: refs/heads/main@{#37872}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275961
    Commit-Queue: Alexander Cooper <alcooper@chromium.org>
    Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/5249@{#5}
    Cr-Branched-From: 7aaeb5a270ba23f5844f7301a50aaff9b6ca6126-refs/heads/main@{#37825}
jamienicol pushed a commit that referenced this pull request Jan 25, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/64edb15e1e5bb86bbcb78f0e8be0a6559097f3f3
    Make P2PTransportChannel implement IceAgentInterface (#5/n)

    This functionally no-op change adds the methods to allow an active ICE controller to manipulate the connection used by the ICE transport. Most methods reuse existing code, this will be explicitly marked for cleanup with a follow-up CL which adds active ICE controller support.

    Non-trivial changes are needed for P2PTransportChannel unit tests to cover the new code, and these are also being added in a follow-up CL.

    Bug: webrtc:14367, webrtc:14131
    Change-Id: I4f012efcd8cb5766eb8c6f0872de50f8375f3a73
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275301
    Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
    Commit-Queue: Sameer Vijaykar <samvi@google.com>
    Cr-Commit-Position: refs/heads/main@{#38081}
jamienicol pushed a commit that referenced this pull request Jan 25, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/4005adc6d639035fdd5323861d9a2fc6bd946e99
    [M107] ice: include tiebreaker in computation of foundation attribute

    the foundation attribute is currently calculated as
      CRC32(baseaddress, protocol, relayprotocol)
    which is a way to satisfy the requirements from
      https://www.rfc-editor.org/rfc/rfc5245#section-4.1.1.3

    However, this leaks the base address which defeats the
    MDNS obfuscation described in
      https://datatracker.ietf.org/doc/draft-ietf-mmusic-mdns-ice-candidates/
    since the CRC32 can be reversed using a table lookup as shown in
      https://github.com/niespodd/webrtc-local-ip-leak/

    To defeat that lookup, "seed" the CRC32 with the ICE tie-breaker which is a randomly picked unsigned 64 bit integer described in
      https://www.rfc-editor.org/rfc/rfc5245#section-5.2

    The tie-breaker is not known to Javascript and adding it scopes the foundation within the peer connection as described in section 4.1.1.3

    To manually test (preferably with a DCHECK for IceTiebreaker() in ComputeFoundation)
    - gather candidates twice on https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ and observe that the foundations are not the same after this change
    - create two RTCPeerConnections with {iceCandidatePoolSize: 1}, create a datachannel, call setLocalDescription, inspect the candidates and observe that the foundations are not the same after this change.

    Unit test changes have been split into a separate CL for easier integration.

    BUG=webrtc:14605,chromium:1378916

    (cherry picked from commit 08b882d762edadb9797334859d915c5c1e34896b)

    Change-Id: I6bbad1635b48997b00ae74d251ae357bf8afd12f
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280621
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
    Commit-Queue: Harald Alvestrand <hta@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#38485}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281421
    Commit-Queue: Philipp Hancke <phancke@microsoft.com>
    Cr-Commit-Position: refs/branch-heads/5304@{#5}
    Cr-Branched-From: 024bd84ca1cf7d3650c27912a3b5bfbb54da152a-refs/heads/main@{#38083}
jamienicol pushed a commit that referenced this pull request Feb 20, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/93081d594f7efff72958a79251f53731b99e902b
    [Merge M108] Ensure video frame buffer is still decodable before decoding

    This ensures that if for some reason, the frame buffer becomes
    undecodable while waiting to decode a frame, the decoding is halted.
    This also guards against receiving an empty temporal unit from the frame
    buffer, even though this should never happen when the frame buffer has a
    decodable temporal unit.

    (cherry picked from commit 8fe5579136c82b558022fe7d1393fa248b151eae)

    Bug: chromium:1378253, chromium:1361623
    Change-Id: I8c4c897bf474d5cbda5f0f357781bf1dc0701fe4
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280701
    Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
    Reviewed-by: Erik Språng <sprang@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#38494}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281720
    Cr-Commit-Position: refs/branch-heads/5359@{#5}
    Cr-Branched-From: fb3bd4a01d7c840dfe7b3efa144c0fbcb6a97fef-refs/heads/main@{#38387}
jamienicol pushed a commit that referenced this pull request Aug 7, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/a624ee1be7a11e795a849edb2a27dc1137d2b63d
    [M114] Avoid touching channel after OnSctpDataChannelClosed

    (cherry picked from commit eec1810760ccbdf95c68ed0d2c2ae10a8575551a)

    Bug: chromium:1454086
    Change-Id: I39573b706c4031d091c45a182b13cb3b2dba6233
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309920
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#40332}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310922
    Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/5735@{#5}
    Cr-Branched-From: df7df199abd619e75b9f1d9a7e12fc3f3f748775-refs/heads/main@{#39949}
jamienicol pushed a commit that referenced this pull request Aug 31, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/6603550a4279b4b68b8b763523370dc8e010500c
    [Merge-M115] Support conversion of VP9 non-flexible mode to generic descriptor for non-layered streams only.

    When VP9 HW encoders don't provide any metadata a minimal non-flexible mode structure is generated for the stream: (https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:third_party/blink/renderer/platform/peerconnection/rtc_video_encoder.cc;l=1275-1298;drc=f80633b34538615fcb73515ad8c4bc56a748abfe).

    (cherry picked from commit 4e0bf2e5a1946b8f94f4b23b57b3e89a25fce65d)

    Bug: chromium:1455428, b/286993839, b/287458300
    Change-Id: I72628f20927d685e9c8ba1744126d763896bd804
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309380
    Commit-Queue: Philip Eliasson <philipel@webrtc.org>
    Reviewed-by: Erik Språng <sprang@webrtc.org>
    Reviewed-by: Henrik Boström <hbos@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#40316}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309921
    Commit-Queue: Henrik Boström <hbos@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/5790@{#5}
    Cr-Branched-From: 2eacbbc03a4a41ea658661225eb1c8fc07884c33-refs/heads/main@{#40122}
jamienicol pushed a commit that referenced this pull request Oct 3, 2023
We already cherry-picked this when we vendored 8fbabf340d.

Upstream commit: https://webrtc.googlesource.com/src/+/626d408ba5d0ae5b1f6b66a7cf244a85ea66c11e
    [M116] Revert mid check in SdpOfferAnswerHandler::CreateDataChannel.

    This check was added here:
      https://webrtc-review.googlesource.com/c/src/+/300544

    When createOffer is used before createAnswer, this check would cause
    SetupDataChannelTransport_n to not be called for the remote channel.

    (cherry picked from commit 299cdc9057fb8925f1692ac8c7573f51b7872df6)

    Bug: webrtc:15258, chromium:1458937
    Change-Id: Ifdab35d1b0260ff03fef4beff13acf8090d59d8f
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310460
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#40357}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/312123
    Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/5845@{#5}
    Cr-Branched-From: f80cf814353d11a9f22bef5ce5e8868f2c72f0d0-refs/heads/main@{#40319}
jamienicol pushed a commit that referenced this pull request Nov 20, 2023
…chevobbe

Just starting up a debug build you will get 40 copies of this printed.

The uri that we fail to get host of is about:newtab. One stack looks like this

#2: mozilla::BasePrincipal::GetIsLoopbackHost(bool*)
#3: mozilla::net::LoadInfo::LoadInfo(nsIPrincipal*, nsIPrincipal*, nsINode*, unsigned int, nsIContentPolicy::nsContentPolicyType, mozilla::Maybe<mozilla::dom::ClientInfo> const&, mozilla::Maybe<mozilla::dom::ServiceWorkerDescriptor> const&, unsigned int, bool
#4: ShouldLoadCachedImage(imgRequest*, mozilla::dom::Document*, nsIPrincipal*, nsIContentPolicy::nsContentPolicyType, bool)
#5: imgLoader::LoadImage(nsIURI*, nsIURI*, nsIReferrerInfo*, nsIPrincipal*, unsigned long long, nsILoadGroup*, imgINotificationObserver*, nsINode*, mozilla::dom::Document*, unsigned int, nsISupports*, nsIContentPolicy::nsContentPolicyType, nsTSubstring<char16
#6: nsContentUtils::LoadImage(nsIURI*, nsINode*, mozilla::dom::Document*, nsIPrincipal*, unsigned long long, nsIReferrerInfo*, imgINotificationObserver*, int, nsTSubstring<char16_t> const&, imgRequestProxy**, nsIContentPolicy::nsContentPolicyType, bool, bool,
#7: mozilla::css::ImageLoader::LoadImage(mozilla::StyleComputedUrl const&, mozilla::dom::Document&)
#8: mozilla::StyleComputedUrl::ResolveImage(mozilla::dom::Document&, mozilla::StyleComputedUrl const*)
#9: nsStyleImageLayers::ResolveImages(mozilla::dom::Document&, nsStyleImageLayers const*)
#10: mozilla::ComputedStyle::StartImageLoads(mozilla::dom::Document&, mozilla::ComputedStyle const*)

Differential Revision: https://phabricator.services.mozilla.com/D193349
jamienicol pushed a commit that referenced this pull request Mar 4, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/79ba9b0b2b28e49ecc32992ff9163917299beedc
    [M121] Disable the use of CGDisplayStreamCreate() for desktop capture on Sonoma

    CGDisplayStreamCreate is an deprecated API. It was believed that the use
    of it was disabled on Sonoma through the setting allow_iosurface = false
    [1], which causes the thumbnails to be created by the API CGDisplayCreateImage.
    This API is not marked as deprecated at the moment.

    However, although the thumbnails are created through CGDisplayCreateImage,
    CGDisplayStreamCreate() is still called and runs in the background.
    This makes the capture chip appear.

    No capture chip appears if this CL is landed and the ScreenCaptureKit
    thumbnail capturer is enabled,
    --enable-features="ScreenCaptureKitMac,ScreenCaptureKitStreamPickerSonoma,ThumbnailCapturerMac:capture_mode/sc_screenshot_manager"

    [1] https://chromium-review.googlesource.com/c/chromium/src/+/4892397

    (cherry picked from commit fb99c6ebb57754e4b764a63dfae7f62ec272ba6b)

    Bug: chromium:1486851
    No-Try: True
    Change-Id: I3422efffc57dcb3e8965f19a5eca7f2a95d62da1
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/334721
    Reviewed-by: Mark Foltz <mfoltz@chromium.org>
    Commit-Queue: Johannes Kron <kron@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#41563}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/335740
    Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/6167@{#5}
    Cr-Branched-From: ece5cb83715dea85617114b6d4e981fdee2623ba-refs/heads/main@{#41315}
jamienicol pushed a commit that referenced this pull request May 24, 2024
…inting background., a=testonly

Automatic update from web-platform-tests
Get border/padding from fragment when painting background.

Since @page border box layout objects aren't in the the layout tree, any
code that wants to walk up the tree to find the containing block will be
in for a surprise.

This would happen if percentage-based @page padding was used [1].
Recomputing padding during painting when we have already done it during
layout is rather pointless anyway. Read it out directly from the
fragment.

[1] #1 blink::LayoutBox::ContainingBlockLogicalWidthForContent()
    #2 blink::LayoutBoxModelObject::ComputedCSSPadding()
    #3 blink::LayoutBoxModelObject::PaddingTop()
    #4 blink::LayoutBoxModelObject::PaddingOutsets()
    #5 blink::BoxPainterBase::PaintFillLayer()
    #6 blink::BoxPainterBase::PaintFillLayers()
    #7 blink::BoxFragmentPainter::PaintBackground()

Bug: 40286153
Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5526469
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1300711}

--

wpt-commits: 601b701a9d708b48a9cddae1ac15963d61be7964
wpt-pr: 46252
jamienicol pushed a commit that referenced this pull request Aug 21, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/876d0c9881eab8e7f8389812eb3738bdd374aa22
    Fix use-of-uninitialized-value in NetEq tests.

    The new version of MSan (rolled by [1]) detects the following:

    ```
    ==39908==WARNING: MemorySanitizer: use-of-uninitialized-value
        #0 0x5591400a52ef in GetPlayoutDelayMs ./../../modules/audio_coding/neteq/decision_logic.cc:466:35
        #1 0x5591400a52ef in webrtc::DecisionLogic::ExpectedPacketAvailable(webrtc::NetEqController::NetEqStatus) ./../../modules/audio_coding/neteq/decision_logic.cc:311:36
        #2 0x5591400a39e9 in webrtc::DecisionLogic::GetDecision(webrtc::NetEqController::NetEqStatus const&, bool*) ./../../modules/audio_coding/neteq/decision_logic.cc:0:0
        #3 0x55913cf590c9 in webrtc::DecisionLogicTest_PreemptiveExpand_Test::TestBody() ./../../modules/audio_coding/neteq/decision_logic_unittest.cc:139:3
        #4 0x55913ef28283 in HandleExceptionsInMethodIfSupported<testing::Test, void> ./../../third_party/googletest/src/googletest/src/gtest.cc:0:3
        #5 0x55913ef28283 in testing::Test::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:2710:5
        #6 0x55913ef2ab46 in testing::TestInfo::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:2856:11
        #7 0x55913ef2da34 in testing::TestSuite::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:3034:30
        #8 0x55913ef621e8 in testing::internal::UnitTestImpl::RunAllTests() ./../../third_party/googletest/src/googletest/src/gtest.cc:5964:44
        #9 0x55913ef60f54 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> ./../../third_party/googletest/src/googletest/src/gtest.cc:0:0
        #10 0x55913ef60f54 in testing::UnitTest::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:5543:10
        #11 0x55913ee1a944 in RUN_ALL_TESTS ./../../third_party/googletest/src/googletest/include/gtest/gtest.h:2334:73
        #12 0x55913ee1a944 in webrtc::(anonymous namespace)::TestMainImpl::Run(int, char**) ./../../test/test_main_lib.cc:203:21
        #13 0x55913cbd36b8 in main ./../../test/test_main.cc:72:16
        #14 0x7fdb18c73082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16
        #15 0x55913cb3e1a9 in _start ??:0:0
    ```

    [1] - https://webrtc-review.googlesource.com/c/src/+/353620

    Bug: b/344970813
    Change-Id: I9b5d7791e68b4c494168ba9f007a3099ae21fed4
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/353581
    Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
    Reviewed-by: Jakob Ivarsson‎ <jakobi@webrtc.org>
    Commit-Queue: Jakob Ivarsson‎ <jakobi@webrtc.org>
    Cr-Commit-Position: refs/heads/main@{#42433}
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 python Pull requests that update Python code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant