Git push causes "Assertion failed" error #6457

Activity

1. dscho commented on Oct 2, 2026

   

   dscho

   on Oct 2, 2026

   Member

   More actions

   Please test the latest snapshot. If it still persists, do try to come up with a more reliable reproducer; Your suggested git push origin HEAD:myBranch works here without any problems.
2. dscho

   added

   unclear

   on Oct 2, 2026
3. jared-m-cohen-civ commented on Oct 2, 2026

   

   jared-m-cohen-civ

   on Oct 2, 2026

   Author

   More actions

   Unfortunately, that isn't really an option. The apps installed on my machine, including Git, are strictly managed by my organization, and they almost certainly would not allow me to install a nightly snapshot build.

   However, I can provide another detail that I forgot to mention, which may help reproduce the issue. The Google thread claims that this issue only affects remote repos with an HTTPS URL. SSH URLs do not trigger the issue, as they bypass Curl entirely and use Windows OpenSSH instead. Can you test with an HTTPS repo and see if that lets you reproduce the problem?
4. dscho commented on Oct 2, 2026

   

   dscho

   on Oct 2, 2026

   Member

   More actions

   The apps installed on my machine, including Git, are strictly managed by my organization, and they almost certainly would not allow me to install a nightly snapshot build.

   The latest snapshot is fully code-signed, just like a full version would be.

   The Google thread claims that this issue only affects remote repos with an HTTPS URL. SSH URLs do not trigger the issue

   Well, yes, I guessed that much, seeing as Git only uses libcurl for the HTTP/HTTPS/FTPS transports. And naturally, I did test this with HTTPS URLs.

   There must be something specific about your data shape (where "data" might include things outside your Git packfiles).
5. jared-m-cohen-civ commented on Oct 2, 2026

   

   jared-m-cohen-civ

   on Oct 2, 2026

   Author

   More actions

   The latest snapshot is fully code-signed, just like a full version would be.

   It wouldn't matter. They're very strict about software versioning and security. Most apps can't even be installed by regular employees like me; only someone with administrator rights (which I don't have) can install software. The only apps I can install myself are those listed in the Software Center app, which only includes stable releases that have been vetted and approved; this is how I got "Git for Windows" installed in the first place.

   There must be something specific about your data shape (where "data" might include things outside your Git packfiles).

   I'm not so sure about that. Pushing this same repo using the Git client bundled with Visual Studio (MinGit 2.55.0 / Git for Windows 2.55.0.windows.5) does still work, which would seem to indicate that the problem is specifically with version 2.56.0.windows.1.
6. becm commented on Oct 2, 2026

   

   becm

   on Oct 2, 2026

   More actions

   @dscho no change with g2734d898d3, running with GIT_CURL_VERBOSE=1 still prints:

   01:11:10.553879 http.c:1033             == Info: !!! WARNING !!!
   01:11:10.553879 http.c:1033             == Info: This is a debug build of libcurl, do not use in production.
   …
   

   Borrowing libcurl-4.dll from MinGit-2.55.0.5-64-bit.zip does not complain about being a debug build.
   Maybe some issue due to the ucrt64 switch?

   @jared-m-cohen-civ calling malloc(0) might be caused by strange condidtions like an empty body or HTTP header.
   Nothing serious, but hard to track down without a reliable (locally debuggable) reproducer.
7. dscho commented on Oct 3, 2026

   

   dscho

   on Oct 3, 2026

   Member

   More actions

   @becm yes, I understand that this works with an older libcurl-4.dll, and I am 99% certain that git-for-windows/MINGW-packages@59514c9 is responsible for this.

   The question is: Why does this assertion trigger at all? That is a bug either in the way Git uses libcurl, or in libcurl itself, and I want to see this bug fixed. I can work around it, but I have a higher standard than merely ignore that assertion.
8. dscho commented on Oct 3, 2026

   

   dscho

   on Oct 3, 2026

   Member

   More actions

   There must be something specific about your data shape (where "data" might include things outside your Git packfiles).

   I'm not so sure about that. Pushing this same repo using the Git client bundled with Visual Studio (MinGit 2.55.0 / Git for Windows 2.55.0.windows.5) does still work, which would seem to indicate that the problem is specifically with version 2.56.0.windows.1.

   @jared-m-cohen-civ you are misreading what is happening here. v2.55 merely "works" because assertions have not been enabled in that build. Assertions are testing hard assumptions, which point to a bug. And the bug is triggered by your specific data shape, there cannot be any question about that at this moment because I have pushed plenty of times, yes, via HTTPS, with the affected libcurl in the time since v8.22.0 was integrated into Git for Windows' SDK, without hitting this assertion even once.
