The glorious life of a bug killer
So there are a lot of things to enjoy while you are developing software. There are also the things that will frustrate you. The last 24 hours has leaned a bit heavy on the frustration side. A story to illustrate what us programmers go through.
So I got a crash report email about the feedback window. I needed to test and this required me to spend some time jumping from my main development system (10.5) to 10.6 (where the crash happened).
Aside: Since coming back I haven’t spent a lot of time in 10.6. I didn’t want to spend my first weeks back migrating all my stuff, I wanted to spend my time working on features and other polish.
So first things first, I test it on 10.6.0 (which shows you how long ago I’ve been here). Hit send, no crash. Upgrade the system to 10.6.2, hit send, no crash. Jump back to 10.5.8, hit send, no crash. Check email but only see a few reports and none from 10.6.
First thought is JRFeedbackController probably needs to be upgraded for 10.6. Go to the project website, see lots of changes but nothing about SL compatibility. Figure I’m going to upgrade anyways. Do the upgrade, rebuild my app, jump to 10.6, hit send, no crash. Try to check my email account for the report via my site’s webmail front end (which I rarely use) and it doesn’t work because of the tricks I play with DNS. So ok, back to 10.5.8 and Entourage to check the email. Still no report.
To recap the feedback window works fine in 10.5.8, no crash, report is sent properly via the PHP form it POSTs to. In 10.6 no crash, but no report either. I need to step through the app to see what is going on. Download and install the Snow Leopard developer tools. Make a copy of the app source try to build, lots of xib warnings about image cropping and a BIG error about a plugin I use, RBSplitView.
Basically my xib uses the class RBSplitView and the Xcode complier requires that Interface Builder on SL know about the plugin. I go into IB, tell it where the plugin is located, try to recompile, still doesn’t work. Go to the project website and grab the latest update (again, maybe there were SL changes that I need to update for). Still doesn’t work. Then find this little jewel in the support forums for the open source project:
Just to clarify with using older nib/xib files with the new plugin, it appears the difference is that the old plugin used the identifier “net.brockerhoff.RBsplitView.IBPlugin”, whereas the new one uses “net.brockerhoff.RBSplitView.IBPlugin” (notice the change in case), so IB treats them as different plugins. To get your old xib file to work, open it up in a text editor, find the “IBDocument.PluginDependencies” object, and change the plugin identifier there to an uppercase “S”, so it matches the new plugin.
Lovely. So I open up the xibs in BBEdit, do the find/replace I need and finally I get the app to build!
Aside: To be clear, I’m not trying to bash JRFeedback or RBSplitView. I love both of these open source projects. Just trying to illustrate the process I’m going through to get my stuff to work.
Over the next hour or so I debug the app, stepping through, trying to get it to output the exact POST request it is pushing out onto the web. Every time I log the post to console it’s way too short. I go a bit deeper in the rabbit hole to the requestWithURL:postForm: class method that is added via a JRFeedback category. This is the method that takes the dictionary of values of the report and encodes them for web transit. I step through this method and honestly the code looks fine. I start adding log statements to see how it progresses and what I find is that when I decode the data into a string to see how the post is looking the string will increase in length as the method processes the dictionary but when I post the string to console via NSLog its always truncated. Like it’s length will be 900 and yet on the console I’m only getting 70 characters.
The demo app for JRFeedback works fine on 10.6.2. The end result is something in my project (a build setting, a colliding category method, ???) is breaking this for me and only on Snow Leopard. I have never seen this strange NSString behavior. I really don’t know where to go next. For now I need to put it away cause it’s killing my brain.
It just really sucks though. Since I pushed out the open beta I know (via log files) that a good number of people have sent in feedback this way. Most on Snow Leopard, with no sign I didn’t get the feedback and of course no reply since I really didn’t get it.
If you have any suggestions please let me know. Thanks.
Posted on: January 15, 2010 – 9:11 PM
Hi. My name is 
3 Comments
Sounds like your string contains a NUL (”) character around the 70 character point. NSString is perfectly happy to contain NUL characters, and it does no harm there. However, the moment that you convert it to a C string, for example when printing it in the debugger, that NUL character will be interpreted as a string terminator, and your output will be truncated. It will not only truncate debug printing, but anything else that goes through a C string, like filesystem paths, and possibly whatever you’re using to post your HTTP request.
To help with debugging, I recommend printing [string dataUsingEncoding: NSUTF8StringEncoding] for this case. The output is not as readable, but it will show the entire string, including any NUL characters.
Well, that NUL didn’t quite come out right. The thing in the single quotes in the parentheses is supposed to be a backslash-zero.
Thanks for the tips Mike. I used em a bit tonight and eventually tripped over the issue (colliding category methods only on 10.6). Hope to post more about the issue on the blog soon.
Post a Comment | Comment RSS feed