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.



    printf("zfs_vnop_mkdir: %p\n", zfs_vnop_mkdir);

    printf("__builtin_frame_address 0-3  %p %p %p %p\n",
    printf("__builtin_return_address 0-3  %p %p %p\n",
    OSReportWithBacktrace("OSReportWithBacktrace: ");
    panic("causing real panic");


   90    0 0xffffff7f81d3a000 0x2dd000   0x2dd000   net.lundman.zfs
   (1.3.1) <89 16 7 5 4 3 1>

      Kernel Extensions in backtrace:
         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
 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 +

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

So kextstat is useless. But trying to lookup any address from any
backtrace (using paniclog address) also fails:


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):

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?


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:

This email sent to arch...@mail-archive.com

Reply via email to