Bug 829950 - googletalk plugin seems to be coredumping because of some udev API change
Summary: googletalk plugin seems to be coredumping because of some udev API change
Keywords:
Status: CLOSED DUPLICATE of bug 831971
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-07 20:59 UTC by Zdenek Kabelac
Modified: 2012-06-14 09:01 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-14 09:01:54 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Zdenek Kabelac 2012-06-07 20:59:25 UTC
Description of problem:

Not really sure where is the problem hidden.
My assupmtion is - udev has changed it's API without being backward compatible, and made GoogleTalk plugin coredumping.

(gdb) bt
#0  udev_list_node_insert_between (next=0x21fe4e0, prev=0x0, new=0x21fece0) at src/libudev/libudev-list.c:62
#1  udev_list_entry_append (list=0x21fe4d8, new=0x21fece0) at src/libudev/libudev-list.c:100
#2  udev_list_entry_add (list=list@entry=0x21fe4d8, name=name@entry=0x7f4afb888c24 "UDEV_LOG", value=value@entry=
    0x7fff024a9650 "3") at src/libudev/libudev-list.c:209
#3  0x00007f4afb88137e in udev_add_property (udev=udev@entry=0x21fe4c0, key=key@entry=0x7f4afb888c24 "UDEV_LOG", 
    value=value@entry=0x7fff024a9650 "3") at src/libudev/libudev.c:299
#4  0x00007f4afb8813fe in udev_set_log_priority (udev=0x21fe4c0, priority=<optimized out>) at src/libudev/libudev.c:285
#5  0x00007f4afaf4185e in udev_new () from /lib64/libudev.so.0
#6  0x00000000004d90a2 in ?? ()
#7  0x000000000048b4a2 in ?? ()
#8  0x0000000000483cf7 in ?? ()
#9  0x0000000000420aa9 in ?? ()
#10 0x000000000040db19 in ?? ()
#11 0x00007f4b0094fba5 in __libc_start_main (main=0x40daf1, argc=1, ubp_av=0x7fff024aea28, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff024aea18) at libc-start.c:225
#12 0x000000000040d6a9 in ?? ()
#13 0x00007fff024aea18 in ?? ()
#14 0x000000000000001c in ?? ()
#15 0x0000000000000001 in ?? ()
#16 0x00007fff024af025 in ?? ()
#17 0x0000000000000000 in ?? ()
(gdb) up
#1  udev_list_entry_append (list=0x21fe4d8, new=0x21fece0) at src/libudev/libudev-list.c:100
100	        udev_list_node_insert_between(&new->node, list->node.prev, &list->node);
(gdb) print list
$2 = (struct udev_list *) 0x21fe4d8
(gdb) print new
$3 = (struct udev_list_entry *) 0x21fece0
(gdb) print *new
$4 = {node = {next = 0x21fe4e0, prev = 0x0}, list = 0x0, name = 0x21fedd0 "UDEV_LOG", value = 0x21fedf0 "3", num = 0}
(gdb) 




Version-Release number of selected component (if applicable):
systemd-185-2.fc18.x86_64

How reproducible:


Steps to Reproduce:
1. try to use googletalk plugin
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Michal Schmidt 2012-06-08 12:43:17 UTC
GoogleTalkPlugin seems to dlopen() libudev.so.0. (I have not run it, but I base this conclusion on having looked at "ldd ./GoogleTalkPlugin" and "strings GoogleTalkPlugin | grep udev").

udev has changed its API somewhat, but it has also bumped the soname to libudev.so.1.

I think the likely explanation for the crash is that somehow both libudev.so.0 and libudev.so.1 ended up loaded in the same process.
An effort is ongoing to remove libudev.so.0 from Rawhide entirely. It should be done quite soon.
Then GoogleTalkPlugin will not be able to dlopen it. I don't know what it will do then, but there's nothing we can do to fix it.

Comment 2 Zdenek Kabelac 2012-06-08 13:04:59 UTC
Is there any particular reason why the API cannot remain binary compatible.
Many much more complex projects then udev are able to provide such compatibility,
so why the udev merge with systemd has to break things ?

Isn't there some way to provide backward compatible functionality here for replaced functions ?

Comment 3 Michal Schmidt 2012-06-08 13:08:12 UTC
I do not know what Kay's intentions are for future libudev API compatibility, but seeing that symbol versioning was introduced in libudev.so.1, there is hope that maintaining compatible APIs should be easier from now on.

Comment 4 Michal Schmidt 2012-06-14 09:01:54 UTC

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


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