From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NO_DNS_FOR_FROM,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by gnuweeb.org (Postfix) with ESMTPSA id BDC6C8060C for ; Fri, 26 Aug 2022 01:39:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gnuweeb.org; s=default; t=1661477999; bh=10CB4t4gUsi/jxvBt5wRaddYHtPK4KH/wQr38Hcr6sA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NKPhDMe6flm2gH7ybm4x7DwGZaib7FFQMXF++6kVK19sFnhz9eE+0Ubr1tjb0gUv8 +LTCPlMD/05Nsjn86dMUo6QnxdeNad9BeS/oSwrfaDbIsDcI135yl7Dmvu39v5B4pH tLJRmNO2AIEBQmSsIfmYemD3YMCHs/8gdaE1YUFzZjkqN93W8fmGB4IYRz86hubunp JY6np4oz7M3EXpMH3LwSnsA/XOyXBv6iaSYtt2qFdfALk+QAS4P/L6JtnU6V7OVps0 2SSHDNu1C72pFqrvoN5aVpWUXTgHRjBjLkrYfZ5ylWRd0GSLd9LZNnssBnsedlW58u fSFowZdqRg9Cw== Received: by mail-lf1-f48.google.com with SMTP id bt10so178829lfb.1 for ; Thu, 25 Aug 2022 18:39:59 -0700 (PDT) X-Gm-Message-State: ACgBeo0+egNdsovfavWXIOMvKJkjjXLXHQSG5piu9yReujWbEAYiJy1x m+XfxYXJvVh282a3zYXNkbuqDE3KuvN6m3uCJ8E= X-Google-Smtp-Source: AA6agR5fIcFyzrdgTTWEqSCRmBbx5Wf+TPkKyS1LA/78/xMblLLugFfHFZOKiBs3sYj7hIo6834S+zwHY0ry8eAj9lQ= X-Received: by 2002:a05:6512:3049:b0:492:f394:11cd with SMTP id b9-20020a056512304900b00492f39411cdmr1954870lfb.165.1661477997921; Thu, 25 Aug 2022 18:39:57 -0700 (PDT) MIME-Version: 1.0 References: <78e1a565-e450-61d8-47b3-87920131cfda@gnuweeb.org> <44ee99d2-d4e6-3638-89ce-152818a9a9bc@gnuweeb.org> In-Reply-To: From: Alviro Iskandar Setiawan Date: Fri, 26 Aug 2022 08:39:46 +0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] ncns update (chunked request body support) To: Ammar Faizi Cc: Kanna Scarlet , Muhammad Rizki , "GNU/Weeb Mailing List" Content-Type: text/plain; charset="UTF-8" List-Id: On Fri, Aug 26, 2022 at 8:34 AM Alviro Iskandar Setiawan wrote: > On Fri, Aug 26, 2022 at 1:36 AM Ammar Faizi wrote: > > On 8/25/22 4:57 PM, Alviro Iskandar Setiawan wrote: > > > pulled into my next branch for testing only, tq > > > > I am not sure what is going on here, but it always fails when > > the written bytes is more than 16K bytes. The current WIP commit > > is here: > > > > https://gitlab.torproject.org/ammarfaizi2/ncns/-/commit/20627519f6e882ab7d2309f6a6b6e451fb19edc4 > > > > Can you spot a mistake in this version? > > > > I have been debugging this for more than 5 hours and haven't > > been able to figure out what is going wrong. I was going to > > say that it's a Chromium bug. But thinking of the Chromium > > stability so far, I doubt to claim so. > > you're tired, get some rest plz, tq for your hard work > > > Please review! > > found it, the problem is not in that commit, but the previous one > > https://gitlab.torproject.org/ammarfaizi2/ncns/-/commit/d113a1611f2eca1f45fd8dd0fe3a02aa92abeb6e#63c8f17eb62643be824f57c1bed41bbf7c80ed5e_50_127 > > if you split the buffer in the middle of the queue, then you put the > rest of the splitted buffer into the tail, then it may get skipped > because the EOF mark can be queued earlier. Even if it doesn't hit EOF > it's still wrong because the FIFO order is violated when the condition > (c.len_ <= dst_len_) evaluates to true better way you shouldn't pop the queue if you're running out of destination buffer, you can wait for the next ReadInternal() call and copy the rest uncopied bytes later time, only the deferring is a bit tricky tq -- Viro