Epiphany Python extension functions are broken on amd64

Bug #36538 reported by Chris Lord on 2006-03-25
Affects Status Importance Assigned to Milestone
epiphany-browser (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

Epiphany immediately segfaults on amd64 when a python extension calls epiphany.ephy_shell_get_default().get_bookmarks().get_keywords().get_children()

I have filed this up-stream (Gnome bug #325930), however the fault is not present when compiling without optimisations.

The Epiphany del.icio.us bookmarks syncing extension 'epilicious' is affected - An intermediary solution (until gcc stops generating broken code) would be to disable optimisations (CFLAGS="-O0") when compiling for amd64.

Sebastien Bacher (seb128) wrote :

Thanks for your bug. That works fine for me on dapper i386. Daniel, do you have the issue on amd64?

Changed in epiphany-browser:
assignee: nobody → desktop-bugs
Daniel Holbach (dholbach) wrote :

Um... I can't find the epilicious plugin.

Sebastien Bacher (seb128) wrote :

do you still have that issue? does it happen from the python console if you run "epiphany.ephy_shell_get_default().get_bookmarks().get_keywords().get_children()" by hand?

Chris Lord (cwiiis) wrote :

Yes, unless I compile with -O0 instead of -O2 in CFLAGS

Sebastien Bacher (seb128) wrote :

Daniel, does it happen on your amd64 installation?

Daniel Holbach (dholbach) wrote :
Download full text (14.6 KiB)

I indeed get the crash. Here the debug backtrace:

Backtrace was generated from '/usr/libexec/epiphany-browser'

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 46912603050304 (LWP 6505)]
[New Thread 1115703648 (LWP 27590)]
[New Thread 1132489056 (LWP 27587)]
[New Thread 1090525536 (LWP 7029)]
[New Thread 1082132832 (LWP 6560)]
0x00002aaaab1cc0fa in waitpid () from /lib/libc.so.6
#0 0x00002aaaab1cc0fa in waitpid () from /lib/libc.so.6
#1 0x00002aaaaba5f4d7 in libgnomeui_segv_handle (signum=11)
    at gnome-ui-init.c:820
#2 0x00002aaaaabd49a8 in nsProfileLock::FatalSignalHandler (signo=11)
    at nsProfileLock.cpp:210
#3 <signal handler called>
#4 0x00000000004c94b8 in _wrap_ephy_node_get_children (
    self=<value optimized out>) at epiphany.override:160
#5 0x00002aaab0135763 in PyEval_EvalFrame (f=0xd50f90)
    at ../Python/ceval.c:3547
#6 0x00002aaab013679f in PyEval_EvalCodeEx (co=0x2aaab3e47f80,
    globals=<value optimized out>, locals=<value optimized out>, args=0x0,
    argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
    at ../Python/ceval.c:2736
#7 0x00002aaab01368b2 in PyEval_EvalCode (co=0xa95e30, globals=0x0,
    locals=0x0) at ../Python/ceval.c:484
#8 0x00002aaab015b04f in PyRun_String (str=<value optimized out>,
    start=<value optimized out>, globals=0x14d9840, locals=0x14d9840)
    at ../Python/pythonrun.c:1265
#9 0x00002aaab0134f2a in PyEval_EvalFrame (f=0xa8d300)
    at ../Python/ceval.c:4219
#10 0x00002aaab013679f in PyEval_EvalCodeEx (co=0x2aaab3bcaf80,
    globals=<value optimized out>, locals=<value optimized out>,
    args=0xd7d048, argcount=2, kws=0xd7d058, kwcount=0, defs=0x0, defcount=0,
    closure=0x0) at ../Python/ceval.c:2736
#11 0x00002aaab0135221 in PyEval_EvalFrame (f=0xd7ceb0)
    at ../Python/ceval.c:3656
#12 0x00002aaab013530e in PyEval_EvalFrame (f=0xb9ebe0)
    at ../Python/ceval.c:3645
#13 0x00002aaab013679f in PyEval_EvalCodeEx (co=0x2aaab3bcace0,
    globals=<value optimized out>, locals=<value optimized out>,
    args=0x2aaab3ea4338, argcount=3, kws=0x0, kwcount=0, defs=0x0,
    defcount=0, closure=0x0) at ../Python/ceval.c:2736
#14 0x00002aaab00e8d3f in function_call (func=0x2aaab3e86398,
    arg=0x2aaab3ea4320, kw=<value optimized out>)
    at ../Objects/funcobject.c:548
#15 0x00002aaab00ce6b0 in PyObject_Call (func=0xa95e30, arg=0x0, kw=0x0)
    at ../Objects/abstract.c:1795
