Skip navigation.
 
mlRe: Crashes with no backtrace when printing
FROM : Ben
DATE : Fri Jul 04 08:55:21 2008

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.

Related mailsAuthorDate
mlCrashes with no backtrace when printing Ben Jul 4, 01:24
mlRe: Crashes with no backtrace when printing Brian Stern Jul 4, 05:39
mlRe: Crashes with no backtrace when printing Jens Alfke Jul 4, 06:44
mlRe: Crashes with no backtrace when printing Ben Jul 4, 08:46
mlRe: Crashes with no backtrace when printing Ben Jul 4, 08:55