Re: [Pyobjc-dev] Getting a better stack trace with PyObjc possible?
Brought to you by:
ronaldoussoren
Menu
▾
▴
Re: [Pyobjc-dev] Getting a better stack trace with PyObjc possible?
|
From: Ronald O. <ron...@ma...> - 2011-12-28 11:34:51
|
You cannot extract the python stack trace from a Apple crash log, but could save one yourself using the faulthandler package <http://pypi.python.org/pypi/faulthandler/>. I have a slightly longer message in my mail.app outgoing folder, that will get send once I have full Internet connectivity again (this mail is send through webmail). Ronald On Dec 28, 2011, at 09:09 AM, Ken Thomases <ke...@co...> wrote: On Dec 27, 2011, at 3:08 PM, Marc Van Olmen wrote: > I looked around the web and more specific stack overflow: I was hoping if there is something I can do to have a better stack trace from pyobjc/python. > > For example my end users send me this, after a hard crash. > > 0 libobjc.A.dylib 0x99b51c22 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 350 > 1 com.apple.CoreFoundation 0x97b2c515 _CFAutoreleasePoolPop + 53 > 2 com.apple.Foundation 0x96316b87 -[NSAutoreleasePool release] + 131 > 3 com.apple.CoreFoundation 0x97b01749 CFRelease + 169 > 4 _objc.so 0x04019c21 object_dealloc + 257 > 5 org.python.python 0x01c6e2cf subtype_dealloc + 575 > 6 org.python.python 0x01c3a041 frame_dealloc + 385 > 7 org.python.python 0x01ced87c tb_dealloc + 156 > 8 org.python.python 0x01ced88c tb_dealloc + 172 > 9 org.python.python 0x01c52179 PyDict_DelItem + 249 > 10 org.python.python 0x01c52251 PyDict_DelItemString + 49 > 11 org.python.python 0x01cb940a PyEval_EvalFrameEx + 4810 > 12 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862 > 13 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862 > 14 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862 > 15 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862 > 16 org.python.python 0x01cbee9d PyEval_EvalCodeEx + 2109 > 17 org.python.python 0x01c3ba36 function_call + 166 > 18 org.python.python 0x01c0a315 PyObject_Call + 85 > 19 org.python.python 0x01c1c8e6 instancemethod_call + 422 > 20 org.python.python 0x01c0a315 PyObject_Call + 85 > 21 org.python.python 0x01cb717e PyEval_CallObjectWithKeywords + 78 > 22 org.python.python 0x01cf89d6 t_bootstrap + 70 > 23 libsystem_c.dylib 0x957c2ed9 _pthread_start + 335 > 24 libsystem_c.dylib 0x957c66de thread_start + 34 > > > Would be nice to know which method and object was called at > > PyEval_EvalFrameEx + 21862 > > for example. I assume you know that "PyEval_EvalFrameEx + 21862" doesn't correspond to any particular Python code. Since Python is running as an interpreter, the Python code is purely data and doesn't correspond to any machine instructions. Therefore, the stack trace doesn't "see" it. It's only seeing the Python interpreter's functions. So, you're asking for the crash reporter to look into the data being used by a function, not just translating the function's address to a symbol. Certainly, there's no way to coax the crash reporter to do that. Likewise, there's no way to deduce the Python code being executed just by analyzing a crash report. Since the crash appears to be due to an over-release, you can try to get more information about the specific object using the "zombies" facilities of the frameworks. If the issue is reproducible, you can ask your users to run your app with certain environment variables set, such as: CFZombieLevel=19 NSZombieEnabled=YES /Applications/YourApp.app/Contents/MacOS/YourApp (I'm not actually certain that the "CFZombieLevel=19" is desirable. You might have them try with and without, if they're willing.) That should at least cause a better diagnostic message to be printed to the console log at the time of the crash. I believe that messaging a zombie triggers a SIGTRAP these days instead of raising an exception. The latter would have been nice in that it might have been translated into a Python exception and provoked Python into dumping a backtrace. Instead, the SIGTRAP will just crash your app in a slightly different way than the above. However, you may be able to translate the SIGTRAP into a Python exception by setting a Python signal handler for SIGTRAP. That would get you a better backtrace from zombies. By the way, you've excerpted a crash report. You may have left out some important information about the specific nature of the crash. Also, if you haven't already, you should ask your users if anything was written to the console log at the same time as the crash. Good luck, Ken ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Pyobjc-dev mailing list Pyo...@li... https://lists.sourceforge.net/lists/listinfo/pyobjc-dev |
