0

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.

Manikandaraj Srinivasan
  • 3,557
  • 5
  • 35
  • 62

1 Answers1

0

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.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • thanks for the reply. I've read before that the FSEvents interface is not reliable, it may miss events and it looks like i can get directory level notifications only(i need to queue each and every directory). And regarding the char* allignment, you can notice some changes to char*, 'entry = (entry_t *)(buf + len - remain); ' from the code. So when the char* is processed fully, when i check for it to delete, it says the length of that char* is 0. It means that the char* pointer is emptied during dump_entry & print_event function calls. So how can i stop this leak ..? – Manikandaraj Srinivasan Feb 14 '14 at 05:14
  • When you create a new memory pointer with malloc, keep track of it (don't pass your original pointer to print_event; pass it a copy). You can later call `free` on the original pointer to release all the memory. – Rob Napier Feb 14 '14 at 14:52
  • if i take another copy, then i would have to free it too right ..? – Manikandaraj Srinivasan Feb 15 '14 at 07:44
  • If you copy it again with memcpy, yes. But "pointer1 = pointer2" copies a pointer, not memory. So you should free only one of those pointers. – Rob Napier Feb 17 '14 at 15:22