public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "matoro_bugzilla_glibc at matoro dot tk" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/29490] New: [bisected] new __brk_call causes dynamic loader segfault on alpha Date: Mon, 15 Aug 2022 04:49:44 +0000 [thread overview] Message-ID: <bug-29490-131@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=29490 Bug ID: 29490 Summary: [bisected] new __brk_call causes dynamic loader segfault on alpha Product: glibc Version: 2.36 Status: UNCONFIRMED Severity: normal Priority: P2 Component: dynamic-link Assignee: unassigned at sourceware dot org Reporter: matoro_bugzilla_glibc at matoro dot tk Target Milestone: --- Hi, the patch series at https://patchwork.ozlabs.org/project/glibc/list/?series=299241 causes the dynamic loader to segfault on alpha. I bisected this using the 2.35 branch, though the commit is from 2.36. Reverting the following commits fixes the issue: "Linux: Introduce __brk_call for invoking the brk system call" "csu: Implement and use _dl_early_allocate during static startup" The commit message says "Alpha and sparc can now use the generic implementation." However, the problem does NOT seem to appear on sparc, only alpha. If you would like access to the live system this was reproduced on, please let me know and I can provide it! Here is as much info as I was able to get out of gdb: (gdb) info frame Stack level 0, frame at 0x11fa9ca50: pc = 0x20000194a30 in sysmalloc (malloc.c:2896); saved pc = 0x20000195bf4 called by frame at 0x11fa9cb10 source language c. Arglist at 0x11fa9ca50, args: nb=656, av=0x200002e2920 <main_arena> Locals at 0x11fa9ca50, Previous frame's sp is 0x11fa9ca50 Saved registers: s0 at 0x11fa9c9d8, s1 at 0x11fa9c9e0, s2 at 0x11fa9c9e8, s3 at 0x11fa9c9f0, s4 at 0x11fa9c9f8, s5 at 0x11fa9ca00, fp at 0x11fa9ca08, ra at 0x11fa9c9d0, pc at 0x11fa9c9d0 (gdb) bt #0 0x0000020000194a30 in sysmalloc (nb=656, av=0x200002e2920 <main_arena>) at malloc.c:2896 #1 0x0000020000195bf4 in _int_malloc (av=0x200002e2920 <main_arena>, bytes=640) at malloc.c:4407 #2 0x0000020000195d24 in tcache_init () at malloc.c:3245 #3 0x0000020000196790 in tcache_init () at malloc.c:3241 #4 __GI___libc_malloc (bytes=35) at malloc.c:3306 #5 0x000002000011f744 in set_binding_values (domainname=0x2000005efa3 "util-linux", dirnamep=0x11fa9cbd0, codesetp=0x0) at bindtextdom.c:202 #6 0x000002000011faa0 in set_binding_values (codesetp=0x0, dirnamep=0x20000068000, domainname=0x0) at bindtextdom.c:322 #7 __bindtextdomain (domainname=0x0, dirname=<error reading variable: Cannot access memory at address 0x20000068000>) at bindtextdom.c:320 #8 0x0000020000052bc0 in ?? () Backtrace stopped: frame did not save the PC (gdb) l 2896 2891 2892 /* Adjust top based on results of second sbrk */ 2893 if (snd_brk != (char *) (MORECORE_FAILURE)) 2894 { 2895 av->top = (mchunkptr) aligned_brk; 2896 set_head (av->top, (snd_brk - aligned_brk + correction) | PREV_INUSE); 2897 av->system_mem += correction; 2898 2899 /* 2900 If not the first time through, we either have a (gdb) info registers v0 0x20000068000 2199023681536 t0 0x0 0 t1 0x22001 139265 t2 0x0 0 t3 0x22000 139264 t4 0x0 0 t5 0xffffffffffffe000 -8192 t6 0x1 1 t7 0x0 0 s0 0x200002e2920 2199026280736 s1 0x20000046000 2199023542272 s2 0x200002e2920 2199026280736 s3 0x200002e2980 2199026280832 s4 0x290 656 s5 0x200002e20c8 2199026278600 fp 0x2b0 688 a0 0x0 0 a1 0x20000068000 2199023681536 a2 0xa 10 a3 0x1 1 a4 0x1 1 a5 0x20000006570 2199023281520 t8 0x8 8 t9 0x1 1 t10 0x200000e3e90 2199024189072 t11 0x2b0 688 ra 0x200001949c4 2199024912836 t12 0x6e 110 at 0xc53b7244 3309007428 gp 0x200002eb688 0x200002eb688 <_res_hconf+32> sp 0x11fa9c9d0 0x11fa9c9d0 pc 0x20000194a30 0x20000194a30 <sysmalloc+1664> (gdb) info locals old_top = 0x200002e2980 <main_arena+96> old_size = <optimized out> old_end = <optimized out> size = <optimized out> brk = <optimized out> correction = 0 snd_brk = <optimized out> front_misalign = <optimized out> end_misalign = <optimized out> aligned_brk = 0x20000046000 <error: Cannot access memory at address 0x20000046000> p = <optimized out> remainder = <optimized out> remainder_size = <optimized out> pagesize = 8192 tried_mmap = <optimized out> __PRETTY_FUNCTION__ = "sysmalloc" -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2022-08-15 4:49 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-08-15 4:49 matoro_bugzilla_glibc at matoro dot tk [this message] 2022-08-15 4:49 ` [Bug dynamic-link/29490] " matoro_bugzilla_glibc at matoro dot tk
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-29490-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).