From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32669 invoked from network); 29 Jun 2022 16:30:46 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 29 Jun 2022 16:30:46 -0000 Received: (qmail 15450 invoked by uid 550); 29 Jun 2022 16:30:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 15427 invoked from network); 29 Jun 2022 16:30:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4eZGhrRY6/sLM/a1gmUTrYGaHQzXVLPRdV/uyDIulNc=; b=Wfup8ENXHO5TQlZ+/DwDA0he4OGMk1o/O7OKQgMmJBxFd8uMedpzeYLrnLTmVpbJS/ eK5yZ5yVvS08fMLMVwc0o/EvceY6oAjJPCbiPDYZPiu0Cjmmzx46iJjQW6u8n4w2IhVU SMqRTOa+FGTORKojkiKPfi8ZSQYGfFd91pdUePe1LlqOi2OZ/cf5LzpuKPeFyjPcvde5 qz6VJTHGJu2IjPqmtieJ6zHMirEOc1P5Wsy0XFZTTk6npgWqwcp3pKSsDZt+yuLjNLZX /0LQvsAHVDCyEksrXPk2BKSqCGyUjcvVDSuKBtPUi5NGXFWd/iWgUDpBncHHSl7IUMsZ xX0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4eZGhrRY6/sLM/a1gmUTrYGaHQzXVLPRdV/uyDIulNc=; b=NciSb5gu2hdgGnZyw+P99rtMYpQWMopFIfQ4rOGvTKPUPB1iS54GXDrCIYKuE558oD ooQdpD+2KXw2Yi79tAeWE0Pc7bx5fT6jqYJD+A8KWFg9IDOCvfKSc9YBwfViHubXwQs1 L7rg9cq5pq3L/sgO5wGbr3uuzQN5YhwNGH+6gddnJk5Yxaanmt38Mk0zMrCo1/DwsOWY iIHi3XQnEkFM9wN1gyCir6wbrT8wLU8JG+goxaBgO6csdKFjrX7QG+nctcTLtiOFCTFZ und8oq9kQrExANT4fIWCOGxEiFjiYEwESLz7UvJ580vfkhvoI82w7dr2gbMqN5xnDzLx So2A== X-Gm-Message-State: AJIora9qCV8zmZ4/YE0695KwuQNvR7VdVR/ioUBhbL8VDC5bs30L8V/4 Sqzk+XBAB8E/xue/FqmNo5HOh9XuFv5EC2S5dEg= X-Google-Smtp-Source: AGRyM1vX/hgR7NoOW/MYWw6rUo3fP/Rd2ayGvXk8me87L3ZXumnQEV7IY+TiXjN5puvBewfH/jZggCi1aYCmpkD4HLI= X-Received: by 2002:a17:903:11d2:b0:167:8a0f:8d4b with SMTP id q18-20020a17090311d200b001678a0f8d4bmr11050818plh.78.1656520230723; Wed, 29 Jun 2022 09:30:30 -0700 (PDT) MIME-Version: 1.0 References: <87sfnn1m5i.fsf@oldenburg.str.redhat.com> In-Reply-To: <87sfnn1m5i.fsf@oldenburg.str.redhat.com> From: =?UTF-8?Q?Thomas_St=C3=BCfe?= Date: Wed, 29 Jun 2022 18:30:19 +0200 Message-ID: To: Florian Weimer Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000ea653605e298abd5" Subject: Re: [musl] Question about calloc, free in CPU_ALLOC and CPU_FREE --000000000000ea653605e298abd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 29, 2022 at 6:15 PM Florian Weimer wrote: > * Thomas St=C3=BCfe: > > > Greetings, > > > > I have a small question about the way muslc implements the CPU_ALLOC an= d > CPU_FREE > > macros. > > > > I see them defined in sched.h as: > > > > #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n))) > > #define CPU_FREE(set) free(set) > > > > whereas the glibc defines them as calls to functions __sched_cpu_alloc(= ) > and > > __sched_cpufree(): > > > > #define __CPU_ALLOC(count) __sched_cpualloc (count) > > #define __CPU_FREE(cpuset) __sched_cpufree (cpuset) > > > > in the end both variants allocate from C-heap, but the muslc variant > > gets inlined directly into the calling code. If that calling code has > > a function "free" or "calloc" (okay, less likely) these get called > > instead. Could also be a class local method in C++. > > calloc and free can be macros, and if an implementation exercises this > possibility, you will have some trouble defining your own functions of > the same name. We ran into this issue when we added an iszero macro to > glibc as part of support for future C revisions. In the end, we had to > use an alternative C++ construct in C++ mode instead of the preprocessor > macro we use for C: too many C++ applications broke because they used > iszero as a member function name. > > I think I can guess which code base this is about. 8-) You really should > adopt a non-colliding naming scheme for your os:: wrapper functions. > This sidesteps this entire set of issues. > > :-) I guess you guess right. Yes, the JVM crashes on Alpine because of ::malloc() -> os::free() disbalance: https://bugs.openjdk.org/browse/JDK-8289477 And you are absolutely right. We should change the naming scheme. > There really isn't a musl bug here, I think (but I'm not a musl > developer). > > I think so too now. > Thanks, > Florian > > Thank you, Thomas --000000000000ea653605e298abd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Jun 29, 2022 at 6:15 PM Florian Weimer <fweimer@redhat.com> wrote:
* Thomas St=C3=BCfe:<= br>
> Greetings,
>
> I have a small question about the way muslc implements the CPU_ALLOC a= nd CPU_FREE
> macros.
>
> I see them defined in sched.h as:
>
> #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
> #define CPU_FREE(set) free(set)
>
> whereas the glibc defines them as calls to functions __sched_cpu_alloc= () and
> __sched_cpufree():
>
> #define __CPU_ALLOC(count) __sched_cpualloc (count)
> #define __CPU_FREE(cpuset) __sched_cpufree (cpuset)
>
> in the end both variants allocate from C-heap, but the muslc variant > gets inlined directly into the calling code. If that calling code has<= br> > a function "free" or "calloc" (okay, less likely) = these get called
> instead. Could also be a class local method in C++.

calloc and free can be macros, and if an implementation exercises this
possibility, you will have some trouble defining your own functions of
the same name.=C2=A0 We ran into this issue when we added an iszero macro t= o
glibc as part of support for future C revisions.=C2=A0 In the end, we had t= o
use an alternative C++ construct in C++ mode instead of the preprocessor macro we use for C: too many C++ applications broke because they used
iszero as a member function name.

I think I can guess which code base this is about. 8-) You really should adopt a non-colliding naming scheme for your os:: wrapper functions.
This sidesteps this entire set of issues.


:-) I guess you guess right.

Yes, the JVM crashes on Alpine because of ::malloc() -> = os::free() disbalance:=C2=A0https://bugs.openjdk.org/browse/JDK-8289477

And you are absolutely right. We should change the naming scheme.
=C2=A0
There really isn't a musl bug here, I think (but I'm not a musl
developer).


I think so too now.
=C2=A0
Thanks,
Florian


Thank you, Thomas=C2=A0
--000000000000ea653605e298abd5--