Date: Thu, 26 Jan 2017 22:23:31 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 216132] devel/gdb: at e.g. -r431413: get_core_register_section can get SIGSEGV from NULL regset arguments Message-ID: <bug-216132-13-GhCmeJYyPo@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-216132-13@https.bugs.freebsd.org/bugzilla/> References: <bug-216132-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216132 --- Comment #10 from Mark Millard <markmi@dsl-only.net> --- (In reply to luca.pizzamiglio from comment #9) Just an FYI: lldb on an arm (bpim3) was able to get a useful interpretation of the qemu_gmake.core file when also given a copy of gmake. Below I give some information for potential comparison uses: For "TCG temporary leak before 00021826" the symbol dump in addresses order shows: Dumping symbol table for 4 modules. Symtab, file =3D /usr/local/bin/gmake, num_symbols =3D 957 (sorted by addre= ss): Debug symbol |Synthetic symbol ||Externally Visible ||| Index UserID DSX Type File Address/Value Load Address Si= ze=20=20 Flags Name ------- ------ --- --------------- ------------------ ------------------ ------------------ ---------- ---------------------------------- . . . [ 538] 6121 X Code 0x0000000000021820 0x00029820 0x0000000000000038 0x00000012 child_handler [ 592] 6175 X Code 0x0000000000021858 0x00029858 0x0000000000000d7c 0x00000012 reap_children . . . This looks like it tends to confirm the SIGCHLD handling is involved. And objdump on gmake shows: 00021820 <child_handler> push {fp, lr} 00021824 <child_handler+0x4> mov fp, sp 00021828 <child_handler+0x8> sub sp, sp, #8 0002182c <child_handler+0xc> mov r1, r0 00021830 <child_handler+0x10> str r0, [sp, #4] 00021834 <child_handler+0x14> movw r0, #36636 ; 0x8f1c 00021838 <child_handler+0x18> movt r0, #5 0002183c <child_handler+0x1c> ldr r2, [r0] 00021840 <child_handler+0x20> add r2, r2, #1 00021844 <child_handler+0x24> str r2, [r0] 00021848 <child_handler+0x28> str r1, [sp] 0002184c <child_handler+0x2c> bl 0002e9f0 <jobserver_signal> 00021850 <child_handler+0x30> mov sp, fp 00021854 <child_handler+0x34> pop {fp, pc} Interestingly 00021826 is between instructions and lldb reported for the registers: (lldb) register read General Purpose Registers: r0 =3D 0x9fffc0f8 r1 =3D 0x9fffc138 r2 =3D 0x000a18c0 r3 =3D 0xf4fde858 r4 =3D 0x9fffc138 r5 =3D 0xf4a00000 r6 =3D 0xb6db6db7 r7 =3D 0x00000012 r8 =3D 0xf4a0c000 r9 =3D 0xf4aa18c0 r10 =3D 0x9fffc260 r11 =3D 0x00000004 r12 =3D 0x9fffc0f8 sp =3D 0x9fffc0f8 lr =3D 0x9fffffcc pc =3D 0x00021822 cpsr =3D 0x80000030 i.e., the pc being 0x00021822 . That would be in the middle of the "push {fp, lr}" instruction and 4 bytes before the 00021826 figure. If it really tried to fetch an instruction at 0x00021822 that likely would also explain getting a SIGILL classification for the 4 bytes starting there. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-216132-13-GhCmeJYyPo>