From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com [IPv6:2001:4860:4864:20::30]) by sourceware.org (Postfix) with ESMTPS id 907553858D28 for ; Thu, 21 Jul 2022 13:24:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 907553858D28 Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-10c0430e27dso2360601fac.4 for ; Thu, 21 Jul 2022 06:24:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:from:to:references:organization:in-reply-to :content-transfer-encoding; bh=dzHAF1RwlM9PG7MSHCykNMRivA3zRdwqImgxncxDjGs=; b=DFRG9A5D00pyqKrZgMnT3dKW74RseTBIIWKzgtUJdh/mtPlLogUYwA/xuoaRN36BD9 R2OOeESM/dGzHioqopY4wC8kwIlF5cfDRyalhTGf6fpkpq3JZDSFd18grNXbsPePM96a rteBZzCqj1FaL2Xo+P4z5ISXp5qz86KpEPkCsYBCnIi/L7KOV9o9oqZtvlZDSAq90XiW ANV0UDv3rZxj+6S2XIXeSjIfXY0yZZOsYeNDOWyCqVhYm+INVh3ZlMbmxn6EyW8jIYwy Q1mhi1wGIi5YyfCt73SUhNLlWyLJCIEf/He+vNxAadEBNmOTN3F8VykjDB9FRxlIDYJW w0qA== X-Gm-Message-State: AJIora+6otwyJHRZlDHsCA8J4ygLL6tbsNXBW+x88ikS7yiq/r3IbvPk +Oivw9IPvaELedYSpuCSJQQ9gg== X-Google-Smtp-Source: AGRyM1sbyRvnTaH7TVYzgQ1bsDq4jIYs+dVUYnPZKbD7tkbezkRayhi51YsZsxh/m9hKywdOxZJE0Q== X-Received: by 2002:a05:6870:961f:b0:10b:ad08:8909 with SMTP id d31-20020a056870961f00b0010bad088909mr4766430oaq.269.1658409860879; Thu, 21 Jul 2022 06:24:20 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:8ded:90a7:7be2:9a21:5f25? ([2804:431:c7cb:8ded:90a7:7be2:9a21:5f25]) by smtp.gmail.com with ESMTPSA id h17-20020a056870d25100b0010c3655967csm751951oac.40.2022.07.21.06.24.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Jul 2022 06:24:20 -0700 (PDT) Message-ID: <9519948b-7913-ea0a-32c7-fad43d61a558@linaro.org> Date: Thu, 21 Jul 2022 10:24:18 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.0.2 Subject: Re: [PATCH] malloc: Simplify implementation of __malloc_assert Content-Language: en-US From: Adhemerval Zanella Netto To: Florian Weimer , libc-alpha@sourceware.org References: <87a6924uvf.fsf@oldenburg.str.redhat.com> <21e64150-606d-df60-e50f-df09ca5a67ff@linaro.org> Organization: Linaro In-Reply-To: <21e64150-606d-df60-e50f-df09ca5a67ff@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2022 13:24:23 -0000 On 21/07/22 10:10, Adhemerval Zanella Netto wrote: > > > On 21/07/22 07:34, Florian Weimer via Libc-alpha wrote: >> It is prudent not to run too much code after detecting heap >> corruption, and __fxprintf is really complex. The line number >> and file name do not carry much information, so it is not included >> in the error message. (__libc_message only supports %s formatting.) >> The function name and assertion should provide some context. >> >> Tested on i686-linux-gnu and x86_64-linux-gnu. Also emulated the >> __libc_message call using GDB, and it produced the expected output. >> >> Thanks, >> Florian >> --- >> malloc/malloc.c | 15 +++++---------- >> 1 file changed, 5 insertions(+), 10 deletions(-) >> >> diff --git a/malloc/malloc.c b/malloc/malloc.c >> index 12908b8f97..bd3c76ed31 100644 >> --- a/malloc/malloc.c >> +++ b/malloc/malloc.c >> @@ -292,19 +292,14 @@ >> # define __assert_fail(assertion, file, line, function) \ >> __malloc_assert(assertion, file, line, function) >> >> -extern const char *__progname; >> - >> -static void >> +_Noreturn static void >> __malloc_assert (const char *assertion, const char *file, unsigned int line, >> const char *function) >> { >> - (void) __fxprintf (NULL, "%s%s%s:%u: %s%sAssertion `%s' failed.\n", >> - __progname, __progname[0] ? ": " : "", >> - file, line, >> - function ? function : "", function ? ": " : "", >> - assertion); >> - fflush (stderr); >> - abort (); >> + __libc_message (do_abort, "\ >> +Fatal glibc error: malloc assertion failure in %s: %s\n", >> + function, assertion); >> + __builtin_unreachable (); >> } >> #endif >> #endif >> > > Would be better to keep the the file and line information? And since the idea here is to avoid the malloc from __asprintf, would be better to make __assert_fail_base call __libc_message (which will either call alloca or mmap) ? Then there is no need to reimplement it for malloc.