Re: Getting a better stack trace with PyObjc possible?

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 <[email protected]>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 <[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

_______________________________________________
Pyobjc-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyobjc-dev