git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

From
Jeff King <peff@peff.net>
Date
Nov 25, 2013, 14:43 UTC
Message-ID
<20131125144321.GA23779@sigill.intra.peff.net>
In-Reply-To
<20131125143213.GA22642@sigill.intra.peff.net>

This is an extension to the fix in 7d80ed64e43515. We may call Curl_disconnect() while cleaning up the multi handle, which could lead to openssl sending packets, which could get a SIGPIPE.

Signed-off-by: Jeff King <peff@peff.net>
---
I really am just cargo-culting here. I have no idea what
multi->closure_handle does, except that it gets used as conn->data for
the connection we pass to Curl_disconnect, so it seems like a reasonable
place to check for the magic no_signal variable.
 lib/multi.c | 9 +++++++++
 1 file changed, 9 insertions(+)
diff --git a/lib/multi.c b/lib/multi.c
index 923e2ce..2ecb1a4 100644
--- a/lib/multi.c
+++ b/lib/multi.c
@@ -41,6 +41,7 @@
 #include "bundles.h"
 #include "multihandle.h"
 #include "pipeline.h"
+#include "sigpipe.h"
 
 #define _MPRINTF_REPLACE /* use our functions only */
 #include <curl/mprintf.h>
@@ -1786,12 +1787,18 @@ CURLMcode curl_multi_cleanup(CURLM *multi_handle)
   struct SessionHandle *nextdata;
 
   if(GOOD_MULTI_HANDLE(multi)) {
+    SIGPIPE_VARIABLE(pipe);
+    bool restore_pipe = FALSE;
+
     multi->type = 0; /* not good anymore */
 
     /* Close all the connections in the connection cache */
     close_all_connections(multi);
 
     if(multi->closure_handle) {
+      sigpipe_ignore(multi->closure_handle, &pipe);
+      restore_pipe = TRUE;
+
       multi->closure_handle->dns.hostcache = multi->hostcache;
       Curl_hostcache_clean(multi->closure_handle,
                            multi->closure_handle->dns.hostcache);
@@ -1836,6 +1843,8 @@ CURLMcode curl_multi_cleanup(CURLM *multi_handle)
     Curl_pipeline_set_server_blacklist(NULL, &multi->pipelining_server_bl);
 
     free(multi);
+    if (restore_pipe)
+      sigpipe_restore(&pipe);
 
     return CURLM_OK;
   }
-- 
1.8.5.rc3.491.ge1614cf
Previous: Jeff KingNext: Daniel Stenberg
Message 13 of 22 in “error: git-remote-https died of signal 13”
  1. Stefan BellerNov 23, 2013
  2. Jeff KingNov 24, 2013
  3. Stefan BellerNov 24, 2013
  4. Jeff KingNov 24, 2013
  5. Stefan BellerNov 24, 2013
  6. Jeff KingNov 24, 2013
  7. Stefan BellerNov 24, 2013
  8. Stefan BellerNov 24, 2013
  9. Jeff KingNov 25, 2013
  10. Daniel StenbergNov 25, 2013
  11. Jeff KingNov 25, 2013
  12. 1/2 factor out sigpipe_reset from easy.cJeff King, Nov 25, 2013
  13. 2/2 ignore SIGPIPE during curl_multi_cleanupJeff King, Nov 25, 2013
  14. Daniel StenbergNov 27, 2013
  15. curlUserMay 22, 2018
  16. Daniel StenbergMay 22, 2018
  17. curlUserMay 22, 2018
  18. dxt29Aug 3, 2018
  19. Jeff KingNov 25, 2013
  20. Daniel StenbergNov 24, 2013
  21. brian m. carlsonNov 24, 2013
  22. Daniel StenbergMay 22, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.