GNU bug report logs - #58218
29.0.50; url-retrieve-synchronously with timeout causes process-query-on-exit

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 58218 in the body.
You can then email your comments to 58218 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: Phil Sainty <psainty <at> orcon.net.nz>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; url-retrieve-synchronously with timeout causes
 process-query-on-exit
Date: Sat, 01 Oct 2022 23:55:05 +1300

If you use the TIMEOUT argument to `url-retrieve-synchronously' and the
response is not obtained within that duration, then the process created
for that request causes query-on-exit behaviour.  I can reproduce this
in all the Emacs builds I have, including this 29.0.50 build.


;; With a short timeout causing the request to be aborted:

(url-retrieve-synchronously "http://www.example.com" nil nil 0.01)
nil

M-x list-processes
www.example.com -- open -- -- Main (network connection to 
www.example.com:80)

C-x C-c
Active processes exist; kill them and exit anyway? (yes or no)



;; With a long timeout (or a nil timeout):

(url-retrieve-synchronously "http://www.example.com" nil nil 5)
#<buffer  *http www.example.com:80*>

M-x list-processes
www.example.com -- open -- -- Main (network connection to 
www.example.com:80)

C-x C-c
exits without any process-related prompt



I'm not sure why the network connection remains open in either case, but
regardless of that it seems as if process-query-on-exit-flag is set if
the request times out, and cleared if it does not.  The query-on-exit
case seems to me like a bug, especially when there is no obvious way to
obtain the process object and change the flag.

I found bug #34607 when searching, but I don't understand what's being
discussed there; especially the example code for this:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34607#22
which seems to me like it would be signalling an error when it winds
up evaluating (with-current-buffer nil ...)



-Phil




In GNU Emacs 29.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.15.10, Xaw scroll bars)
 of 2022-07-15 built on phil-lp
Repository revision: 00eb894a56d63fad3573a53dd57c323289711512
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 
11.0.12008000
System Description: Ubuntu 18.04.6 LTS

Configured using:
 'configure --prefix=/home/phil/emacs/trunk/usr/local
 --with-x-toolkit=lucid --without-sound
 '--program-transform-name=s/^ctags$/ctags_emacs/''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP THREADS
TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LC_MONETARY: en_NZ.UTF-8
  value of $LC_NUMERIC: en_NZ.UTF-8
  value of $LC_TIME: en_NZ.UTF-8
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  savehist-mode: t
  windmove-mode: t
  winner-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr ibuffer ibuffer-loaddefs cl-extra thingatpt
shortdoc help-fns radix-tree help-mode emacsbug message mailcap
yank-media puny rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date subr-x
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils savehist windmove winner ring dired-aux cl-loaddefs cl-lib
dired dired-loaddefs advice rmc iso-transl tooltip eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
faces cus-face macroexp files window text-properties overlay sha1 md5
base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)

Memory information:
((conses 16 58167 33316)
 (symbols 48 6207 0)
 (strings 32 20424 1989)
 (string-bytes 1 582261)
 (vectors 16 11596)
 (vector-slots 8 167080 10019)
 (floats 8 74 16)
 (intervals 56 488 2)
 (buffers 992 16))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 58218 <at> debbugs.gnu.org
Subject: Re: bug#58218: 29.0.50;
 url-retrieve-synchronously with timeout causes process-query-on-exit
Date: Sat, 01 Oct 2022 14:44:43 +0300

> Date: Sat, 01 Oct 2022 23:55:05 +1300
> From: Phil Sainty <psainty <at> orcon.net.nz>
> 
> If you use the TIMEOUT argument to `url-retrieve-synchronously' and the
> response is not obtained within that duration, then the process created
> for that request causes query-on-exit behaviour.  I can reproduce this
> in all the Emacs builds I have, including this 29.0.50 build.
> 
> 
> ;; With a short timeout causing the request to be aborted:
> 
> (url-retrieve-synchronously "http://www.example.com" nil nil 0.01)
> nil
> 
> M-x list-processes
> www.example.com -- open -- -- Main (network connection to 
> www.example.com:80)
> 
> C-x C-c
> Active processes exist; kill them and exit anyway? (yes or no)
> 
> 
> 
> ;; With a long timeout (or a nil timeout):
> 
> (url-retrieve-synchronously "http://www.example.com" nil nil 5)
> #<buffer  *http www.example.com:80*>
> 
> M-x list-processes
> www.example.com -- open -- -- Main (network connection to 
> www.example.com:80)
> 
> C-x C-c
> exits without any process-related prompt
> 
> 
> 
> I'm not sure why the network connection remains open in either case, but
> regardless of that it seems as if process-query-on-exit-flag is set if
> the request times out, and cleared if it does not.  The query-on-exit
> case seems to me like a bug, especially when there is no obvious way to
> obtain the process object and change the flag.

