Date: Sun, 14 May 2017 04:15:33 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such Message-ID: <bug-219153-29464-UH58XrGI2A@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-219153-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-219153-29464@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=3D219153 --- Comment #11 from Mark Millard <markmi@dsl-only.net> --- (In reply to Mark Millard from comment #9) [This note is limited to contexts with gcc 4.2.1 based kernels.] Summary after avoiding a user error: looks like there is a default of debug.minidump=3D1 that means that the process information is not in the vmcore file. I'll have to generate new cores with that disabled. Details: I really needed to use: ps -M /var/crash/vmcore.7 -N /usr/lib/debug/boot/kernel/kernel.debug because when I look at the vmcore.*'s I'm not using the kernel that fails periodically. (Not using the kernel build that I wanted to use kgdb with to look at its crashes.) (A debug kernel build works but a production build of the same sources crashes in a pid 11 thread [idle thread] eventually. I manually unload boot kergcd instead of using /boot/kernel/kernel when I do not want the kernel to fail for what I'm doing. /boot/kernel/kernel and /usr/lib/debug/boot/kernel/kernel.debug are a matching pair for the failing kernel. truss shows where ps extracts the nprocs figure and such. My own calculations via looking at: readelf -a /var/crash/vmcore.7 | more and readelf -a /usr/lib/debug/boot/kernel/kernel.debug agrees with what I see in: cat /var/crash/vmcore.7 | hd | more The address shown in ddb matches my calculations as well. But to do this with matching files I had to use some more recent vmcore.* files because other experiments had updated the kernel (and world). So here is what I found based on having a matching -N for the -M : nprocs=3D52 (0x36) (which is good) but when it gets into: static int kvm_proclist(kvm_t *kd, int what, int arg, struct proc *p, struct kinfo_proc *bp, int maxcnt) and its code: for (; cnt < maxcnt && p !=3D NULL; p =3D LIST_NEXT(&proc, = p_list)) { memset(kp, 0, sizeof *kp); if (KREAD(kd, (u_long)p, &proc)) { _kvm_err(kd, kd->program, "can't read proc = at %p", p); return (-1); } the _kvm_err is being called for the first p value: (gdb) print p $4 =3D (struct proc *) 0x873c370 for which no VirtAddr/MemSiz combination in the vmcore.9 file spans representing that address: # readelf -a /var/crash/vmcore.9=20 ELF Header: Magic: 7f 45 4c 46 01 02 01 ff 00 00 00 00 00 00 00 00=20 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI: StandAlone ABI Version: 0 Type: CORE (Core file) Machine: PowerPC 32-bit Version: 0 Entry point address: 0 Start of program headers: 52 (bytes into file) Start of section headers: 0 (bytes into file) Flags: 0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 3 Size of section headers: 40 (bytes) Number of section headers: 0 (0) Section header string table index: 0 Elf file type is CORE (Core file) Entry point 0x0 There are 3 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x008fe000 0xffffffff 0x6d7000 0x6d7000 R 0x1000 LOAD 0x6d8000 0xd0005000 0xffffffff 0x18000 0x18000 R 0x1000 LOAD 0x6f0000 0xd001d000 0xffffffff 0x01000 0x01000 R 0x1000 There are no sections in this file. There is no dynamic section in this file. --=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-219153-29464-UH58XrGI2A>