#16 0x00002aaab00d69f1 in instancemethod_call (func=<value optimized out>,
    arg=0x2aaab3ea4320, kw=0x0) at ../Objects/classobject.c:2447
#17 0x00002aaab00ce6b0 in PyObject_Call (func=0xa95e30, arg=0x0, kw=0x0)
    at ../Objects/abstract.c:1795
#18 0x00002aaab012ef8c in PyEval_CallObjectWithKeywords (func=0x2aaab3e428c0,
    arg=0x2aaab3e4dcb0, kw=0x0) at ../Python/ceval.c:3430
#19 0x00002aaab3456953 in initgobject ()
   from /usr/lib/python2.4/site-packages/gtk-2.0/gobject.so
#20 0x00002aaab05fb910 in IA__g_closure_invoke (closure=0x15f2820,
    return_value=) at gclosure.c:490
#21 0x00002aaab060aaf2 in signal_emit_unlocked_R (node=0xdb62a0, detail=0,

Daniel Holbach (dholbach) wrote :

Oh, and I just tested: I get this issue either way, "noopt" or not.

Could you remove $(NO_STRICT_ALIASING_CFLAGS) from src/Makefile.am (or set NO_STRICT_ALIASING_CFLAGS to emtpy in the generated src/Makefile), and do a -Wall -Werror build on x86-64 to see if there are any warnings when compiling the python sources (epiphany.c) ?

Chris Lord (cwiiis) wrote :

Seems you guys have this, but just a note to Daniel, setting noopt in DEB_OPTS (or whatever the variable is supposed to be) doesn't work for this package (the variable seems to be ignored) - I had to set CFLAGS manually.

Sebastien Bacher (seb128) wrote :

Might be worth building with -O0 on amd64 for dapper, what do you think Daniel?

Sebastien Bacher (seb128) wrote :

upstream recommand just building epiphany.c with -O0 if we do that

Chris Lord (cwiiis) wrote :

Any progress? Will be 'downgrading' to 32-bit this summer, would be nice to see this fixed before then :)

Sebastien Bacher (seb128) wrote :

Having somebody using an amd64 installation working on it would be nice. It'll not be fixed for dapper since dapper is frozen now, might be a candidate for dapper-updates though

Changed in epiphany-browser:
status: Unconfirmed → Confirmed
Chris Lord (cwiiis) wrote :

Any progress on this? All it requires is CFLAGS=-O0 and things work fine, it would be a nice stop-gap measure until whatever the real course is, is fixed.

Sebastien Bacher (seb128) wrote :

building with -O0 has a speed cost, since almost nothing use the python interface it's not clear that's a good tradeof to do that

Chris Lord (cwiiis) wrote :

Given that you can't actually get a 'slow' amd64 machine and that whatever performance increase -O3 gives is probably negligible (and comes at the cost of stability, clearly), this doesn't seem like reasonable argument against this, for this architecture?

I've been rebuilding the packages since discovering this and have noticed no appreciable drop in performance (but a very appreciable improvement in the whole not-crashing department)

Sebastien Bacher (seb128) wrote :

speaking about stability, is there issue if you don't use the python feature? If that's python specific, is there many users playing with it? Note that building with -O0 is a workaround and will likely lead to get nobody bothering about the bug enough to fix it after that since it'll have no effect, I would prefer something trying to understand why it crashes and coming with a real fix for it

Henrik Nilsen Omma (henrik) wrote :

Is anyone still seeing this om Gutsy. Removing dapper task as this is not an SRU issue.

Kjetil Thuen (kjetil-thuen) wrote :

I am still seing this on Gutsy.

Changed in epiphany-browser:
status: Confirmed → Triaged
Eetu Huisman (eh) wrote :

Yes, it still exists on 64-bit Gutsy.

Eetu Huisman (eh) wrote :

...and I'm willing to debug it, if anyone points me in the right direction.

Daniel T Chen (crimsun) wrote :

Is this symptom reproducible on current 8.04 or 8.10 alpha?

Kjetil Thuen (kjetil-thuen) wrote :

Yes, its still a problem on both 8.04 and 8.10 (alpha 5).

Javier Jardón (jjardon) wrote :

Is this symptom reproducible on current 9.04 or 9.10 alpha?

Sebastien Bacher (seb128) wrote :

could you try if that's still an issue in jaunty or karmic version?

Changed in epiphany-browser (Ubuntu):
status: Triaged → Incomplete
Changed in epiphany:
status: New → Incomplete
Changed in epiphany:
status: Incomplete → Confirmed
Vish (vish) wrote :

Re-setting back to triaged, since this a known issue upstream.

Changed in epiphany-browser (Ubuntu):
status: Incomplete → Triaged
Changed in epiphany:
importance: Unknown → Critical
Changed in epiphany:
status: Confirmed → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.