From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <9front-bounces@9front.inri.net>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE
	autolearn=ham autolearn_force=no version=3.4.4
Received: from 9front.inri.net (9front.inri.net [168.235.81.73])
	by inbox.vuxu.org (Postfix) with ESMTP id C19D32511C
	for <ml@inbox.vuxu.org>; Tue, 23 Jan 2024 17:54:48 +0100 (CET)
Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Tue Jan 23 11:53:38 -0500 2024
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org;
	s=20200506; t=1706028838;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=dXINowBc84wIIGwjupWB3hFw8S8g+6vQqx0FbFiVSWw=;
	b=kYMCLzCp/71t1WVmfdO7SvCX45O6dNvlfvQCnNG892BVwBLwsuYpAMIHD/UEb6AXzCkF1r
	6ILXLI3bINPhueQqrW5QmjURlLnjYjkjPZYuZ1wmyC45mkC17qKZu1Mm1Ph8jNpucISIPn
	Vy+PPDhYHjw2MrSwCSeyIR0CbrL7x4Y=
Received: from [192.168.168.200] (<unknown> [207.45.82.38])
	by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 7a80efe2 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO)
	for <9front@9front.org>;
	Tue, 23 Jan 2024 10:53:57 -0600 (CST)
Message-ID: <b0233255-2f1f-4797-9f41-52ecedb7d4ef@posixcafe.org>
Date: Tue, 23 Jan 2024 10:53:35 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: 9front@9front.org
References: <da549402-071f-4185-97d2-5c4cd8e18ecb@gmail.com>
From: Jacob Moody <moody@posixcafe.org>
In-Reply-To: <da549402-071f-4185-97d2-5c4cd8e18ecb@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: decentralized optimized injection persistence manager 
Subject: Re: [9front] [PATCH] awk: don't write an extra NUL past the end of a
 block
Reply-To: 9front@9front.org
Precedence: bulk

Can you provide an example input that would generate this crash?

For awk things I usually tend to cross reference our bug fixes
against the onetrueawk to see if it was fixed there or not.
 From what I can tell onetrueawk also has this code:
https://github.com/onetrueawk/awk/blob/master/lib.c

I have a sneaking feeling that there are other cases
where this code is needed, but I'm not entirely sure.
It looks like there is some condition where we avoid that
loop, and that's why the code was there. Perhaps we
could just alloc length of string + 2?

Maybe give onetrueawk a try and see if you can reproduce the
crash there as well, and if not perhaps we should copy their fix.


Thanks,
moody

On 1/23/24 01:44, Kristo wrote:
> When splitting a record into individual fields awk seems to write an
> extra NUL at the end, which is not an issue when a record fits in the
> default buffer. However, with larger records the buffer is allocated to
> length of the string + 1, meaning that the extra NUL goes past the end
> of the block and causes a "mem user overflow" panic.
> 
> diff 26c21f9b5d06296d13f40b53de14e22007e189c2 uncommitted
> --- a/sys/src/cmd/awk/lib.c
> +++ b/sys/src/cmd/awk/lib.c
> @@ -287,7 +287,6 @@
>  			while (*r != ' ' && *r != '\t' && *r != '\n' && *r != '\0');
>  			*fr++ = 0;
>  		}
> -		*fr = 0;
>  	} else if ((sep = *inputFS) == 0) {		/* new: FS="" => 1 char/field */
>  		for (i = 0; *r != 0; r += w) {
>  			char buf[UTFmax + 1];
> @@ -320,7 +319,6 @@
>  			if (*r++ == 0)
>  				break;
>  		}
> -		*fr = 0;
>  	}
>  	if (i > nfields)
>  		FATAL("record `%.30s...' has too many fields; can't happen", r);
>