【问题标题】:- (void) processImage:(char *)image; ---char* causes a memory leak?- (void) processImage:(char *)image; ---char* 导致内存泄漏?
【发布时间】:2009-08-26 12:21:46
【问题描述】:

在我的应用程序中,我正在尝试处理来自网络摄像头的 YUV422 图像。但我遇到了巨大的内存泄漏。下面你可以看到我的应用程序的简化代码示例。如果我禁用函数中的“(m1...”行,则没有泄漏。(但图像没有被处理)。我尝试了锁、池等,但没有任何改变。我是可可相对较新,所以所有这些方括号对我来说看起来很有趣/很可怕;-)
使用“char
”有问题吗?在我的旧 linux+c++ 应用程序中没有问题。但我使用的是“unsigned char*”,没有线程,而且我从未检查过泄漏...

全局:

...
char m [640*480];

“主要”:

...
[NSThread detachNewThreadSelector:@selector(processOutputBuffer) toTarget:self withObject:nil];
...

函数1:

- (void)processOutputBuffer {
[NSThread setThreadPriority:0.4];
[lock lock];
...
Ptr outputBufferBaseAddress = (Ptr)CVPixelBufferGetBaseAddress(outputBuffer);
CVPixelBufferLockBaseAddress(outputBuffer, 0);
[self yuv422_to_y8uv8:outputBufferBaseAddress m1:m];
...
}

函数2:

- (void) yuv422_to_y8uv8:(char *)image m1:(char *)m1 {
 int x,y;
 for (y = 0; y < 480; y++)
  for (x = 0; x < 640; x++)
   {
   *(m1 + (640 * y) + (x))=*(image + (640*2 * y) + (x*2)+1);
   }
}

【问题讨论】:

    标签: cocoa image-processing memory-leaks


    【解决方案1】:

    如果我在函数中禁用“*(m1...”行,就没有泄漏。

    不真实。那只是一个任务。要么没有泄漏,要么这不是泄漏的原因。

    您可以使用 Instruments 来查找泄漏的对象(普通内存分配和 Cocoa 对象),并诊断泄漏。

    使用“char *”有问题吗?

    没有。类型不会导致泄漏。不正确的内存管理会导致泄漏。

    在我的旧 linux+c++ 应用程序中没有问题。但我使用的是“unsigned char*”,没有线程,而且我从未检查过泄漏...

    您可能在添加线程或添加 Cocoa 代码时引入了泄漏。同样有可能泄漏一直存在,而您以前从未见过。只有当您发现 Instruments 或其他工具的问题时,您才能确定。

    您也可以尝试运行 Clang 静态分析器。它可以检测一些导致泄漏的代码模式等。

    【讨论】:

    • 静态分析器发现了一些问题,但没有泄漏;仪器(来自 xcode v3.1 的 v1.5)发现了一个巨大的泄漏(仅在启用该行时)但是......它说 CVObject 需要 496 B(这对我来说没有意义,因为这条特定的行不包含任何 CVObject(无论是什么)) LeakedBlocks>XxXXXXXHistory> Category=CVObject, EventType=malloc, size=496, ResponsibleLibrary=CoreVideo, ResponsiblCaller=CVObject::alloc(..long, ..const, ..long , ..long) .....谢谢您的任何建议.....
    • 496 字节不是“巨大的泄漏”。尝试按净对象数对列表进行排序,然后查找既不是 Cocoa 也不是 Core Foundation 的类。
    • 感谢您的回答。它对我帮助很大——我终于开始使用正确的工具在正确的方向上搜索...#net 没有显示泄漏,就像我将 496B 误认为是“巨大泄漏”一样。但是,观察另一台仪器正在运行,我注意到“GeneralBlock-618496”的#net 计数相对较小,但 NetBytes 巨大 - 1 分钟后运行超过 500MB。这些实例的 ReponsibleCallers 是:CVPixelBufferBacking::initWithPixelBufferDescription(...) 所以现在我知道我迷路了,我想我现在回到了正轨;-)
    • 这看起来与我当前的问题相似:lists.apple.com/archives/quicktime-api/2008/Jul/msg00161.html
    • 确保你释放outputBuffer,如有必要(这取决于你如何获得它,你没有显示)。
    【解决方案2】:

    一个蹩脚的答案...我知道。但万一你没有更好的答案。您总是可以将函数放在 C 文件中,并使其成为纯 c。

    看看它是否能解决泄漏甚至可能会很高兴。如果不是,那么问题出在其他地方。

    【讨论】:

    • 我可能想尝试一下,但不幸的是我“必须”走向可可,而不是“回到”c/c++
      但是.....当然...... .如果没有任何帮助,我也会尝试。谢谢。
    • so.... 事实证明我不会尝试这个,因为泄漏完全在其他地方。无论如何 - 感谢您的时间和“善意”
    猜你喜欢
    • 2011-12-14
    • 2015-07-22
    • 1970-01-01
    • 1970-01-01
    • 2018-10-09
    • 2013-01-25
    • 2021-11-01
    • 1970-01-01
    • 2011-07-09
    相关资源
    最近更新 更多