chrome crashing in with-browser image, in podman and kubernetes

[audacioustux]

Brief summary

Faced this problem in Kubernetes(v1.28, k3s, k6-operator) first. The image works fine in docker but failing on Podman (with and without --privileged) and Kubernetes.

k6 version

v0.49.0 (commit/b5328aa782, go1.21.6, linux/arm64)

OS

oracle linux, amazon linux

Docker version and image (if applicable)

4.6.1 <- podman

Steps to reproduce the problem

• Use any sample k6 script:

  import { browser } from 'k6/experimental/browser'
  import { Rate } from 'k6/metrics';
  
  export const options = {
    scenarios: {
      ui: {
        executor: "ramping-vus",
        stages: [
          { duration: "1m", target: 5 },
        ],
        options: {
          browser: {
            type: 'chromium',
          },
        },
      },
    },
    thresholds: {
      iteration_duration: [{ threshold: 'p(95)<60000', abortOnFail: true }],
    }
  }
  
  export default async function () {
    const page = browser.newPage()
  
    try {
      await page.goto('https://test.k6.io/my_messages.php')
    } finally {
      page.close()
    }
  }

• run docker run --rm -v "$PWD:/k6" ghcr.io/grafana/k6:latest-with-browser run /k6/script.js

Expected behaviour

Browser tests should run in rootless environments and kubernetes

Actual behaviour

Crash with process with PID 14 unexpectedly ended: signal: trace/breakpoint trap (core dumped)

[Phil1602]

Hi,
we are facining similiar problems when using k6-operator to run these browser based k6 images and our testcases in Kubernetes.

However, we were able to run the same code/testcase as a standalone Pod (basically using the same Image and properties, but without the additional k6 operator logic for segmentation and synchronisation).

So - at least from our side - it looks like specific options (execution segmentation, paused or k6 operators) seems to cause this, but we were not yet able to reproduce this without using k6-operator.

@audacioustux were you able to gather new information about this? Thanks!

Even though the execution environment is different, this might be related to #4370 as well.

[audacioustux]

@audacioustux were you able to gather new information about this? Thanks!

Hi,
Nope, didn't look into it later