🤖 bug: sharp image resize crashes Electron's Node runtime on headless Linux (SIGSEGV)
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 44/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- electron, linux, typescript
- Ambito
- backend, desktop, performance
Direzione di ricerca
Start by reading src/node/utils/attachments/resizeRasterImageAttachment.ts and the Linux Electron sharp note in src/node/workers/mcpIconDecode.ts. Reproduce with the two oversized fixtures under ELECTRON_RUN_AS_NODE=1, then verify on a real Linux desktop in a packaged build using attach_file. Done means oversized image resizing works without a crash; the payload suggests a plain Node worker or sharp's WebAssembly build as possible fixes.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
On a headless Linux host, sharp crashes Electron when it resizes an image inside Electron's Node runtime. The process exits with SIGSEGV. The same script works under plain Node.
CAUTION: I saw this only under ELECTRON_RUN_AS_NODE=1 on a headless Linux host with no display. It happens with sharp 0.34.5 (main) and with sharp 0.35.5. I did not verify it on a real Linux desktop or in a packaged Linux build, so I do not know if desktop users hit it.
Steps (Electron 44.5.1, Linux x64, no DISPLAY)
- Build the main process:
make build-main. - Make two large fixtures (a 9001x10 PNG and a 10x9001 JPEG with EXIF orientation 6) with sharp under plain
node. - Run a script that calls
resizeRasterImageAttachmentBufferIfNeededfromdist/node/utils/attachments/resizeRasterImageAttachment.json both files:node run.cjsprintsoversized.png true 9001x10 -> 2000x2 image/png ...and the JPEG line, then exits 0.ELECTRON_RUN_AS_NODE=1 node_modules/.bin/electron run.cjsprints.../node_modules/electron/dist/electron exited with signal SIGSEGV.
ELECTRON_RUN_AS_NODE=1 node_modules/.bin/electron -e 'require("sharp")'alone does not crash. The crash comes when the image is processed.
The full desktop smoke path (MUX_ATTACH_FILE_SMOKE_TEST_PNG_PATH / MUX_ATTACH_FILE_SMOKE_TEST_JPEG_PATH with electron --no-sandbox --ozone-platform=headless dist/desktop/main.js) also exits with SIGSEGV after "App ready, creating window...". On this host that is not conclusive, because no X display exists.
New warning in sharp 0.35
With sharp 0.35.5, loading sharp in Electron on Linux prints:
[SharpElectronLinux] Warning: Binaries provided by Electron for use on Linux may be incompatible with sharp - see https://sharp.pixelplumbing.com/install#electron-and-linux
src/node/workers/mcpIconDecode.ts already notes a GLib symbol conflict between Linux Electron and native sharp for SVG. This crash is a guess at the same class of problem. I did not verify the cause.
What to check
- Run
attach_filewith an image larger than the resize limit in a packaged Linux build (AppImage or deb) on a real desktop. - If it crashes, choose one fix: run the resize in a plain Node worker the way
mcpIconDecoderuns, or use sharp's WebAssembly build on Linux Electron.
Refs #7384 (sharp 0.35.5 bump).
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high
- Lingua principale
- TypeScript
- Stelle
- 2.1k
- Fork
- 140
- Merge medio
- 5h 8m
- PR unite (30g)
- 952
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di coder/xum
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
a10y a10y-audit ai-driven-qa claude
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
linagora/twake-directory-manager#219 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
type: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 79/100
I maintainer di solito rispondono entro 1 giorno
-
0️⃣ phase/new
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Pulse v7: buildPreferencesFromTelos() bypasses telosSectionOrFile(), renders empty on unified-TELOS installsForse già presa @zephyr91 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
danielmiessler/LifeOS#2393 ·
I maintainer di solito rispondono entro 4 giorni