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: Marc V. O. <mar...@gm...> - 2011-12-28 15:47:30
|
Thanks to both of you for your thoughtful answers! I just looked at the source code of: http://pypi.python.org/pypi/faulthandler/ This looks very interesting, it doesn't seem to have much overhead, I could easily add this to my shipping app. This could be a very helpful tool. Thanks again. marc On Wed, Dec 28, 2011 at 6:34 AM, Ronald Oussoren <ron...@ma...>wrote: > 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 > > |
