NSTableView reloadData泄漏内存 [英] NSTableView reloadData leaking memory

问题描述

我一直在使用Instruments应用程序检查我的应用程序是否泄漏.在某些情况下，HUD面板中的表视图将每秒更新一次.一切正常，除了每秒(reloadData)_NSArrayl对象的数量增加一.如果我将数据源更改为return(@"); (它们都是文本单元格)，问题仍然存在(不变).如果我将所有周围的代码都删除为:

I've been checking my application for leaks using the Instruments application. Under a certain set of circumstances a table view in a HUD Panel is being updated once a second. It is all working fine except every second (reloadData) the number of _NSArrayl objects increases by one. If I change my datasource to just a return(@""); (they are all text cells) then the problem stays (no change). If I remove all my surrounding code to just:

[myTableView reloadData];

和

- (id)tableView:(NSTableView *)tv objectValueForTableColumn:(NSTableColumn *)column row:(int)rowIndex {
   return(@"");
}

(甚至返回nil)

问题仍然存在.注释掉[myTableView reloadData]，问题就消失了. 每个块都是一个_NSarrayl，大小为32个字节，详细信息:

problem persists. Comment out the [myTableView reloadData] and problem goes away. Each block is an _NSarrayl and is 32 bytes in size, and the detail:

   0 libsystem_c.dylib calloc
   1 libobjc.A.dylib class_createInstance
   2 CoreFoundation __CFAllocateObject2
   3 CoreFoundation +[__NSArrayI __new::]
   4 CoreFoundation -[__NSPlaceholderArray initWithObjects:count:]
   5 CoreFoundation +[NSArray arrayWithObjects:]
   6 AppKit -[NSWindow _runLoopModesForInvalidCursorRectsObserver]
   7 AppKit __-[NSWindow _postInvalidCursorRects]_block_invoke_1
   8 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
   9 CoreFoundation __CFRunLoopDoObservers
  10 CoreFoundation __CFRunLoopRun
  11 CoreFoundation CFRunLoopRunSpecific
  12 HIToolbox RunCurrentEventLoopInMode
  13 HIToolbox ReceiveNextEventCommon
  14 HIToolbox BlockUntilNextEventMatchingListInMode
  15 AppKit _DPSNextEvent
  16 AppKit -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
  17 AppKit -[NSApplication run]
  18 AppKit NSApplicationMain

我在这些对象的历史记录中注意到有一个自动释放条目，因此我想知道它是否已被自动释放(保留计数仍为1).但是5分钟后，没有任何东西释放它们，因此也许没有释放自动释放池.我不创建任何自动释放池(也不释放任何池)，而保留应用程序框架.我应该对自动释放池做些什么?

I have noticed in the history for these objects there is an Autorelease entry so I do wonder if it has been autoreleased (retain count is still 1). But after 5 mins+, nothing has released them so maybe the autorelease pool is not being released. I do not create any autorelease pools (and don't release any), leaving that the application framework. Should I be doing something with the autorelease pools ?

#   Address Category    Event Type  RefCt   Timestamp   Size    Responsible Library Responsible Caller
0   0x100669cf0 __NSArrayI  Malloc  1   00:01.342.634   32  AppKit  -[NSWindow _runLoopModesForInvalidCursorRectsObserver]
1   0x100669cf0 __NSArrayI  Autorelease <null>  00:01.342.636   0   AppKit  -[NSWindow _runLoopModesForInvalidCursorRectsObserver]

关于我可能做错了什么的任何建议，将不胜感激.

Any suggestions as to what I might be doing incorrectly will be very appreciated.

请注意，一秒钟更新的情况不是应用程序的正常情况"，但是可能会发生，因此设计应用程序的时间很长；即不是运行，退出，再次运行，退出等应用程序.

Note that the circumstances of 1 second updates is not a "normal situation" for the application but it can happen and then application is designed for a long time; i.e. not an application your run, exit, run again, exit, etc.

它们没有被检测为泄漏"，但是分配计数一直在增加，因此我认为它们实际上是泄漏(或出了问题)

They are not being detected as "leaks" but the allocation count keeps increasing for ever so I assume they are leaks in practice (or something is going wrong)

我不使用ARC，而不是垃圾回收"，仅使用保留/释放系统，而我倾向于使用保留/释放，我自己的代码偶尔仅使用自动释放，而与此代码无关.

I'm NOT using ARC not "Garbage Collection" - just the retain/release system and I'm tend to use retain/release and my own code only uses autorelease occasionally and nowhere to do with this code.

其他信息:我一直在观看计数增加，仅使用Instruments应用程序(表格视图位于始终可见的HUD中).但是，如果我将鼠标移到泄漏的"表格视图上-计数回落到合理的水平.在屏幕上稍微移动包含表视图的HUD窗口，然后计数递减，依此类推.这似乎是由于缺少用户活动而导致的.我仍然很困惑，但是认为这个新发现可能对想法有所帮助(或者是否有人尝试复制它).

Additional Info: I have been sitting watching the count increase, only using the Instruments application (the tableview is in a HUD that is always visible). However, if I e.g. move the mouse over the "leaky" tableview - the count goes back down to something reasonable. Move the HUD window containing the tableview on the screen a bit and the count goes back down, etc. It seems to be the lack of user activity that is allowing this to happen. I'm still stumped but thought this new observation might help with ideas (or if anybody tried to reproduce it).

推荐答案

更新和后续问题(对不起)** 按照您的建议，我在[myTableView reloadData]下面添加了一些内容，以向应用程序发布虚拟消息/无害消息(看上去比直接发布到相关窗口更安全).

Update and subsequent question (sorry) ** Following your advice, I have added a bit below the [myTableView reloadData] to post a dummy/harmless message to the Application (looked safer than posting directly to the window concerned).

NSEvent *dummyEvent=[NSEvent mouseEventWithType:NSMouseMoved location:NSMakePoint(0.0,0.0) modifierFlags:0 timestamp:0.0 windowNumber:0 context:nil eventNumber:0 clickCount:0 pressure:0.0];
[NSApp postEvent:dummyEvent atStart:FALSE];

我的想法是添加一些将在表视图包含所有内容之后发生的事情(基本上是在事件队列为空时.这看起来像用户在做某事.它似乎在分配分配不断增加的范围内起作用)不再增加(按预期移动，但基本稳定).

My idea was to add something that will happen after the table view has cone everything (basically when the event queue becomes empty. that will look like the user doing something. It seems to work in so far as the ever increasing allocation count no longer increases (moves around a bit as expected but is basically stable).

但是，我对事件没有做太多事情，并且担心我的"dummyEvent"可能不是无害的，或者将来可能会引起问题.有没有更好的方法可以做到这一点，还是有更好的事件(或参数)我应该使用?

However, I have not done much with events and am concerned that my "dummyEvent" might not be harmless or might start causing problems in future. Is there a better way to achieve this or is there a better event (or parameters) I should use ?

我确实尝试过

NSEvent *dummyEvent=[NSEvent otherEventWithType:NSApplicationDefined location:NSMakePoint(0.0,0.0) modifierFlags:0 timestamp:0.0 windowNumber:0 context:nil subtype:(short)(0) data1:0 data2:0];

但是我对此没有那么大的信心，因为我没有自定义事件处理程序，并且不确定它可能在哪里结束.另外，我还第一次遇到了这种变体的地址冲突-但我想知道那是否是其他事情了，因为它没有再发生.只要我的任何参数都不会导致崩溃/断言失败或类似情况，我就能看到虚拟的鼠标移动将是无害的.

but I am less confidant in this as I have no custom event handlers and am unsure where it might end-up. Plus I also got an address violation 1st time with this variant - but I wonder if that is something else as it is has not happened again. I can see how a dummy mouse move would be harmless as long as none of my parameters would cause a crash/assertion failure or similar.

这篇关于NSTableView reloadData泄漏内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！