mach

I'm intentionally causing an EXC_BAD_ACCESS . By triggering a write to an NSObject in a read-only virtual memory page. Ideally, I'd like to catch EXC_BAD_ACCESS , mark the virtual memory page as read-write and have execution continue as it normally would have. Is this even possible? The code I've written to cause the EXC_BAD_ACCESS is below. WeakTargetObject.h (ARC) @interface WeakTargetObject : NSObject @property (nonatomic, weak) NSObject *target; @end WeakTargetObject.m (ARC) @implementation WeakTargetObject @end main.m (MRR) - (void)main { char *mem = NULL; vm_allocate(mach_task_self(),

Why does host_statistics64() in OS X 10.6.8 (I don't know if other versions have this problem) return counts for free, active, inactive, and wired memory that don't add up to the total amount of ram? And why is it missing an inconsistent number of pages? The following output represents the number of pages not classified as free, active, inactive, or wired over ten seconds (sampled roughly once per second). 458 243 153 199 357 140 304 93 181 224 The code that produces the numbers above is: #include <stdio.h> #include <mach/mach.h> #include <mach/vm_statistics.h> #include <sys/types.h> #include

I am trying to install a privileged helper tool to perform some elevated work. I am using SMJobBless for the same. I am able to install the tool fine and also able to communicate with it. I am using Mac OS X 10.8.4 and using NSXPCConnection for the same. I have added .mach service in the plist which will be installed in /Library/LaunchDaemons . I am using [initWithMachServiceName:options:] in the app as the helper is privileged tool and [– initWithMachServiceName:] in the helper to listen. The communication is working fine. But the problem is I tried the same communication with another

I've encountered a very strange issue that affects my code running only on OSX 10.10 systems. I've seen this anomaly occur on over 25 OSX 10.10 systems running my code, whereas the exact same code did not exhibit this behavior before upgrading (10.7). Furthermore, this issue is not 100% reproducible in that it occurs randomly ~0-5% of the time. While testing the code, nothing else critical or CPU exhaustive is occurring on the machine. Even if something else was happening, the very fact that the delays I'm experiencing are soooo ridiculously long make that conclusion seem suspicious. Anyhow,

I am doing a comparison of different IPC mechanisms available on Mac OS X (pipes, sockets, System V IPC, etc.), and I would like to see how Mach ports compare to the higher-level alternatives. However, I've run into a very basic issue: getting send rights to ports across processes (specifically, across a parent process and a child process). Unlike file descriptors, ports are generally not carried over to forked processes . This means that some other way to transfer them must be established. Just about the only relevant page I could find about this was this one , and they state in an update

There appear to be some similar-looking long alphanumeric strings that commonly occur in Mach-O 64 bit executables and ELF 64-bit LSB executables among other symbols that are not alphanumeric: cat /bin/bash | grep -c "AWAVAUATSH" has 181 results, and cat /usr/bin/gzip | grep -c "AWAVAUATSH" has 9 results. What are these strings? Interesting question. Since I didn't know the answer, here are the steps I took to figure it out: Where in the file does the string occur? strings -otx /bin/gzip | grep AWAVAUATUSH 35e0 AWAVAUATUSH 69a0 AWAVAUATUSH 7920 AWAVAUATUSH 8900 AWAVAUATUSH 92a0 AWAVAUATUSH