GNU bug report logs - #23158
25.1.50; crash by consecutive http accesses

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23158 in the body.
You can then email your comments to 23158 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1.50; crash by consecutive http accesses
Date: Wed, 30 Mar 2016 15:20:09 +0900

[Message part 1 (text/plain, inline)]

(Recipe, bt full, and xbacktrace are below)

Hi,

I got a spam mail that crashes Emacs (at least the one built from
the git master and 24.5 bundled with Cygwin).  The mail contains
a lot of mail addresses in the From: header like this:

From: user<at>greenstream.in
	ly.com,abehera<at>jmi.ac.in,Alana<at>jmpco.com,ahron<at>jmpeacecorps.gov,kyu<at>jmtek.com,campfijf<at>jmu.edu,cnrrao<at>jncasr.ac.in,jeffv<at>jndtho
	mas.com,calpolyslofellow<at>jnf.org,edwin.rainbow<at>jnled.nl,a728399<at>jnxjn.com,cf<at>job114.cc,jroberts<at>jobeshenderson.com,salishnavaja
	...

When trying to read it using Gnus, Gnus tries to fetch gravatar
image for each address, and those consecutive http accesses seem
to crash Emacs.  Here is a simplified code for `emacs -Q' to
reproduce the problem:

(progn
  (require 'gnus-gravatar)
  (require 'url)
  (with-temp-buffer
    (let ((url-cache-expire-time 0)
	  (gnus-article-buffer (current-buffer)))
      (insert "From:")
      (dotimes (i 255) (insert " foo <at> example.com.invalid,"))
      (insert "\n")
      (gnus-gravatar-transform-address "from" 'from-gravatar))))

`bt full' and xbacktrace are attached.  Thanks in advance.

In GNU Emacs 25.1.50.1 (i686-pc-cygwin, GTK+ Version 3.14.13)
 of 2016-03-30 built on localhost
Windowing system distributor 'The Cygwin/X Project', version 11.0.11702000
Configured using:
 'configure --verbose --with-x-toolkit=gtk3 --with-xwidgets'

[bt-full.gz (application/x-gunzip, attachment)]

[xbacktrace.gz (application/x-gunzip, attachment)]

Message #8 received at 23158 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 23158 <at> debbugs.gnu.org
Subject: Re: bug#23158: 25.1.50; crash by consecutive http accesses
Date: Wed, 30 Mar 2016 18:23:19 +0300

> Date: Wed, 30 Mar 2016 15:20:09 +0900
> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
> 
> (Recipe, bt full, and xbacktrace are below)
> 
> Hi,
> 
> I got a spam mail that crashes Emacs (at least the one built from
> the git master and 24.5 bundled with Cygwin).  The mail contains
> a lot of mail addresses in the From: header like this:
> 
> From: user<at>greenstream.in
> 	ly.com,abehera<at>jmi.ac.in,Alana<at>jmpco.com,ahron<at>jmpeacecorps.gov,kyu<at>jmtek.com,campfijf<at>jmu.edu,cnrrao<at>jncasr.ac.in,jeffv<at>jndtho
> 	mas.com,calpolyslofellow<at>jnf.org,edwin.rainbow<at>jnled.nl,a728399<at>jnxjn.com,cf<at>job114.cc,jroberts<at>jobeshenderson.com,salishnavaja
> 	...
> 
> When trying to read it using Gnus, Gnus tries to fetch gravatar
> image for each address, and those consecutive http accesses seem
> to crash Emacs.  Here is a simplified code for `emacs -Q' to
> reproduce the problem:
> 
> (progn
>   (require 'gnus-gravatar)
>   (require 'url)
>   (with-temp-buffer
>     (let ((url-cache-expire-time 0)
> 	  (gnus-article-buffer (current-buffer)))
>       (insert "From:")
>       (dotimes (i 255) (insert " foo <at> example.com.invalid,"))
>       (insert "\n")
>       (gnus-gravatar-transform-address "from" 'from-gravatar))))
> 
> `bt full' and xbacktrace are attached.  Thanks in advance.

Thanks.  Can you try reproducing the problem in an unoptimized build,
and show the backtrace from that?

Message #11 received at 23158 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 23158 <at> debbugs.gnu.org
Subject: Re: bug#23158: 25.1.50; crash by consecutive http accesses
Date: Wed, 30 Mar 2016 17:43:55 +0200

Katsumi Yamaoka <yamaoka <at> jpl.org> writes:

