Segmentation fault

[atbe]

How can we reproduce the crash?

No response

Relevant log output

No response

Stack Trace (bun.report)

Bun v1.1.18 (5a0b935) on linux x86_64baseline []

Segmentation fault at address 0x00000167

• ld-temp.o:0: WTF::jscSignalHandler
• ??
• response.zig:0: src.bun.js.webcore.response.Fetch.FetchTasklet.onProgressUpdate
• event_loop.zig:977: src.bun.js.event_loop.EventLoop.tickQueueWithCount__anon_116898
• event_loop.zig:1249: src.bun.js.event_loop.EventLoop.tick
• javascript.zig:1336: src.bun.js.javascript.OpaqueWrap__anon_51464__struct_81802.callback
• bindings.cpp:4825: JSC__VM__holdAPILock
• shimmer.zig:197: src.cli.Cli.start
• main.zig:50: main

[Jarred-Sumner]

Please let us know if you still run into this in the canary build of Bun

bun upgrade --canary

[7f8ddd]

Please let us know if you still run into this in the canary build of Bun

bun upgrade --canary

Bun v1.1.20-canary (ae19489) on linux x86_64 [RunCommand]

Segmentation fault at address 0x00000012

• ld-temp.o:0: WTF::jscSignalHandler
• ??
• response.zig:0: src.bun.js.webcore.response.Fetch.FetchTasklet.onProgressUpdate
• event_loop.zig:979: src.bun.js.event_loop.EventLoop.tickQueueWithCount__anon_117904
• event_loop.zig:1251: src.bun.js.event_loop.EventLoop.tick
• event_loop.zig:1418: src.bun.js.javascript.OpaqueWrap__anon_51579__struct_81641.callback
• bindings.cpp:4823: JSC__VM__holdAPILock
• shimmer.zig:197: src.bun_js.Run.boot
• run_command.zig:1399: src.cli.run_command.RunCommand.exec__anon_72162
• cli.zig:1801: src.cli.Cli.start

Features: jsc, abort_signal, dotenv, fetch, http_server, transpiler_cache, tsconfig

[7f8ddd]

Please let us know if you still run into this in the canary build of Bun

bun upgrade --canary

I can't come up with a reproduction but it happened when my application was basically idle and just updating some data. Each fetch request is ~1 min apart.

[atbe]

@Jarred-Sumner this is coming from a worker in our network, so its challenging to get them to run the canary build without building a unique binary just for them -- we'll be upgrading to the latest version of bun soon and hopefully the error is fixed there. Otherwise we'll keep walking the stable versions with the hopes that it gets resolved.

Is there any other info I can provide that would make it easier to debug this?

[Jarred-Sumner]

@atbe bun v1.1.20 has the same code now that the canary did

So if it’s not fixed in that version then it still isn’t fixed.

It seemed like it could’ve been a stackoverflow in the http client @cirospaciari fixed.