Archive for December, 2014

2014 in review

December 29, 2014

The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog.

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 16,000 times in 2014. If it were a concert at Sydney Opera House, it would take about 6 sold-out performances for that many people to see it.

Click here to see the complete report.

Posting forms with Knockout to dynamic Sammy routes

December 27, 2014

 

You are reading the old blog! This post has been moved to http://www.ohadsoft.com/2014/12/posting-forms-with-knockout-to-dynamic-sammy-routes/

 

Single-page applications (SPAs) are the standard these days, and two aspects are typically considered for their development:

  1. Data binding the view (HTML) with the model (Javascript)
  2. Navigating between logical “pages” without reloading.

There are many libraries that handle both needs, and I went with Knockout for (1) and Sammy for (2) – mostly because I was already familiar with them (they are both excellent).

The way Sammy works is by defining “routes” (typically hash tag routes for SPAs), which are basically URLs that trigger JS methods. For example, you might define the following route:

get('#/:name', function() {
    alert(this.params['name']);
});

When the URL changes to mysite.com/#/Ohad, an alert will pop up saying “Ohad”. Now, suppose we have a form we want to “submit” to the route above Sammy route:

<form
data-bind="submit:function(){window.location='#/'+name();}">
 <input type="text" data-bind="value: name"></input>
 <button type="submit">Submit</button>
</form>

The input’s data-bind attribute binds the input’s value to our view model’s name observable. The form’s data-bind attribute binds the form submission event to a URL redirection for the desired Sammy route. For more information about Knockout bindings, visit http://learn.knockoutjs.com.

The code above works, but not exactly as expected. See, when no action attribute is specified on the form element, the browser assumes the current URL without hashtags is the submission URL, and so right after the URL is redirected to mysite.com/#/MyName it is reverted to just mysite.com by the browser.

This messed up my hash tag navigation model, and nothing I tried prevented the browser from reverting the address (canceling the form submission event, returning false from the handler method, etc). And then it hit me – why fight the browser?

<form
data-bind="attr: { action: '#/'+name() }">
 <input type="text" data-bind="value: name"></input>
 <button type="submit">Submit</button>
</form>

See what we did here? Instead of using knockout to circumvent the normal form submission flow, I go with it. Whereas Knockout’s submit binding tries to cancel the browser’s submission event and replace it with the supplied method, here the submission flow is completely standard. We just need to make sure the action attribute points to the right place, and voila – hash tag history is preserved.

BTW, you may wonder why I insisted to go with a form, where in truth no “real” submission takes place here. Indeed, a regular div with a regular button would not have had this issue to begin with!

Well, the answer is a bit silly. I could not find any reliable cross-browser method to intercept the [enter] key on the input in order to trigger submission (everything is either deprecated or not globally supported). And frankly, even if I did, it would be a hack – the browser should handle such logic. Plus, I enjoyed the challenge 🙂

Static definitions in header files may cause malloc errors on application teardown

December 12, 2014

 

You are reading the old blog! This post has been moved to http://www.ohadsoft.com/2014/12/static-definitions-in-header-files-may-cause-malloc-errors-on-application-teardown/

 

I recently encountered the following error in the shutdown procedure of XCTest (we’re using Kiwi which is based on it):

Malloc Error: pointer being freed was not allocated

Here’s how the stack looked like (truncated to section of interest):

(lldb) bt

frame #4: 0x00e12ae7 OurProduct`std::__1::basic_string<char16_t, std::__1::char_traits<char16_t>, std::__1::allocator<char16_t> >::~basic_string(this=0x042a2058) + 103 at string:2093

frame #5: 0x00e10cb7 OurProductI`std::__1::basic_string<char16_t, std::__1::char_traits<char16_t>, std::__1::allocator<char16_t> >::~basic_string(this=0x042a2058) + 23 at string:2090

frame #6: 0x0c94a7ac libsystem_sim_c.dylib`__cxa_finalize_ranges + 315

frame #7: 0x0c94a832 libsystem_sim_c.dylib`__cxa_finalize + 59

frame #8: 0x0c94ab55 libsystem_sim_c.dylib`exit + 57

frame #9: 0x20117684 XCTest`+[XCTestProbe exitTests:] + 57

As you can see, XCTest was executing its shutdown procedure, and during this finalization phase the destructors of static instances were executed. It was somewhat vexing that a static destructor would try to free up a pointer that was never allocated – after all, statics are allocated only once when the process starts up. And if some static was not defined (or defined multiple times), a linker error should have been thrown. How could this situation come to be?