> When trying to read it using Gnus, Gnus tries to fetch gravatar
> image for each address, and those consecutive http accesses seem
> to crash Emacs.  Here is a simplified code for `emacs -Q' to
> reproduce the problem:
>
> (progn
>   (require 'gnus-gravatar)
>   (require 'url)
>   (with-temp-buffer
>     (let ((url-cache-expire-time 0)
> 	  (gnus-article-buffer (current-buffer)))
>       (insert "From:")
>       (dotimes (i 255) (insert " foo <at> example.com.invalid,"))
>       (insert "\n")
>       (gnus-gravatar-transform-address "from" 'from-gravatar))))

Hm...  this doesn't crash Emacs on this Linux machine, at least.

> #0  0x00475e27 in setup_coding_system (coding_system=2025368, coding=0xffffffff) at coding.c:5706
>         eol_type = <optimized out>
> #1  0x005734fa in setup_process_coding_systems (process=process <at> entry=1659289077) at process.c:7507
>         inch = 64
>         outch = 64
>         coding_system = <optimized out>
> #2  0x00577705 in Fmake_network_process (ip_addresses=<optimized out>, proc=1659289077) at process.c:3375
>         family = 2

This is happening in the code paths that were refactored during the
async network rewrite, but this seems to be called pretty
straightforwardly here (not in a callback from the DNS code).  (Which
makes sense, since Windows doesn't have getaddrinfo_a...)

Hm...  coding=0xffffffff looks pretty suspicious, but it's difficult to
tell with an optimised build.

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

Message #14 received at 23158 <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23158 <23158 <at> debbugs.gnu.org>
Subject: Re: bug#23158: 25.1.50; crash by consecutive http accesses
Date: Thu, 31 Mar 2016 11:31:52 +0900

On Wed, 30 Mar 2016 18:23:19 +0300, Eli Zaretskii wrote:
>> those consecutive http accesses seem to crash Emacs.

> Thanks.  Can you try reproducing the problem in an unoptimized build,
> and show the backtrace from that?

I built Emacs from the git master with the option CFLAGS='-O0'
and verified it works for the test code with no problem.  However,
for reading the spam mail in question, Emacs doesn't crash but it
gets to be unusable; when I try to run some command, Emacs says

Wrong type argument: sequencep, #<process www.gravatar.com<46>>

and does not proceed.  A Lisp backtrace follows:

Debugger entered--Lisp error: (wrong-type-argument sequencep #<process www.gravatar.com<46>>)
  process-list()
  window--process-window-list()
  window--adjust-process-windows()
  read-from-minibuffer("Switch to buffer in other frame (default *Summary nnml:tmp*): " nil (keymap (10 . minibuffer-complete-and-exit) (13 . minibuffer-complete-and-exit) keymap (menu-bar keymap (minibuf "Minibuf" keymap (tab menu-item "Complete" minibuffer-complete :help "Complete as far as possible") (space menu-item "Complete Word" minibuffer-complete-word :help "Complete at most one word") (63 menu-item "List Completions" minibuffer-completion-help :help "Display all possible completions") "Minibuf")) (27 keymap (118 . switch-to-completions)) (prior . switch-to-completions) (63 . minibuffer-completion-help) (32 . minibuffer-complete-word) (9 . minibuffer-complete) keymap (menu-bar keymap (minibuf "Minibuf" keymap (previous menu-item "Previous History Item" previous-history-element :help "Put previous minibuffer history element in the minibuffer") (next menu-item "Next History Item" next-history-element :help "Put next minibuffer history element in the minibuffer") (isearch-backward menu-item "Isearch History Backward" isearch-backward :help "Incrementally search minibuffer history backward") (isearch-forward menu-item "Isearch History Forward" isearch-forward :help "Incrementally search minibuffer history forward") (return menu-item "Enter" exit-minibuffer :key-sequence "" :help "Terminate input and exit minibuffer") (quit menu-item "Quit" abort-recursive-edit :help "Abort input and exit minibuffer") "Minibuf")) (10 . exit-minibuffer) (13 . exit-minibuffer) (7 . abort-recursive-edit) (C-tab . file-cache-minibuffer-complete) (9 . self-insert-command) (XF86Back . previous-history-element) (up . previous-line-or-history-element) (prior . previous-history-element) (XF86Forward . next-history-element) (down . next-line-or-history-element) (next . next-history-element) (27 keymap (114 . previous-matching-history-element) (115 . next-matching-history-element) (112 . previous-history-element) (110 . next-history-element))) nil buffer-name-history "*Summary nnml:tmp*" nil)
  completing-read-default("Switch to buffer in other frame (default *Summary nnml:tmp*): " internal-complete-buffer nil confirm-after-completion nil buffer-name-history "*Summary nnml:tmp*" nil)
  read-buffer("Switch to buffer in other frame: " #<buffer *Summary nnml:tmp*> confirm-after-completion)
  read-buffer-to-switch("Switch to buffer in other frame: ")
  (list (read-buffer-to-switch "Switch to buffer in other frame: "))
  call-interactively(switch-to-buffer-other-frame nil nil)
  command-execute(switch-to-buffer-other-frame)

Thanks.

Message #17 received at 23158 <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: 23158 <at> debbugs.gnu.org
Subject: Re: bug#23158: 25.1.50; crash by consecutive http accesses
Date: Thu, 31 Mar 2016 11:45:27 +0900

A spam mail that causes the problem is:

http://www.jpl.org/tmp/bug#23158-mail

Message #20 received at 23158 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 23158 <at> debbugs.gnu.org
Subject: Re: bug#23158: 25.1.50; crash by consecutive http accesses
Date: Thu, 31 Mar 2016 19:33:41 +0300

> Date: Thu, 31 Mar 2016 11:31:52 +0900
> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
> Cc: 23158 <23158 <at> debbugs.gnu.org>
> 
> On Wed, 30 Mar 2016 18:23:19 +0300, Eli Zaretskii wrote:
> >> those consecutive http accesses seem to crash Emacs.
> 
> > Thanks.  Can you try reproducing the problem in an unoptimized build,
> > and show the backtrace from that?
> 
> I built Emacs from the git master with the option CFLAGS='-O0'
> and verified it works for the test code with no problem.  However,
> for reading the spam mail in question, Emacs doesn't crash but it
> gets to be unusable; when I try to run some command, Emacs says
> 
> Wrong type argument: sequencep, #<process www.gravatar.com<46>>
> 
> and does not proceed.  A Lisp backtrace follows:
> 
> Debugger entered--Lisp error: (wrong-type-argument sequencep #<process www.gravatar.com<46>>)

So what is #<process www.gravatar.com<46>>? nil?

Message #23 received at 23158 <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23158 <23158 <at> debbugs.gnu.org>
Subject: Re: bug#23158: 25.1.50; crash by consecutive http accesses
Date: Fri, 01 Apr 2016 09:28:52 +0900

On Thu, 31 Mar 2016 19:33:41 +0300, Eli Zaretskii wrote:
>> Debugger entered--Lisp error: (wrong-type-argument sequencep #<process www.gravatar.com<46>>)

> So what is #<process www.gravatar.com<46>>? nil?

Unfortunately I have no access to a variable that holds the
value #<process www.gravatar.com<46>>.  But I can guess from
process-list (defined in process.c) that `process_alist' has it
as a non-list value, i.e.:

