FWIW, this doesn't crash for me using ubuntu breezy i386 version, perhaps it is some amd64 wierdness

Do you think you would be able to get a stack trace for us ? Without a stack trace from the crash it's very hard to determine what caused it.
Please see http://live.gnome.org/GettingTraces for more information on how to do so.

Not sure if this is what you want, but hopefully it'll help:

(gdb) where

+ Trace 64994

I'm afraid the trace isn't very useful... could you rebuild epiphany with debug symbols to get a better trace? See https://wiki.ubuntu.com/DebuggingProgramCrash .

After rebuilding with debugging symbols, the crash no longer occurs... I guess I'll run this version for the moment, but is there any further way to debug this?

Hmm the debug build uses a different optimisation setting probably, not -O2 like a normal build... I suspect this might be some aliasing problem since when I don't compile with -fno-strict-aliasing I get some warnings when compiling the pyphany bindings (nothing about bookmarks/node children though)... could you try again with DEB_BUILD_OPTIONS="nostrip" (i.e. without "noopt") ?

The crashes happen when I *don't* include debugging symbols ('-g' in CFLAGS) - Otherwise, it behaves as normal, with or without noopt/nostrip. With debugging symbols enabled, I seem to get unexplained intermittent crashes (and often crashes on close), but this particular function seems to work fine.

Tried this again recently, the error isn't present when compiling without optimisations (-O0). This is with gcc v4.0.3 (4.0.3-1ubuntu3).

Backtrace from epiphany 2.14.3 on dapper:

Program received signal SIGSEGV, Segmentation fault.

+ Trace 69879

From the build:

"...
Could not write method EphyNode.signal_connect_object: No ArgType for 'EphyNodeCallback'
Could not write method EphyNode.signal_disconnect_object: No ArgType for 'EphyNodeCallback'
Could not write method EphyNode.set_property: No ArgType for 'const-GValue*'
Could not write method EphyNode.get_property: No ArgType for 'GValue*'
Could not write method EphyNode.write_to_xml: No ArgType for 'xmlTextWriterPtr'
Could not write method EphyNode.sort_children: No ArgType for 'GCompareFunc'
Could not write method EphyNode.reorder_children: No ArgType for 'int*'
Could not write method EggEditableToolbar.set_drag_dest: No ArgType for 'const-GtkTargetEntry*'
Could not write method EphyDialog.construct: No ArgType for 'const-EphyDialogProperty*'
Could not write method EphyDialog.add_enum: No ArgType for 'const-char*-const*'
Could not write method EphyDialog.set_size_group: varargs functions not supported
Could not write method EphyDialog.get_controls: varargs functions not supported
Could not write method EphyDialog.get_value: No ArgType for 'GValue*'
Could not write method EphyDialog.set_value: No ArgType for 'const-GValue*'
Could not write method EphyExtensionsManager.get_extensions: No ArgType for 'GList*'
Warning: generating old-style constructor for ephy_link_action_group_new
Warning: generating old-style constructor for ephy_node_db_new
Could not write method EphyNodeDb.load_from_file: No ArgType for 'const-xmlChar*'
Could not write method EphyNodeDb.write_to_xml_safe: varargs functions not supported
Could not write method EggToolbarsModel.get_types: No ArgType for 'GList*'
Could not write method EggToolbarsModel.set_types: No ArgType for 'GList*'
Could not write method EggToolbarsModel.get_name_avail: No ArgType for 'GPtrArray*'
Could not write function ephy_node_new_from_xml: No ArgType for 'xmlNodePtr'
Could not write function ephy_bookmarks_compare_topics: No ArgType for 'gconstpointer'
Could not write function ephy_bookmarks_compare_topic_pointers: No ArgType for 'gconstpointer'
Could not write function ephy_bookmarks_compare_bookmarks: No ArgType for 'gconstpointer'
Could not write function ephy_bookmarks_compare_bookmark_pointers: No ArgType for 'gconstpointer
..."

I just tried this on Dapper (i386) but I couldn't make Ephy crash.

Yes, this is an amd64 issue - It disappears when compiling without optimisations - See also Ubuntu bug: https://launchpad.net/bugs/36538

