Re: Crashes with no backtrace when printing
Re: Crashes with no backtrace when printing
- Subject: Re: Crashes with no backtrace when printing
- From: Ben <email@hidden>
- Date: Fri, 4 Jul 2008 07:55:21 +0100
Thanks for the tips Brian & Jen, using them I've now found that when
the app crashes, there is a reference count underflow somewhere:
MyApp(15221,0xb0103000) malloc: reference count underflow for
0x14d6220, break on auto_refcount_underflow_error to debug.
Using the breakpoint above in the debugger enables me to get a more
meaningful backtrace. I have uploaded screenshots of the first here,
and the second is what happens when you continue from that point.
http://tinypic.com/view.php?pic=11tsk5g&s=3
http://tinypic.com/view.php?pic=zwdafs&s=3
It also generates this:
=shlibs-removed,shlib-info=[num="112",name="X20Function",kind="F",dyld-
addr="0xb522000",reason="dyld",requested-state="E",state="E",path="/
Library/Printers/EPSON/InkjetPrinter/Libraries/X20Function.framework/
Versions/A/X20Function",description="/Library/Printers/EPSON/
InkjetPrinter/Libraries/X20Function.framework/Versions/A/
X20Function",loaded_addr="0xb522000",slide="0xb522000",prefix=""]
Now normally I wouldn't be arrogant enough to say that this is a bug
in the frameworks or some other dependancy, but I cannot see a fault
anywhere in my two methods within those traces. All the needed objects
are still around at the end of printing, so nothing seems to be being
collected. Could it be somewhere in the epson printer framework? The
calls to PDEContent::InitDialog look like C++ to me and that's just
voodoo as far as I'm concerned.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden