https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028
--- Comment #221 from Mark Millard <marklmi26-f...@yahoo.com> --- (In reply to George Mitchell from comment #220) +0x274 == +628 (at 0xffffffff80bc0ab4) 1488 if (strcmp(mod->name, name) == 0 && 0xffffffff80bc0aa8 <+616>: mov 0x18(%rbx),%rdi 0xffffffff80bc0aac <+620>: mov %r12,%rsi 0xffffffff80bc0aaf <+623>: call 0xffffffff80cf0100 <strcmp> 0xffffffff80bc0ab4 <+628>: test %eax,%eax 0xffffffff80bc0ab6 <+630>: jne 0xffffffff80bc0aa0 <linker_load_dependencies+608> I expect that kgdb would expose strcmp in the backtrace, as it does a better job generally. (The original Fatal Trap notice reported the address in strcmp as well.) This suggests problems for the value in mp->md_cval (via modname) as of the strcmp call (based on where the Fatal Trap was reported to be at in strcmp). Note the mod->name argument to strcmp . Note that if mod-> could not be dereferenced, the failure would be before strcmp was called. Thus it looks to be the ->name value that strcmp ends up using that lead to the failure. Same sort of thing as for comment #82 (but a separate in-line). in strcmp it showed: 0xffffffff80cf0110 <+16>: movzbl (%rdi,%rcx,1),%eax So if you ever get a chance to have it report the %rdi value on an actual failure, the value may prove interesting. Of course, none of this gets far enough to suggest why the value of mod->name would be messed up. -- You are receiving this mail because: You are the assignee for the bug.
