I honestly thought I would be blogging a little bit more, since switching from Android to iPhone, since the iOS WordPress app is so nice, but I just don’t seem to get into it. It’s just too easy to post short stuff to Twitter, and photos to Instagram or Facebook …
I think a part of this is the belief that more people follow me on Twitter, or are friends of mine on Facebook, than read my blog.
There are times when I need to write something down because I know my poor rat brain won’t remember it, so I post it to my blog for my future self.
Then, there are times I want to share something with others… and those are the kinds of things I post to social media sites because that’s where I figure I’ll reach the most people. I suppose if I had the kind of audience that celebrities have, I could post everything here… but I don’t.
I guess I’m just doing some thinking out loud here (uh, typing out loud? writing out loud? writing in plain view?) … just confirming that my lack of posting is definitely not because of some barrier of difficulty: this iOS WordPress app makes this so damn easy.
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:
Along with this will be an entry in the system log which you can see in Console.app:
1/25/13 12:19:02.275 PM ReportCrash: Saved crash report for pstopsprinter1 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> [redacted], panoptic.com )
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 [redacted].panoptic.com
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>( [redacted], panoptic.com )
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.