sentry with profiling is crashing vitest with free(): invalid next size (fast)

[capaj]

Describe the bug

free(): invalid next size (fast)
Aborted (core dumped)
 ELIFECYCLE  Test failed. See above for more details.

Reproduction

I tried to setup a minimal repro here: https://stackblitz.com/edit/vitest-dev-vitest-1gd3e9?file=src%2Fsentry.ts

but I failed, because profiling integration does not run on stackblitz.
So what you need to do:

1. download from stackblitz
2. extract
3. pnpm i
4. pnpm test
5. hit enter to restart the tests for few seconds(10 times probably+-)

System Info

System:
    OS: Linux 5.15 Ubuntu 22.04.3 LTS 22.04.3 LTS (Jammy Jellyfish)
    CPU: (24) x64 AMD Ryzen 9 5900X 12-Core Processor
    Memory: 41.11 GB / 62.71 GB
    Container: Yes
    Shell: 5.8.1 - /usr/bin/zsh
  Binaries:
    Node: 18.18.0 - ~/.nvm/versions/node/v18.18.0/bin/node
    Yarn: 1.22.19 - ~/.yarn/bin/yarn
    npm: 9.8.1 - ~/.nvm/versions/node/v18.18.0/bin/npm
    pnpm: 8.10.2 - ~/.local/share/pnpm/pnpm
  Browsers:
    Brave Browser: 120.1.61.109

Used Package Manager

pnpm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[capaj]

I even recorded a video of a repro

Screencast.from.5.1.2024.17.53.35.webm

[capaj]

The crash in video has different error message. The one I got with the free(): invalid next size (fast) occured on our github action

[capaj]

FYI I also opened the same bug in sentry repo here: getsentry/profiling-node#228

it seems like it's more likely their fault. They are probably doing all sort of nastyness in the profiling package

[capaj]

but maybe it would be worth adding some kind of a warning if this nastyness can be detected

[AriPerkkio]

Does it reproduce with pool: 'forks'? Prisma had similar crashes since they are not compatible with worker_threads.

[AriPerkkio]

Sentry's crashes can be reproduced without Vitest. Save this as repro.mjs and run the file couple of times.

Node crashes with following errors:

node(47851,0x1769f7000) malloc: *** error for object 0x142efe538: pointer being freed was not allocated
node(47851,0x1769f7000) malloc: *** set a breakpoint in malloc_error_break to debug
Abort trap: 6

Segmentation fault: 11
Bus error: 10

import { Worker, isMainThread } from "node:worker_threads";
import { resolve } from "node:path";

import * as SentryApi from "@sentry/node";
import { ProfilingIntegration } from "@sentry/profiling-node";

if (isMainThread) {
  for (const _ of Array(10).fill()) {
    new Worker(resolve("./repro.mjs"));
  }
} else {
  SentryApi.init({
    integrations: [new ProfilingIntegration()],
  });
}

This is similar issue as with Prisma: #3106

As work-around you can use --pool=forks and Vitest will switch from node:worker_threads to node:child_process. I'm unable to reproduce the crash with forks pool.

[AriPerkkio]

Closing this as the root cause is unrelated to Vitest - see above how to crash Sentry with just Node APIs.

Below are similar issues where third party modules crashed when ran inside node:worker_threads. Most, if not all of those, cases contained modules that were written in native code. All cases worked fine with Vitest's pool: 'forks'.

• Hitting Segmentation fault when running Vitest . #3143
• Vitest crashes when running tests with Prisma #3106
• Getting Node low level errors running vitest #3816
• vitest will crash when using ffi-napi #2091