来自 UIAlertView _performPopup 的低级 iOS 崩溃

发布于 2024-10-04 21:48:38 字数 1258 浏览 0 评论 0原文

我最近遇到了一些低级别的崩溃,尤其是这个崩溃很难确定应用程序的起源/状态。有谁见过这个或知道这个问题吗?谢谢!

异常类型:EXC_BAD_ACCESS (SIGSEGV) 异常代码:KERN_INVALID_ADDRESS 位于 0x3dcccccd 崩溃的线程:0

异常类型:EXC_BAD_ACCESS (SIGSEGV) 异常代码:KERN_INVALID_ADDRESS 位于 0x3dcccccd 崩溃的线程: 0

线程 0 崩溃: 0 libobjc.A.dylib 0x000025fa objc_msgSend + 18 1 UIKit 0x00162d1c -[UIAlertView(Private) _performPopup:] + 12 2 UIKit 0x001628de -[UIAlertView(私人)_repopup] + 10 3 UIKit 0x0016d196 - [UIAlertView(私人)_removeAlertWindowOrShowAnOldAlert] + 70 4 UIKit 0x00162afa -[UIAlertView(私人)_popoutAnimationDidStop:完成:] + 502 5 UIKit 0x00050ae4 -[UIViewAnimationState sendDelegateAnimationDidStop:完成:] + 184 6 UIKit 0x000509ee -[UIViewAnimationStateanimationDidStop:完成:] + 34 7 QuartzCore 0x0002ee8c run_animation_callbacks(双精度,void *)+ 284 8 QuartzCore 0x0002ed2c CA::timer_callback(__CFRunLoopTimer*, void*) + 96 9 CoreFoundation 0x00022d1c CFRunLoopRunSpecific + 2092 10 核心基础 0x000224da CFRunLoopRunInMode + 42 11 图形服务 0x000030d4 GSEventRunModal + 108 12 图形服务 0x00003180 GSEventRun + 56 13 UIKit 0x0000342a-[UIApplication_run] + 374 14 UIKit 0x00001954 UIApplicationMain + 636 15 iPadDrinkHub.1.0.7 0x00002f24 0x1000 + 7972 16 iPadDrinkHub.1.0.7 0x00002ed8 0x1000 + 7896

I've been getting some low level crashes lately, and this one in particular is hard to determine the origin / state of the app. Has anyone seen this or know the problem? Thanks!

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x3dcccccd
Crashed Thread: 0

Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x3dcccccd Crashed Thread: 0

Thread 0 Crashed: 0 libobjc.A.dylib 0x000025fa objc_msgSend + 18 1 UIKit 0x00162d1c -[UIAlertView(Private) _performPopup:] + 12 2 UIKit 0x001628de -[UIAlertView(Private) _repopup] + 10 3 UIKit 0x0016d196 -[UIAlertView(Private) _removeAlertWindowOrShowAnOldAlert] + 70 4 UIKit 0x00162afa -[UIAlertView(Private) _popoutAnimationDidStop:finished:] + 502 5 UIKit 0x00050ae4 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 184 6 UIKit 0x000509ee -[UIViewAnimationState animationDidStop:finished:] + 34 7 QuartzCore 0x0002ee8c run_animation_callbacks(double, void*) + 284 8 QuartzCore 0x0002ed2c CA::timer_callback(__CFRunLoopTimer*, void*) + 96 9 CoreFoundation 0x00022d1c CFRunLoopRunSpecific + 2092 10 CoreFoundation 0x000224da CFRunLoopRunInMode + 42 11 GraphicsServices 0x000030d4 GSEventRunModal + 108 12 GraphicsServices 0x00003180 GSEventRun + 56 13 UIKit 0x0000342a -[UIApplication _run] + 374 14 UIKit 0x00001954 UIApplicationMain + 636 15 iPadDrinkHub.1.0.7 0x00002f24 0x1000 + 7972 16 iPadDrinkHub.1.0.7 0x00002ed8 0x1000 + 7896

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

画▽骨i 2024-10-11 21:48:38

奇怪的崩溃有时是内存损坏和/或管理不善的症状。几天前,我刚刚在我的一个应用程序中发现并修复了一个难以发现的错误。该应用程序在 iOS 3.2 上完美运行了 6 个月,但在 iOS 4.2 上会立即崩溃。在 applicationDidFinishLaunching 期间将主视图添加到窗口时发生崩溃。堆栈跟踪显示 100% iOS 代码;那里没有我的任何功能(除了 applicationDidFinishLaunching )。事实证明,我在加载视图时先前调用的代码中过度释放了 UIImage。 (我错误地在自动释放的 UIImage 上调用了release)。

我还没有看到您所看到的具体崩溃,但您可以尝试以下一些操作,这些操作可能会带来一些启发:

(1) 使用 NSZombieEnabled 运行应用程序。这是您通过 Xcode 设置的环境变量,它通常会识别您可能引用已释放对象的位置(例如,像我之前提到的过度释放示例)。其他详细信息如下:

http://www.cocoadev.com/index.pl?NSZombieEnabled

(2) 您可以打开日志记录,记录发送到所有对象的所有消息。该日志写入 tmp 文件夹中的文本文件。如果您检查导致崩溃的日志文件,您可能会深入了解崩溃之前发生的情况。这实际上是我用来解决 bug 的技术。您可以修改代码以启用/禁用日志记录:

instrumentObjcMessageSends(YES);
// Do stuff...
instrumentObjcMessageSends(NO);

或者,您可以直接从调试器调用该函数。例如,在崩溃之前设置一个断点,然后进入调试器控制台并执行以下操作:

(gdb) call (void)instrumentObjcMessageSends(YES)

其他详细信息如下:

http://www.dribin.org/dave/blog/archives/2006/04/22/tracing_objc/

Weird crashes are sometimes a symptom of memory corruption and/or mismanagement. I just found and fixed a difficult-to-find bug in one of my apps a few days ago. The app had been working flawlessly for 6 months on iOS 3.2, but would crash instantly on iOS 4.2. The crash was happening while adding the main view to the window during applicationDidFinishLaunching. The stack trace showed 100% iOS code; there wasn't a single function of mine in there anywhere (except for applicationDidFinishLaunching). It turned out I was over-releasing a UIImage in code that had been called earlier while views were getting loaded. (I was mistakenly calling release on an autoreleased UIImage).

I haven't seen the specific crash that you're seeing, but here are a few things you can try that may shed some light:

(1) Run the app with NSZombieEnabled. This is an environment variable you set via Xcode that will often identify places where you may be referencing objects that have already been freed (e.g., like the over-release example I mentioned earlier). Additional details are here:

http://www.cocoadev.com/index.pl?NSZombieEnabled

(2) You can turn on logging that will log all messages sent to all objects. The log is a written to a text file in the tmp folder. If you inspect the log file leading up to the crash, you may gain some insight into what's happening right before the crash. This is actually the technique I used to solve my bug. You can either modify your code to enable/disable logging:

instrumentObjcMessageSends(YES);
// Do stuff...
instrumentObjcMessageSends(NO);

Or, you can call the function directly from the debugger. For example, set a breakpoint right before the crash, then drop into the debugger console and do this:

(gdb) call (void)instrumentObjcMessageSends(YES)

Additional details are here:

http://www.dribin.org/dave/blog/archives/2006/04/22/tracing_objc/

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文