为啥 DTrace 有时但并非总是给我无效地址错误？

Posted 2023-03-06

【中文标题】为啥 DTrace 有时但并非总是给我无效地址错误？

【英文标题】：Why does DTrace give me invalid-address errors sometimes but not always?为什么 DTrace 有时但并非总是给我无效地址错误？

【发布时间】：2009-07-29 04:57:02

【问题描述】：

我的程序：

typedef struct objc_class 
    struct objc_class *isa;
    struct objc_class *super_class;
    char *name;
    long version;
    long info;
    long instance_size;
    void *ivars;
    void *methodLists;
    void *cache;
    void *protocols;
 *Class;
struct objc_object 
    Class isa;
;

/* Code to extract the class name from arg0 based on a snippet by Bill Bumgarner: http://friday.com/bbum/2008/01/26/objective-c-printing-class-name-from-dtrace/ */

objc$target:NSObject:-init:entry 
    printf("time: %llu\n", timestamp);
    printf("arg0: %p\n", arg0);
    obj = (struct objc_object *)copyin(arg0, sizeof(struct objc_object));
    printf("obj: %p\n", obj);
    printf("obj->isa: %p\n", obj->isa);
    isa = (Class)copyin((user_addr_t)obj->isa, sizeof(struct objc_class));
    printf("isa: %p\n", obj->isa);
    classname = copyinstr((user_addr_t)(isa->name));
    printf("classname: %s\n", classname);

一些输出：

dtrace: script 'test.d' matched 1 probe
dtrace: error on enabled probe ID 1 (ID 61630: objc5936:NSObject:-init:entry): invalid address (0x90206b98) in action #8 at DIF offset 28
dtrace: error on enabled probe ID 1 (ID 61630: objc5936:NSObject:-init:entry): invalid address (0x90206b98) in action #8 at DIF offset 28
dtrace: error on enabled probe ID 1 (ID 61630: objc5936:NSObject:-init:entry): invalid address (0x90206b98) in action #8 at DIF offset 28
CPU     ID                    FUNCTION:NAME
  0  61630                      -init:entry time: 28391086668386
arg0: 1291ae10
obj: 6f0a1158
obj->isa: a023f360
isa: a023f360
classname: NSBitmapImageRep

  1  61630                      -init:entry time: 28391586872297
arg0: 12943560
obj: 6f4a1158
obj->isa: 2fca0
isa: 2fca0
classname: GrowlApplicationTicket

  1  61630                      -init:entry time: 28391586897807
arg0: 152060
obj: 6f4a1280
obj->isa: 2fe20
isa: 2fe20
classname: GrowlNotificationTicket

  2  61630                      -init:entry time: 28391079142905
arg0: 129482d0
obj: 700a1128
obj->isa: a0014140
isa: a0014140
classname: NSDistributedObjectsStatistics

  2  61630                      -init:entry time: 28391079252640
arg0: 147840
obj: 700a1250
obj->isa: a0014780
isa: a0014780
classname: NSDistantObjectTableEntry

为什么会出现错误？好像是类名（这是唯一的%s，删除也不会报错），但为什么会认为某些类名是无效指针？

有什么方法可以让错误消息真正告诉我我的 DTrace 程序的哪一行导致了问题？

有没有办法打电话给object_getClassName 而不是做这种结构检查舞？

不管怎样，我正在跟踪的程序运行良好——它没有崩溃，所以我不相信这些类真的坏了。

【参考方案1】：

Colin 非常接近正确。

见：

http://www.friday.com/bbum/2008/01/03/objective-c-using-dtrace-to-trace-messages-to-nil/

您很可能需要将DYLD_SHARED_REGION 环境变量设置为avoid。 dtrace 仅对实际驻留在物理内存中的映射内存真正起作用。

您可以使用vmmap 命令行工具找出缺少的内容。

生成上述失败消息后，在您的应用程序上执行vmmap PID。查看输出，看看像0x90206b98 这样的地址属于哪个区域。鉴于该地址，它可能位于不可写的共享内存块中，可能不是常驻的，因此 dtrace 无法从中读取。

【参考方案2】：

当在尚未出错的页面上使用 copyin / copyinstr 时会发生此错误。一个常见的解决方法是让函数使用有问题的数据，然后在 :::return 子句中复制 [str]。例如：

syscall::open:entry

    self->filename = arg0;  /* Hang on to the file name pointer.  */


syscall::open:return
/self->filename/

    @files[copyinstr(self->filename)] = count();
    self->filename = 0;


END

    trunc(@files, 5);

【参考方案3】：

我自己还没有完全追踪到这一点。 DTrace 可能正在尝试解析一些 Objective-C 符号。尽管 DTrace 是一种动态跟踪工具，但它不能很好地与 Objective-C 在运行时动态加载事物相结合。当 Objective-C 确实加载新类时，DTrace 必须解决这个问题，这需要一点时间，尤其是当您的应用程序刚刚启动时。即使它确实加载了东西，并且您的 objc 应用程序仍在将新类加载到 objc 运行时，它可能的 DTrace 可能会搞砸并以错误的顺序打印方法（如果您关心看到正在执行的正确顺序方法） ，打印不正确的计时结果等。

【参考方案4】：

根据所提供的信息，这是我的最佳猜测。

DTrace 的设计目的是使 DTrace 脚本尽可能具有确定性。这就是为什么没有if 语句、循环、子例程（DTrace 本身提供的伪子例程除外）等的原因。这是因为您的 DTrace 脚本中的代码在内核模式下运行，而不是用户态的一部分被跟踪的过程。一般来说，DTrace 可以访问的信息是“只读的”（就像大多数概括一样，这不是严格正确的），能够在程序或内核中使用像 DTrace 这样强大的东西可以导致事情发生非常非常错误，非常非常快。

美元到甜甜圈，您遇到的问题是因为指针指向的页面没有被 VM 系统映射到核心。 DTrace 只能检查内核中的内存信息——它不能双重错误以使 VM 系统加载到页面中。

如果您知道类“应该”是什么并通过执行一堆引用所需类的虚拟 NSLog() 语句来强制将页面映射到核心，您可能可以帮助缓解问题在程序启动初期的某个方便的时间点。

【讨论】：

昨晚我想到了这个。 DTrace 的设计将内核中运行的“代码”数量保持在最低限度，并尽可能“安全”。符号名称解析发生在内核之外。内核仅将地址记录在缓冲区中，外部程序在事后将其转换为可读的内容。这个想法是 - 为什么不将 ObjC 类名称解析添加到这些“内核之外”活动之一？可能值得进行一些调查，看看它是否可行，然后向 Apple 报告 RFE 错误。