You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While previewing a large (in dimensions, the file size can be tiny) SVG, (1) memory usage grows rapidly and (2) the / directory starts becoming filled, causing the system to crash. With all preloaders and previewers disabled, no crash occurs.
Minimal reproducer
(Note that this might crash the entire and system and potentially cause data loss)
This is a partial duplicate of #2345. The memory issue is obviously on IM's side:
magick -density 200 brick_system.svg -flatten -resize 200x200 -auto-orient out.jpg takes ~13 GB of RAM on my system. Interestingly, setting MAGICK_MEMORY_LIMIT=10000 has no effect on this - and as a result, setting image_alloc doesn't help either. In both cases, magick produces a broken JPEG file but 'works'.
When yazi previews the file, something causes systemd-coredump to write >0.5 GBs (!) of core dumps to /every second (see attached video), crashing the entire session in ~10-20 seconds. This might be due to a crash in magick which doesn't happen when run directly.
Screencast of disk usageyaziClip.mp4
TBH I expect none of this to be yazi's fault - and the attached SVG file is a bit extreme (although it is a info-stripped version of a real SVG file) - but it would be nice to prevent users from inadvertently running into this. I think using rsvg-convert over magick might be better (also for other reasons)... but that's probably a feature request.
What system are you running Yazi on?
Linux Wayland
What terminal are you running Yazi in?
kitty 0.36.4
yazi --debugoutputYazi Version: 25.3.7 (1765aba 2025-03-30) Debug : false Triple : x86_64-unknown-linux-gnu (linux-x86_64) Rustc : 1.85.1 (4eb16125 2025-03-15) Ya Version: 25.3.7 (1765aba 2025-03-30) Emulator TERM : Some("xterm-256color") TERM_PROGRAM : None TERM_PROGRAM_VERSION: None Brand.from_env : None Emulator.detect : Emulator { kind: Right(Unknown { kgp: false, sixel: false }), light: false, cell_size: None } Adapter Adapter.matches : Wayland Dimension.available: WindowSize { rows: 51, columns: 237, width: 0, height: 0 } Desktop XDG_SESSION_TYPE : Some("wayland") WAYLAND_DISPLAY : Some("wayland-1") DISPLAY : Some(":0") SWAYSOCK : Some("/run/user/1000/sway-ipc.1000.458567.sock") HYPRLAND_INSTANCE_SIGNATURE: None WAYFIRE_SOCKET : None SSH shared.in_ssh_connection: false WSL WSL: false Variables SHELL : Some("/bin/bash") EDITOR : Some("nvim") VISUAL : Some("nvim") YAZI_FILE_ONE : None YAZI_CONFIG_HOME: None YAZI_ZOXIDE_OPTS: None FZF_DEFAULT_OPTS: None Text Opener default : Some(OpenerRule { run: "${EDITOR:-vi} \"$@\"", block: true, orphan: false, desc: "$EDITOR", for_: None, spread: true }) block-create: Some(OpenerRule { run: "${EDITOR:-vi} \"$@\"", block: true, orphan: false, desc: "$EDITOR", for_: None, spread: true }) block-rename: Some(OpenerRule { run: "${EDITOR:-vi} \"$@\"", block: true, orphan: false, desc: "$EDITOR", for_: None, spread: true }) Multiplexers TMUX : false tmux version : tmux 3.5a tmux build flags : enable-sixel=Unknown ZELLIJ_SESSION_NAME: None Zellij version : No such file or directory (os error 2) Dependencies file : 5.45 ueberzugpp : No such file or directory (os error 2) ffmpeg/ffprobe: 7.0.2 / 7.0.2 pdftoppm : 24.08.0 magick : 7.1.1-41 fzf : 0.54.3 fd/fdfind : 10.1.0 / No such file or directory (os error 2) rg : 14.1.1 chafa : 1.14.2 zoxide : No such file or directory (os error 2) 7zz/7z : No such file or directory (os error 2) / 16.02 jq : 1.7.1 Clipboard wl-copy/paste: 2.2.1 / 2.2.1 xclip : 0.13 xsel : 1.2.1 Routine `file -bL --mime-type`: text/plain See https://yazi-rs.github.io/docs/plugins/overview#debugging on how to enable logging or debug runtime errors.Describe the bug
While previewing a large (in dimensions, the file size can be tiny) SVG, (1) memory usage grows rapidly and (2) the
/directory starts becoming filled, causing the system to crash. With all preloaders and previewers disabled, no crash occurs.Minimal reproducer
(Note that this might crash the entire and system and potentially cause data loss)
btop)Anything else?
This is a partial duplicate of #2345. The memory issue is obviously on IM's side:
magick -density 200 brick_system.svg -flatten -resize 200x200 -auto-orient out.jpgtakes ~13 GB of RAM on my system. Interestingly, settingMAGICK_MEMORY_LIMIT=10000has no effect on this - and as a result, setting image_alloc doesn't help either. In both cases,magickproduces a broken JPEG file but 'works'.When
yazipreviews the file, something causessystemd-coredumpto write >0.5 GBs (!) of core dumps to/every second (see attached video), crashing the entire session in ~10-20 seconds. This might be due to a crash inmagickwhich doesn't happen when run directly.Screencast of disk usage
yaziClip.mp4
TBH I expect none of this to be yazi's fault - and the attached SVG file is a bit extreme (although it is a info-stripped version of a real SVG file) - but it would be nice to prevent users from inadvertently running into this. I think using
rsvg-convertovermagickmight be better (also for other reasons)... but that's probably a feature request.Checklist
yazi --debug) input box to the nightly that I triedmv ~/.config/yazi ~/.config/yazi-backup)