ubiquity crashed with SIGSEGV in GtkNode::MatchStringProperty()

StacktraceTop:
 GtkNode::MatchStringProperty (this=0x988dd10, name=..., value=...) at /build/buildd/autopilot-gtk-1.4+14.04.20140107/lib/GtkNode.cpp:302
 ~basic_string (this=0xbf9b23e8, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/basic_string.h:539
 internal_visit<std::basic_string<char> > (this=<optimized out>, operand=...) at /usr/include/boost/variant/variant.hpp:315
 visitation_impl_invoke_impl<boost::detail::variant::destroyer, void*, std::basic_string<char> > (visitor=..., storage=0xbf9b23e8) at /usr/include/boost/variant/detail/visitation_impl.hpp:130
 visitation_impl_invoke<boost::detail::variant::destroyer, void*, std::basic_string<char>, boost::variant<std::basic_string<char>, bool, int>::has_fallback_type_> (internal_which=<optimized out>, visitor=..., t=0x0, storage=0xbf9b23e8) at /usr/include/boost/variant/detail/visitation_impl.hpp:173

For the record, the only occurances of std::string in GtkNode::MatchStringProperty are now the method arguments; they are const references though, and shouldn't be handled at all at method exit. The stack trace doesn't make too much sense to me, though (i. e., why does the std::string destructor call GtkNode::MatchStringProperty()?)

I'm not entirely sure this is a bug in autopilot-gtk.

See http://paste.ubuntu.com/6725605/. Where you can see that the segfault occurs before the autopilot test executes the progress bar tests. Which is where we get the MatchStringProperty fail when trying to match the webkitwindow's name.

I cannot find anything sinister that would cause the atk_object_set_parent in Gtk/Atk and WebKitGtk, I even ran various tests against the GtkWidgets that use set_parent, which resulted in no problems. I also went through at-spi2-atk, thinking maybe if there was an invalid pointer a d-bus connection was being closed, but even that seemed to be ok.

I'm wondering if this is something to do with bug 1260396, and also with this bug starting to appear after the update to Gtk 3.10. on 10th December. The point where the segfault is occurring is the point I highlight in bug 1260396 where the window flickers back from full screen width to the correct size.

Could this be caused by slow rendering/transitioning of the window coming back to to its default size??? i.e a parent object not entirely in place before the atk object cache is being 're-synced'??

I've recommended to Dan to try and work around this issue inside the ubiquity tests for the moment. The fixes for the bug Dan mentioned above have landed but the issue continues in the ubiquity tests.

Given our inability to reproduce this issue, it will be hard to find a direct fix. Thus far, none of the attempts have completely eliminated it.