bun crashed

[projaguar]

How can we reproduce the crash?

No response

Relevant log output

============================================================
Bun v1.1.27 (267afa29) Linux x64 (baseline)
Linux Kernel v5.15.0 | glibc v2.31
CPU: sse42 popcnt avx avx2
Args: "bun" "--bun" "main.js"
Features: jsc Bun.stdin(2) Bun.stdout fetch(1332) http_server tsconfig_paths tsconfig(29) 
Builtins: "bun:main" "detect-libc" "node:assert" "node:async_hooks" "node:buffer" "node:child_process" "node:crypto" "node:dns" "node:events" "node:fs" "node:http" "node:https" "node:module" "node:net" "node:os" "node:path" "node:perf_hooks" "node:process" "node:querystring" "node:stream" "node:string_decoder" "node:tls" "node:tty" "node:url" "node:util" "node:util/types" "node:zlib" "node:http2" 
Elapsed: 13579542ms | User: 7654ms | Sys: 1308ms
RSS: 0.75GB | Peak: 0.22GB | Commit: 0.75GB | Faults: 44

panic(main thread): Segmentation fault at address 0x0
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

To send a redacted crash report to Bun's team,
please file a GitHub issue using the link below:

Stack Trace (bun.report)

Bun v1.1.27 (267afa2) on linux x86_64_baseline [AutoCommand]

Segmentation fault at address 0x00000000

• ld-temp.o:0: char32_t WTF::Unicode::next<(...)0, char8_t>
• ??
• ld-temp.o:0: JSC::IsoInlinedHeapCellType<JSC::JSString>::finishSweep
• ld-temp.o:0: JSC::MarkedBlock::Handle::sweep
• ld-temp.o:0: JSC::MachineThreads::gatherConservativeRoots
• ld-temp.o:0: JSC::LocalAllocator::allocateSlowCase
• HashFunctions.h:80: WTF::HashTable<unsigned long, unsigned long, WTF::IdentityExtractor, WTF::DefaultHash<unsigned long>, WTF::HashTraits<unsigned long>, WTF::HashTraits<unsigned long> >::rehash
• ld-temp.o:0: JSC::JSString* JSC::repeatCharacter<char16_t>
• ld-temp.o:0: JSC::fastJoin
• ld-temp.o:0: JSC::arrayProtoFuncPop

[Jarred-Sumner]

Can you help us reproduce this? Unfortunately, it's going to be difficult for us to take action on this crash without some code to reproduce it.

[projaguar]

Can you help us reproduce this? Unfortunately, it's going to be difficult for us to take action on this crash without some code to reproduce it.

This is a phenomenon that occurs occasionally in production, and since it is the last log left before death, I could not find the location of the problem. Unfortunately, I cannot reproduce it.

but

If we estimate the task at the time of the problem, it is estimated that it occurred while repeatedly performing the task of creating a jsonl in memory, making a batch request with open-ai, and receiving and parsing the jsonl of the completed batch task. It is not clear whether it matches the time of death, but there was a log in the log that parsed and caught an incorrect json string. I hope this is a small hint.