Failing to answer that question armed with the data above alone, I proceeded to attempt and locate the faulty string in our code. I had hoped I could spot something unusual about it, that would hopefully hint me at the root cause of the failure.

(lldb) frame select 4
(lldb) frame variable *this

(std::__1::basic_string<char16_t, std::__1::char_traits<char16_t>, std::__1::allocator<char16_t> >) *this = {

__r_ = {

std::__1::__libcpp_compressed_pair_imp<std::__1::basic_string<char16_t, std::__1::char_traits<char16_t>, std::__1::allocator<char16_t> >::__rep, std::__1::allocator<char16_t> > = {

__first_ = {

= {

__l = (__cap_ = 17, __size_ = 14, __data_ = u”Helvetica Neue“)
__s = {

The string looked innocent enough. However, but upon finding it in our code (thankfully the literal appeared as is, and only once), I noticed it was defined (initialized) in the header. Statics should be declared in the header – never defined. Code such as  Bar::foo = “Helvetica Neue” belongs in the cpp file. For more information see http://stackoverflow.com/questions/185844/initializing-private-static-members.

And indeed, moving the definition to the cpp resolved the issue. Now, the keen reader will notice that a linker error should have been thrown, rather than the runtime exception I encountered. I’m not exactly clear on why the former was not the case, but the prevailing theory entails a linker optimization that allocated only once for multiple compilation units, which backfired when the shutdown sequence tried to free all occurrences separately (or one occurrence that happened to not be the one that was initialized).

If you have a better explanation, I’ll be happy to hear it. In the meantime, mind your statics 🙂

Debugging unobserved concurrency runtime task exceptions

December 4, 2014

 

You are reading the old blog! This post has been moved to http://www.ohadsoft.com/2014/12/debugging-unobserved-concurrency-runtime-task-exceptions/

 

The C++ Concurrency runtime (AKA PPLX) is the unmanaged answer to the Task Parallel Library (TPL), and it works surprisingly well. It is even cross platform by way of the C++ Rest SDK (codename Casablanca).

I work at Microsoft and in our group we are making extensive use of this library (we develop an iOS application). Recently, I encountered an interesting crash due to an unobserved exception. An unobserved exception is basically an exception thrown from a task, which no other entity (be it the caller or some later continuation) observed (typically by calling task::wait or task::get). In PPLX, such exceptions crash the process (in .NET they used to, and still may depending on configuration).

When an unobserved PPLX exception occurs, the debugger will break in the following location inside pplxtasks.h:

// If you are trapped here, it means an exception thrown in task chain didn’t get handled.
// Please add task-based continuation to handle all exceptions coming from tasks.
// this->_M_stackTrace keeps the creation callstack of the task generates this exception.
_REPORT_PPLTASK_UNOBSERVED_EXCEPTION(); // <– debugger will break here

Your mileage may vary, but I wasn’t able to inspect the _M_stackTrace variable in XCode’s debugger.

However, using the lldb console (you can bring it up with ⌘+Shift+C) I was able to inspect its value:

(lldb) expr _M_stackTrace

Here is a sample output:

(pplx::details::_TaskCreationCallstack) $1 = {
_M_SingleFrame = 0x00c0935d
_M_frames = size=0 {}
}

In this case, the frame of interest is stored in _M_SingleFrame (otherwise the list of frames would have been stored in _M_frames and _M_SingleFrame would have been null). Of course, “0x00c0935d” is not a terribly useful piece of data for root cause analysis, and I wasn’t even sure what that address represented! Fortunately, following macro in the same header clarified that mystery:

#define _CAPTURE_CALLSTACK() ::pplx::details::_TaskCreationCallstack::_CaptureSingleFrameCallstack(_ReturnAddress())

So now we know it is a return address, pointing to the code creating the offending exception. Fortunately, lldb can resolve that address to source:

(lldb) so l -a 0x00c0935d

Sample output:

/Users/ohads/Library/Developer/Xcode/DerivedData/ios-gdhrlqjldqgqktgtpdnpssahaqme/Build/Products/OurApp`pplx::task<void> pplx::task_from_exception<void, std::exception>(std::exception, pplx::task_options const&) + 62 at …

It’s not perfect, but it should be enough to narrow the search down (in this case, there was only one place in our code using task_from_exception).