Debugging a strange MacOS X printing problem

At some point in time, something changed on my system that resulted in my printer no longer printing. (Cue a relevant scene from Office Space here…) A quick Googling of relevant keywords didn’t turn up anyone else complaining about what I was observing, so I did what any lazy person would do: I found another way to print what I needed to print, and forgot all about it.

Now, several months later, the problem still persists, and while I found a suitable workaround (use the “Generic PostScript printer” driver instead of the Lexmark one), the hardcore geek in me felt it necessary to struggle against the injustice of this whole “it doesn’t work” thing. It should work, damn it.

First, here’s what the most obvious symptom looks like:

/Library/Printers/Lexmark/filter/pstopsprinter1 failed

Along with this will be an entry in the system log which you can see in

1/25/13 12:19:02.275 PM ReportCrash: Saved crash report for pstopsprinter1[78490] version ??? (???) to /Library/Logs/DiagnosticReports/pstopsprinter1_2013-01-25-121902_localhost.crash

If you look inside the crash report, you’ll see:

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFArray length]: unrecognized selector sent to instance 0x1006036b0'

Great. Just great. So, we fire up our handy-dandy debugger, and what is the object it’s choking on?

(gdb) po 0x1006036b0
<__NSCFArray 0x1006036b0>

Aww, damn. I recognize what that is. Those are the domains defined in my /etc/resolv.conf‘s “search” parameter.

Here’s the whole backtrace:

(gdb) bt
#0  0x00007fff93b09ce2 in __pthread_kill ()
#1  0x00007fff9392a7d2 in pthread_kill ()
#2  0x00007fff9391ba7a in abort ()
#3  0x00007fff8ce037bc in abort_message ()
#4  0x00007fff8ce00fcf in default_terminate ()
#5  0x00007fff8d9931b9 in _objc_terminate ()
#6  0x00007fff8ce01001 in safe_handler_caller ()
#7  0x00007fff8ce0105c in std::terminate ()
#8  0x00007fff8ce02152 in __cxa_throw ()
#9  0x00007fff8d992e7a in objc_exception_throw ()
#10 0x00007fff954c81be in -[NSObject doesNotRecognizeSelector:] ()
#11 0x00007fff95428e23 in ___forwarding___ ()
#12 0x00007fff95428c38 in __forwarding_prep_0___ ()
#13 0x00007fff9539f426 in CFStringGetLength ()
#14 0x00007fff953affac in CFStringFindWithOptionsAndLocale ()
#15 0x00007fff953b67da in CFStringHasSuffix ()
#16 0x00007fff953ed7f6 in -[__NSCFString hasSuffix:] ()
#17 0x00007fff8e1ab6da in __-[NSHost resolveCurrentHostWithHandler:]_block_invoke_7 ()
#18 0x00007fff90497c75 in _dispatch_barrier_sync_f_invoke ()
#19 0x00007fff8e1a9b5d in -[NSHost resolveCurrentHostWithHandler:] ()
#20 0x00007fff8e1aa5a7 in __-[NSHost resolve:]_block_invoke_1 ()
#21 0x00007fff90495a82 in _dispatch_call_block_and_release ()
#22 0x00007fff904972d2 in _dispatch_queue_drain ()
#23 0x00007fff9049712e in _dispatch_queue_invoke ()
#24 0x00007fff90496928 in _dispatch_worker_thread2 ()
#25 0x00007fff9392a3da in _pthread_wqthread ()
#26 0x00007fff9392bb85 in start_wqthread ()

Well, let’s see what it was trying to resolve, maybe that’ll give us a clue:

(gdb) frame 20
#20 0x00007fff8e1aa5a7 in __-[NSHost resolve:]_block_invoke_1 ()
(gdb) po $rdi

Yup, that would be the DNS name of my machine, based on the reverse DNS of my IP address on my local private network. However, it appears that forward DNS for that FQDN isn’t resolvable, due to a recent change in my DNS setup. Let’s fix this, and correct the DNS so that the FQDN resolves, and test again.

Still fails. Damn, not going to be that easy, huh?

(gdb) frame 13
#13 0x00007fff9539f426 in CFStringGetLength ()
(gdb) info frame
Stack level 13, frame at 0x1003d72c0:
 rip = 0x7fff9539f426 in CFStringGetLength; saved rip 0x7fff953affac
 called by frame at 0x1003d7770, caller of frame at 0x1003d72a0
 Arglist at 0x1003d72b8, args: 
 Locals at 0x1003d72b8, Previous frame's sp is 0x1003d72c0
 Saved registers:
  rbx at 0x1003d72a8, rbp at 0x1003d72b0, rip at 0x1003d72b8
(gdb) po $rbx
<__NSCFArray 0x1006036b0>(

And, here it is. CFStringGetLength is expecting a CFStringRef and instead getting handed a NSCFArray, and is blowing up because CFStringGetLength trying to [str length] it.

I wish I knew someone who was doing OSX development at Apple to pass this bug along to …

Updated: I filed this as a bug in Apple’s Radar bug reporting system. It was assigned bug ID #13089829.


  1. Ron says:

    I have the same problem, but, on my side, it is related to the last “Airport utility” update. My printer is plugged in the usb port of my Airport Extreme router and was working good before the last Airport utility update. You know, the one with the new look and less options. Since then, I have lost the “printer” tab. Anyway, since 10.7 Apple is slowly losing it ! Bizarre… success seems to mean worst development from Apple. I find it sad !

Speak Your Mind