Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Animated GIF uses over 35GB RAM in Acorn on M1 Mac, likely due to memory leak

twitter.com

Post reply on HN
Print view View original

51–60 of 342 posts

Re: Animated GIF uses over 35GB RAM in Acorn on M1 Mac, likely due to memory leak

#51

Post by Toutouxc »

mlyle wrote: post #45
callahad wrote: post #41

Earlier quoted context omitted.

All the M1 Macs can be upgraded to 16 GB, including the Air, and macOS uses memory compression by default, so there can be a bit more life to these machines than you'd otherwise expect. Edit: Since posting this comment, the parent has been edited to include "hope you got the 16G version" -- at the time I replied, jacquesm's comment mistakenly asserted an absolute "maximum memory size of 8G."

The ram is soldered onto the CPU package. How exactly does one upgrade it, short of doing hot-air rework of a dense BGA?

They meant upgraded at the time of purchase.

Re: Animated GIF uses over 35GB RAM in Acorn on M1 Mac, likely due to memory leak

#52

Post by hn3333 »

techrat wrote: post #8

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.

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

Re: Animated GIF uses over 35GB RAM in Acorn on M1 Mac, likely due to memory leak

#53

Post by simion314 »

supermatt wrote: post #34
marcan_42 wrote: post #25

Earlier quoted context omitted.

The latest information I have suggests it's fixed in macOS 11.4.

Do you have a link for info on this? If this is a real issue (which I still have my doubts about), Apple can’t just sweep it under the rug, after all.

>Apple can’t just sweep it under the rug

Check history, until a class action lawsuit forces Apple to admit the problem they will sweep it under the rug or they claim you are using it wrong.

Re: Animated GIF uses over 35GB RAM in Acorn on M1 Mac, likely due to memory leak

#54

Post by nieve »

BoorishBears wrote: post #26
Dylan16807 wrote: post #22

Earlier quoted context omitted.

> gif bombs of the past. Which would also require opening it in a specific program. This is a strange complaint.

They would require *rendering* in a specific program This program is an image editor essentially opening 700 tabs, one for each frame. It's not a "bomb" when you intentionally blow it up...

Several programs including Firefox Nightly have been reported to blow up, so no it's not limited to a "specific program".

Re: Animated GIF uses over 35GB RAM in Acorn on M1 Mac, likely due to memory leak

#55

Post by kelnos »

BoorishBears wrote: post #26
Dylan16807 wrote: post #22

Earlier quoted context omitted.

> gif bombs of the past. Which would also require opening it in a specific program. This is a strange complaint.

They would require *rendering* in a specific program This program is an image editor essentially opening 700 tabs, one for each frame. It's not a "bomb" when you intentionally blow it up...

730 frames of a 400x240 pixel image at 8 bits per pixel (which is all GIF allows) is 70MB (plus 768 bytes for the palette). We should be able to load each frame of the GIF many, many times before we reach even 1GB of RAM, let alone 35GB.

The x86 version of the same editor can open this GIF in the same way with reasonable memory consumption. This is clearly an issue with either the image editor, or as seems to be the case (based on investigation in the Twitter thread) an issue with a macOS system framework the editor uses.

Not sure why you feel the need to be so belligerent on this. All the information we need to identify this as a problem specific to the M1 version of macOS is in the first tweet, with more details that give us exact numbers in a follow-up.

Re: Animated GIF uses over 35GB RAM in Acorn on M1 Mac, likely due to memory leak

#56

Post by umed »

kzrdude wrote: post #44
chirau wrote: post #30

Does Mac have swap? If so, how does it allocate it by default?

My macos knowledge is dated (didn't use it seriously since 10.5), but it used to be a dynamically growing collection of swapfiles, usually covering all of the RAM (probably can't do that anymore).

MacOS Big Sur: recently implemented an algorithm that leaked and left it running for quite some time. Got notification that there is not enough RAM and suggestion to close some apps once size of swap grown up to 64GB (or it was size of RAM + swap, don't remember).

Re: Animated GIF uses over 35GB RAM in Acorn on M1 Mac, likely due to memory leak

#57

Post by BoorishBears »

kelnos wrote: post #55
BoorishBears wrote: post #26

Earlier quoted context omitted.

They would require *rendering* in a specific program This program is an image editor essentially opening 700 tabs, one for each frame. It's not a "bomb" when you intentionally blow it up...

730 frames of a 400x240 pixel image at 8 bits per pixel (which is all GIF allows) is 70MB (plus 768 bytes for the palette). We should be able to load each frame of the GIF many, many times before we reach even 1GB of RAM, let alone 35GB. The x86 version of the same editor can open this GIF in the same way with reasonable memory consumption. This is clearly an issue with either the image editor, or as seems to be the…

I don't like the title, it's as simple as that.

No one said there isn't a bug, but not about the gif, it's about editing the gif.

This title is like saying a guy killed 10 people with a pen, and it turns out he signed an order for their execution.

It's a bug, but nowhere near what the title implies.

-

Edit: No it's not about the gif, just like it's not about the pen even if it was involved.

The editor completely changes things and makes the gif the least interesting part.

Re: Animated GIF uses over 35GB RAM in Acorn on M1 Mac, likely due to memory leak

#58

Post by nfin »

Toutouxc wrote: post #51
mlyle wrote: post #45

Earlier quoted context omitted.

The ram is soldered onto the CPU package. How exactly does one upgrade it, short of doing hot-air rework of a dense BGA?

They meant upgraded at the time of purchase.

on Apples shop website I can‘t see a 16Gb Macbook Air.

Did I miss it? Or can‘t I see it if there is no availability anymore? Anyone a link?

Re: Animated GIF uses over 35GB RAM in Acorn on M1 Mac, likely due to memory leak

#59

Post by Gaelan »

marcan_42 wrote: post #29
techrat wrote: post #8

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.

Try this one: 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.

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.

Re: Animated GIF uses over 35GB RAM in Acorn on M1 Mac, likely due to memory leak

#60

Post by eduo »

okamiueru wrote: post #47
JKCalhoun wrote: post #32

My first thought was that each "frame" of the GIF is being expanded/rendered to its own backingstore. GIFs are pretty optimized files — where each "frame" can be a diff from the previous. "De-diffing", converting palette-based pixels to full 24 or 32-bit RGB could really blow up fast.

From a codec perspective gifs would be the first thing that came to mind for a poorly optimized format. The only thing it has going for it is simplicity. This is a bit besides the point you're making, but I did a double take at seeing the words "gif" and "pretty optimized" together. I'm also curious as to what this has to do with M1 in particular. Looks to be like a memory allocation issue in the decoder library. But…

"Optimized" in this sense meant that animated gifs can have a frame reference only three pixels of the original image. So an image of 300K with only small movement (think cinemagraphs) wouldn't be much larger.

This is a given for movie formats, but at the time the animated GIF came up it was revolutionary. I think the proper phrase should be "animated GIFs can be pretty optimized, taking into account how inefficient the algorithm is, when compared with other animation algorithms of the time".

I also think there's an interpretation that applies here: When you see an animated gif, even if it's a frame that changes three pixels and nothing else, internally the renderer may be expanding it into a full movie (that is, uncompressing each resulting "frame"). This usually makes GIFs (regardless of how large or small the GIF actually is) take much more memory than common sense would tell you.

Post reply on HN