From patchwork Tue Oct 13 14:45:23 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Johannes Schindelin X-Patchwork-Id: 11835587 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D3ABEC433E7 for ; Tue, 13 Oct 2020 14:45:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 86F232488C for ; Tue, 13 Oct 2020 14:45:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PhgOFEaE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388947AbgJMOp1 (ORCPT ); Tue, 13 Oct 2020 10:45:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38502 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388932AbgJMOp1 (ORCPT ); Tue, 13 Oct 2020 10:45:27 -0400 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1356C0613D0 for ; Tue, 13 Oct 2020 07:45:26 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id e17so24356620wru.12 for ; Tue, 13 Oct 2020 07:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:date:subject:fcc:content-transfer-encoding :mime-version:to:cc; bh=yzCY+/KaZ4eGqn5hBF0emRHlX69a4Tebw9q7aJQ7JGk=; b=PhgOFEaERISfbsu2KZu0SoXT3Sz2X0R5Qxrnls4pt97PJWiQgK1f97jhcNVgHqrg1d zKFJ8+94nYPkbaz70xBBq+hOiIFS5GwejFzRNwpQR4QVno/8WC3vrJSnK3bPkQcHh8ez cbP5lAx/zCaTGZEWx2bzJkhSeiVC+qscZopStxLcywDW+XrgLCbrkQOGrEJnZRvJ/Uaa 6rf8aigsBJqCPmeuWn4vuR2C2n16Mx/KrOyAzxXl7wv6UGrny363yetBw8UJMzp3DB3j eGHM5DvEXDGxF6CZBCQmN3z6gfZlTk2yqXbjcSw6umb37KDVqw+DCvjnKKaSrxfQwp2X eVdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:date:subject:fcc :content-transfer-encoding:mime-version:to:cc; bh=yzCY+/KaZ4eGqn5hBF0emRHlX69a4Tebw9q7aJQ7JGk=; b=d7mcCdR24TWZ/Qfj03lEEBW7pTPohyCmKxRvVjo3aHPuFY511XMAJJuN9JRMSFTUk1 YwP3t2TJClgrfJmMhOpbNhq85hBMZLAOZ9nLBNnKQC9zxZeI2AzMtbe5YbLXSbWqA0QH wMwcNpzz14/8PudY6sntMZBvH1LYclT01u0rAwcTrQ0nn2fKCBK0y7Kq3Ous78pzIjI8 RZlY01pj95u8k+iiwo4nsZZQVbQKkkvVP/jyMzNJXm26oqkZ+5ohci0yLeKpkp8C3zpu BxVgfQr6yWtuEeJnbpsTqDpKLHiC8iJVfdQg+OWmLIaddDTjr//QXqnb3d5/54vfO2y5 +vpg== X-Gm-Message-State: AOAM532iCC/TvPwYsKWcXZAu6ufSqLySnBXiSF3syc/StfMc2NEP/Y18 BiUZQHosXrmBsEv9+do4JgHwhJ4McD8= X-Google-Smtp-Source: ABdhPJygb3XCJCzMVbqCT49owA+SpdBOeJMwr0ZHJ2ANQcYwa2+NBMvE+MBG8b04x4OivHxlcXny3Q== X-Received: by 2002:a5d:4f0b:: with SMTP id c11mr35580987wru.316.1602600325266; Tue, 13 Oct 2020 07:45:25 -0700 (PDT) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id k18sm10968608wrx.96.2020.10.13.07.45.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Oct 2020 07:45:24 -0700 (PDT) Message-Id: Date: Tue, 13 Oct 2020 14:45:23 +0000 Subject: [PATCH] t5500.43: make the check a bit more robust Fcc: Sent MIME-Version: 1.0 To: git@vger.kernel.org Cc: Jonathan Tan , Johannes Schindelin , Johannes Schindelin Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: Johannes Schindelin From: Johannes Schindelin In 2b695ecd74d (t5500: count objects through stderr, not trace, 2020-05-06) we tried to ensure that the "Total 3" message could be grepped in Git's output, even if it sometimes got chopped up into multiple lines in the trace machinery. However, the first instance where this mattered now goes through the sideband machinery, where it is _still_ possible for messages to get chopped up. Note: we have code in `demultiplex_sideband()` _specifically_ to stitch back together lines that were delivered in separate sideband packets. However, this stitching fails when a primary packet is delivered in between the two sideband packets: since a primary packet was received, `demultiplex_sideband()` has to return that (and cannot wait for other sideband packets, and therefore has to flush any incomplete line it received). This seems only to happen occasionally in the `vs-test` part of our CI builds, i.e. with binaries built using Visual C, but not when building with GCC or clang; The symptom is that t5500.43 fails to find a line matching `remote: Total 3` in the `log` file, which ends in something along these lines: remote: Tota remote: l 3 (delta 0), reused 0 (delta 0), pack-reused 0 To work around that, use some `sed` magic to re-stitch together those split lines, after the fact. The other test case touched by 2b695ecd74d (t5500: count objects through stderr, not trace, 2020-05-06) is not affected by this issue because the sideband machinery is not involved there. Signed-off-by: Johannes Schindelin --- Work around flakiness in t5500.43 It seems that this test became flaky only recently, although I have to admit that I have no idea why: the involved code does not seem to have changed recently at all. It should have been fixed by https://lore.kernel.org/git/20200506220741.71021-1-jonathantanmy@google.com/ , but apparently wasn't completely fixed, despite what I said in that thread. Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-753%2Fdscho%2Funflake-t5500.43-v1 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-753/dscho/unflake-t5500.43-v1 Pull-Request: https://github.com/gitgitgadget/git/pull/753 t/t5500-fetch-pack.sh | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) base-commit: d4a392452e292ff924e79ec8458611c0f679d6d4 diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh index 3557374312..5e556313af 100755 --- a/t/t5500-fetch-pack.sh +++ b/t/t5500-fetch-pack.sh @@ -400,7 +400,20 @@ test_expect_success 'in_vain not triggered before first ACK' ' test_commit -C myserver bar && git -C myclient fetch --progress origin 2>log && - test_i18ngrep "remote: Total 3 " log + if ! test_i18ngrep "remote: Total 3 " log + then + # It is possible that the "Total 3" line is delivered in + # multiple sideband packets, and that a primary packet is + # delivered in between. When that happens, the line will be + # presented on multiple "remote:" lines. + sed "/^remote: T/{ + :a + N + s/\nremote: // + ba + }" log >log.unsplit && + test_i18ngrep "remote: Total 3 " log.unsplit + fi ' test_expect_success 'in_vain resetted upon ACK' ' From patchwork Mon Oct 19 19:35:41 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Johannes Schindelin X-Patchwork-Id: 11845029 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B114C43457 for ; Mon, 19 Oct 2020 19:35:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A5AB822314 for ; Mon, 19 Oct 2020 19:35:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="d1o6Zfdh" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731272AbgJSTfr (ORCPT ); Mon, 19 Oct 2020 15:35:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731266AbgJSTfr (ORCPT ); Mon, 19 Oct 2020 15:35:47 -0400 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CEC43C0613D0 for ; Mon, 19 Oct 2020 12:35:46 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id x7so1047342wrl.3 for ; Mon, 19 Oct 2020 12:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:in-reply-to:references:from:date:subject:fcc :content-transfer-encoding:mime-version:to:cc; bh=KQ/Om1iJNa++UOs6ipGuMhVM81spY9yADMMzBFismRs=; b=d1o6ZfdhbboMA3PGz7mj1XNEJgIQ2AAda5JpH0b7Y6Qo1dSexCPzDQMl6WSxKCCLxf QbwCFIVbyd3xz8wkqFJgUfKEgvzjJzdKsHGtiQq//YT4W474mgtyUxPLvNOgJ+RdyF8Q BK/FCyfGS3WIjaeDHA4ifEdJYMV7yrBIco7CjwRF9C8eFzoOeaRFO+8XyIBoVbAHFh9G pfwnweRUNvyGFZTRfJYfnDqgt9YU+JCgn1i4TaZSr5xoGWwp9bkrGrgOz8aZJsx5TXff EsP//ACTGs+nIKz+I69ymoTEkFwACtNFOYYB0fL/BuIZWNsbxJ7lLRGkVmF0uFY2cCpC F9mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:in-reply-to:references:from:date :subject:fcc:content-transfer-encoding:mime-version:to:cc; bh=KQ/Om1iJNa++UOs6ipGuMhVM81spY9yADMMzBFismRs=; b=j9/QnZF8p/1nQxrG85SPzmKKcjnWM9G+VbliuaL6vC5Vb5+Axfrohaml4ckb++bUEU 7W0BvxsD1aQJpcsbPOvfKsUX8UqtBUFXWQcJ/qOqlVGbSFaaAzd2DYk4WpnmA/Lgffiu 0xtFlTt+D68eCWLnEuYMximYLb6Pv+RfaxxKLEAw+nedkvRUJ7oxBq/V2DaLD5PU1BOb 16JvIieYpbrq5R1206u0yd6Xh3ZIJVw2LXbkb1wuhiATAya7VB2JCTuM7HyW5FpmFEg3 L97hp2osw5HuUPJxdhUmq7fQQm29Ol0MbWx94JAXWq8DxnfwUXz0PWE45LvEoiajxfYz +beQ== X-Gm-Message-State: AOAM533ixpQD6GC1ukRGwG/4nfHfe91bTe9MYY+90y6sIQPP3lszibHe uSMTBPPDSPXSHTLaXicUXX64VF+RaDk= X-Google-Smtp-Source: ABdhPJw9+4dgZ8aHKQHXCLwkMWBKswYkHqtEgg2+ovWgn4hPSSQHYxtNuRHvO49DW97xNlaC7akpGA== X-Received: by 2002:a5d:6845:: with SMTP id o5mr816119wrw.87.1603136145511; Mon, 19 Oct 2020 12:35:45 -0700 (PDT) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id a8sm675776wmj.31.2020.10.19.12.35.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2020 12:35:45 -0700 (PDT) Message-Id: <9ffcc5b78e358d0ed4da2c52ba87174dc94e544c.1603136143.git.gitgitgadget@gmail.com> In-Reply-To: References: Date: Mon, 19 Oct 2020 19:35:41 +0000 Subject: [PATCH v2 2/3] sideband: report unhandled incomplete sideband messages as bugs Fcc: Sent MIME-Version: 1.0 To: git@vger.kernel.org Cc: Jonathan Tan , Jeff King , Johannes Schindelin , Johannes Schindelin , Johannes Schindelin Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: Johannes Schindelin From: Johannes Schindelin It was pretty tricky to verify that incomplete sideband messages are handled correctly by the `recv_sideband()`/`demultiplex_sideband()` code: they have to be flushed out at the end of the loop in `recv_sideband()`, but the actual flushing is done by the `demultiplex_sideband()` function (which therefore has to know somehow that the loop will be done after it returns). To catch future bugs where incomplete sideband messages might not be shown by mistake, let's catch that condition and report a bug. Signed-off-by: Johannes Schindelin --- pkt-line.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/pkt-line.c b/pkt-line.c index 844c253ccd..657a702927 100644 --- a/pkt-line.c +++ b/pkt-line.c @@ -471,6 +471,9 @@ int recv_sideband(const char *me, int in_stream, int out) write_or_die(out, buf + 1, len - 1); break; default: /* errors: message already written */ + if (scratch.len > 0) + BUG("unhandled incomplete sideband: '%s'", + scratch.buf); return sideband_type; } } From patchwork Mon Oct 19 19:35:42 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Johannes Schindelin X-Patchwork-Id: 11845033 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ABFEEC43457 for ; Mon, 19 Oct 2020 19:35:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 502A5223BF for ; Mon, 19 Oct 2020 19:35:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="i4ItQs94" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731297AbgJSTfu (ORCPT ); Mon, 19 Oct 2020 15:35:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731280AbgJSTfs (ORCPT ); Mon, 19 Oct 2020 15:35:48 -0400 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6CE7C0613CE for ; Mon, 19 Oct 2020 12:35:47 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id g12so987727wrp.10 for ; Mon, 19 Oct 2020 12:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:in-reply-to:references:from:date:subject:fcc :content-transfer-encoding:mime-version:to:cc; bh=51qnyM0oQPKf1T95ynoz0JMbhKqPGV0a/d3fTLw2UhA=; b=i4ItQs94jve7G1blO1liADjtgvZbJUTifwU1aDkQRHdYAtMfjstYD3XvflwqocY5MF 7h31C83TCOzA3eg5a2YTkiynowqKcZFETXtVDeDIynFc5LBktzgmQtqGS0vWOTXGRq36 bWBJNepO3gW4uV/UwM//H2NMjzpVM2mXQJwYjMLJrXrv4r1rOEGaiwqeLxJW/DKMUIMj BJCQxQLfBm33E9ZLRmmbZGqYN4yrNnGSteMX1JR+qUo5IC+5T33wxm75sCXPJKtd3lNB FjCav8JeU9yIi8ZJTVLB0pQ01Efb+6J3/c/KAugVGIXwgiv0AqTjKwQBqhyoKnhBnKS5 6Y3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:in-reply-to:references:from:date :subject:fcc:content-transfer-encoding:mime-version:to:cc; bh=51qnyM0oQPKf1T95ynoz0JMbhKqPGV0a/d3fTLw2UhA=; b=q9bdzbyAYAerla6sxFKaPlqWCy6zQN8R0tmBaIaBJAx0bI0oXN0qmo19T3NmykerJ/ EB1EDKx1x+ZpSCqEAhNBVl/4C8KUiHp5tmkLo1LFtSgbFK7WjHSBRY6LJhrreDdB33f0 bzGn2lfxt41sieXNp43XzGuKcMXY0wJ5NAPHG4Zc7eAgwH6dGA8szgMjtxBRP7jBzVa/ RhlovUrNRBaGyB3WZtU6s3nSD9L9OHZt3NnzgDn9g8ZHUTGwL5yXMxQ9Cuib7zpDZCB+ vYfwu9d4hjB7j0tRPtLzEpb8csCVBAYldJWWthV5JIABd0PfhTifBOYgSaeIiuPGZGan q8gA== X-Gm-Message-State: AOAM530pNYM3TQ1ZrFcgTFneX5kUDq3i//WU/iXZ3Y912rcWMfSPuwOC C0lboEYhcIHRgHzS7Sxt8HUbO2h5hAk= X-Google-Smtp-Source: ABdhPJykYjpK4ou9paMBx/Tlr4ZeGJryzmoZg/unVdYtx8BQqUM348hIQTDXkZE3LZRVE/6Kxenx4Q== X-Received: by 2002:a5d:494c:: with SMTP id r12mr849444wrs.406.1603136146312; Mon, 19 Oct 2020 12:35:46 -0700 (PDT) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id j7sm681160wmc.7.2020.10.19.12.35.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2020 12:35:45 -0700 (PDT) Message-Id: In-Reply-To: References: Date: Mon, 19 Oct 2020 19:35:42 +0000 Subject: [PATCH v2 3/3] sideband: add defense against packets missing a band designator Fcc: Sent MIME-Version: 1.0 To: git@vger.kernel.org Cc: Jonathan Tan , Jeff King , Johannes Schindelin , Johannes Schindelin , Johannes Schindelin Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: Johannes Schindelin From: Johannes Schindelin While there is currently no instance of code producing this type of packet, if the `demultiplex_sideband()` would receive a packet whose payload is not only empty but even misses the band designator, it would mistake it for a flush packet. Let's defend against such a bug in the future. Note: `demultiplex_sideband()` will treat empty flush, delim, eof and response-end packets all alike: it will treat them as flush packets. Since empty packets by definition are missing a band designator, this is the best that function can do. Therefore, it would make little sense to pass the `status` on to `demultiplex_sideband()`. Besides, fbd76cd450 (sideband: reverse its dependency on pkt-line, 2019-01-16) went out of its way to _stop_ the code inside `demultiplex_sideband()` from relying on anything in `pkt-line.h`; that includes the data type `enum packet_read_status` that we would need if we were to pass `status` as a parameter to that function. Based on a suggestion by Jeff King. Signed-off-by: Johannes Schindelin --- pkt-line.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/pkt-line.c b/pkt-line.c index 657a702927..f72048f623 100644 --- a/pkt-line.c +++ b/pkt-line.c @@ -461,8 +461,10 @@ int recv_sideband(const char *me, int in_stream, int out) enum sideband_type sideband_type; while (1) { - len = packet_read(in_stream, NULL, NULL, buf, LARGE_PACKET_MAX, - 0); + int status = packet_read_with_status(in_stream, NULL, NULL, buf, + LARGE_PACKET_MAX, &len, 0); + if (!len && status == PACKET_READ_NORMAL) + BUG("missing band designator"); if (!demultiplex_sideband(me, buf, len, 0, &scratch, &sideband_type)) continue; @@ -520,6 +522,8 @@ enum packet_read_status packet_reader_read(struct packet_reader *reader) reader->options); if (!reader->use_sideband) break; + if (!reader->pktlen && reader->status == PACKET_READ_NORMAL) + BUG("missing band designator"); if (demultiplex_sideband(reader->me, reader->buffer, reader->pktlen, 1, &scratch, &sideband_type))