Bug 1228804 - Terminology fails to launch
Summary: Terminology fails to launch
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: terminology
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Conrad Meyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-05 19:47 UTC by L.L.Robinson
Modified: 2015-07-30 00:46 UTC (History)
6 users (show)

Fixed In Version: efl-1.14.2-1.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-30 00:46:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
coredump from terminology on laptop without Gnome installed (28.00 KB, text/plain)
2015-06-09 09:33 UTC, L.L.Robinson
no flags Details
someone on #e wanted a backtrace (16.02 KB, text/plain)
2015-06-09 10:05 UTC, L.L.Robinson
no flags Details

Description L.L.Robinson 2015-06-05 19:47:29 UTC
Description of problem:

When trying to launch terminology It throws an error
Launching a SCIM daemon with Socket FrontEnd...
panel_initialize() failed!!!
Ecore IM Module: Cannot connect to Panel!


Version-Release number of selected component (if applicable):
terminology-0.8.0-2.fc22

How reproducible:
Always

Steps to Reproduce:
1.launch terminology
2.
3.

Actual results:
Terminology launches, does not crash, but does not display terminal

shows

Launching a SCIM daemon with Socket FrontEnd...
panel_initialize() failed!!!
Ecore IM Module: Cannot connect to Panel!

Expected results:

Terminology to launch a terminal

Additional info:

Comment 1 Tom "spot" Callaway 2015-06-05 20:16:11 UTC
Hmm. What version of efl/enlightenment are you using?

Comment 2 Tom "spot" Callaway 2015-06-05 20:46:37 UTC
Okay, you may need to do this first:

export ECORE_IMF_MODULE="xim"

This fixes the issue launching terminology from GNOME. I haven't tested whether that is needed in Enlightenment yet.

Comment 3 L.L.Robinson 2015-06-05 20:50:06 UTC
It runs under wayland! I've not tried the export thing yet.

for reference
enlightenment-data-0.19.4-1.fc22.noarch
enlightenment-0.19.4-1.fc22.x86_64

Comment 4 L.L.Robinson 2015-06-05 21:10:53 UTC
export ECORE_IMF_MODULE="xim" works when I launch terminology on X11 under Gnome 3.16.

Although on one of my machines it core dumps, not sure what's different about that.

also I'm using 
enlightenment-0.19.5-2.fc22.x86_64
enlightenment-data-0.19.5-2.fc22.noarch
not .4

Comment 5 L.L.Robinson 2015-06-09 09:33:27 UTC
Created attachment 1036666 [details]
coredump from terminology on laptop without Gnome installed

I have two laptops with terminology and enlightenment installed, one also has Gnome installed and lots of other stuff and terminology works fine with the environment variable set. the other launches but as soon as I type a key in the window it does this coredump. In this case the key I typed was "l"

Comment 6 L.L.Robinson 2015-06-09 10:05:55 UTC
Created attachment 1036680 [details]
someone on #e wanted a backtrace

My first backtrace, someone on #e said it would  be helpful

Comment 7 Conrad Meyer 2015-06-09 14:11:49 UTC
(In reply to junk from comment #6)
> Created attachment 1036680 [details]
> My first backtrace, someone on #e said it would  be helpful

Some program logic bug, or else they broke ABI without bumping soname. Something ends up corrupting the stack:

#1  0x00007ffff3e6d72a in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007ffff3eaeea2 in __libc_message () from /lib64/libc.so.6
No symbol table info available.
#3  0x00007ffff3f4a9f7 in __fortify_fail () from /lib64/libc.so.6
No symbol table info available.
#4  0x00007ffff3f4a9c0 in __stack_chk_fail () from /lib64/libc.so.6    *******
No symbol table info available.                                        *******
#5  0x0000000000411dc0 in keyin_handle (khdl=khdl@entry=0x85f9c0, ty=0xa35460, ev=ev@entry=0x7fffffffbb00, ctrl=ctrl@entry=0 '\000', alt=alt@entry=0 '\000', 
    shift=shift@entry=0 '\000', win=0 '\000') at keyin.c:292
No locals.
#6  0x0000000000428b43 in _smart_cb_key_down (data=0x80000016c00000b7, e=<optimized out>, obj=<optimized out>, event=0x7fffffffbb00) at termio.c:1919
        ev = 0x7fffffffbb00
        sd = 0x85f860
        ctrl = 0
        alt = 0
        shift = 0
        win = <optimized out>
        __FUNCTION__ = "_smart_cb_key_down"
#7  0x00007ffff6b981a4 in _eo_evas_object_cb () from /lib64/libevas.so.1
No symbol table info available.
#8  0x00007ffff5df2eeb in _eo_base_event_callback_call () from /lib64/libeo.so.1
No symbol table info available.
#9  0x00007ffff5df095b in eo_event_callback_call () from /lib64/libeo.so.1
No symbol table info available.
#10 0x00007ffff6b98634 in evas_object_event_callback_call () from /lib64/libevas.so.1
No symbol table info available.
#11 0x00007ffff6b9e6f2 in _canvas_event_feed_key_down_internal.part.13 () from /lib64/libevas.so.1
No symbol table info available.
#12 0x00007ffff6bb3f8e in evas_canvas_event_feed_key_down_with_keycode () from /lib64/libevas.so.1
No symbol table info available.
#13 0x00007ffff6bb6fe3 in evas_event_feed_key_down_with_keycode () from /lib64/libevas.so.1
No symbol table info available.
#14 0x00007fffefcd59de in ecore_event_evas_key_down () from /lib64/libecore_input_evas.so.1
No symbol table info available.
#15 0x00007ffff6922dc5 in _ecore_event_call () from /lib64/libecore.so.1
No symbol table info available.
#16 0x00007ffff692a9b9 in _ecore_main_loop_iterate_internal () from /lib64/libecore.so.1
No symbol table info available.
#17 0x00007ffff692acd7 in ecore_main_loop_begin () from /lib64/libecore.so.1
No symbol table info available.
#18 0x000000000041381d in elm_main (argc=argc@entry=1, argv=argv@entry=0x7fffffffe0c8) at main.c:925

Comment 8 Conrad Meyer 2015-06-09 14:12:56 UTC
Can you run terminology from another terminal (gnome-terminal, xterm, etc) and see if glibc blats out more information on how the stack was corrupted? I think I remember it doing that.

Comment 9 Max Kovgan 2015-06-13 05:40:54 UTC
guys, this is duplication of a bug 1222934 in ON_QA.
the library libedbus has moved into efl, and now is named libeldbus.
refer to the bug:

*** This bug has been marked as a duplicate of bug 1222934 ***

Comment 10 Max Kovgan 2015-06-13 05:58:58 UTC
Sorry guys, I was too quick on the trigger.
This is related, but not the same.

Comment 11 Fedora Admin XMLRPC Client 2015-06-18 14:10:00 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 12 Fedora Update System 2015-07-08 01:45:45 UTC
efl-1.14.2-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/efl-1.14.2-1.fc22

Comment 13 Fedora Update System 2015-07-10 19:07:49 UTC
Package efl-1.14.2-1.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing efl-1.14.2-1.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-11269/efl-1.14.2-1.fc22
then log in and leave karma (feedback).

Comment 14 L.L.Robinson 2015-07-11 20:08:27 UTC
new elf causes bug 1242166

Comment 15 Fedora Update System 2015-07-30 00:46:10 UTC
efl-1.14.2-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.


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