So is this an Epiphany or a Python bug? Does it still happen?

Created attachment 86643 [details]
epiphany.ephy_shell_get_default().get_bookmarks().get_keywords().get_children()

Created attachment 86644 [details]
epiphany.ephy_shell_get_default().get_bookmarks().get_keywords().get_children()

Created attachment 86645 [details]
epiphany.ephy_shell_get_default().get_bookmarks().get_keywords().get_children()

Created attachment 86646 [details]
epiphany.ephy_shell_get_default().get_bookmarks().get_keywords().get_children()

I'm not sure what all these attachments are for, but I do know that bugzilla finds that I'm not authorized to access them!

Reinout: they're spam.

one of the ubuntu comments states that's still happening on gutsy

I can reproduce it on debian/unstable, amd64 only; both with packages or with svn trunk; when ephy is compiled with -O2, but not when it is compiled with -O0. Unfortunately I'm not familiar at all with this aspect of python programming.

*** Bug 497828 has been marked as a duplicate of this bug. ***

This is still happening on 64-bit Gutsy. I'm willing to debug it, if anyone points me in the right direction...

It looks like get_children() is returning the wrong object.

>>> bk=epiphany.ephy_shell_get_default().get_bookmarks()
>>> bk
<epiphany.Bookmarks object at 0x10e6410 (EphyBookmarks at 0x74ba70)>

(gdb) print (EphyBookmarks) *0x74ba70
$1 = {parent = {g_type_instance = {g_class = 0x1108640}, ref_count = 2,
    qdata = 0x1c9b600}, priv = 0x74ba90}
(gdb) print *((EphyBookmarks) *0x74ba70).priv
$4 = {init_defaults = 0, dirty = 0, save_timeout_id = 0,   xml_file = 0x110625$
  rdf_file = 0x11062a0 "/home/joss/.gnome2/epiphany/bookmarks.rdf",
  db = 0xc189c0, bookmarks = 0xc18a00, keywords = 0xc18ac0,
  favorites = 0xc18b80, notcategorized = 0xc18c80, smartbookmarks = 0xbd5580,
  lower_fav = 0x11e3240, lower_score = 0,
  disable_bookmark_editing_notifier_id = 3758096547, local = 0xc18d40,
  ga_client = 0xc18e00, browse_handles = {0xbcd190, 0xbcd1e0, 0xbcd230},
  resolve_handles = 0xc18e40}

We can see that the correct EphyNode returned by
ephy_bookmarks_get_keywords() should be 0xc18ac0:

(gdb) print (EphyNode) *0xc18ac0
$5 = {ref_count = 1, id = 1, properties = 0xfd4220, parents = 0xc18b00,
  children = 0xfd4230, signals = 0xc18b40, signal_id = 10, emissions = 0,
  invalidated_signals = 0, is_drag_source = 1, is_drag_dest = 1,
  db = 0xc189c0}

However, the python bindings seem to think otherwise:

>>> bk.get_keywords()
<EphyNode at 0x2bb6cc8>

$6 = {ref_count = 14901663, id = 0, properties = 0x4c2d90,
  parents = 0x4c4790, children = 0xe43630, signals = 0x2ab63f0688d0,
  signal_id = 1057391232, emissions = 10934, invalidated_signals = 14987376,
  is_drag_source = 0, is_drag_dest = 0, db = 0x2ab64002a180}

Of course any operation made on this object will lead to a crash.


It seems that all other functions based on EphyNode lead to the same kind of problems, so maybe this is a problem that appears only for boxed types, or a mismatch in type declarations, but I don't understand GObject's internals enough to go deeper in the analysis.

You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you.

Can you please check again if the issue you reported here still happens in a recent version and update this report by adding a comment and adjusting the 'Version' field?

Again thank you for reporting this and sorry that it could not be fixed for the version you originally used here.

Without feedback this report will be closed as INCOMPLETE after 6 weeks.

*** Bug 419712 has been marked as a duplicate of this bug. ***

Please don't close this bug.  It's still present in 2.26.3.  In my experience it only affects optimised builds on amd64.

Hello Magnus,

thank you for you response.

As for your comments,  rising the version to 2.25