0

I'm trying to figure out why inspection of a crashed process is failing on OSX 10.8. I am adding Breakpad to the Mac version of a very large and complex professional application. I am currently using Breakpad r1035. Due to circumstances outside my control, my application is built using XCode 3.2.6 (GCC 4.2). This is probably a long shot, since there hasn't been a lot of activity under the Breakpad tag on SO lately.

I've done a bit of digging through the Breakpad code to determine where exactly the failure occurs. The generator.Write(...) call in Inspector::InspectTask() returns false. Within Write(), the call to WriteMemoryListStream(...) leads to ReadTaskMemory(...) which makes a mach_vm_read(...) system call that has an error later reported by Inspector as: Error writing minidump - errno=No such process

Is there a reason why the crashing process wouldn't exist, or why it would not be detected properly by Inspector? I have tried changing the @BREAKPAD_SEND_AND_EXIT setting to "NO", but that did not make a difference. A 2MB .dmp file is generated each time I cause a crash, containing non-human readable text.

Here is the stdout from Inspector when I induce a crash:

message ID = 0
exception_type = 1
exception_code = 1
exception_subcode = 0
remote_task = 7171
crashing_thread = 6915
handler_thread = 6659
ack_port_ = 6403
parameter count = 18
Inspector: sent acknowledgement (os/kern) successful (0)

Here is the stderr from Inspector when I induce a crash (edited to remove the directories):

Suspended Remote task
Writing minidump to directory (<correct location>)
minidump path (<correct location>/DD6D8905-F55F-4035-96BA-25460453F236.dmp)
Error writing minidump - errno=No such process
Resumed remote task
Inspector: trying to send acknowledgement to port 6403
Inspection of crashed process failed

Has anyone experienced similar issues while adding Breakpad to an application on the Mac? Or seen mach_vm_read(...) fail in a similar way?

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
Ben
  • 163
  • 1
  • 7
  • To read memory from an external process, you need at some point to get send rights to a task port (in Mach parlance), and the OS restricts applications that can do that. I don't think the rules have changed since 2010, and you can find them [here](http://os-tres.net/blog/2010/02/17/mac-os-x-and-task-for-pid-mach-call/). Do you know if you're good on that front? – zneak Apr 23 '14 at 16:26
  • @zneak The code that sets up the rights already existed as part of the framework. I don't know enough about Mach to rule out send rights, though other people seem to use Breakpad without experiencing this issue. Is it possible to get the "No such process" error I'm getting because of Mach send rights? – Ben Apr 23 '14 at 17:15
  • I can't find any official documentation for mach_vm_read, and since [it only calls the undocumented and private `_kernelrpc_mach_vm_read`](http://www.opensource.apple.com/source/xnu/xnu-2422.1.72/libsyscall/mach/mach_vm.c), I don't think that there's any way to know which errors are returned under which conditions. If you want to be sure, you'd have to verify that the result of `task_for_pid` (or of whatever other technique is used to get send rights) is correct. `task_for_pid` returns 5 ("(os/kern) failure") when you don't have the permission to use it. – zneak Apr 23 '14 at 18:06
  • I thought that Breakpad always worked out of process but it's not the case. It can just use `mach_task_self()` to get a Mach port to the current process and sidestep all the task_for_pid stuff, so the problem could be elsewhere. – zneak Apr 23 '14 at 18:15
  • @zneak I am using Breakpad out of process. As far as I can tell, when an exception is being handled the main process uses `mach_task_self()` as it gathers information to send a mach message to the out of process Inspector task. I'm not sure where exactly rights get configured, but the main task also creates a `ReceivePort` that appears to enable two-way communication. – Ben Apr 23 '14 at 18:39

0 Answers0