Maybe I'm missing something, but if url-retrieve-synchronously exits
with a timeout, isn't it expected that the process be still alive, and
therefore that Emacs will ask you about killing it?

Or are you saying that when url-retrieve-synchronously exits due to
timeout, it should kill the process?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 58218 <at> debbugs.gnu.org
Subject: Re: bug#58218: 29.0.50; url-retrieve-synchronously with timeout
 causes process-query-on-exit
Date: Sat, 01 Oct 2022 14:33:46 +0200

Phil Sainty <psainty <at> orcon.net.nz> writes:

> (url-retrieve-synchronously "http://www.example.com" nil nil 0.01)
> nil
>
> M-x list-processes
> www.example.com -- open -- -- Main (network connection to
> www.example.com:80)
>
> C-x C-c
> Active processes exist; kill them and exit anyway? (yes or no)

Yes, it seems to be an accounting error in the code around
`url-http-mark-connection-as-busy' -- that function is called too late,
and marks the connection as busy after we've already exited, and then it
never marks the connection as non-busy...  Hm...

We never get to

http -> Marking connection as free: www.example.com:80 #<process www.example.com<1>>

because we never get the callback.  Hm...

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 58218 <at> debbugs.gnu.org
Subject: Re: bug#58218: 29.0.50; url-retrieve-synchronously with timeout
 causes process-query-on-exit
Date: Sat, 01 Oct 2022 14:50:42 +0200

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

> because we never get the callback.  Hm...

OK, found the problem.  I've now fixed this in Emacs 29.

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

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58218 <at> debbugs.gnu.org
Subject: Re: bug#58218: 29.0.50; url-retrieve-synchronously with timeout
 causes process-query-on-exit
Date: Sun, 02 Oct 2022 01:51:12 +1300

On 2022-10-02 00:44, Eli Zaretskii wrote:
> Maybe I'm missing something, but if url-retrieve-synchronously exits
> with a timeout, isn't it expected that the process be still alive, and
> therefore that Emacs will ask you about killing it?

Only (IMO) if you were to try to exit Emacs so quickly that the process
was still waiting for the URL response at that time.

I wasn't clear about that, but I was leaving ample time for the process
to receive a response before using C-x C-c (at least several seconds, 
for
a request which was taking less than 1 second when no shorter timeout 
was
set).


> Or are you saying that when url-retrieve-synchronously exits due to
> timeout, it should kill the process?

My bug report was only about the query-on-exit behaviour, but... killing
the process if it times out might a good idea -- or a good thing to be
able to specify optionally?

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

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 58218 <at> debbugs.gnu.org
Subject: Re: bug#58218: 29.0.50; url-retrieve-synchronously with timeout
 causes process-query-on-exit
Date: Sun, 02 Oct 2022 01:59:08 +1300

On 2022-10-02 01:50, Lars Ingebrigtsen wrote:
> OK, found the problem.  I've now fixed this in Emacs 29.

That was quick :)  Cheers!

Previous Next

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