This seems to be an Apple bug. There's a `_CUILog()` function in the CoreUI private framework that writes a CFString/NSString object to that module's `mac_crash_info`'s `message` field, then deletes it. This is *two* violations of the `mac_crash_info` "protocol": 1) All strings fields should contain UTF8 strings 2) The memory they occupy should be valid. The message "object" written by `_CUILog()` is full of `0xe5` characters (a poison value for memory occupied by deleted objects). And even if it weren't, it would be unparseable by code that expects a UTF8 or ASCII string. The question now is what to do about it. Maybe we should just do nothing. Apparently this error condition doesn't always cause a crash. (And if it did, the crash stacks would be distinctive enough to be noticeable.) And it seems to be quite rare -- only two examples since Mozilla started gathering `mac_crash_info` about a month ago. And even if we wanted to, there might be nothing we *can* do. I'll think about this for a while.
Bug 1715812 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This seems to be an Apple bug. There's a `_CUILog()` function in the CoreUI private framework that writes a CFString/NSString object to that module's `mac_crash_info`'s `message` field, then deletes it. This is *two* violations of the `mac_crash_info` "protocol": 1) All strings fields should contain UTF8 strings 2) The memory they occupy should be valid. The message "object" written by `_CUILog()` is full of `0xe5` characters (a poison value for memory occupied by deleted objects). And even if it weren't, it would be unparseable by code that expects a UTF8 or ASCII string. The question now is what to do about it. Maybe we should just do nothing. Apparently this error condition doesn't always cause a crash. (And when it did, the crash stacks would be distinctive enough to be noticeable.) And it seems to be quite rare -- only two examples since Mozilla started gathering `mac_crash_info` about a month ago. And even if we wanted to, there might be nothing we *can* do. I'll think about this for a while.
This seems to be an Apple bug. There's a `_CUILog()` function in the CoreUI private framework that writes a CFString/NSString object to that module's `mac_crash_info`'s `message` field, then deletes it. This is *two* violations of the `mac_crash_info` "protocol": 1) All strings fields should contain UTF8 strings 2) The memory they occupy should be valid. The message "object" written by `_CUILog()` is full of `0xe5` characters (a poison value for memory formerly used by deleted objects). And even if it weren't, it would be unparseable by code that expects a UTF8 or ASCII string. The question now is what to do about it. Maybe we should just do nothing. Apparently this error condition doesn't always cause a crash. (And when it did, the crash stacks would be distinctive enough to be noticeable.) And it seems to be quite rare -- only two examples since Mozilla started gathering `mac_crash_info` about a month ago. And even if we wanted to, there might be nothing we *can* do. I'll think about this for a while.