{"thread":{"id":"65881","subject":"Re: 2.54.0: fyi: endless loop at 100% CPU","startedAt":"2026-06-27T19:40:08Z","lastAt":"2026-06-28T16:37:57Z","messageCount":4,"participants":["Michael Montalbo","Steffen Nurpmeso"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"546561","messageId":"CAC2Qwm+48Gpj=AWHzx-nO00bwVfuYoGiwd=3gExbybcOyHC45Q@mail.gmail.com","threadId":"65881","inReplyTo":null,"subject":"Re: 2.54.0: fyi: endless loop at 100% CPU","fromName":"Michael Montalbo","fromEmail":"mmontalbo@gmail.com","sentAt":"2026-06-27T19:39:55Z","receivedAt":"2026-06-27T19:40:08Z","isPatch":false,"body":"Steffen Nurpmeso <steffen@sdaoden.eu> writes:\n> I have no idea and i am not looking either, but my scripted update\n> of tracked repos stuck, and i can a hundred percent reproduce an\n> endless loop that consumes hundred percent CPU by doing\n>\n>  git ls-remote https://gitlab.xiph.org/xiph/opus.git\n\nHello, thank you for the report.\n\nWhen I tried reproducing this locally I was able to get a response\neventually, though there was what seemed to be a stall mid-way\nthrough the response from the server. After looking closer, the linked\nrepo appears to be behind Anubis[1] which may be rate-limiting\nand/or blocking the requests from your script. FWIW, running:\n\nGIT_TRACE_CURL=1 git ls-remote https://gitlab.xiph.org/xiph/opus.git 2>&1\n\nlocally showed the TLS handshake starting then pausing for a significant\nperiod of time before eventually completing the request successfully.\nMaybe running the command with the trace will show something on your\nend?\n\nAlso, here are some other potentially relevant configuration options [2][3]:\n  git -c http.version=HTTP/1.1 \\\n  -c http.lowSpeedLimit=1000 \\\n  -c http.lowSpeedTime=10\n\n[1] https://anubis.techaro.lol/\n[2] https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpversion\n[3] https://git-scm.com/docs/git-config#Documentation/git-config.txt-httplowSpeedLimit\n"},{"id":"546563","messageId":"20260627201558.Bw6A-jbx@steffen%sdaoden.eu","threadId":"65881","inReplyTo":"CAC2Qwm+48Gpj=AWHzx-nO00bwVfuYoGiwd=3gExbybcOyHC45Q@mail.gmail.com","subject":"Re: 2.54.0: fyi: endless loop at 100% CPU","fromName":"Steffen Nurpmeso","fromEmail":"steffen@sdaoden.eu","sentAt":"2026-06-27T20:15:58Z","receivedAt":"2026-06-27T20:16:04Z","isPatch":false,"body":"Michael Montalbo wrote in\n <CAC2Qwm+48Gpj=AWHzx-nO00bwVfuYoGiwd=3gExbybcOyHC45Q@mail.gmail.com>:\n |Steffen Nurpmeso <steffen@sdaoden.eu> writes:\n |> I have no idea and i am not looking either, but my scripted update\n |> of tracked repos stuck, and i can a hundred percent reproduce an\n |> endless loop that consumes hundred percent CPU by doing\n |>\n |>  git ls-remote https://gitlab.xiph.org/xiph/opus.git\n |\n |Hello, thank you for the report.\n |\n |When I tried reproducing this locally I was able to get a response\n |eventually, though there was what seemed to be a stall mid-way\n |through the response from the server. After looking closer, the linked\n |repo appears to be behind Anubis[1] which may be rate-limiting\n |and/or blocking the requests from your script. FWIW, running:\n |\n |GIT_TRACE_CURL=1 git ls-remote https://gitlab.xiph.org/xiph/opus.git 2>&1\n\nIt now works for me.  I cannot reproduce it no more.\n(Fwiw i got the same behavior for all repositories there, i track\nmore from there.)\n(And no \"network hang\", that is, whatever, but it really busy\nlooped!)\n\n |locally showed the TLS handshake starting then pausing for a significant\n |period of time before eventually completing the request successfully.\n |Maybe running the command with the trace will show something on your\n |end?\n |\n |Also, here are some other potentially relevant configuration options \\\n |[2][3]:\n |  git -c http.version=HTTP/1.1 \\\n |  -c http.lowSpeedLimit=1000 \\\n |  -c http.lowSpeedTime=10\n |\n |[1] https://anubis.techaro.lol/\n |[2] https://git-scm.com/docs/git-config#Documentation/git-config.txt-htt\\\n |pversion\n |[3] https://git-scm.com/docs/git-config#Documentation/git-config.txt-htt\\\n |plowSpeedLimit\n\nThanks for these pointers, i did not know about such configuration\nvariables.  I will set them like you show.  Before i only had\n\n  [http]\n  sslVerify = true\n  #sslCAInfo = /home/steffen/sec.arena/tls.git/cacert.pem\n  sslTry = true\n\n --End of <CAC2Qwm+48Gpj=AWHzx-nO00bwVfuYoGiwd=3gExbybcOyHC45Q@mail.gmail\\\n .com>\n\nThank you.  Ciao!\n\n--steffen\n|\n|Der Kragenbaer,                The moon bear,\n|der holt sich munter           he cheerfully and one by one\n|einen nach dem anderen runter  wa.ks himself off\n|(By Robert Gernhardt)\n"},{"id":"546572","messageId":"CAC2Qwm+v2pRp30TYJpy8Wxzb7gbX+nzybZ_3A99cHb-xjjpCnQ@mail.gmail.com","threadId":"65881","inReplyTo":"20260627201558.Bw6A-jbx@steffen%sdaoden.eu","subject":"Re: 2.54.0: fyi: endless loop at 100% CPU","fromName":"Michael Montalbo","fromEmail":"mmontalbo@gmail.com","sentAt":"2026-06-27T23:03:14Z","receivedAt":"2026-06-27T23:03:27Z","isPatch":false,"body":"On Sat, Jun 27, 2026 at 1:16 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:\n>\n> Thanks for these pointers, i did not know about such configuration\n> variables.  I will set them like you show.\n\nNo problem! Just to clarify, I'm not sure you should actually use those\nconfiguration values verbatim. I was more pointing in the direction of\npotentially relevant options for debugging / working around the issue.\n"},{"id":"546612","messageId":"20260628163748.ewryhWxh@steffen%sdaoden.eu","threadId":"65881","inReplyTo":"CAC2Qwm+v2pRp30TYJpy8Wxzb7gbX+nzybZ_3A99cHb-xjjpCnQ@mail.gmail.com","subject":"Re: 2.54.0: fyi: endless loop at 100% CPU","fromName":"Steffen Nurpmeso","fromEmail":"steffen@sdaoden.eu","sentAt":"2026-06-28T16:37:48Z","receivedAt":"2026-06-28T16:37:57Z","isPatch":false,"body":"Michael Montalbo wrote in\n <CAC2Qwm+v2pRp30TYJpy8Wxzb7gbX+nzybZ_3A99cHb-xjjpCnQ@mail.gmail.com>:\n |On Sat, Jun 27, 2026 at 1:16 PM Steffen Nurpmeso <steffen@sdaoden.eu> \\\n |wrote:\n |>\n |> Thanks for these pointers, i did not know about such configuration\n |> variables.  I will set them like you show.\n |\n |No problem! Just to clarify, I'm not sure you should actually use those\n |configuration values verbatim. I was more pointing in the direction of\n |potentially relevant options for debugging / working around the issue.\n\nWe'll see.  But if there was some kind of \"with love from canada\"\nmisconfiguration -- i have seen quite a bit of those, and\npermanent sub-second page reload was one of those effects, in\na browser though .. and git has a little road 'till it gets to\nthat stage (i hope) -- then maybe these settings .. Or i have to\ntweak.\n\nRestartable \"fetch\" is likely not on that roadmap of git -- that\nwould (have) be(en) so cool.  (But for years i now have\na WireGuard VPN and go through that, which has improved my TCP\nconnectivity / stability massively.  But it is still a thriller to\ngo for some rate-limited fetch of large size ..)\n\nOh.  Maybe i see.\n\n  $ git ls-remote https://gitlab.xiph.org/xiph/opus.git\n  fatal: unable to access 'https://gitlab.xiph.org/xiph/opus.git/': Operation too slow. Less than 1000 bytes/sec transferred the last 10 seconds\n  $ git ls-remote https://gitlab.xiph.org/xiph/opus.git\n  fatal: unable to access 'https://gitlab.xiph.org/xiph/opus.git/': Operation too slow. Less than 500 bytes/sec transferred the last 10 seconds\n  $ git ls-remote https://gitlab.xiph.org/xiph/opus.git\n  fatal: unable to access 'https://gitlab.xiph.org/xiph/opus.git/': Operation too slow. Less than 500 bytes/sec transferred the last 21 seconds\n\nIt succeeds with\n\n  lowSpeedLimit = 500\n  lowSpeedTime = 33\n\nBut at least it does not busy loop:\n\n  steffen   2960  2959   0  0.0   2738   2016 S+   00:00:00 18:26 pts/4    /usr/lib/git-core/git remote-https https://gitlab.xiph.org/xiph/opus.git https://gitlab.xiph.org/xiph/opus.git\n  steffen   2961  2960   0  0.0  41213  11316 S+   00:00:00 18:26 pts/4    /usr/lib/git-core/git-remote-https https://gitlab.xiph.org/xiph/opus.git https://gitlab.xiph.org/xiph/opus.git\n\nUnfortunately no info where and why it busy looped.  If it would\nbe non-blocking I/O and .. in this area, one could understand\na bit.  Some ticks-per-sec limit (without X progress) is not\nconfigurable?  I am not really keen to create a rlimit wrapper\nfor git, or whatever.  (I have limiting cgroups, but still.)\n\nA nice Sunday,\nCiao and greetings from Germany,\n\n--steffen\n|\n|Der Kragenbaer,                The moon bear,\n|der holt sich munter           he cheerfully and one by one\n|einen nach dem anderen runter  wa.ks himself off\n|(By Robert Gernhardt)\n"}]}