Snow Leopard + WebKit + GC + CSS? Nope.

UPDATE: I’ve belatedly realize that although I quote the bug, I probably make it sound like this bug relates to all dynamic CSS, which is not the case.  In general it’s probably pretty rare to find random CSS code on the web that will trip the bug.  That said, if you are using Apple’s excellent Dashcode tool to create your HTML/CSS/JS, it’s actually pretty hard NOT to trip the bug.

Recently I was using a WebKit to serve up some static content in my Snow Leopard only, garbage collected app, when I ran into a crash with a call stack winding through WebKit and ending in an errant CFRelease.

The crash manifested whenever I tried to change CSS properties from JavaScript called back from my Objective-C code (via the WebKit WebScriptObject interface).  Pretty quickly, I realized that I could also get the crash to happen from JavaScript code changing CSS properties in a vanilla JavaScript timer callback, or pretty much any JavaScript code post page load / initial page render for that matter.

A good bit of WebKit source spelunking later revealed this little gem:

http://trac.webkit.org/changeset/50918

Thankfully, there is more than just the opaque reference to rdar://problem/7390716 (wonder what that bug is) and we get a reference to:

https://bugs.webkit.org/show_bug.cgi?id=31429

Which bottom lines to this little beauty:

“Crash when a CSS transition is run on a CSS transform in a GC supported or GC required build.”

Sweet.  I am alone in thinking that this means there is pretty much no way to use WebKit in a garbage collected (or even garbage collection supported for that matter) Mac application?

Oh, well, score one for open source; custom local build of WebKit.framework here I come!

Published in: on January 20, 2010 at 3:02 pm  Comments (5)  

Debugging Wierdness iPhone and Xcode

UPDATED: Filed a bug on this issue for any Apple folks reading this at rdar://problem/7590305.

Recently, at The Department, we experienced some problems debugging an iPhone 3.1.2 application written in a mix of Objective-C and C++ in Xcode (or the raw gdb console for that matter).

The symptoms were that while the app would run and we could set and hit breakpoints, attempting to browse locals or “p” or “po” in gdb while in a breakpoint would just report total garbage.

The app in question is split across multiple static libraries in multiple Xcode project files.  To complicate things even more, there are multiple targets for different platforms in the various projects (iPhone, simulator, Mac OS).

Initially, it seemed like maybe the problem was relating to the multi-target, multi-platform project structure.  It was certainly not easy to coax all these targets and platforms into the various projects, and is not a generally not recommended practice in the first place, but boy is it convenient!

Luckily we found we could reproduce the same debugging problem in a simple test application.  To replicate, we just created a fresh project using iPhone OS “Application” template called “Window-based Application”.  We just added two simple classes, one C++ and one Objective-C class, each with a handful of member variables.  Next we added instances of those two classes as member of the AppDelegate Objective-C class generated by Xcode. Set a breakpoint and run on the target device in the AppDelegate’s initializer and boom!  Garbage locals.

The weird part is that reproducing the same steps using the iPhone OS “Application” template called “OpenGL ES Application” worked fine.  No garbage locals when debugging.

Using trusty Araxis merge to compare the two project files, we spotted one minor difference in the two Xcode generated projects. The line:

"GCC_THUMB_SUPPORT[arch=armv6]" = "";

was present in the project that we could see locals for, but not in the one that resulted in garbage locals in the debugger.

After adding this line into the non-working project, everything worked great in the debugger. No problem seeing locals.

Weirdly try as we might, we were not able to figure out a way to get the Xcode user interface to add this line to our bugged out (but Xcode generated) project. And similarly, we were not able to figure out how a way to get the Xcode user interface to removed this line from a working project.  It seems this line needs to be added in by hand in the project XML (or appear in Apple’s project template in the first place).

Happily, we added this line to all our various Xcode targets and projects in our complex app and…everything now works great!

Published in: on January 20, 2010 at 1:33 pm  Comments (4)  
Tags: , ,
Follow

Get every new post delivered to your Inbox.