public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "ycliang at andestech dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug malloc/29624] New: errno is not cleared when entering main Date: Wed, 28 Sep 2022 10:31:56 +0000 [thread overview] Message-ID: <bug-29624-131@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=29624 Bug ID: 29624 Summary: errno is not cleared when entering main Product: glibc Version: 2.35 Status: UNCONFIRMED Severity: normal Priority: P2 Component: malloc Assignee: unassigned at sourceware dot org Reporter: ycliang at andestech dot com Target Milestone: --- According to the ANSI C standard "7.5 Errors <errno.h>" section 3[1], "The value of errno is zero at program startup, but is never set to zero by any library function." The "program startup" is also defined in ANSI C standard "5.1.2.2.1 Program startup" section 1[2], "The function called at program startup is named main." Therefore, it should be reasonable to expect errno be zero when main is executed. However, we found that the following program would get non-zero errno under some circumstances. ``` /* errno.c */ #include <errno.h> #include <stdio.h> int main() { printf("errno: %d\n", errno); return 0; } $ riscv64-linux-gcc -O0 -g -static -o errno_st errno.c [ 51.968765] random: fast init done /mnt # ./errno errno: 11 [ 51.968765] random: fast init done [ 262.517056] crng init done /mnt # ./errno errno: 0 ``` If the above program is statically-linked, and if the program is executed before "crng init done", the errno will not be zero when entering main. There seems to be syscall (__getrandom) before main is entered, and if the crng is not initialized, the syscall will fail causing the errno to be set. (_dl_get_origin -> __libc_malloc -> ptmalloc_init -> tcache_key_initialize -> __getrandom) Thanks to Florian's suggestion: "Hiding the getrandom failure is probably sufficient. All other failures in malloc will lead to the process failing to start, so those errors don't need to be masked." We should clear the errno for the getrandom failure Related discussion: https://sourceware.org/pipermail/libc-help/2022-September/006301.html -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2022-09-28 10:31 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-09-28 10:31 ycliang at andestech dot com [this message] 2022-09-30 18:27 ` [Bug malloc/29624] " adhemerval.zanella at linaro dot org 2024-01-12 13:24 ` cvs-commit at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-29624-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).