bug#23158: 25.1.50; crash by consecutive http accesses

bug#23158: 25.1.50; crash by consecutive http accesses

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

(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@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'

[-- Attachment #2: bt-full.gz --]
[-- Type: application/x-gunzip, Size: 6079 bytes --]

[-- Attachment #3: xbacktrace.gz --]
[-- Type: application/x-gunzip, Size: 323 bytes --]

bug#23158: 25.1.50; crash by consecutive http accesses

[Eli Zaretskii]

> Date: Wed, 30 Mar 2016 15:20:09 +0900
> From: Katsumi Yamaoka <yamaoka@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@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?

bug#23158: 25.1.50; crash by consecutive http accesses

[Katsumi Yamaoka]

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.

bug#23158: 25.1.50; crash by consecutive http accesses

[Katsumi Yamaoka]

A spam mail that causes the problem is:

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

bug#23158: 25.1.50; crash by consecutive http accesses

[Eli Zaretskii]

> Date: Thu, 31 Mar 2016 11:31:52 +0900
> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Cc: 23158 <23158@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?

bug#23158: 25.1.50; crash by consecutive http accesses

[Katsumi Yamaoka]

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>>)

bug#23158: 25.1.50; crash by consecutive http accesses

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

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

A process object.

Andreas.

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

bug#23158: 25.1.50; crash by consecutive http accesses

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@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@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@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

bug#23158: 25.1.50; crash by consecutive http accesses

[Lars Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@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@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