9. jared-m-cohen-civ commented on Oct 5, 2026

   

   jared-m-cohen-civ

   on Oct 5, 2026

   Author

   More actions

   @dscho OK...so what do you suggest? I can't just post my entire project here, it's proprietary code and it's way too big to attach anyway.

   Since we know precisely what line in memdebug.c is triggering the assertion, could you speculate on precisely what condition(s) would need to be present in order for that assertion to fail? Then I could try creating a dummy project that meets those conditions, and use that as your local reproducer.
10. dscho commented on Oct 5, 2026

    

    dscho

    on Oct 5, 2026

    Member

    More actions

    In the future, I might let this report serve as an excellent example how bug reports with too terse, too little information can quite possibly cause a ton of work for already overworked maintainers, how it can cost them entire weekends, and how such reports, as a consequence, can harm open source by burning out the very software engineers that keep it running.

    After many hours of investigation, I have the working theory (and for those who mistake "theory" in a scientist's writing for something less than solid, rest assured that it as solid as I can make it) that the data shape in question is an unmentioned server-side setup where IIS is configured with Require SSL: Checked and Client certificates: Accept or Require.

    Since I do not have anything remotely close to that environment, nor client certificates to work with, I painstakingly wrote this Node.JS reproducer (where AI was, for once, more helpful than the human reporter):

    const { execSync } = require('child_process');
    const fs = require('fs');
    const https = require('https');
    const path = require('path');
    
    const CERT_FILE = path.join(__dirname, '.test-cert.pem');
    const KEY_FILE = path.join(__dirname, '.test-key.pem');
    const PORT = process.env.PORT || 9443;
    
    // Generate temporary self-signed certificate if missing
    if (!fs.existsSync(CERT_FILE) || !fs.existsSync(KEY_FILE)) {
      console.log('Generating temporary certificate...');
      execSync(
        `openssl req -x509 -newkey rsa:2048 -nodes -keyout "${KEY_FILE}" -out "${CERT_FILE}" -days 1 -subj "/CN=localhost" 2>/dev/null`
      );
    }
    
    const options = {
      key: fs.readFileSync(KEY_FILE),
      cert: fs.readFileSync(CERT_FILE),
      maxVersion: 'TLSv1.2'
    };
    
    const server = https.createServer(options, (req, res) => {
      console.log(`[server] Incoming request: ${req.method} ${req.url}`);
      console.log('[server] Requesting TLS renegotiation (HelloRequest)...');
    
      req.socket.renegotiate({ requestCert: true }, (err) => {
        if (err) {
          console.log('[server] Renegotiation callback:', err.message);
        } else {
          console.log('[server] Renegotiation completed');
        }
        res.writeHead(200, { 'Content-Type': 'text/plain' });
        res.end('OK\n');
      });
    });
    
    server.listen(PORT, () => {
      console.log(`[server] Listening on https://localhost:${PORT}`);
      console.log('[server] Run the following command with the WinSSL debug build:');
      console.log(`         git -c http.sslBackend=schannel -c http.sslVerify=false ls-remote https://localhost:${PORT}/repo.git`);
    });
    
    process.on('SIGINT', () => {
      server.close(() => {
        try {
          fs.unlinkSync(CERT_FILE);
          fs.unlinkSync(KEY_FILE);
        } catch (_) {}
        process.exit(0);
      });
    });

    With this reproducer, I get the very same assertion.
11. jared-m-cohen-civ commented on Oct 5, 2026

    

    jared-m-cohen-civ

    on Oct 5, 2026

    Author

    More actions

    I apologize for the lack of detail. I fully understand and appreciate the value of a well-documented, reproducible bug report. I would have gladly provided a working example if I had had one, but I genuinely did not know how to create one. As far as I know, I didn't do anything unusual or abnormal when I created the project, so I had no idea exactly what factors were causing this assertion to fail, and thus no idea how to create a sample project that would reliably reproduce it.
12. dscho

    added a commit that references this issue on Oct 5, 2026

    Avoid curl assertion when renegotiating with empty token (#226)

    ...

    a99de6f
13. dscho

    added

    sdk-packages

    on Oct 5, 2026
14. dscho

    added this to the Next release milestone on Oct 5, 2026
15. dscho

    closed this as completedon Oct 5, 2026
16. jay

    added a commit that references this issue on Oct 5, 2026

    schannel: handle empty tokens during renegotiation

    ...

    6d6bab9
17. dscho

    marked Bundled curl 8.22.0 is built with debugging enabled in Git for Windows 2.56.0 #6500 as a duplicate of this issue on Oct 21, 2026