* bug#23158: 25.1.50; crash by consecutive http accesses
@ 2016-03-30 6:20 Katsumi Yamaoka
2016-03-30 15:23 ` Eli Zaretskii
2016-03-30 15:43 ` Lars Magne Ingebrigtsen
0 siblings, 2 replies; 9+ messages in thread
From: Katsumi Yamaoka @ 2016-03-30 6:20 UTC (permalink / raw)
To: 23158
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#23158: 25.1.50; crash by consecutive http accesses
2016-03-30 6:20 bug#23158: 25.1.50; crash by consecutive http accesses Katsumi Yamaoka
@ 2016-03-30 15:23 ` Eli Zaretskii
2016-03-31 2:31 ` Katsumi Yamaoka
2016-03-30 15:43 ` Lars Magne Ingebrigtsen
1 sibling, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2016-03-30 15:23 UTC (permalink / raw)
To: Katsumi Yamaoka; +Cc: 23158
> 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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#23158: 25.1.50; crash by consecutive http accesses
2016-03-30 6:20 bug#23158: 25.1.50; crash by consecutive http accesses Katsumi Yamaoka
2016-03-30 15:23 ` Eli Zaretskii
@ 2016-03-30 15:43 ` Lars Magne Ingebrigtsen
2019-09-24 8:16 ` Lars Ingebrigtsen
1 sibling, 1 reply; 9+ messages in thread
From: Lars Magne Ingebrigtsen @ 2016-03-30 15:43 UTC (permalink / raw)
To: Katsumi Yamaoka; +Cc: 23158
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#23158: 25.1.50; crash by consecutive http accesses
2016-03-30 15:23 ` Eli Zaretskii
@ 2016-03-31 2:31 ` Katsumi Yamaoka
2016-03-31 2:45 ` Katsumi Yamaoka
2016-03-31 16:33 ` Eli Zaretskii
0 siblings, 2 replies; 9+ messages in thread
From: Katsumi Yamaoka @ 2016-03-31 2:31 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 23158
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#23158: 25.1.50; crash by consecutive http accesses
2016-03-31 2:31 ` Katsumi Yamaoka
@ 2016-03-31 2:45 ` Katsumi Yamaoka
2016-03-31 16:33 ` Eli Zaretskii
1 sibling, 0 replies; 9+ messages in thread
From: Katsumi Yamaoka @ 2016-03-31 2:45 UTC (permalink / raw)
To: 23158
A spam mail that causes the problem is:
http://www.jpl.org/tmp/bug#23158-mail
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#23158: 25.1.50; crash by consecutive http accesses
2016-03-31 2:31 ` Katsumi Yamaoka
2016-03-31 2:45 ` Katsumi Yamaoka
@ 2016-03-31 16:33 ` Eli Zaretskii
2016-04-01 0:28 ` Katsumi Yamaoka
2016-04-01 6:51 ` Andreas Schwab
1 sibling, 2 replies; 9+ messages in thread
From: Eli Zaretskii @ 2016-03-31 16:33 UTC (permalink / raw)
To: Katsumi Yamaoka; +Cc: 23158
> 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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#23158: 25.1.50; crash by consecutive http accesses
2016-03-31 16:33 ` Eli Zaretskii
@ 2016-04-01 0:28 ` Katsumi Yamaoka
2016-04-01 6:51 ` Andreas Schwab
1 sibling, 0 replies; 9+ messages in thread
From: Katsumi Yamaoka @ 2016-04-01 0:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 23158
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>>)
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#23158: 25.1.50; crash by consecutive http accesses
2016-03-31 16:33 ` Eli Zaretskii
2016-04-01 0:28 ` Katsumi Yamaoka
@ 2016-04-01 6:51 ` Andreas Schwab
1 sibling, 0 replies; 9+ messages in thread
From: Andreas Schwab @ 2016-04-01 6:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Katsumi Yamaoka, 23158
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."
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#23158: 25.1.50; crash by consecutive http accesses
2016-03-30 15:43 ` Lars Magne Ingebrigtsen
@ 2019-09-24 8:16 ` Lars Ingebrigtsen
0 siblings, 0 replies; 9+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-24 8:16 UTC (permalink / raw)
To: Katsumi Yamaoka; +Cc: 23158
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-09-24 8:16 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-30 6:20 bug#23158: 25.1.50; crash by consecutive http accesses Katsumi Yamaoka
2016-03-30 15:23 ` Eli Zaretskii
2016-03-31 2:31 ` Katsumi Yamaoka
2016-03-31 2:45 ` Katsumi Yamaoka
2016-03-31 16:33 ` Eli Zaretskii
2016-04-01 0:28 ` Katsumi Yamaoka
2016-04-01 6:51 ` Andreas Schwab
2016-03-30 15:43 ` Lars Magne Ingebrigtsen
2019-09-24 8:16 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.