Hugo 0.162.1 panic "Error allocating memory for blob data"

support
1

Running Hugo 0.162.1 on macOS 15.7.3 from the official package, I’m seeing this

Start building sites …
hugo v0.162.1-bba860e3eda3091efe8c6d1a96bc49a29ad2d5f6 darwin/arm64 BuildDate=2026-05-28T17:40:44Z VendorInfo=gohugoio

[578501154] Error allocating memory for blob data
Error parsing JSON line
panic: call with ID 0 not found

goroutine 154 [running]:
github.com/gohugoio/hugo/internal/warpc.(*dispatcher[...]).pendingCall(0x104d289c0?, 0x0?)
	/root/project/hugo/internal/warpc/warpc.go:422 +0x130
github.com/gohugoio/hugo/internal/warpc.(*dispatcher[...]).inputJSON(0x104fd4e40)
	/root/project/hugo/internal/warpc/warpc.go:370 +0xd8
github.com/gohugoio/hugo/internal/warpc.newDispatcher[...].func6()
	/root/project/hugo/internal/warpc/warpc.go:731 +0x24
golang.org/x/sync/errgroup.(*Group).Go.func1()
	/root/project/gomodcache/golang.org/x/sync@v0.20.0/errgroup/errgroup.go:93 +0x4c
created by golang.org/x/sync/errgroup.(*Group).Go in goroutine 41
	/root/project/gomodcache/golang.org/x/sync@v0.20.0/errgroup/errgroup.go:78 +0x90

This happens after I changed my images from WebP to AVIF.
Changing it back to WebP gets everything back to normal.
Almost all original images are JPEG, they are converted to WebP (or AVIF) in an image template.
The repo is currently private but I can of course give access to someone who wants to take a look.

2

After some research, I found several JPGs that were fairly big. Scaling everything down so that no image is larger than 2MB didn’t make the error go away, though.
I’m dealing with about 2400 JPGs, the largest of which is 1.6 MB.

3

How about image size in pixels (width multiplied by height)?

4

The largest one is 1024 by 1015 pixels, that’s 1,039,360 overall.

I tried to figure out if there’s a single image that causes the panic by adding warnf to the template, but the results were always different. Also, debug log gave always different results.

And I noticed that not all images are JPGs originally, there are also some WebP ones. The largest one of those is 500KB, 1240 by 930 pixels. That is 1,153,200 overall.

5

You have a 1024x1015 pixel JPEG at 1.6MB?

6 
$ file "content/blog/Biennale 2024/Yijing.jpg"
content/blog/Biennale 2024/Yijing.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), density 300x300, segment length 16, Exif Standard: [TIFF image data, little-endian, direntries=9, manufacturer=Canon, model=Canon EOS R100, xresolution=32, yresolution=40, resolutionunit=2, software=Adobe Photoshop Camera Raw 16.5 (Macintosh), datetime=2024:08:16 16:33:52, GPS-Data], progressive, precision 8, 1024x1015, components 3
$ ls -l "content/blog/Biennale 2024/Yijing.jpg"
-rw-r--r--@ 1 ck  staff  1679976  1 Jun 13:07 content/blog/Biennale 2024/Yijing.jpg

I used maximum quality on them.

7

If you mean you did this:

[imaging]
  quality = 100

Or included this in the processing spec:

q100

Try setting to 99 to see what happens.

Experimentation shows that quality = 100 produces a file that is roughly 40-80 percent larger when compared to quality = 99, strongly suggesting that quality = 100 triggers lossless encoding despite having compression set to lossy.

8

Sorry, I was a bit brief in my explanation. The “originals” are JPGs that were mostly saved with maximum quality.
This is what Hugo works with. Before 0.162, I converted the JPGs to WebPs without any changes in quality. Different sizes for responsive images, too. Which worked flawlessly.
Now I thought to convert the JPGs to AVIFs. I set quality to 75 in my hugo.toml and run the server, which leads to the crash. Everything else remains unchanged, also the different image sizes.
So, JPG conversion to WebP works ok, identical JPG conversion to AVIF causes the panic.

9

It would be helpful if you could share a reproducible example.

10

I have built the site that you shared privately on an Ubuntu VM, macOS (MacBook Air M4 with 16 GB memory), and Windows 11… no problems on any of them.

I do not doubt that there’s a problem, I just can’t reproduce it.

11
12

@chrillek I suspect the details here – I’m running similar setup as you (MacOS 15). If you could temporarily give me permission to clone your repo (I’m bep on GitHub) then I can take it for a spin. The image sizes you mention should be well within what we should be able to handle. In my tests fixing the error message above I had to set the memory limit to 8MB (down from default 384MB) with a 3000x3000 image to trigger the error situation (“Error allocating memory”).

13

Just added you. But be warned that @jmooring wasn’t able to reproduce the problem.
Here, it persisted after a reboot.

14

Yea, I cannot reproduce it, either. But I find only 3 AVIF files processed in that project, is that correct?

 find resources -name "*.avif"                                                                     main
resources/_gen/images/img/logo-full_hu_8f82345b2147f91a.avif
resources/_gen/images/img/logo-full_hu_2d7d147d54950220.avif
resources/_gen/images/img/logo-full_hu_86c97e94cdca5bf0.avif

That said, there are a fair amount of related improvements in the next Hugo release (better error message. and the memory usage when encoding should bey default be cut in half).

15

The template picture-handler converts every jpg, webp and png file to AVIF. Or should. All in all, there are a little over 2600 images.
In my resources/_gen, I see about 3000 AVIFs. Probably because of different sizes?

I’ll try again with the next release, then.

16

And the panic is gone with 0.163.0

Thanks a lot!