[microsoft/playwright][BUG] 不支持在同一进程中使用 libsoup2 和 libsoup3。

2024-04-09 722 views
1
系统信息
  • 编剧版本:[v1.38.0]
  • 操作系统:Docker 镜像mcr.microsoft.com/playwright:v1.38.0-jammy
  • 浏览器:[WebKit]
  • 其他信息:该图像在 Circle-ci 上运行。相同的图像在 firefox 和 chrome 浏览器中没有问题。我们在本地运行相同的代码没有任何问题。

存在类似的问题并已关闭:https://github.com/microsoft/playwright/issues/26653 此问题应在 Playwright 1.38.0 中修复,但我们仍然有它,但仅限于 safari 浏览器。

如果您克隆存储库,则本地不应出现任何错误,您可以通过运行以下命令进行测试:

$ make bootstrap
$ make e2e

您还可以通过以下链接在circle-ci上检查结果:https://app.circleci.com/pipelines/github/openfun/marsha/14253/workflows/28f88761-d423-43c1-b4c1-4702c879a09f/jobs/421630

libsoup 2 和 3 确实都安装在该映像中:

$ docker run --rm -it mcr.microsoft.com/playwright:v1.38.0-jammy /bin/bash -c "dpkg -l | grep libsoup"
ii  libsoup-3.0-0:amd64                  3.0.7-0ubuntu1                          amd64        HTTP library implementation in C -- Shared library
ii  libsoup-3.0-common                   3.0.7-0ubuntu1                          all          HTTP library implementation in C -- Common files
ii  libsoup2.4-1:amd64                   2.74.2-3                                amd64        HTTP library implementation in C -- Shared library
ii  libsoup2.4-common                    2.74.2-3                                all          HTTP library implementation in C -- Common files

如果libsoup2删除(仅用于测试),它还会删除似乎由 webkit 使用的 gstreamer 插件。

源代码

链接到带有重现的 GitHub 存储库

https://github.com/openfun/marsha/blob/804a873683fa650623e0c48e92313b072d31f3bf/.circleci/config.yml#L620-L747

此提交是此 PR 的一部分:https://github.com/openfun/marsha/pull/2433

预期的

测试套件运行 libsoup 时应该没有问题。 Libsoup 兼容性问题已在 1.38.0 版本中修复,并且在 Firefox 和 Chrome 浏览器中没有此问题。

回答

1

不,我们仅在 Circleci 上复制它。

5

我们在 Jenkins 管道中也遇到同样的问题。我们使用 mcr.microsoft.com/playwright:v1.38.1-jammy 作为基础映像。在我们的 docker 镜像中使用 FROM mcr.microsoft.com/playwright:v1.38.1-jammy RUN apt-get remove -y libsoup2.4 目前可以解决我们的问题。不确定所提到的 gstreamer 插件实际上没有问题,或者在我们的具体用例中是否不需要它们。 (我们也使用 webkit。)

3

是的,有些涉及视频的场景需要gstreamer插件。

4

这确实是我们的情况

4

我在 GitLab CI 中也看到了同样的问题。我们的测试不包括视频(即使我们的应用程序包括),但通过以下方式解决了before_script:(感谢@tobbsel评论?)

playwright_tests:
  stage: e2e-test
  image: mcr.microsoft.com/playwright:v1.38.1-jammy
  before_script:
    - apt-get remove -y libsoup2.4
  script:
    - npm ci
    - npm run test:e2e
1

FWIW 我在 Semaphore CI 中也遇到同样的问题。还使用mcr.microsoft.com/playwright:v1.38.1-jammy

3

使用 Buildkite CI 时也是如此mcr.microsoft.com/playwright:latest。所以看来这个问题即使在1.39版本中也存在。

9

重现步骤:

  1. 创建 Ubuntu 20.04 虚拟机
  2. 安装 Docker 并使用 WebKit 运行 22.04 PW Docker 容器:
    curl -L get.docker.com | sh
    docker run --rm -it mcr.microsoft.com/playwright:v1.39.0-jammy /bin/bash
    cd
    npm init playwright -y testpw
    # Press Enter a few times
    cd testpw
    npx playwright test --project=webkit

预期:有效 实际:无效

    Error: browserType.launch: Browser closed.
    ==================== Browser output: ====================
    <launching> /ms-playwright/webkit-1921/pw_run.sh --inspector-pipe --headless --no-startup-window
    <launched> pid=963
    [pid=963][err] 
    [pid=963][err] (MiniBrowser:985): GStreamer-WARNING **: 13:40:22.894: External plugin loader failed. This most likely means that the plugin loader helper binary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your setup is unusual. This should normally not be required though.
    [pid=963][err] 
    [pid=963][err] (MiniBrowser:985): libsoup-ERROR **: 13:40:23.080: libsoup3 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.
    [pid=963][err] /ms-playwright/webkit-1921/pw_run.sh: line 24:   985 Trace/breakpoint trap   (core dumped) WEBKIT_FORCE_COMPLEX_TEXT="1" "$MINIBROWSER" "$@"
    [pid=963] <process did exit: exitCode=133, signal=null>
    [pid=963] starting temporary directories cleanup
    =========================== logs ===========================
    <launching> /ms-playwright/webkit-1921/pw_run.sh --inspector-pipe --headless --no-startup-window
    <launched> pid=963
    [pid=963][err] 
    [pid=963][err] (MiniBrowser:985): GStreamer-WARNING **: 13:40:22.894: External plugin loader failed. This most likely means that the plugin loader helper binary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your setup is unusual. This should normally not be required though.
    [pid=963][err] 
    [pid=963][err] (MiniBrowser:985): libsoup-ERROR **: 13:40:23.080: libsoup3 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.
    [pid=963][err] /ms-playwright/webkit-1921/pw_run.sh: line 24:   985 Trace/breakpoint trap   (core dumped) WEBKIT_FORCE_COMPLEX_TEXT="1" "$MINIBROWSER" "$@"
    [pid=963] <process did exit: exitCode=133, signal=null>
    [pid=963] starting temporary directories cleanup
    ============================================================

要调查的主要问题:为什么当 Docker Host Ubuntu 版本匹配时它可以工作,而如果是 Ubuntu 20.04 则不起作用?

注意:如果用户运行 Docker 容器,--privileged它将按预期工作。

8

我也遇到过这个问题mcr.microsoft.com/playwright:v1.39.0-jammy

I was able to work around this issue by deleting libsoup2.4 explicitly before starting the e2e tests.

My .gitlab-ci.yml file looks something like this.

script:
    - pnpm install
    - pnpm dlx playwright install --with-deps
    - pnpm dlx playwright install chrome
    - pnpm dlx playwright install msedge
    - apt-get remove -y libsoup2.4 # needed because of https://github.com/microsoft/playwright/issues/27313
    - pnpm e2e # executes playwright test
4

cc @TingPing since you were adding this check in libsoup.

Do you know maybe why there is a difference in loading when using a privileged vs unprivileged Docker container? @dpino and me did some experiments (with strace and LD_DEBUG) and in the privileged one there was no occurrence of libsoup at all which made us wonder why thats the case. First we don't understand how privileged affects module loading of libsoup and second that there is no occurrence of it in the privileged logs. Would appreciate a ton, thanks!

Summary: https://github.com/microsoft/playwright/issues/27313#issuecomment-1782979478

7

I can't imagine any reason that would matter.

The solution is just using the soup module from GStreamer 1.20 or newer as it detects which version of libsoup is in use and only uses that one. Earlier versions could only be built against a single version, thus breaking anything mixing the other version.