Mac OS X中fsevents观察器中的内存泄漏

我需要Mac OS X中的文件系统通知，并且正在从/ dev/fsevents中读取数据。在Mac OS X中捕获fsevents的示例代码：http://www.codecollector.net/view/1066/raw_fsevents。在这段代码中，您可以看到从/ dev/fsevents读取的缓冲区在读取后立即被处理。但是当我这样做时，由于处理中创建的延迟而导致事件丢失。所以我创建了一个新的char指针，并从/ dev/fsevents读取缓冲区，并将新的char *添加到队列中，并在新线程中处理队列。但是当我处理'print_event'&'dump_entry'中的char *时，char *指针会被重新分配，并且当我在处理后检查strlen（）时，它仅表示0或1个字节长度。所以在处理过程中，内存在泄漏。Mac OS X中fsevents观察器中的内存泄漏

任何想法如何删除已分配的char *，这会泄漏更多内存以获取更多事件。请分享你的想法。提前致谢。

来源

2014-02-13 Manikanda raj S

只是好奇：你手动处理/ dev/fsevents，而不是使用FSEvents接口，用于与它进行交互（至少在最常见的情况下）的任何原因？直接与/ dev/fsevents交谈非常棘手。 Ars Technica did a nice writeup.

对于这种类型的代码，我会远离malloc和memcpy。这会给你的队列管理增加很多开销。我会摆脱手动线程管理。这正是GCD旨在处理的问题，特别是使用dispatch_data。它可以让你创建不可变的内存块，你可以处理和操作而不需要复制。您可以使dispatch_source读取/ dev/fsevents并将您传回dispatch_data对象。有关示例，请参见并发编程指南的Reading Data from a Descriptor部分。

“char *指针被重新分配”的含义并不十分清楚。你的意思是你在两个线程上修改同一个变量而不锁吗？

但是，除非你真的需要原始访问，否则我会查看FSEvents接口。

来源

2014-02-13 17:25:43

感谢您的回复。我以前读过FSEvents接口不可靠，它可能会错过事件，它看起来像我只能得到目录级通知（我需要排队每个目录）。关于char * allignment，你可以注意到char *，'entry =（entry_t *）（buf + len - remain）的一些变化; '从代码。因此，当char *被完全处理时，当我检查它是否被删除时，它表示该char *的长度为0.这意味着在dump_entry和print_event函数调用期间char *指针被清空。那么我怎么能阻止这个泄漏..？ –

当您使用malloc创建新的内存指针时，请记住它（不要将您的原始指针传递给print_event;将它传递给副本）。您稍后可以在原始指针上调用'free'来释放所有内存。 –

如果我拿另一份，然后我将不得不释放它吧..？ –

Mac OS X中fsevents观察器中的内存泄漏

回答

相关问题