处理关键事件时NSTextField泄漏

处理关键事件时NSTextField泄漏

本文介绍了处理关键事件时NSTextField泄漏的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是这个论坛的新手,我已经搜索过但未找到解决此问题的任何答案,这个问题困扰了我本周的大部分时间.

I'm new to this forum and I have searched but not found any answers to this problem which has been puzzling me for best part of this week.

每次按下一个键时,NSTextField都会导致内存泄漏.

An NSTextField causes a memory leak every time a key is pressed.

我已经从代码中隔离了此问题,可以将其复制如下:

I have isolated this problem from my code and it can be reproduced as follows:

  • 创建一个新的可可应用"项目.
  • 在主菜单xib窗口中放置一个NSTextfield. (无约束力,插座或动作)
  • 产品->配置文件,选择内存泄漏"工具(在XCode 4中)

在用户在文本字段中输入字符之前,不会泄漏.我得到8个泄漏的32bytes的NSCFString对象,其类型如下:

No leaks until the user enters a character in the text field.I get 8 leaked NSCFString objects of 32bytes of the following types:


Library     Responsible Caller
0     CFString     Malloc     00:11.524.538     1     0x100130bb0     32     AppKit     -[NSEvent charactersIgnoringModifiers]
1     CFString     Malloc     00:11.622.145     1     0x100136950     32     AppKit     -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]

请注意,该项目除了自动生成的内容外没有其他代码.

Please note that this project has no code other than the auto generated stuff.

如果有人能重现此问题,甚至可能提出如何防止此问题的建议,我会很感兴趣.

I would be interested if anyone else can reproduce this problem and maybe even offer a suggestion how to prevent it from occuring.

带有XCode 4.0.2的OS X 10.6.8(与3.2.6发生相同的问题)

OS X 10.6.8 with XCode 4.0.2 (same problem occurs with with 3.2.6)

任何建议将不胜感激,并且可以减少我目前的沮丧情绪.

Any suggestion would be greatly appreciated and would decrease my current level of frustration.

更新:

在不同的Mac上尝试了上面的项目创建.发现其中一个不产生泄漏(使用与上述相同的过程来创建项目)在从未安装XCode的Mac上安装了XCode 4-没有泄漏!

Tried the above project creation on different macs.Found that one of them produces no leaks (using the same procedure as above to create project)Installed XCode 4 on a mac that never had XCode installed - no leaks!

仍然有记忆.

  • 删除了同一MPro上的HDD,安装了OS X 10.6,软件更新为10.6.8
  • 已安装XCode4
  • 创建了与上述相同的测试项目

没有内存泄漏!!!!

现在很清楚,此问题的根源在安装过程中的某个地方,而不仅仅是Instruments的误报".我的个人资料运行已执行了多次,因此一次过执行,其行为在我的Mac上可100%重现.

It is now clear that the root of this problem is somewhere in the installation and not just a "False Positive" of Instruments. My profile runs were executed multiple times so there is being a one-off and the behaviour was 100% re-producable on my macs.

现在的问题:我仍然有27英寸的iMac,无法删除HDD.我猜测安装的某些东西(框架?)在升级或重新安装XCode时不会更新/删除.

Problem now: I still have a 27" iMac where HDD erase is not an option.I'm guessing that there is something installed (Framework?) that doesn't get updated/deleted when upgrading or reinstalling XCode.

非常感谢您提出此问题的想法.

Your ideas on the cause of this issue are greatly appreciated.

推荐答案

这几乎肯定是假阳性.泄漏工具不是万无一失的,它在某些情况下可能会标记为泄漏(单例是常见示例),请参见.

This is almost certainly a false positive. The Leaks instrument is not infallible, and it may mark some things as a leak when they are not (singletons are a common example), see my answer to this question.

我怀疑这里看到的是字段编辑器的创建,该编辑器为每个包含至少一个文本字段单元格的窗口创建一次.它是延迟创建的,因此仅在需要时即在开始文本编辑时才实例化.然后,它将重新用于该窗口中的所有文本字段编辑,并且直到窗口消失后才将其释放.这正是可能会在泄漏"工具中触发误报的行为.

I suspect that are seeing here is the creation of the field editor, which is created once for each window containing at least one text field cell. It is lazily created so will only be instantiated when required, i.e. when text editing begins. It is then re-used for all text field editing in that window and is not deallocated until the window goes away. This is exactly the sort of behaviour that can trigger false positives in the Leaks instrument.

通用对象极其不太可能发生主要的内存泄漏.它们已经过非常彻底的测试,并且在OS版本之间根本没有太大变化.

Common objects such as NSTextField are extremely unlikely to have major memory leaks. They have been very thoroughly tested and do not change much if at all between OS versions.

这篇关于处理关键事件时NSTextField泄漏的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-02 05:34