(let ((Vprocess_alist '\#<process\ www.gravatar.com<46>>))
  (mapcar #'cdr Vprocess_alist))
 => (wrong-type-argument sequencep \#<process\ www\.gravatar\.com<46>>)

Message #26 received at 23158 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Katsumi Yamaoka <yamaoka <at> jpl.org>, 23158 <at> debbugs.gnu.org
Subject: Re: bug#23158: 25.1.50; crash by consecutive http accesses
Date: Fri, 01 Apr 2016 08:51:27 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> So what is #<process www.gravatar.com<46>>? nil?

A process object.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #29 received at 23158 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 23158 <at> debbugs.gnu.org
Subject: Re: bug#23158: 25.1.50; crash by consecutive http accesses
Date: Tue, 24 Sep 2019 10:16:27 +0200

Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:

> Hm...  this doesn't crash Emacs on this Linux machine, at least.
>
>> #0 0x00475e27 in setup_coding_system (coding_system=2025368,
>> coding=0xffffffff) at coding.c:5706
>>         eol_type = <optimized out>
>> #1 0x005734fa in setup_process_coding_systems
>> (process=process <at> entry=1659289077) at process.c:7507
>>         inch = 64
>>         outch = 64
>>         coding_system = <optimized out>
>> #2 0x00577705 in Fmake_network_process (ip_addresses=<optimized
>> out>, proc=1659289077) at process.c:3375
>>         family = 2

This was three years ago on Emacs 25, so I doubt we'll be able to make
any further progress here, and I'm closing this bug report.  If you're
still seeing this in more modern Emacs versions, please reopen.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.