Hello list,
Apologies for only *just* being inside of filesystem-dev, but perhaps
someone here has already found a solution around this problem.
We are trying to find a way to print the calling stack without halting
execution. Ie, panic without the reboot. Calling panic() for a "modified
after freed" or similar soft errors is a bit extreme.
KDK_10.10.4_14E46.kdk
Source:
zfs_vnop_mkdir()
{
printf("zfs_vnop_mkdir: %p\n", zfs_vnop_mkdir);
printf("__builtin_frame_address 0-3 %p %p %p %p\n",
__builtin_frame_address(0),
__builtin_frame_address(1),
__builtin_frame_address(2));
printf("__builtin_return_address 0-3 %p %p %p\n",
__builtin_extract_return_addr(__builtin_return_address(0)),
__builtin_extract_return_addr(__builtin_return_address(1)),
__builtin_extract_return_addr(__builtin_return_address(2)));
OSReportWithBacktrace("OSReportWithBacktrace: ");
panic("causing real panic");
}
kextstat:
90 0 0xffffff7f81d3a000 0x2dd000 0x2dd000 net.lundman.zfs
(1.3.1) <89 16 7 5 4 3 1>
panic:
Kernel Extensions in backtrace:
net.lundman.zfs(1.3.1)[5180737B-8B0D-3895-9F19-1B377DC91D91]@
0xffffff7f9b53a000 -> 0xffffff7f9b816fff
kextstat load address vs paniclog load address:
0xffffff7f9b53a000 - 0xffffff7f81d3a000 = 0x19800000
Why? The addresses are not the same, and each time it is a different
amount. I've not managed to use kextstat address for anything useful at all.
Output from it running:
kernel[0]: zfs_vnop_mkdir: 0xffffff7f9b6324f0
kernel[0]: __builtin_frame_address 0-3
0xffffff80c9d6b8f0 0xffffff80c9d6b970 0xffffff80c9d6bb90
0xffffff7f9b68ec36
kernel[0]: __builtin_return_address 0-3
0xffffff8019d712ca 0xffffff8019d43c90 0xffffff8019d5e52a
kernel[0]: OSReportWithBacktrace:
kernel[0]: Backtrace 0xffffff80005712ca
0xffffff8000543c90 0xffffff800055e52a 0xffffff8000552d17
0xffffff800084bc56 0xffffff8000435376 0x0
from paniclog:
0xffffff80c9d6b890 : 0xffffff7f9b6325d6 net.lundman.zfs :
_zfs_vnop_mkdir + 0xe6
0xffffff80c9d6b8f0 : 0xffffff8019d712ca mach_kernel : _vn_mkdir + 0xaa
0xffffff80c9d6b970 : 0xffffff8019d43c90 mach_kernel : _vn_create +
0x210
Using "atos" with paniclog address, and the zfs_vnop_mkdir address we
can look up the function name. This at least shows we can look up
something known.
xcrun atos -arch x86_64 -l 0xffffff7f9b53a000 -o
module/zfs/zfs.kext/Contents/MacOS/zfs 0xffffff7f9b6324f0
zfs_vnop_mkdir (in zfs) (zfs_vnops_osx.c:725)
If I simply use the addresses in the paniclog, I can also look it up:
atos -l 0xffffff7f9b53a000 0xffffff7f9b6325d6
zfs_vnop_mkdir (in zfs) (zfs_vnops_osx.c:757)
But the same using kextstat loading address, we can not:
atos -l 0xffffff7f81d3a000 0xffffff7f9b6324f0
0xffffff7f9b6324f0
So kextstat is useless. But trying to lookup any address from any
backtrace (using paniclog address) also fails:
__builtin_frame_address
__builtin_return_address
OSReportWithBacktrace
So there is no way to get stack addresses without causing panic. Is
there no way around this? When did this break, as I seem to remember I
used to do this without issue.
I have also tried using lldb to lookup, here is from OSReport:
(lldb) target create --no-dependents --arch x86_64 module/zfs/zfs
(lldb) target modules load --file zfs __TEXT 0xffffff7f9b53a000
(lldb) image lookup --verbose --address 0xffffff80005712ca
And using paniclog address:
(lldb) image lookup --verbose --address 0xffffff7f9b6325d6
LineEntry: [0xffffff7f9b6325cf-0xffffff7f9b6325df):
/Users/lundman/src/zfs/osx.zfs/x/zfs/module/zfs/zfs_vnops_osx.c:757:2
So, from a running system, how to get the real (working) load address
if kextstat gives something else.
How to print the stack backtrace from the kext which can be used to
lookup the function name, if all three (__builtin_frame_address,
__builtin_return_address, OSReportWithBacktrace) can not be used with
atos and lldb.
Alas, I am not allowed to call panic_i386_backtrace() myself, but since
it has the keepsym check, I wouldn't want to. I could lift in all the
code it has, including kvtophys(), panic_print_kmod_symbol_name() - but
that is a fair bit of code and structures I am "not supposed" to look in.
Has anyone found a way around it?
Lund
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (Filesystem-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
