8 ms·

Even 360MB seemed a bit high to me so I had to open it up in a few apps to get some perspective. Ristretto: 48.8MB. EOG: 51.3MB. ImageMagick: 169MB. Firefox: 3

Even 360MB seemed a bit high to me so I had to open it up in a few apps to get some perspective. Ristretto: 48.8MB. EOG: 51.3MB. ImageMagick: 169MB. Firefox: 305.1MB. Vivaldi: 185.2MB. Edge: 196.5MB. GIMP: 244.8MB. OS memory usage remained relatively flat once app exited. xUbuntu 20.04.

thanatos519 5y ago
My GIMP process reached 278MB (93MB of which was shared). According to the Dashboard tab, 60MB of that was cache, including layer thumbnails and mipmaps. It's definitely not inflating the memory footprint more than expected. It's hard to count the total pixels, since every frame has different dimensions.
marcan_42 5y ago
Try this one: https://mrcn.st/t/bomb.gif https://mrcn.st/t/bomb.gif It at least causes ImageMagick to explode, and generally anything that tries to flatten out the GIF into full canvas-sized frames.
- Gaelan 5y ago
  iOS Safari seems to render it with no performance issues. Interestingly, it can’t seem to decide whether the background is black or green—it’s different each time I load the gif.
  - marcan_42 5y ago
    Browsers and other players will generally be fine, as they render the image progressively. However, editors /processing tools which attempt to load it as a series of frames or a video will usually break, as memory consumption explodes, unless they have a smart disk buffer system to handle it. I wouldn't be surprised if some poorly implemented players were built on top of abstraction layers that end up flattening the whole thing too and also break, but browsers at least generally do it right.
    - slver 5y ago
      And this kids, is why we have key and delta frames. We should drop gif support.
      - paulryanrogers 5y ago
        Why not cap animated gifs at a maximum duration or file size? GIFs original use cases are already served by formats better suited to the modern era. Their continued popularity seems due mostly to their historical auto play behavior. One that apps are so reluctant to disrupt we're filling landfills with electronic waste to keep up with ever larger and longer meme animations.
        slver 5y ago
        It's too late to (re)define GIF. Actually software which edits animated GIFs doesn't have to crash per se, it's all about how smartly it's implemented, and because GIF editing isn't exactly a sprawling industry, most apps tend to be, well, not that smart, and so edge cases can get them.
        paulryanrogers 5y ago
        Formats don't have to be fully implemented to their original spec for all time. If it's not serving us well today then we can change how our software uses it.
        beckingz 5y ago
        Wouldn't it be better to make a new specification that provides backwards compatibility?
        paulryanrogers 5y ago
        If the goal is to stop obscene memory and bandwidth bloat then changing the default to a click-to-play/load would be better. My thinking is too change the incentives so producers aren't exploiting an old format to force autoplay at the expense of wasted resources and user control.
hn3333 5y ago
It would be very bad if OS memory usage did not return to flat no?
- boomboomsubban 5y ago
  Depends on what you mean, there is no real reason to blank memory just because a program is exited.
  - notrandom 5y ago
    A program should not hold memory anymore when it is no longer running. If it did, that would be an OS memory leak.
    - deleted 5y ago
      [deleted]
    - simondotau 5y ago
      A process which doesn't exist cannot hold memory. But the OS can certainly chose to defer the erasure as long as there's no better use for that memory. This is often done to speed up the performance of processes which are frequently quit/stopped and reopened/started.
      - Elv13 5y ago
        > A process which doesn't exist cannot hold memory Not quite. Some leaks are across processes. If your process talk to a local daemon and cause it to hold memory then quitting the client process wont necessarily free it. In a similar way, some application are multi-process and keep some background process active even when you quit to "start faster next time" (of act as spywares). This includes some infamous things like Apple updater that came with iTunes on Windows. It's also possible to cause SHM enabled caches to leak quite easily. Finally, the kernel caches as much as it can (file system content, libraries, etc) in case it is reused. That caching can push "real process memory" into the swap. So quitting a process does not always restore the total amount of available memory.
nix23 5y ago
have 114MB on FreeBSD with MPV
deaddodo 5y ago
EoG here (Dell XPS 15 9500, 32GB) only uses 14.6mb. Chrome spawns a renderer process that takes a good 200mb though.
kevingadd 5y ago
This sort of thing is a known historical attack surface. At one point not too long ago, people were attacking Discord's browser and desktop clients by embedding massive carefully-authored GIF files to exploit the fact that Chromium (thus, Chrome and Electron) decodes GIFs partially or wholly in advance, so the GIF would quickly consume all memory available to the tab/app and either crash it or bog down the system. I think Discord implemented some measures to guard against those files and Chromium was patched to mitigate this (which is why Edge and Vivaldi are fine), so it's not surprising that something like Safari might struggle with Evil GIFs under certain circumstances as well.

