Bug 205499 - Segmentation fault in EmbedPrivate::Realize
Segmentation fault in EmbedPrivate::Realize
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
: 300881 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-09-06 15:01 EDT by Daniel Walsh
Modified: 2018-04-11 09:17 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-20 11:47:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 370767 None None None Never

  None (edit)
Description Daniel Walsh 2006-09-06 15:01:08 EDT
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()
        # self.moz.load_url('http://www.pygtk.org')
        data = '<html><head><title>Hello</title></head><body>pygtk
        self.moz.render_data(data, long(len(data)), 'file:///', 'text/html')
if __name__ == '__main__':

python t.py
Segmentation fault

Since this is the example, I think it needs to be fixed.
Comment 1 Haïkel Guémar 2006-10-26 03:56:41 EDT
This also affects Listen.
It segfaults each time, it loads a gtkmozembed widget, just try by clicking on
wikipedia or Lyrics tabs.
Comment 2 Matthew Barnes 2006-11-04 18:11:46 EST
Forwarded this bug upstream:
Comment 3 John Dennis 2006-11-16 19:44:07 EST
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:


(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:
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);

  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.

Comment 4 John Dennis 2006-11-16 20:14:09 EST
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.
Comment 5 John Dennis 2006-11-16 21:00:08 EST
Looks like these upstream bugs are relevant:

Comment 6 Matthew Barnes 2006-11-17 13:28:27 EST
Based on the above comments, I'm reassigning this to firefox.
Comment 7 John Dennis 2006-11-17 14:07:30 EST
adding this to the example makes it work


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?
Comment 8 John Dennis 2006-11-20 13:48:49 EST
perhaps the python bindings needed to export something akin to get_comp_path by
calling GRE_GetGREPathWithProperties() as documented here:

The TestGtkEmbed program should probably be calling
GRE_GetGREPathWithProperties() and then setting the component path based on the
results of the query.

Sound right?
Comment 9 Matthew Barnes 2007-10-02 22:41:28 EDT
*** Bug 300881 has been marked as a duplicate of this bug. ***
Comment 10 Matěj Cepl 2007-12-20 11:47:54 EST
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
Comment 11 Chris Wilson 2012-11-09 10:24:13 EST
For anyone who finds this while looking for solutions to gtkmozembed crashing, the answer is here:


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.

Note You need to log in before you can comment on or make changes to this bug.