Memory Leak in fsevents watcher in Mac OS X

Question

I need file system notifications in Mac OS X and i'm reading from /dev/fsevents. A Sample code of capturing fsevents in Mac OS X : http://www.codecollector.net/view/1066/raw_fsevents. In this code, you can see the buffer read from /dev/fsevents is processed as soon as it is read. But when i do that, events are missing due to the delay created in processing. So i have created a new char pointer and memcpy'd the buffer read from /dev/fsevents and added the new char* to a queue and processed the queue in a new thread. But when i process the char* like in 'print_event' & 'dump_entry', the char* pointer gets realligned and when i check for strlen() after processing, it says 0 or 1 bytes length only. So during processing, the memory is leaking.

Any idea how to delete the allocated char*, this is leaking more memory for more events. Please share your thoughts on this. Thanks in advance.

Answer 1

Just curious: any reason you manually processing /dev/fsevents rather than using the FSEvents interface that's designed for interacting with it (at least for the most common cases)? /dev/fsevents is pretty tricky to talk to directly. Ars Technica did a nice writeup.

For this kind of code, I'd get away from malloc and memcpy. That's going to add a lot of overhead to your queue management. And I'd get away from manual thread management. This is exactly the kind of problem that GCD is designed to handle, in particular using dispatch_data. It lets you create immutable memory blocks that you can process and manipulate without requiring copying. You can make a dispatch_source to read /dev/fsevents and pass you back dispatch_data objects. See the Reading Data from a Descriptor section of the Concurrency Programming Guide for an example.

It's not quite clear what you mean by "the char* pointer gets realligned." Do you mean you're modifying the same variable on two threads without locks?

But unless you really need raw access, I'd be looking at the FSEvents interface.