thanatos519 5y ago

My GIMP process reached 278MB (93MB of which was shared). According to the Dashboard tab, 60MB of that was cache, including layer thumbnails and mipmaps. It's definitely not inflating the memory footprint more than expected. It's hard to count the total pixels, since every frame has different dimensions.

marcan_42 5y ago

Try this one: https://mrcn.st/t/bomb.gif https://mrcn.st/t/bomb.gif It at least causes ImageMagick to explode, and generally anything that tries to flatten out the GIF into full canvas-sized frames.

Gaelan 5y ago
iOS Safari seems to render it with no performance issues. Interestingly, it can’t seem to decide whether the background is black or green—it’s different each time I load the gif.
- marcan_42 5y ago
  Browsers and other players will generally be fine, as they render the image progressively. However, editors /processing tools which attempt to load it as a series of frames or a video will usually break, as memory consumption explodes, unless they have a smart disk buffer system to handle it. I wouldn't be surprised if some poorly implemented players were built on top of abstraction layers that end up flattening the whole thing too and also break, but browsers at least generally do it right.
  - slver 5y ago
    And this kids, is why we have key and delta frames. We should drop gif support.
    - paulryanrogers 5y ago
      Why not cap animated gifs at a maximum duration or file size? GIFs original use cases are already served by formats better suited to the modern era. Their continued popularity seems due mostly to their historical auto play behavior. One that apps are so reluctant to disrupt we're filling landfills with electronic waste to keep up with ever larger and longer meme animations.
      - slver 5y ago
        It's too late to (re)define GIF. Actually software which edits animated GIFs doesn't have to crash per se, it's all about how smartly it's implemented, and because GIF editing isn't exactly a sprawling industry, most apps tend to be, well, not that smart, and so edge cases can get them.
        paulryanrogers 5y ago
        Formats don't have to be fully implemented to their original spec for all time. If it's not serving us well today then we can change how our software uses it.
        beckingz 5y ago
        Wouldn't it be better to make a new specification that provides backwards compatibility?
        paulryanrogers 5y ago
        If the goal is to stop obscene memory and bandwidth bloat then changing the default to a click-to-play/load would be better. My thinking is too change the incentives so producers aren't exploiting an old format to force autoplay at the expense of wasted resources and user control.

hn3333 5y ago

It would be very bad if OS memory usage did not return to flat no?

boomboomsubban 5y ago
Depends on what you mean, there is no real reason to blank memory just because a program is exited.
- notrandom 5y ago
  A program should not hold memory anymore when it is no longer running. If it did, that would be an OS memory leak.
  - deleted 5y ago
    [deleted]
  - simondotau 5y ago
    A process which doesn't exist cannot hold memory. But the OS can certainly chose to defer the erasure as long as there's no better use for that memory. This is often done to speed up the performance of processes which are frequently quit/stopped and reopened/started.
    - Elv13 5y ago
      > A process which doesn't exist cannot hold memory Not quite. Some leaks are across processes. If your process talk to a local daemon and cause it to hold memory then quitting the client process wont necessarily free it. In a similar way, some application are multi-process and keep some background process active even when you quit to "start faster next time" (of act as spywares). This includes some infamous things like Apple updater that came with iTunes on Windows. It's also possible to cause SHM enabled caches to leak quite easily. Finally, the kernel caches as much as it can (file system content, libraries, etc) in case it is reused. That caching can push "real process memory" into the swap. So quitting a process does not always restore the total amount of available memory.

nix23 5y ago

have 114MB on FreeBSD with MPV

deaddodo 5y ago

EoG here (Dell XPS 15 9500, 32GB) only uses 14.6mb. Chrome spawns a renderer process that takes a good 200mb though.

kevingadd 5y ago

This sort of thing is a known historical attack surface. At one point not too long ago, people were attacking Discord's browser and desktop clients by embedding massive carefully-authored GIF files to exploit the fact that Chromium (thus, Chrome and Electron) decodes GIFs partially or wholly in advance, so the GIF would quickly consume all memory available to the tab/app and either crash it or bog down the system. I think Discord implemented some measures to guard against those files and Chromium was patched to mitigate this (which is why Edge and Vivaldi are fine), so it's not surprising that something like Safari might struggle with Evil GIFs under certain circumstances as well.