From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 38AFE3858435; Mon, 15 Aug 2022 04:49:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 38AFE3858435 From: "matoro_bugzilla_glibc at matoro dot tk" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.36 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: matoro_bugzilla_glibc at matoro dot tk X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2022 04:49:45 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29490 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=3D299241 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, on= ly 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 =3D 0x20000194a30 in sysmalloc (malloc.c:2896); saved pc =3D 0x20000195= bf4 called by frame at 0x11fa9cb10 source language c. Arglist at 0x11fa9ca50, args: nb=3D656, av=3D0x200002e2920 Locals at 0x11fa9ca50, Previous frame's sp is 0x11fa9ca50 Saved registers: s0 at 0x11fa9c9d8, s1 at 0x11fa9c9e0, s2 at 0x11fa9c9e8, s3 at 0x11fa9c9f= 0, s4 at 0x11fa9c9f8, s5 at 0x11fa9ca00, fp at 0x11fa9ca08, ra at 0x11fa9c9d0,= pc at 0x11fa9c9d0 (gdb) bt #0 0x0000020000194a30 in sysmalloc (nb=3D656, av=3D0x200002e2920 ) at malloc.c:2896 #1 0x0000020000195bf4 in _int_malloc (av=3D0x200002e2920 , bytes=3D640) 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=3D35) at malloc.c:3306 #5 0x000002000011f744 in set_binding_values (domainname=3D0x2000005efa3 "util-linux", dirnamep=3D0x11fa9cbd0, codesetp=3D0x0) at bindtextdom.c:202 #6 0x000002000011faa0 in set_binding_values (codesetp=3D0x0, dirnamep=3D0x20000068000, domainname=3D0x0) at bindtextdom.c:322 #7 __bindtextdomain (domainname=3D0x0, dirname=3D) 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 !=3D (char *) (MORECORE_FAILURE)) 2894 { 2895 av->top =3D (mchunkptr) aligned_brk; 2896 set_head (av->top, (snd_brk - aligned_brk + correction) | PREV_INUSE); 2897 av->system_mem +=3D 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 (gdb) info locals old_top =3D 0x200002e2980 old_size =3D old_end =3D size =3D brk =3D correction =3D 0 snd_brk =3D front_misalign =3D end_misalign =3D aligned_brk =3D 0x20000046000 p =3D remainder =3D remainder_size =3D pagesize =3D 8192 tried_mmap =3D __PRETTY_FUNCTION__ =3D "sysmalloc" --=20 You are receiving this mail because: You are on the CC list for the bug.=