bug#45907: [PATCH] Shr memory singularity gif89a

[Lars Ingebrigtsen]

dick <dick.r.chiang@gmail.com> writes:

> With the increased use of gif89a, my gnus is achieving memory
> consumption singularity more frequently.
>
> * lisp/net/shr.el (shr-put-image): When content-type is
> application/octet-stream, do not attempt insert-image.

This was a slightly confusing bug report and patch, but I think this was
the proposed functional change:

diff --git a/lisp/net/shr.el b/lisp/net/shr.el
index 9c3740fccc..c05ac17521 100644
--- a/lisp/net/shr.el
+++ b/lisp/net/shr.el
@@ -1124,6 +1124,8 @@ shr-put-image
                     ((eq content-type 'image/svg+xml)
                       (when (image-type-available-p 'svg)
                        (create-image data 'svg t :ascent 100)))
+                     ((eq content-type 'application/octet-stream)
+                      nil)
                     ((eq size 'full)
                      (ignore-errors
                        (shr-rescale-image data content-type

But I don't think that makes much sense: It doesn't really matter what
the content type is.  The problem is that Emacs chokes on a particular
GIF file.  To reproduce:

curl 
"https://raw.githubusercontent.com/enphysoft/search-gmail-using-message-id/main/images/lgmid.gif";
 > /tmp/lgmid.gif
emacs -Q /tmp/lgmid.gif

This initially hangs Emacs, but then it finally is able to display the
file...  but Emacs uses 2GB worth of memory and 100% CPU.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no