* error: git-remote-https died of signal 13 @ 2013-11-23 16:36 Stefan Beller 2013-11-24 6:54 ` Jeff King 0 siblings, 1 reply; 22+ messages in thread From: Stefan Beller @ 2013-11-23 16:36 UTC (permalink / raw) To: GIT Mailing-list Hi, Using the latest git version (1.8.5.rc3), I get this this warning/error: sb@sb:/tmp$ git clone https://github.com/Bertram25/ValyriaTear.git Cloning into 'ValyriaTear'... remote: Counting objects: 21346, done. remote: Compressing objects: 100% (6307/6307), done. remote: Total 21346 (delta 16463), reused 19820 (delta 15000) Receiving objects: 100% (21346/21346), 176.39 MiB | 445.00 KiB/s, done. Resolving deltas: 100% (16463/16463), done. Checking connectivity... done. error: git-remote-https died of signal 13 However the repository seems to be cloned fine. I can clone different repos from github and they are working fine without the error. Would that be an issue on my side or on githubs side? Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: error: git-remote-https died of signal 13 2013-11-23 16:36 error: git-remote-https died of signal 13 Stefan Beller @ 2013-11-24 6:54 ` Jeff King 2013-11-24 12:54 ` Stefan Beller 0 siblings, 1 reply; 22+ messages in thread From: Jeff King @ 2013-11-24 6:54 UTC (permalink / raw) To: Stefan Beller; +Cc: GIT Mailing-list On Sat, Nov 23, 2013 at 05:36:36PM +0100, Stefan Beller wrote: > sb@sb:/tmp$ git clone https://github.com/Bertram25/ValyriaTear.git > Cloning into 'ValyriaTear'... > remote: Counting objects: 21346, done. > remote: Compressing objects: 100% (6307/6307), done. > remote: Total 21346 (delta 16463), reused 19820 (delta 15000) > Receiving objects: 100% (21346/21346), 176.39 MiB | 445.00 KiB/s, done. > Resolving deltas: 100% (16463/16463), done. > Checking connectivity... done. > error: git-remote-https died of signal 13 > > However the repository seems to be cloned fine. > I can clone different repos from github and they are working fine > without the error. > Would that be an issue on my side or on githubs side? Almost certainly on your side. 13 is SIGPIPE, so git-remote-https is trying to write something but the other side of the pipe has hung up. This might be a race condition in the transport-helper protocol, where we've had similar problems before. It doesn't reproduce here for me. Can you reproduce it consistently on this repo? I would not be at all surprised if it is intermittent. If you can reproduce, it would be interesting to see the output with GIT_TRANSPORT_HELPER_DEBUG=1, or even with "strace -f". That could at least tell us what it was trying to write (and to where) when it got the SIGPIPE. -Peff ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: error: git-remote-https died of signal 13 2013-11-24 6:54 ` Jeff King @ 2013-11-24 12:54 ` Stefan Beller 2013-11-24 13:33 ` Jeff King 0 siblings, 1 reply; 22+ messages in thread From: Stefan Beller @ 2013-11-24 12:54 UTC (permalink / raw) To: Jeff King; +Cc: GIT Mailing-list On 24.11.2013 07:54, Jeff King wrote: > On Sat, Nov 23, 2013 at 05:36:36PM +0100, Stefan Beller wrote: > >> sb@sb:/tmp$ git clone https://github.com/Bertram25/ValyriaTear.git >> Cloning into 'ValyriaTear'... >> remote: Counting objects: 21346, done. >> remote: Compressing objects: 100% (6307/6307), done. >> remote: Total 21346 (delta 16463), reused 19820 (delta 15000) >> Receiving objects: 100% (21346/21346), 176.39 MiB | 445.00 KiB/s, done. >> Resolving deltas: 100% (16463/16463), done. >> Checking connectivity... done. >> error: git-remote-https died of signal 13 >> >> However the repository seems to be cloned fine. >> I can clone different repos from github and they are working fine >> without the error. >> Would that be an issue on my side or on githubs side? > > Almost certainly on your side. 13 is SIGPIPE, so git-remote-https is > trying to write something but the other side of the pipe has hung up. > This might be a race condition in the transport-helper protocol, where > we've had similar problems before. > > It doesn't reproduce here for me. Can you reproduce it consistently on > this repo? I would not be at all surprised if it is intermittent. > I tested 3 times before sending the mail and I always got the error. Testing now doesn't always trigger this problem. So yeah it's kind of intermittent. > If you can reproduce, it would be interesting to see the output with > GIT_TRANSPORT_HELPER_DEBUG=1, or even with "strace -f". That could at > least tell us what it was trying to write (and to where) when it got the > SIGPIPE. > > -Peff > Here is the output of sb@sb:/tmp$ GIT_TRANSPORT_HELPER_DEBUG=1 git clone https://github.com/Bertram25/ValyriaTear.git tmp Cloning into 'tmp'... Debug: Remote helper: -> capabilities Debug: Remote helper: Waiting... Debug: Remote helper: <- fetch Debug: Got cap fetch Debug: Remote helper: Waiting... Debug: Remote helper: <- option Debug: Got cap option Debug: Remote helper: Waiting... Debug: Remote helper: <- push Debug: Got cap push Debug: Remote helper: Waiting... Debug: Remote helper: <- check-connectivity Debug: Got cap check-connectivity Debug: Remote helper: Waiting... Debug: Remote helper: <- Debug: Capabilities complete. Debug: Remote helper: Waiting... Debug: Remote helper: <- 064275ea9c91688442ab215b5b641ac93fdd77b0 HEAD Debug: Remote helper: Waiting... Debug: Remote helper: <- a32429792c9b393732bd026d42374f226c928559 refs/heads/0.6 Debug: Remote helper: Waiting... Debug: Remote helper: <- 6153fdaf34d9d3eec5fc1541b0373db6ef0eac25 refs/heads/HEI-Release Debug: Remote helper: Waiting... Debug: Remote helper: <- 9d452017c18389120c662bfe5a3379a0c15458e7 refs/heads/HeroOfAllacrost Debug: Remote helper: Waiting... Debug: Remote helper: <- 064275ea9c91688442ab215b5b641ac93fdd77b0 refs/heads/master Debug: Remote helper: Waiting... Debug: Remote helper: <- f5a3727f88d5c48f3c28af85bd32567772314c1a refs/heads/sdl2 Debug: Remote helper: Waiting... Debug: Remote helper: <- aa2cc4a7961e5c85db8c971f8ca15febeea84ac9 refs/pull/101/head Debug: Remote helper: Waiting... Debug: Remote helper: <- b707dc07da480829b46b31b114fa3335ac10066f refs/pull/101/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 995d48764fd0485e1fd2286768926d33f436b983 refs/pull/103/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 40c6020443fabf86b9516567caf4aa5b4478022d refs/pull/103/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 0fc5e0abd6e5070df90b155a54c80ec07aabb1f0 refs/pull/111/head Debug: Remote helper: Waiting... Debug: Remote helper: <- dd855fe5f09f9984dad933b9512305b9ab539c55 refs/pull/111/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- de0347d77025ad8b87da616c487c650b28834182 refs/pull/114/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 224b18b50c2a0a58c6566972b7d85a5451f5c3aa refs/pull/114/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- fae33cbba4cf3c0a786f23ae6ef1808c77e4d79f refs/pull/115/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 1659dffb9828946b77fc41ef175a91f94d908e55 refs/pull/115/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- ee99c3b5c2e31482c89826c7821a8feadda0ec56 refs/pull/116/head Debug: Remote helper: Waiting... Debug: Remote helper: <- ab9e412654cc8a3f50fcf63e73aa6232e35bd7a9 refs/pull/116/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- a04786140b697f3d732caae99984d94c66d8da57 refs/pull/117/head Debug: Remote helper: Waiting... Debug: Remote helper: <- b07e621e4bce831daf2881eb128b1ebef2b83414 refs/pull/117/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- c303913334cadcaefecb7ef8df51b9437a0d9d65 refs/pull/118/head Debug: Remote helper: Waiting... Debug: Remote helper: <- fd074efa3286be31b92c6380a85ce15799f3ce7d refs/pull/118/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 5eb3c686e430c8337652e56313a23a394482b552 refs/pull/119/head Debug: Remote helper: Waiting... Debug: Remote helper: <- a69fdef2ab67447024133a84ce3835519809ef3a refs/pull/119/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- d217eaf9ee0758e5589a52ca03dde3e741ed139e refs/pull/120/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 2646a7baa37e7abecc32ef64fdc1a8d8390b0078 refs/pull/120/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 67d29a5a5880da9be97ce1b7986a42ca2728a535 refs/pull/133/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 3aa0ca69b8aeaf584da8214fb8659268ea0861fd refs/pull/133/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- b72e8ca2f6983f814a230da6c97efac0092709db refs/pull/135/head Debug: Remote helper: Waiting... Debug: Remote helper: <- fb7bd1c2c190e2802924a04f9b9138680dc7feb6 refs/pull/135/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- ecd8db92684f8b4b306ba22a3d031586867712eb refs/pull/136/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 6f3255b619407401d5e917414b9290b49d29c45e refs/pull/136/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- c818fb005b57df1b6a1702a17c426031f9a7d4f5 refs/pull/137/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 2f20102c596087ee993315ee63668aa0946e4ac7 refs/pull/137/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 8717cfb9f689b12420ed6c1d99b7287809aa08c1 refs/pull/139/head Debug: Remote helper: Waiting... Debug: Remote helper: <- c4342ccd4157722fc04a26a202205c7e1b8bf77e refs/pull/139/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- b7b92e6a0997d8e564b058b25bc4c82426ca4e12 refs/pull/140/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 4035dd121da5218fe45044c1d4a5974e2724a9b6 refs/pull/140/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 47f4834f015392c588e0ee7204552a9c0f648a78 refs/pull/144/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 9a90bfa25c4d448227815b182d78d206a3785be9 refs/pull/145/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 07ff69b42879a1f4ae1d4c747e70a49c4d7f3b6c refs/pull/145/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 6fa31b5145cc9105523bfe358b215d9cb1022290 refs/pull/146/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 0d0ca67bced99463f0bd969b7cd5f6fe1d9dc4dc refs/pull/146/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- e3a4d29fd4c5b33ff7e3359dc0640ae5fcfcdba6 refs/pull/151/head Debug: Remote helper: Waiting... Debug: Remote helper: <- b4e2bda0ba11d2225f4fbbf778a2d2666d9b10b9 refs/pull/151/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- f8a2e833944f1e07e603ea67cd2d2d18ebf52661 refs/pull/152/head Debug: Remote helper: Waiting... Debug: Remote helper: <- b6ecd4822f403b9c7d6f376ab516856ad3b71ecd refs/pull/152/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- f93cde603cc4d5b566507495a9bfa6b7e33870e2 refs/pull/154/head Debug: Remote helper: Waiting... Debug: Remote helper: <- e52682db2a98cd5aff36531d2cac72797fdfc113 refs/pull/154/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- b35e6ef9c42bd58e7dc93a625a6d38369e51eb45 refs/pull/16/head Debug: Remote helper: Waiting... Debug: Remote helper: <- a4b3ec6df618e39076c98e9de9c7d3590cbd6948 refs/pull/16/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 77433715ae16062650125c3ca9c6e3cf4781f556 refs/pull/165/head Debug: Remote helper: Waiting... Debug: Remote helper: <- d344ffb0823d0b6eb783faa61362ace28ce3d25d refs/pull/165/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 807d1212c20a90b3272df065e2d760534de325e7 refs/pull/173/head Debug: Remote helper: Waiting... Debug: Remote helper: <- ddfb5ab3b908fb742eb9600620f062461da96112 refs/pull/173/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 6cea8518d3d8f8c4712dceee2830f391c2ea1386 refs/pull/175/head Debug: Remote helper: Waiting... Debug: Remote helper: <- c6942e7329f65d7e16d3e2c460ed1b90af5204ef refs/pull/175/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 0b74db27b2b1db1dcfdd1b238fd5dcfc4725b3a8 refs/pull/176/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 487fb35d2558a62440487ca5466af53a1cfd1c3c refs/pull/176/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- a2453e58058e57d9f8d55c12cafb42865981df93 refs/pull/177/head Debug: Remote helper: Waiting... Debug: Remote helper: <- b9cd7ec469bf1470317106f4b3e4fa357c16f17c refs/pull/177/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 4ee3fc1bfaee3a9f80f672f11fb9fa7ee7de5ca4 refs/pull/180/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 12dd091a4f2979a1eceb7b775d803a503ca8eacd refs/pull/180/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 7fc474ca95fbd60c4ee2d61d5cfbdb9a681697a5 refs/pull/181/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 7fc03a7250a6a5fb6d29ad7175cb34ae5d897b85 refs/pull/181/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 1acdb17064604518c973e386d80d460a020f14c5 refs/pull/182/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 413e75591bce8c7e2797eabcc41ae3af46765bbd refs/pull/182/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 0009b73972bd3dcfc227df5b5cd9fe3033b7667a refs/pull/183/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 478ad00eeb9a0b0042d8ace521b6963fa79461a0 refs/pull/183/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 2b304b528b76000aa3eb2acef7d3ff56753174dc refs/pull/184/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 6844a78056eaa79cba3d5ffe4b8daaecbd2c05fe refs/pull/184/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- e99f34aaef9e070f2620f336447e0d6b284d9855 refs/pull/185/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 59e47dba9e3b1e80b30d2e88beab5b16983c8db3 refs/pull/185/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 4232e258a00614102b6476d2b79b37a1edc1366c refs/pull/187/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 7a436aa4f88e013f10c3de25bc482d0b8ad1aeeb refs/pull/187/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 11af4677088521ed0c5170baf5bbaceae07b9d45 refs/pull/188/head Debug: Remote helper: Waiting... Debug: Remote helper: <- fdf737cc4887d4ca1941dc82bf1554c522376e61 refs/pull/188/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- c72285165e716550c2b9df5fa1b759dc1d0c24ef refs/pull/189/head Debug: Remote helper: Waiting... Debug: Remote helper: <- debe335a4a68c902b3d2b157454619f259a1b551 refs/pull/189/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- e95006ba47f1fea8164a154dbea59d6f0e5ad475 refs/pull/190/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 29e47864f058438b4f3a44d837d9124a64171182 refs/pull/190/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- dd2640db2289b36cd3af001d296d04bf420c2f30 refs/pull/191/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 888b9fedef90129fac9caf24fc67aa3dce48163f refs/pull/191/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- bc3ec56780376ffe01786baf09945e98107446b2 refs/pull/192/head Debug: Remote helper: Waiting... Debug: Remote helper: <- cb40ac81e4a19a61dff274d6ff56bc731c8f9971 refs/pull/192/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 3a5d3c3af3a695c605daf93d583e1e02cd5c9a24 refs/pull/193/head Debug: Remote helper: Waiting... Debug: Remote helper: <- d703ebb170d59fb41541c6523e3b83af51ab07b0 refs/pull/193/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- d37e2d4360034128379f3083d54fc9769b26debb refs/pull/194/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 7378a71cac536206fafb5eb2258e2f9e98671f45 refs/pull/194/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 5b7d90a9fa1e06f5612cded44a247d75905be90c refs/pull/195/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 47bad1ecbf6fd00bb6e2ede9ed65b5ecc21b85f3 refs/pull/195/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- abe8a4a2a04abf33b41e0d3a5a11bdb8a1922978 refs/pull/196/head Debug: Remote helper: Waiting... Debug: Remote helper: <- def0e6f2650bdfa8d9dcdb8b6fdbcfda4f82eb84 refs/pull/196/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- a0ac4fe552872927f5c93c326eca7be53aaa788c refs/pull/197/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 1a398e0cff4849840f2f4bd14eca0579cb1f7ed6 refs/pull/197/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 65c48a7d691840df90ebe260b25d83e2d969a69b refs/pull/200/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 38ef1e4e2cb68b32766facffdbdc74a43df748de refs/pull/200/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 0188e20da2e289862f93bbb093ca4522fb308de1 refs/pull/205/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 70d3eb9ce5788cc66d9ced7a1e3a78c4a09eccf3 refs/pull/205/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 65ee01faedf5c4e53d963277c32509007f91986f refs/pull/211/head Debug: Remote helper: Waiting... Debug: Remote helper: <- b82b7dcecca61fe252f257efb524c0d7c5ab5c0f refs/pull/211/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 92ab6ecc3036ecfb2d8816b71abef06be6e507b5 refs/pull/213/head Debug: Remote helper: Waiting... Debug: Remote helper: <- ebeac4813732feec180ffa3bc58d503cd5928455 refs/pull/213/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- e2bef652b8054406d13dafb7bae8bf6840c51a2f refs/pull/219/head Debug: Remote helper: Waiting... Debug: Remote helper: <- c5a947558c15a58e649b0799385c0832c61be603 refs/pull/219/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 3de31950417820b88ce181cff1e0741e9a50b785 refs/pull/225/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 615373767843d9b519691c63f1e22ffadea19b6a refs/pull/225/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- b1136a8dbf9f85fb16bf74b2dca70c5f251b5e32 refs/pull/244/head Debug: Remote helper: Waiting... Debug: Remote helper: <- b1d84a951623221dafc9a928cfcbdf8d2c9fee5a refs/pull/244/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 6b53813f0e5ac1fe7e005791d5b78163a6c0d8be refs/pull/249/head Debug: Remote helper: Waiting... Debug: Remote helper: <- cd3acb3a216aaf06506fa534cf431683628bc007 refs/pull/249/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 9006bfd8333a599b4a0354cf9f47898a652ee0e6 refs/pull/27/head Debug: Remote helper: Waiting... Debug: Remote helper: <- b2d1abb763c02d2a46093a855cdba65f2a78a80c refs/pull/27/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 7536a0ce010b4667522fa3c30f470d13c3cb32da refs/pull/28/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 31a511e20dd4e51a09cba26495551481a548e9cd refs/pull/28/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 1ebb44d3baca29026a96e2741a8bc742bd82d648 refs/pull/29/head Debug: Remote helper: Waiting... Debug: Remote helper: <- b49b3e90d731cbfe198e7af3367d693ac68fb4ce refs/pull/29/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- b1b038a854fea47676ccf8331f33602a8c507a05 refs/pull/32/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 7ff9bf883561f18d31a27e2b3049d4e846175805 refs/pull/32/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 8951b125c207e4bf8a8432bab067072a33c83f18 refs/pull/34/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 83b7a22622618b545bfe184a6dcd169240c57914 refs/pull/34/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- aa7c6c13177b05eaeab97fdf69d19fa60b1c5b54 refs/pull/35/head Debug: Remote helper: Waiting... Debug: Remote helper: <- d319d6558ab545e84fe9e1c54921200c6a03b0c7 refs/pull/35/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- a434292b75b12ae2a805ef5dbca29f396ac3b68f refs/pull/36/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 0a81bf44197ae941e77bc80a0e80c55b9c42b20e refs/pull/36/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 8634ae7c74fab76bb4ed8369786971bc502bdeaf refs/pull/40/head Debug: Remote helper: Waiting... Debug: Remote helper: <- f2833395e3900cb6eba591fc5e8037af1ca658c0 refs/pull/40/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- f050618b1bfa150e33a2027ad238542d0204ddbf refs/pull/47/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 949d74de7aac670b6a2016466571d283790d3cc7 refs/pull/47/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 87667df4232d81275b0b252ddfbdc85a0c4b1b87 refs/pull/50/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 94b850a29c4c1cb3c159d85d67139e4a364f0fb2 refs/pull/50/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- ffdb4cd9e9f772a85799b0e2333d652c979d8f78 refs/pull/52/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 446e1359e752d94cdd7c9bea77099a588ef2c43c refs/pull/52/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- bf530b81110339279ebcd6546ef73efc957b7a5b refs/pull/59/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 80b665b9daf3e6eb9b7461c61f3854a6f4c99c20 refs/pull/59/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 495bc60651bea4b695bc270d6ae53d6041aa7c92 refs/pull/61/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 0d3fe6839f6cf2038484a8e76236b68c2d6a6f63 refs/pull/61/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 21557db0c13b091dbe81e28dd45ce29e852bd02a refs/pull/69/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 383ac7786539eca3d15e286fd18ac045947acacd refs/pull/69/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 832dea19d6b7cc55e7fde5bffb9f718cc5127e02 refs/pull/70/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 55a6649bef659871c667f043c062b617b55dcf1e refs/pull/70/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- f5837ecffc50b2eed1d208af697cba135b044229 refs/pull/71/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 38ec58be3f554fdd10e4291ec77785dcd260b8a3 refs/pull/71/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- d45d305f03611a4fdcddc517760e88aec6d67109 refs/pull/73/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 78dfbaeabc0fe2026ccba3f825b2cab0eb443834 refs/pull/73/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- d63d8ad0f3140f9e73dad8bd56c2ab53f535a399 refs/pull/76/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 60028c36110cd26418c0fb31efa392f6e0823179 refs/pull/76/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 9c66224187bd8d55b0cf9b2c0d15a886c5559222 refs/pull/77/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 4b1f63112800fb0a31160d6ea80bb91465771548 refs/pull/77/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 58462ec625d22c0f562acf4865d97e3082d89b1d refs/pull/78/head Debug: Remote helper: Waiting... Debug: Remote helper: <- e607ed1342bf7e38931019baee6d64fd41c98980 refs/pull/78/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 9ad448ffb3e49920b20d36c47e410a2d3d0fda12 refs/pull/79/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 34706ec386c721933a4f2d366ee2c951d77cf2d2 refs/pull/79/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 763549817b5af82da1e37ec2711a0f948ba83ef5 refs/pull/86/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 73463b18143a2e4393d567de41c681f7c329f347 refs/pull/86/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- a388e5772e411107af684cfa1eac63875310a332 refs/pull/88/head Debug: Remote helper: Waiting... Debug: Remote helper: <- afbb8c2f38f6fbbf26dc8bd3d6bff925ce30d9b7 refs/pull/88/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 751ef19b2643b931db0811a89ae40cf34f60460f refs/pull/91/head Debug: Remote helper: Waiting... Debug: Remote helper: <- bc829ea8805a9eb766c389bc629d06c9c0b5ce80 refs/pull/91/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- fde3682d22a71e1848fbcbc7346e621518ff49e8 refs/pull/95/head Debug: Remote helper: Waiting... Debug: Remote helper: <- 6bdad763038145e90c12ebac87629a84e95b0197 refs/pull/95/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- e13368413bd5c68f444164e1e944ab52b9487c13 refs/pull/96/head Debug: Remote helper: Waiting... Debug: Remote helper: <- b4f62a2f45f9be4c7f8aa16d5f9c1d15853681d4 refs/pull/96/merge Debug: Remote helper: Waiting... Debug: Remote helper: <- 3af3e0632b5475427646e87b8eb4285582f431d9 refs/tags/0.5.0 Debug: Remote helper: Waiting... Debug: Remote helper: <- 3cece960f3f62af3b0414a1e09013b68db28a186 refs/tags/0.5.1 Debug: Remote helper: Waiting... Debug: Remote helper: <- a32429792c9b393732bd026d42374f226c928559 refs/tags/0.6.0 Debug: Remote helper: Waiting... Debug: Remote helper: <- f805e6aeb4e837900ec365e3bcc659d8ca5a0e5b refs/tags/0.6.0-rc1 Debug: Remote helper: Waiting... Debug: Remote helper: <- 2945a5023280b0f407dc04e08a6efb72ea24cc7c refs/tags/Christmas-Pre-Release Debug: Remote helper: Waiting... Debug: Remote helper: <- 4a419dd6c423d085466fbfd5d5adf1d996f74e04 refs/tags/Christmas-Pre-Release^{} Debug: Remote helper: Waiting... Debug: Remote helper: <- b452068830d19113fb3fdb51ee52232c0534ffbb refs/tags/HEI-RC2 Debug: Remote helper: Waiting... Debug: Remote helper: <- 93233be952de0dc656c9c8440147aaf4a3969567 refs/tags/HEI-RC2^{} Debug: Remote helper: Waiting... Debug: Remote helper: <- Debug: Read ref listing. Debug: Remote helper: -> option progress true Debug: Remote helper: Waiting... Debug: Remote helper: <- ok Debug: Remote helper: -> option verbosity 1 Debug: Remote helper: Waiting... Debug: Remote helper: <- ok Debug: Remote helper: -> option check-connectivity true Debug: Remote helper: Waiting... Debug: Remote helper: <- ok Debug: Remote helper: -> fetch 064275ea9c91688442ab215b5b641ac93fdd77b0 HEAD fetch a32429792c9b393732bd026d42374f226c928559 refs/heads/0.6 fetch 6153fdaf34d9d3eec5fc1541b0373db6ef0eac25 refs/heads/HEI-Release fetch 9d452017c18389120c662bfe5a3379a0c15458e7 refs/heads/HeroOfAllacrost fetch 064275ea9c91688442ab215b5b641ac93fdd77b0 refs/heads/master fetch f5a3727f88d5c48f3c28af85bd32567772314c1a refs/heads/sdl2 fetch 3af3e0632b5475427646e87b8eb4285582f431d9 refs/tags/0.5.0 fetch 3cece960f3f62af3b0414a1e09013b68db28a186 refs/tags/0.5.1 fetch a32429792c9b393732bd026d42374f226c928559 refs/tags/0.6.0 fetch f805e6aeb4e837900ec365e3bcc659d8ca5a0e5b refs/tags/0.6.0-rc1 fetch 2945a5023280b0f407dc04e08a6efb72ea24cc7c refs/tags/Christmas-Pre-Release fetch b452068830d19113fb3fdb51ee52232c0534ffbb refs/tags/HEI-RC2 Debug: Remote helper: Waiting... remote: Counting objects: 21346, done. remote: Compressing objects: 100% (6307/6307), done. remote: Total 21346 (delta 16463), reused 19820 (delta 15000) Receiving objects: 100% (21346/21346), 176.39 MiB | 619.00 KiB/s, done. Resolving deltas: 100% (16463/16463), done. Debug: Remote helper: <- lock /tmp/tmp/.git/objects/pack/pack-0fbfc20b972e818e42e3c83a68d80bf4bf9f80ef.keep Debug: Remote helper: Waiting... Debug: Remote helper: <- connectivity-ok Debug: Remote helper: Waiting... Debug: Remote helper: <- Checking connectivity... done. Debug: Disconnecting. error: git-remote-https died of signal 13 sb@sb:/tmp$ The output of "strace -f git clone ..." is 100M, so attaching and sending to the list is no option, but the error is also in there $ cat strace_err |grep died write(2, "error: git-remote-https died of "..., 42error: git-remote-https died of signal 13 If you're interested in peaking around that file, obtain it with wget http://www.stefanbeller.de/tmp/strace_err Thanks, Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: error: git-remote-https died of signal 13 2013-11-24 12:54 ` Stefan Beller @ 2013-11-24 13:33 ` Jeff King 2013-11-24 15:01 ` Stefan Beller 0 siblings, 1 reply; 22+ messages in thread From: Jeff King @ 2013-11-24 13:33 UTC (permalink / raw) To: Stefan Beller; +Cc: GIT Mailing-list On Sun, Nov 24, 2013 at 01:54:34PM +0100, Stefan Beller wrote: > Here is the output of > sb@sb:/tmp$ GIT_TRANSPORT_HELPER_DEBUG=1 git clone https://github.com/Bertram25/ValyriaTear.git tmp Thanks. I think I see what is going on. We finish the helper conversation here: > Checking connectivity... done. > Debug: Disconnecting. > error: git-remote-https died of signal 13 > sb@sb:/tmp$ which means that remote-https is trying to exit, and is cleaning up any curl connections. The actual SIGPIPE in the strace is here: [pid 28319] write(3, "\25\3\2\0...[binary goo]...", 27) = -1 EPIPE (Broken pipe) and if you walk backwards, fd 3 is: [pid 28319] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 ... [pid 28319] connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.30.252.131")}, 16 ) = -1 EINPROGRESS (Operation now in progress) So it's sending binary junk to the https socket while trying to exit, which makes me guess that it's something to do with terminating the SSL session, but the server has already hung up. Which would make it a curl problem. Googling "curl sigpipe" seems to come up with a report of this exact case: http://curl.haxx.se/mail/archive-2013-01/0003.html with a bug opened here: http://sourceforge.net/p/curl/bugs/1180/ Looks like the fix went into curl 7.32.0. I have 7.33.0, which seems fine. Can you confirm that your libcurl is a bit older? -Peff ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: error: git-remote-https died of signal 13 2013-11-24 13:33 ` Jeff King @ 2013-11-24 15:01 ` Stefan Beller 2013-11-24 15:54 ` Jeff King 0 siblings, 1 reply; 22+ messages in thread From: Stefan Beller @ 2013-11-24 15:01 UTC (permalink / raw) To: Jeff King; +Cc: GIT Mailing-list On 24.11.2013 14:33, Jeff King wrote: > On Sun, Nov 24, 2013 at 01:54:34PM +0100, Stefan Beller wrote: > >> Here is the output of >> sb@sb:/tmp$ GIT_TRANSPORT_HELPER_DEBUG=1 git clone https://github.com/Bertram25/ValyriaTear.git tmp > > Thanks. I think I see what is going on. > > We finish the helper conversation here: > >> Checking connectivity... done. >> Debug: Disconnecting. >> error: git-remote-https died of signal 13 >> sb@sb:/tmp$ > > which means that remote-https is trying to exit, and is cleaning up any > curl connections. The actual SIGPIPE in the strace is here: > > [pid 28319] write(3, "\25\3\2\0...[binary goo]...", 27) = -1 EPIPE (Broken pipe) > > and if you walk backwards, fd 3 is: > > [pid 28319] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 > ... > [pid 28319] connect(3, {sa_family=AF_INET, > sin_port=htons(443), > sin_addr=inet_addr("192.30.252.131")}, 16 > ) = -1 EINPROGRESS (Operation now in progress) > > So it's sending binary junk to the https socket while trying to exit, > which makes me guess that it's something to do with terminating the SSL > session, but the server has already hung up. Which would make it a curl > problem. > > Googling "curl sigpipe" seems to come up with a report of this exact > case: > > http://curl.haxx.se/mail/archive-2013-01/0003.html I cannot reproduce the error using the curl command from that site. curl returns with 0. > > with a bug opened here: > > http://sourceforge.net/p/curl/bugs/1180/ > > Looks like the fix went into curl 7.32.0. I have 7.33.0, which seems > fine. Can you confirm that your libcurl is a bit older? > dpkg -l |grep curl ii curl 7.32.0-1ubuntu1 amd64 command line tool for transferring data with URL syntax ii libcurl3:amd64 7.32.0-1ubuntu1 amd64 easy-to-use client-side URL transfer library (OpenSSL flavour) ii libcurl3-gnutls:amd64 7.32.0-1ubuntu1 amd64 easy-to-use client-side URL transfer library (GnuTLS flavour) ii libcurl4-openssl-dev 7.32.0-1ubuntu1 amd64 development files and documentation for libcurl (OpenSSL flavour) ii python-pycurl 7.19.0-5ubuntu8 amd64 Python bindings to libcurl Thanks, Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: error: git-remote-https died of signal 13 2013-11-24 15:01 ` Stefan Beller @ 2013-11-24 15:54 ` Jeff King 2013-11-24 16:13 ` Stefan Beller ` (3 more replies) 0 siblings, 4 replies; 22+ messages in thread From: Jeff King @ 2013-11-24 15:54 UTC (permalink / raw) To: Stefan Beller; +Cc: Daniel Stenberg, GIT Mailing-list [+cc Daniel, who worked on the curl fix] On Sun, Nov 24, 2013 at 04:01:43PM +0100, Stefan Beller wrote: > On 24.11.2013 14:33, Jeff King wrote: > > On Sun, Nov 24, 2013 at 01:54:34PM +0100, Stefan Beller wrote: > > > >> Here is the output of > >> sb@sb:/tmp$ GIT_TRANSPORT_HELPER_DEBUG=1 git clone https://github.com/Bertram25/ValyriaTear.git tmp > > > > Thanks. I think I see what is going on. > > > > We finish the helper conversation here: > > > >> Checking connectivity... done. > >> Debug: Disconnecting. > >> error: git-remote-https died of signal 13 > >> sb@sb:/tmp$ > > > > which means that remote-https is trying to exit, and is cleaning up any > > curl connections. The actual SIGPIPE in the strace is here: > > > > [pid 28319] write(3, "\25\3\2\0...[binary goo]...", 27) = -1 EPIPE (Broken pipe) > > > > and if you walk backwards, fd 3 is: > > > > [pid 28319] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 > > ... > > [pid 28319] connect(3, {sa_family=AF_INET, > > sin_port=htons(443), > > sin_addr=inet_addr("192.30.252.131")}, 16 > > ) = -1 EINPROGRESS (Operation now in progress) > > > > So it's sending binary junk to the https socket while trying to exit, > > which makes me guess that it's something to do with terminating the SSL > > session, but the server has already hung up. Which would make it a curl > > problem. > > > > Googling "curl sigpipe" seems to come up with a report of this exact > > case: > > > > http://curl.haxx.se/mail/archive-2013-01/0003.html > > I cannot reproduce the error using the curl command from that site. > curl returns with 0. > > > > > with a bug opened here: > > > > http://sourceforge.net/p/curl/bugs/1180/ > > > > Looks like the fix went into curl 7.32.0. I have 7.33.0, which seems > > fine. Can you confirm that your libcurl is a bit older? > > > > dpkg -l |grep curl > ii curl 7.32.0-1ubuntu1 amd64 command line tool for transferring data with URL syntax > ii libcurl3:amd64 7.32.0-1ubuntu1 amd64 easy-to-use client-side URL transfer library (OpenSSL flavour) > ii libcurl3-gnutls:amd64 7.32.0-1ubuntu1 amd64 easy-to-use client-side URL transfer library (GnuTLS flavour) > ii libcurl4-openssl-dev 7.32.0-1ubuntu1 amd64 development files and documentation for libcurl (OpenSSL flavour) > ii python-pycurl 7.19.0-5ubuntu8 amd64 Python bindings to libcurl Hmm. The fix in curl's 7d80ed64e435155 seems to involve strategically placed calls to ignore SIGPIPE. I wonder if there is another spot that needs similar treatment. It looks like curl_easy_cleanup is covered, though, and that's where I would expect problem to come. It would be interesting to see a backtrace from remote-curl when we get the SIGPIPE. Doing so would be slightly tricky; instrumenting with the patch below may be enough. Another thought is that the curl fix seems to only kick in when built with openssl support. I'm not sure I understand how ubuntu's packaging of curl uses gnutls versus openssl for the shared library. That may be related. -Peff --- diff --git a/http.c b/http.c index bcf54aa..ac709cc 100644 --- a/http.c +++ b/http.c @@ -473,13 +473,17 @@ void http_cleanup(void) { struct active_request_slot *slot = active_queue_head; + warning("in http_cleanup"); while (slot != NULL) { struct active_request_slot *next = slot->next; if (slot->curl != NULL) { #ifdef USE_CURL_MULTI + warning("calling curl_multi_remove_handle"); curl_multi_remove_handle(curlm, slot->curl); #endif + warning("calling curl_easy_cleanup on slot"); curl_easy_cleanup(slot->curl); + warning("curl_easy_cleanup done"); } free(slot); slot = next; @@ -487,13 +491,19 @@ void http_cleanup(void) active_queue_head = NULL; #ifndef NO_CURL_EASY_DUPHANDLE + warning("calling curl_easy_cleanup on default"); curl_easy_cleanup(curl_default); + warning("curl_easy_cleanup done"); #endif #ifdef USE_CURL_MULTI + warning("calling curl_multi_cleanup"); curl_multi_cleanup(curlm); + warning("curl_multi_cleanup done"); #endif + warning("calling curl_global_cleanup"); curl_global_cleanup(); + warning("curl_global_cleanup done"); curl_slist_free_all(pragma_header); pragma_header = NULL; ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: error: git-remote-https died of signal 13 2013-11-24 15:54 ` Jeff King @ 2013-11-24 16:13 ` Stefan Beller 2013-11-24 16:32 ` Stefan Beller ` (2 subsequent siblings) 3 siblings, 0 replies; 22+ messages in thread From: Stefan Beller @ 2013-11-24 16:13 UTC (permalink / raw) To: Jeff King; +Cc: Daniel Stenberg, GIT Mailing-list On 24.11.2013 16:54, Jeff King wrote: > Hmm. The fix in curl's 7d80ed64e435155 seems to involve strategically > placed calls to ignore SIGPIPE. I wonder if there is another spot that > needs similar treatment. It looks like curl_easy_cleanup is covered, > though, and that's where I would expect problem to come. > > It would be interesting to see a backtrace from remote-curl when we get > the SIGPIPE. Doing so would be slightly tricky; instrumenting with the > patch below may be enough. Ok I'll test that now. > > Another thought is that the curl fix seems to only kick in when built > with openssl support. I'm not sure I understand how ubuntu's packaging > of curl uses gnutls versus openssl for the shared library. That may be > related. > A better information would be the --version from curl then: curl --version curl 7.32.0 (x86_64-pc-linux-gnu) libcurl/7.32.0 OpenSSL/1.0.1e zlib/1.2.8 libidn/1.28 librtmp/2.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: error: git-remote-https died of signal 13 2013-11-24 15:54 ` Jeff King 2013-11-24 16:13 ` Stefan Beller @ 2013-11-24 16:32 ` Stefan Beller 2013-11-25 6:39 ` Jeff King 2013-11-24 22:13 ` Daniel Stenberg 2013-11-24 23:51 ` brian m. carlson 3 siblings, 1 reply; 22+ messages in thread From: Stefan Beller @ 2013-11-24 16:32 UTC (permalink / raw) To: Jeff King; +Cc: Daniel Stenberg, GIT Mailing-list On 24.11.2013 16:54, Jeff King wrote: > [+cc Daniel, who worked on the curl fix] > > On Sun, Nov 24, 2013 at 04:01:43PM +0100, Stefan Beller wrote: > >> On 24.11.2013 14:33, Jeff King wrote: >>> On Sun, Nov 24, 2013 at 01:54:34PM +0100, Stefan Beller wrote: >>> >>>> Here is the output of >>>> sb@sb:/tmp$ GIT_TRANSPORT_HELPER_DEBUG=1 git clone https://github.com/Bertram25/ValyriaTear.git tmp >>> >>> Thanks. I think I see what is going on. >>> >>> We finish the helper conversation here: >>> >>>> Checking connectivity... done. >>>> Debug: Disconnecting. >>>> error: git-remote-https died of signal 13 >>>> sb@sb:/tmp$ >>> >>> which means that remote-https is trying to exit, and is cleaning up any >>> curl connections. The actual SIGPIPE in the strace is here: >>> >>> [pid 28319] write(3, "\25\3\2\0...[binary goo]...", 27) = -1 EPIPE (Broken pipe) >>> >>> and if you walk backwards, fd 3 is: >>> >>> [pid 28319] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 >>> ... >>> [pid 28319] connect(3, {sa_family=AF_INET, >>> sin_port=htons(443), >>> sin_addr=inet_addr("192.30.252.131")}, 16 >>> ) = -1 EINPROGRESS (Operation now in progress) >>> >>> So it's sending binary junk to the https socket while trying to exit, >>> which makes me guess that it's something to do with terminating the SSL >>> session, but the server has already hung up. Which would make it a curl >>> problem. >>> >>> Googling "curl sigpipe" seems to come up with a report of this exact >>> case: >>> >>> http://curl.haxx.se/mail/archive-2013-01/0003.html >> >> I cannot reproduce the error using the curl command from that site. >> curl returns with 0. >> >>> >>> with a bug opened here: >>> >>> http://sourceforge.net/p/curl/bugs/1180/ >>> >>> Looks like the fix went into curl 7.32.0. I have 7.33.0, which seems >>> fine. Can you confirm that your libcurl is a bit older? >>> >> >> dpkg -l |grep curl >> ii curl 7.32.0-1ubuntu1 amd64 command line tool for transferring data with URL syntax >> ii libcurl3:amd64 7.32.0-1ubuntu1 amd64 easy-to-use client-side URL transfer library (OpenSSL flavour) >> ii libcurl3-gnutls:amd64 7.32.0-1ubuntu1 amd64 easy-to-use client-side URL transfer library (GnuTLS flavour) >> ii libcurl4-openssl-dev 7.32.0-1ubuntu1 amd64 development files and documentation for libcurl (OpenSSL flavour) >> ii python-pycurl 7.19.0-5ubuntu8 amd64 Python bindings to libcurl > > Hmm. The fix in curl's 7d80ed64e435155 seems to involve strategically > placed calls to ignore SIGPIPE. I wonder if there is another spot that > needs similar treatment. It looks like curl_easy_cleanup is covered, > though, and that's where I would expect problem to come. > > It would be interesting to see a backtrace from remote-curl when we get > the SIGPIPE. Doing so would be slightly tricky; instrumenting with the > patch below may be enough. > GIT_TRANSPORT_HELPER_DEBUG=1 git clone https://github.com/Bertram25/ValyriaTear.git now ends with: Debug: Remote helper: Waiting... remote: Counting objects: 21354, done. remote: Compressing objects: 100% (6249/6249), done. remote: Total 21354 (delta 16466), reused 19888 (delta 15066) Receiving objects: 100% (21354/21354), 176.42 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (16466/16466), done. Debug: Remote helper: <- lock /tmp/ValyriaTear/.git/objects/pack/pack-b6f360ab28b5078a9aefafe1c4144e6c7782c317.keep Debug: Remote helper: Waiting... Debug: Remote helper: <- connectivity-ok Debug: Remote helper: Waiting... Debug: Remote helper: <- Checking connectivity... done. Debug: Disconnecting. warning: in http_cleanup warning: calling curl_multi_remove_handle warning: calling curl_easy_cleanup on slot warning: curl_easy_cleanup done warning: calling curl_easy_cleanup on default warning: curl_easy_cleanup done warning: calling curl_multi_cleanup error: git-remote-https died of signal 13 Thanks, Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: error: git-remote-https died of signal 13 2013-11-24 16:32 ` Stefan Beller @ 2013-11-25 6:39 ` Jeff King 2013-11-25 7:20 ` Daniel Stenberg 0 siblings, 1 reply; 22+ messages in thread From: Jeff King @ 2013-11-25 6:39 UTC (permalink / raw) To: Stefan Beller; +Cc: Daniel Stenberg, GIT Mailing-list On Sun, Nov 24, 2013 at 05:32:34PM +0100, Stefan Beller wrote: > GIT_TRANSPORT_HELPER_DEBUG=1 git clone https://github.com/Bertram25/ValyriaTear.git > now ends with: > > Debug: Remote helper: Waiting... > remote: Counting objects: 21354, done. > remote: Compressing objects: 100% (6249/6249), done. > remote: Total 21354 (delta 16466), reused 19888 (delta 15066) > Receiving objects: 100% (21354/21354), 176.42 MiB | 1.22 MiB/s, done. > Resolving deltas: 100% (16466/16466), done. > Debug: Remote helper: <- lock /tmp/ValyriaTear/.git/objects/pack/pack-b6f360ab28b5078a9aefafe1c4144e6c7782c317.keep > Debug: Remote helper: Waiting... > Debug: Remote helper: <- connectivity-ok > Debug: Remote helper: Waiting... > Debug: Remote helper: <- > Checking connectivity... done. > Debug: Disconnecting. > warning: in http_cleanup > warning: calling curl_multi_remove_handle > warning: calling curl_easy_cleanup on slot > warning: curl_easy_cleanup done > warning: calling curl_easy_cleanup on default > warning: curl_easy_cleanup done > warning: calling curl_multi_cleanup > error: git-remote-https died of signal 13 Thanks. I'm having trouble reproducing the SIGPIPE locally, but I am able to see via strace the write we make in curl_multi_cleanup. The call stack is: curl_multi_cleanup -> close_all_connections -> Curl_disconnect -> Curl_ossl_close ... Daniel, does the call to Curl_disconnect need to be wrapped with sigpipe_ignore/reset, similar to 7d80ed64e435155? -Peff ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: error: git-remote-https died of signal 13 2013-11-25 6:39 ` Jeff King @ 2013-11-25 7:20 ` Daniel Stenberg 2013-11-25 14:32 ` Jeff King 0 siblings, 1 reply; 22+ messages in thread From: Daniel Stenberg @ 2013-11-25 7:20 UTC (permalink / raw) To: Jeff King; +Cc: Stefan Beller, GIT Mailing-list On Mon, 25 Nov 2013, Jeff King wrote: > Thanks. I'm having trouble reproducing the SIGPIPE locally, but I am able to > see via strace the write we make in curl_multi_cleanup. The call stack is: > > curl_multi_cleanup > -> close_all_connections > -> Curl_disconnect > -> Curl_ossl_close > ... > > Daniel, does the call to Curl_disconnect need to be wrapped with > sigpipe_ignore/reset, similar to 7d80ed64e435155? Yes. It very much looks like that. The SSL "closing" is what was the problem I had to adress. But I then decided that if a 3rd library has one way to generate SIGPIPE it may very well have another in a separate spot so I decided to do the wrap at the top level immediately in the entry point when getting called by the application. Following that, the SIGPIPE ignore/restore should rather be made in curl_multi_cleanup. -- / daniel.haxx.se ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: error: git-remote-https died of signal 13 2013-11-25 7:20 ` Daniel Stenberg @ 2013-11-25 14:32 ` Jeff King 2013-11-25 14:35 ` [curl PATCH 1/2] factor out sigpipe_reset from easy.c Jeff King ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Jeff King @ 2013-11-25 14:32 UTC (permalink / raw) To: Daniel Stenberg; +Cc: Stefan Beller, GIT Mailing-list On Mon, Nov 25, 2013 at 08:20:18AM +0100, Daniel Stenberg wrote: > >Daniel, does the call to Curl_disconnect need to be wrapped with > >sigpipe_ignore/reset, similar to 7d80ed64e435155? > > Yes. It very much looks like that. The SSL "closing" is what was the > problem I had to adress. > > But I then decided that if a 3rd library has one way to generate > SIGPIPE it may very well have another in a separate spot so I decided > to do the wrap at the top level immediately in the entry point when > getting called by the application. Following that, the SIGPIPE > ignore/restore should rather be made in curl_multi_cleanup. Unfortunately, we need an actual SessionHandle to know whether it is OK to reset signals at all. There may be a more elegant way of checking that, but here's the patch series I came up with. It does turn off SIGPIPE for the specific case I'm seeing (again, I'm having trouble actually getting EPIPE in the first place, but from Stefan's strace, I think this would fix his problem). [1/2]: factor out sigpipe_reset from easy.c [2/2]: ignore SIGPIPE during curl_multi_cleanup -Peff ^ permalink raw reply [flat|nested] 22+ messages in thread
* [curl PATCH 1/2] factor out sigpipe_reset from easy.c 2013-11-25 14:32 ` Jeff King @ 2013-11-25 14:35 ` Jeff King 2013-11-25 14:43 ` [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup Jeff King 2013-11-25 14:46 ` error: git-remote-https died of signal 13 Jeff King 2 siblings, 0 replies; 22+ messages in thread From: Jeff King @ 2013-11-25 14:35 UTC (permalink / raw) To: Daniel Stenberg; +Cc: Stefan Beller, GIT Mailing-list Commit 7d80ed64e43515 introduced some helpers to handle sigpipe in easy.c. However, that fix was incomplete, and we need to add more callers in other files. The first step is making the helpers globally accessible. Since the functions are small and should generally end up inlined anyway, we simply define them in the header as static functions. Signed-off-by: Jeff King <peff@peff.net> --- We can also do it as a separate '.c' file if you prefer. Note that this will #include the system signal.h at a different point in easy.c now (in particular, after we have included more local headers). I don't know if that has any portability implications. I almost wonder if the SIGPIPE_IGNORE definition (and inclusion of signal.h) should go into curl-setup.h. I have very little knowledge of the curl code base and conventions, so please feel free to hack it up or point me in the right direction. lib/Makefile.inc | 2 +- lib/easy.c | 56 +----------------------------------------------------- lib/sigpipe.h | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 60 insertions(+), 56 deletions(-) create mode 100644 lib/sigpipe.h diff --git a/lib/Makefile.inc b/lib/Makefile.inc index ec71770..62bc0b3 100644 --- a/lib/Makefile.inc +++ b/lib/Makefile.inc @@ -46,4 +46,4 @@ HHEADERS = arpa_telnet.h netrc.h file.h timeval.h qssl.h hostip.h \ curl_ntlm_msgs.h curl_sasl.h curl_schannel.h curl_multibyte.h \ curl_darwinssl.h hostcheck.h bundles.h conncache.h curl_setup_once.h \ multihandle.h setup-vms.h pipeline.h dotdot.h x509asn1.h gskit.h \ - http2.h + http2.h sigpipe.h diff --git a/lib/easy.c b/lib/easy.c index 1e718ab..1dbdcb7 100644 --- a/lib/easy.c +++ b/lib/easy.c @@ -50,11 +50,6 @@ #include <sys/param.h> #endif -#if defined(HAVE_SIGNAL_H) && defined(HAVE_SIGACTION) && defined(USE_OPENSSL) -#define SIGPIPE_IGNORE 1 -#include <signal.h> -#endif - #include "strequal.h" #include "urldata.h" #include <curl/curl.h> @@ -78,6 +73,7 @@ #include "warnless.h" #include "conncache.h" #include "multiif.h" +#include "sigpipe.h" #define _MPRINTF_REPLACE /* use our functions only */ #include <curl/mprintf.h> @@ -85,56 +81,6 @@ /* The last #include file should be: */ #include "memdebug.h" -#ifdef SIGPIPE_IGNORE -struct sigpipe_ignore { - struct sigaction old_pipe_act; - bool no_signal; -}; - -#define SIGPIPE_VARIABLE(x) struct sigpipe_ignore x - -/* - * sigpipe_ignore() makes sure we ignore SIGPIPE while running libcurl - * internals, and then sigpipe_restore() will restore the situation when we - * return from libcurl again. - */ -static void sigpipe_ignore(struct SessionHandle *data, - struct sigpipe_ignore *ig) -{ - /* get a local copy of no_signal because the SessionHandle might not be - around when we restore */ - ig->no_signal = data->set.no_signal; - if(!data->set.no_signal) { - struct sigaction action; - /* first, extract the existing situation */ - memset(&ig->old_pipe_act, 0, sizeof(struct sigaction)); - sigaction(SIGPIPE, NULL, &ig->old_pipe_act); - action = ig->old_pipe_act; - /* ignore this signal */ - action.sa_handler = SIG_IGN; - sigaction(SIGPIPE, &action, NULL); - } -} - -/* - * sigpipe_restore() puts back the outside world's opinion of signal handler - * and SIGPIPE handling. It MUST only be called after a corresponding - * sigpipe_ignore() was used. - */ -static void sigpipe_restore(struct sigpipe_ignore *ig) -{ - if(!ig->no_signal) - /* restore the outside state */ - sigaction(SIGPIPE, &ig->old_pipe_act, NULL); -} - -#else -/* for systems without sigaction */ -#define sigpipe_ignore(x,y) Curl_nop_stmt -#define sigpipe_restore(x) Curl_nop_stmt -#define SIGPIPE_VARIABLE(x) -#endif - /* win32_cleanup() is for win32 socket cleanup functionality, the opposite of win32_init() */ static void win32_cleanup(void) diff --git a/lib/sigpipe.h b/lib/sigpipe.h new file mode 100644 index 0000000..73fb853 --- /dev/null +++ b/lib/sigpipe.h @@ -0,0 +1,58 @@ +#ifndef HEADER_CURL_SIGPIPE_H +#define HEADER_CURL_SIGPIPE_H + +#include "curl_setup.h" + +#if defined(HAVE_SIGNAL_H) && defined(HAVE_SIGACTION) && defined(USE_OPENSSL) +#include <signal.h> + +struct sigpipe_ignore { + struct sigaction old_pipe_act; + bool no_signal; +}; + +#define SIGPIPE_VARIABLE(x) struct sigpipe_ignore x + +/* + * sigpipe_ignore() makes sure we ignore SIGPIPE while running libcurl + * internals, and then sigpipe_restore() will restore the situation when we + * return from libcurl again. + */ +static void sigpipe_ignore(struct SessionHandle *data, + struct sigpipe_ignore *ig) +{ + /* get a local copy of no_signal because the SessionHandle might not be + around when we restore */ + ig->no_signal = data->set.no_signal; + if(!data->set.no_signal) { + struct sigaction action; + /* first, extract the existing situation */ + memset(&ig->old_pipe_act, 0, sizeof(struct sigaction)); + sigaction(SIGPIPE, NULL, &ig->old_pipe_act); + action = ig->old_pipe_act; + /* ignore this signal */ + action.sa_handler = SIG_IGN; + sigaction(SIGPIPE, &action, NULL); + } +} + +/* + * sigpipe_restore() puts back the outside world's opinion of signal handler + * and SIGPIPE handling. It MUST only be called after a corresponding + * sigpipe_ignore() was used. + */ +static void sigpipe_restore(struct sigpipe_ignore *ig) +{ + if(!ig->no_signal) + /* restore the outside state */ + sigaction(SIGPIPE, &ig->old_pipe_act, NULL); +} + +#else +/* for systems without sigaction */ +#define sigpipe_ignore(x,y) Curl_nop_stmt +#define sigpipe_restore(x) Curl_nop_stmt +#define SIGPIPE_VARIABLE(x) +#endif + +#endif /* HEADER_CURL_SIGPIPE_H */ -- 1.8.5.rc3.491.ge1614cf ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup 2013-11-25 14:32 ` Jeff King 2013-11-25 14:35 ` [curl PATCH 1/2] factor out sigpipe_reset from easy.c Jeff King @ 2013-11-25 14:43 ` Jeff King 2013-11-27 21:39 ` Daniel Stenberg 2013-11-25 14:46 ` error: git-remote-https died of signal 13 Jeff King 2 siblings, 1 reply; 22+ messages in thread From: Jeff King @ 2013-11-25 14:43 UTC (permalink / raw) To: Daniel Stenberg; +Cc: Stefan Beller, GIT Mailing-list 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup 2013-11-25 14:43 ` [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup Jeff King @ 2013-11-27 21:39 ` Daniel Stenberg 2018-05-22 10:26 ` curlUser ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Daniel Stenberg @ 2013-11-27 21:39 UTC (permalink / raw) To: Jeff King; +Cc: Stefan Beller, GIT Mailing-list On Mon, 25 Nov 2013, Jeff King wrote: > 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. Thanks a lot. I'll merge these ones in a second and they will be included in the coming 7.34.0 release (due to ship in mid December). -- / daniel.haxx.se ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup 2013-11-27 21:39 ` Daniel Stenberg @ 2018-05-22 10:26 ` curlUser 2018-05-22 10:50 ` Daniel Stenberg 2018-05-22 15:01 ` curlUser 2018-08-03 12:29 ` dxt29 2 siblings, 1 reply; 22+ messages in thread From: curlUser @ 2018-05-22 10:26 UTC (permalink / raw) To: git Hi, Again SIGPIPE is seen with curl version 7.45.0 with multi interface. Backtrace shows : #7 0x00007f141bea40cd in Curl_ossl_close (conn=0x7f14193f9848, sockindex=0) at vtls/openssl.c:881 #8 0x00007f141bea8f54 in Curl_ssl_close (conn=0x7f14193f9848, sockindex=0) at vtls/vtls.c:527 #9 0x00007f141be63969 in Curl_disconnect (conn=0x7f14193f9848, dead_connection=true) at url.c:2791 #10 0x00007f141be63f4b in disconnect_if_dead (conn=0x7f14193f9848, data=0xb6a598) at url.c:3050 #11 0x00007f141be63f84 in call_disconnect_if_dead (conn=0x7f14193f9848, param=0xb6a598) at url.c:3066 #12 0x00007f141bea01c2 in Curl_conncache_foreach (connc=0xae0f48, param=0xb6a598, func=0x7f141be63f59 <call_disconnect_if_dead>) at conncache.c:295 #13 0x00007f141be6400f in prune_dead_connections (data=0xb6a598) at url.c:3081 Looks like SIGPIPE_IGNORE to be added in prune_dead connections or in disconnect_if_dead? Can anyone comment on this. -- Sent from: http://git.661346.n2.nabble.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup 2018-05-22 10:26 ` curlUser @ 2018-05-22 10:50 ` Daniel Stenberg [not found] ` <CAG4qzjti3MRXZ_Kofbb8b6whwDw7Se8g1VAe0mcU4ZdiWRfxpQ@mail.gmail.com> 0 siblings, 1 reply; 22+ messages in thread From: Daniel Stenberg @ 2018-05-22 10:50 UTC (permalink / raw) To: curlUser; +Cc: git On Tue, 22 May 2018, curlUser wrote: > Again SIGPIPE is seen with curl version 7.45.0 with multi interface. > Backtrace shows : ... > Looks like SIGPIPE_IGNORE to be added in prune_dead connections or in > disconnect_if_dead? Can anyone comment on this. I'm pretty sure this issue isn't present in any recent libcurl versions, but if you can reproduce it with 7.60.0, I'll be very interested. -- / daniel.haxx.se ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <CAG4qzjti3MRXZ_Kofbb8b6whwDw7Se8g1VAe0mcU4ZdiWRfxpQ@mail.gmail.com>]
* Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup [not found] ` <CAG4qzjti3MRXZ_Kofbb8b6whwDw7Se8g1VAe0mcU4ZdiWRfxpQ@mail.gmail.com> @ 2018-05-22 15:06 ` Daniel Stenberg 0 siblings, 0 replies; 22+ messages in thread From: Daniel Stenberg @ 2018-05-22 15:06 UTC (permalink / raw) To: Suganthi; +Cc: git On Tue, 22 May 2018, Suganthi wrote: > We may not be able to upgrade to 7.60.0 any soon, Is the fix present in 7.45 > , in this sequence of code. Please let me know. I don't know. I can't recall any SIGPIPE problems in recent days in libcurl, which is why I believe this problem doesn't exist anymore. libcurl 7.45.0 is 2.5 years and 1500+ bug fixes old after all. My casual searches for a curl problem like this - fixed in 7.45.0 or later - also failed. -- / daniel.haxx.se ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup 2013-11-27 21:39 ` Daniel Stenberg 2018-05-22 10:26 ` curlUser @ 2018-05-22 15:01 ` curlUser 2018-08-03 12:29 ` dxt29 2 siblings, 0 replies; 22+ messages in thread From: curlUser @ 2018-05-22 15:01 UTC (permalink / raw) To: git We may not be able to upgrade to 7.60.0 any soon, Is the fix present in 7.45 , in this sequence of code. Please let me know. -- Sent from: http://git.661346.n2.nabble.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup 2013-11-27 21:39 ` Daniel Stenberg 2018-05-22 10:26 ` curlUser 2018-05-22 15:01 ` curlUser @ 2018-08-03 12:29 ` dxt29 2 siblings, 0 replies; 22+ messages in thread From: dxt29 @ 2018-08-03 12:29 UTC (permalink / raw) To: git I have curl 7.35.0 installed on my ubuntu14.04, version infos is as below I have recompiled git against openssl. the git version is 1.9.1. I encountered this error "error: git-remote-http died of signal 13" when I issue `git clone http://github.com/tensorflow/tensorflow.git`. Should I upgrade curl to a higher version? Or is there other easy solutions? Thanks. -- Sent from: http://git.661346.n2.nabble.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: error: git-remote-https died of signal 13 2013-11-25 14:32 ` Jeff King 2013-11-25 14:35 ` [curl PATCH 1/2] factor out sigpipe_reset from easy.c Jeff King 2013-11-25 14:43 ` [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup Jeff King @ 2013-11-25 14:46 ` Jeff King 2 siblings, 0 replies; 22+ messages in thread From: Jeff King @ 2013-11-25 14:46 UTC (permalink / raw) To: Daniel Stenberg; +Cc: Stefan Beller, GIT Mailing-list On Mon, Nov 25, 2013 at 09:32:13AM -0500, Jeff King wrote: > > But I then decided that if a 3rd library has one way to generate > > SIGPIPE it may very well have another in a separate spot so I decided > > to do the wrap at the top level immediately in the entry point when > > getting called by the application. Following that, the SIGPIPE > > ignore/restore should rather be made in curl_multi_cleanup. > > Unfortunately, we need an actual SessionHandle to know whether it is OK > to reset signals at all. There may be a more elegant way of checking > that, but here's the patch series I came up with. Scratch that. I had originally written something like: if (conn->data) sigpipe_ignore(conn->data, &pipe); Curl_disconnect(conn, ...); sigpipe_restore(&pipe); but while sending it out, I realized that the "data" we attach to each connection when we close it is just the multi->closure_handle. So I was able to hoist the check out to curl_multi_cleanup (and that's what I just sent). -Peff ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: error: git-remote-https died of signal 13 2013-11-24 15:54 ` Jeff King 2013-11-24 16:13 ` Stefan Beller 2013-11-24 16:32 ` Stefan Beller @ 2013-11-24 22:13 ` Daniel Stenberg 2013-11-24 23:51 ` brian m. carlson 3 siblings, 0 replies; 22+ messages in thread From: Daniel Stenberg @ 2013-11-24 22:13 UTC (permalink / raw) To: Jeff King; +Cc: Stefan Beller, GIT Mailing-list On Sun, 24 Nov 2013, Jeff King wrote: > Hmm. The fix in curl's 7d80ed64e435155 seems to involve strategically placed > calls to ignore SIGPIPE. I wonder if there is another spot that needs > similar treatment. It looks like curl_easy_cleanup is covered, though, and > that's where I would expect problem to come. Sounds like a plausible reason. > It would be interesting to see a backtrace from remote-curl when we get the > SIGPIPE. Doing so would be slightly tricky; instrumenting with the patch > below may be enough. > > Another thought is that the curl fix seems to only kick in when built with > openssl support. I'm not sure I understand how ubuntu's packaging of curl > uses gnutls versus openssl for the shared library. That may be related. I'm only aware of a SIGPIPE problem with openssl that can make it write to the socket in some situations when the remote end is no longer there - something we can't prevent it from doing. I *believe* the problem doesn't exist in the similar way when built to use gnutls, but I may of course be wrong. -- / daniel.haxx.se ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: error: git-remote-https died of signal 13 2013-11-24 15:54 ` Jeff King ` (2 preceding siblings ...) 2013-11-24 22:13 ` Daniel Stenberg @ 2013-11-24 23:51 ` brian m. carlson 3 siblings, 0 replies; 22+ messages in thread From: brian m. carlson @ 2013-11-24 23:51 UTC (permalink / raw) To: Jeff King; +Cc: Stefan Beller, Daniel Stenberg, GIT Mailing-list [-- Attachment #1: Type: text/plain, Size: 1119 bytes --] On Sun, Nov 24, 2013 at 10:54:39AM -0500, Jeff King wrote: > Another thought is that the curl fix seems to only kick in when built > with openssl support. I'm not sure I understand how ubuntu's packaging > of curl uses gnutls versus openssl for the shared library. That may be > related. Debian (and presumably Ubuntu) build the curl source three times: once each for OpenSSL, GnuTLS, and NSS. Each shared library is named differently (libcurl-openssl.so.3, etc.) and in its own package (libcurl3-openssl). The corresponding -dev package for each version sets up the symlinks and install headers to point to the proper version, so you always compile and link as you expect. The reason for this is that Debian cannot distribute GPLv2-only programs (like git) linked against OpenSSL, so GnuTLS becomes necessary. On Debian and Ubuntu, git is by default linked against libcurl3-gnutls. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2018-08-03 12:39 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-23 16:36 error: git-remote-https died of signal 13 Stefan Beller
2013-11-24 6:54 ` Jeff King
2013-11-24 12:54 ` Stefan Beller
2013-11-24 13:33 ` Jeff King
2013-11-24 15:01 ` Stefan Beller
2013-11-24 15:54 ` Jeff King
2013-11-24 16:13 ` Stefan Beller
2013-11-24 16:32 ` Stefan Beller
2013-11-25 6:39 ` Jeff King
2013-11-25 7:20 ` Daniel Stenberg
2013-11-25 14:32 ` Jeff King
2013-11-25 14:35 ` [curl PATCH 1/2] factor out sigpipe_reset from easy.c Jeff King
2013-11-25 14:43 ` [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup Jeff King
2013-11-27 21:39 ` Daniel Stenberg
2018-05-22 10:26 ` curlUser
2018-05-22 10:50 ` Daniel Stenberg
[not found] ` <CAG4qzjti3MRXZ_Kofbb8b6whwDw7Se8g1VAe0mcU4ZdiWRfxpQ@mail.gmail.com>
2018-05-22 15:06 ` Daniel Stenberg
2018-05-22 15:01 ` curlUser
2018-08-03 12:29 ` dxt29
2013-11-25 14:46 ` error: git-remote-https died of signal 13 Jeff King
2013-11-24 22:13 ` Daniel Stenberg
2013-11-24 23:51 ` brian m. carlson
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).