GNU bug report logs - #71295
29.3; url-retrieve-synchronously does not timeout if initial connection hangs

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: z <at> bcc32.com, 71295 <at> debbugs.gnu.org, azeng <at> janestreet.com
Subject: bug#71295: 29.3; url-retrieve-synchronously does not timeout if initial connection hangs
Date: Mon, 10 Jun 2024 01:05:27 +0300

On 09/06/2024 07:39, Eli Zaretskii wrote:
>> Date: Sun, 9 Jun 2024 01:34:03 +0300
>> Cc:z <at> bcc32.com,71295 <at> debbugs.gnu.org,azeng <at> janestreet.com
>> From: Dmitry Gutov<dmitry <at> gutov.dev>
>>
>> Thinking further, though, our ability to do so bring the existence of
>> this variable into question (we only change it in
>> url-retrieve-synchronously).
>>
>> I see it's been added as part of bug#26835 resolution, so maybe we'll
>> need to re-examine that fix.
> Maybe.  Suggestions welcome.

This seems to work:

diff --git a/lisp/url/url.el b/lisp/url/url.el
index 0ac2917b213..1972ff254fe 100644
--- a/lisp/url/url.el
+++ b/lisp/url/url.el
@@ -245,7 +245,8 @@ url-retrieve-synchronously
                                 data-buffer)))
          (start-time (current-time))
          (proc-buffer (url-retrieve url callback nil silent
-                                    inhibit-cookies)))
+                                    inhibit-cookies))
+         failed-message)
     (if (not proc-buffer)
         (url-debug 'retrieval "Synchronous fetching unnecessary %s" url)
       (unwind-protect
@@ -276,6 +277,8 @@ url-retrieve-synchronously
                   ;; Process sentinel vagaries occasionally cause
                   ;; url-retrieve to fail calling callback.
                   (unless data-buffer
+                    (when (memq (process-status proc) '(signal failed))
+                      (setq failed-message (process-exit-status proc)))
                     (url-debug 'retrieval "Dead process %s" url)
 		    (throw 'done 'exception))))
               ;; Querying over consumer internet in the US takes 100
@@ -285,7 +288,9 @@ url-retrieve-synchronously
         (when (and data-buffer
                    (not (eq data-buffer proc-buffer)))
           (let (kill-buffer-query-functions)
-            (kill-buffer proc-buffer)))))
+            (kill-buffer proc-buffer))))
+      (when failed-message
+        (error "Retrieval failed: `%s'" failed-message)))
     data-buffer))

 ;; url-mm-callback called from url-mm, which requires mm-decode.


It's doesn't show the same kind of error like the nowait version:

Debugger entered--Lisp error: (error "The x509 certificate does not 
match \"wrong.host.badssl.com\"")
  gnutls-boot(#<process wrong.host.badssl.com<35>> gnutls-x509pki 
(:complete-negotiation t :priority "NORMAL:%DUMBFW" :hostname 
"wrong.host.badssl.com" :loglevel 0 :min-prime-bits nil :trustfiles 
("/etc/ssl/certs/ca-certificates.crt") :crlfiles nil :keylist nil 
:verify-flags nil :verify-error t :pass nil :flags nil :callbacks nil))
  gnutls-negotiate(:process #<process wrong.host.badssl.com<35>> :type 
gnutls-x509pki :keylist nil :hostname "wrong.host.badssl.com")

But the error is still meaningful:

(error "Retrieval failed: ‘The Network Security Manager stopped the 
connections’")

Unfortunately, the error is sometimes not triggered (the process object 
not created maybe?) - so some more investigation is needed.

Previous Next

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