如何避免GC环境中自定义NSURLProtocol中_NSCFURLProtocolBridge中的引用计数下溢

Question

基础知识是我有一个自定义的 NSURLProtocol。 在 startLoading 中，[self client] 的类型为：

<_NSCFURLProtocolBridge> {NSURLProtocol, CFURLProtocol}

问题是在垃圾收集环境中运行它。 因为我正在编写一个屏幕保护程序，所以我被迫对其进行垃圾收集。 然而， _NSCFURLProtocolBridge 协议似乎总是抛出：

malloc：(memory_id_here) 的引用计数下溢，在 auto_refcount_underflow_error 上中断进行调试

转储到调试控制台的示例如下：

ScreenSaverEngine[1678:6807] 客户端是 <_NSCFURLProtocolBridge 0x20025ab00> {NSURLProtocol 0x200258ec0，CFURLProtocol 0x20029c400} ScreenSaverEngine(1678,0x102eda000) malloc：0x20025ab00 的引用计数下溢，在 auto_refcount_underflow_error 上中断进行调试。

您可以看到 <_NSCFURLProtocolBridge 0x20025ab00> 发生了下溢。

当我中断 auto_refcount_underflow_error 时，似乎堆栈跟踪回 URLProtocolDidFinishLoading: 中：

id client = [self client];
...
[client URLProtocolDidFinishLoading:self];

这个问题似乎已经存在了一段时间，但似乎没有答案全部在线：

http://lists.apple.com/archives /cocoa-dev/2008/May/msg01272.html http://www.cocoabuilder.com/archive/message/cocoa /2007/12/17/195056

该错误也仅在这些列出的错误的垃圾收集环境中出现。 关于如何解决这个问题而不引起内存问题有什么想法吗？ 我假设这可能与 NSURLProtocol 下的 CF 类型发布不当有关？

Answer 1

这是我不久前提交的错误报告：

http://openradar.appspot.com/8087384

也许也值得归档，它已经被复制了，但最好能修复它。

正如 Alex 所说，一位苹果开发人员查看了我面前的源代码，并通过我们的示例轻松找到了问题所在。

Answer 2

有时在打开的对话框过滤器中使用 NSURL 会出现同样的错误。
对我来说，在我不再需要它之后将其明确设置为 nil 就足够了。

Answer 3

上次 WWDC 上我们向一位 webkit 工程师确认了这个 bug，他可以在代码中看到这个 bug，所以希望他们能够修复它。 解决方法是在 initWithRequest 方法中 CFRetain 客户端。

- (id)initWithRequest:(NSURLRequest *)request cachedResponse:(NSCachedURLResponse *)cachedResponse client:(id <NSURLProtocolClient>)client
{
    // work around for NSURLProtocol bug
    // note that this leaks!
    CFRetain(client);

    if (self = [super initWithRequest:request cachedResponse:cachedResponse client:client])
    {
    }

    return self;
}

Answer 4

这是 _NSCFURLProtocolBridge 实现中的一个错误。

请使用 http://bugreport.apple.com/ 并提交错误。 如果您包含此页面的 URL，我们将不胜感激（如果您使用 Radar # 更新此页面，我们也将不胜感激）。 理想情况下，如果您可以附加屏幕保护程序的二进制文件，那将非常有帮助； 无需来源。

幸运的是，它不会导致崩溃。 不幸的是，它可能会导致泄漏。

Answer 5

此错误通常表明对象是用 -retain 保留的，但用 CFRelease() 释放的。 如果您认为这不可能是您的目标（这并不是一个可怕的信念），那么您应该打开另一个雷达。 但您应该首先环顾四周，看看是否有一个 CF 对象正在使用 -retain，而您也许应该使用 CFRetain()。

其余的都是在黑暗中拍摄......

您可以通过逐步提高堆栈并查看传递给这些 C++ 方法（或特别是 auto_zone_release）的参数来获得一些见解。 在 gdb 中尝试查看第一个参数中的内容：

p *($esp)

并查看是否可以深入了解正在传递的对象。 如果你幸运的话，也许这会起作用：

po (id)(*($esp))

Answer 6

我通过 CFRetain-ing 客户端，并在下次调用 startLoading 时再次 CFRelease-ing 解决了这个问题

-(void)startLoading 
{
        if ( client ) CFRelease(client);
        client = [self client];
        CFRetain(client);

，当然， Finalize中的

-(void)finalize
{
    if ( client ) CFRelease(client);
    [super finalize];
}

client是NSURLProtocol子类的实例变量。