Version -2.14.2-1.fc6 Example app segfaults. cat > /tmp/t.py << _EOF import gtk import gtkmozembed class TinyGecko: def __init__(self): self.moz = gtkmozembed.MozEmbed() win = gtk.Window() win.add(self.moz) win.show_all() # self.moz.load_url('http://www.pygtk.org') data = '<html><head><title>Hello</title></head><body>pygtk dev</body></html>' self.moz.render_data(data, long(len(data)), 'file:///', 'text/html') if __name__ == '__main__': TinyGecko() gtk.main() _EOF python t.py Segmentation fault Since this is the example, I think it needs to be fixed.
This also affects Listen. It segfaults each time, it loads a gtkmozembed widget, just try by clicking on wikipedia or Lyrics tabs.
Forwarded this bug upstream: http://bugzilla.gnome.org/show_bug.cgi?id=370767
Tracked it down to this: EmbedPrivate::Realize (this=0x8cd8fc8, aAlreadyRealized=0xbfd3b2f8) at embedding/browser/gtk/src/EmbedPrivate.cpp:257 257 mNavigation->SetSessionHistory(mSessionHistory); mNavigation is NULL, as is mSessionHistory, dereferencing mNavigationHistory is the cause of the segmentation fault. webBrowser is NULL and I suspect that is the root cause of the other NULL pointers. webBrowser looks like it's initialized a couple of lines up with this: mWindow->GetWebBrowser(getter_AddRefs(webBrowser)); (gdb) p mWindow $8 = (class EmbedWindow *) 0x8cf6ed0 so it looks like GetWebBrowser is failing and no one is checking the results. it looks like GetWebBrowser is returning its mWebBrowser (gdb) p mWindow.mWebBrowser $13 = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>} which is NULL, I'm going to make a guess mWebBrowser is initialized here: nsresult EmbedWindow::Init(EmbedPrivate *aOwner) { // save our owner for later mOwner = aOwner; // create our nsIWebBrowser object and set up some basic defaults. mWebBrowser = do_CreateInstance(NS_WEBBROWSER_CONTRACTID); if (!mWebBrowser) return NS_ERROR_FAILURE; mWebBrowser->SetContainerWindow(NS_STATIC_CAST(nsIWebBrowserChrome *, this)); nsCOMPtr<nsIDocShellTreeItem> item = do_QueryInterface(mWebBrowser); item->SetItemType(nsIDocShellTreeItem::typeContentWrapper); return NS_OK; } That's as far as I've gotten, feel free to jump in if you know more about this code than I do.
FWIW, the test program TestGtkEmbed fails exactly the same way, thus the failure does not seem to have anything to do with the python binding.
Looks like these upstream bugs are relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=358926 https://bugzilla.mozilla.org/show_bug.cgi?id=358923
Based on the above comments, I'm reassigning this to firefox.
adding this to the example makes it work comp_path='/usr/lib/firefox-1.5.0.7' gtkmozembed.set_comp_path(comp_path) FWIW, when googling gtkmozembed issue I found several recommendations that set_comp_path was a necessary prerequisite for making gtkmozembed work. Unless there is a query to get the comp path (is there? I didn't find one) then I don't see how this is going to work with deployed software. How are we going to know what the comp path is on any given machine? Isn't this something which should be handled internally in the library? It seems like it used to be because prior to FC6 the gtkmozembed example and test programs worked, but now they fail. What changed? Why can't the mozilla/firefox libraries find their own loadable modules?
perhaps the python bindings needed to export something akin to get_comp_path by calling GRE_GetGREPathWithProperties() as documented here: http://developer.mozilla.org/en/docs/GRE The TestGtkEmbed program should probably be calling GRE_GetGREPathWithProperties() and then setting the component path based on the results of the query. Sound right?
*** Bug 300881 has been marked as a duplicate of this bug. ***
We just updated the Firefox version in Fedora/development from 2.0 to a 3.0 pre-release version, which improves performance, memory usage, and fixes many bugs and crashes. Closing as CANTFIX since we aren't fixing bugs filed against 2.0 now that 3.0 is in. If this bug is still present in rawhide using a Firefox 3.0 version, please re-open this bug. Thanks and Happy Holidays
For anyone who finds this while looking for solutions to gtkmozembed crashing, the answer is here: https://bugzilla.mozilla.org/show_bug.cgi?id=358926#c5 gecko embedding requirements include someone telling gecko where to find the libraries they want used. classically this is handled by (running your application through) run-mozilla.sh.