https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153
--- Comment #11 from Mark Millard <mar...@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=1 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=52 (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 != NULL; p = 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 = (struct proc *) 0x873c370 for which no VirtAddr/MemSiz combination in the vmcore.9 file spans representing that address: # readelf -a /var/crash/vmcore.9 ELF Header: Magic: 7f 45 4c 46 01 02 01 ff 00 00 00 00 00 00 00 00 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. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"