Version-Release number of selected component (if applicable): libswt3-gtk2-3.2.1-22.fc7 How reproducible: All swt based applications (eclipse, azureus, ...) that try to open a file dialog (this also reproduces it: http://www.java2s.com/ExampleCode/SWT-JFace-Eclipse/FileDialogExample.htm). I tried: eclipse + jdk1.5.0 native eclipse + jdk1.5.0 eclipse + gcj native eclipse + gcj All combinations reproduce the bugs. When I run strace on the simple example at the end I get this (killed it at the end): socket(PF_FILE, SOCK_STREAM, 0) = 11 connect(11, {sa_family=AF_FILE, path=@/tmp/dbus-tJslKvVVOV}, 23) = 0 fcntl64(11, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(11, F_SETFL, O_RDWR|O_NONBLOCK) = 0 fcntl64(11, F_GETFD) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 getuid32() = 500 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0 poll([{fd=11, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1 write(11, "\0", 1) = 1 write(11, "AUTH EXTERNAL 353030\r\n", 22) = 22 poll([{fd=11, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(11, "OK 5ede5bb19c3a29b81bf7eb00456db"..., 2048) = 37 poll([{fd=11, events=POLLOUT, revents=POLLOUT}], 1, -1) = 1 write(11, "BEGIN\r\n", 7) = 7 poll([{fd=11, events=POLLIN|POLLOUT, revents=POLLOUT}], 1, -1) = 1 writev(11, [{"l\1\0\1\0\0\0\0\1\0\0\0n\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 128}, {"", 0}], 2) = 128 gettimeofday({1164821649, 503182}, NULL) = 0 poll([{fd=11, events=POLLIN, revents=POLLIN}], 1, 25000) = 1 read(11, "l\3\1\1\326\0\0\0\1\0\0\0]\0\0\0\4\1s\0\'\0\0\0org.fre"..., 2048) = 326 read(11, 0x892d858, 2048) = -1 EAGAIN (Resource temporarily unavailable) close(11) = 0 futex(0x8929480, FUTEX_WAIT, 2, NULL) = -1 EINTR (Interrupted system call) It seems there is a problem with dbus. --- SIGINT (Interrupt) @ 0 (0) ---
I get a problem when I run the example too. Here's what I have installed: eclipse-platform-3.2.1-22.fc7.i386 dbus-1.0.1-2.fc7.i386 Here's what I get when I run that example: % strace java -cp /usr/lib/eclipse/swt-gtk-3.2.jar:. FileDialogExample ... open("/var/lib/dbus/machine-id", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "process 21006: ", 15process 21006: ) = 15 write(2, "D-Bus library appears to be inco"..., 206D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/var/lib/dbus/machine-id": No such file or directory See the manual page for dbus-uuidgen to correct this issue. ) = 206 write(2, " D-Bus not built with -rdynamic"..., 64 D-Bus not built with -rdynamic so unable to print a backtrace ) = 64 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(21006, 21006, SIGABRT) = 0 --- SIGABRT (Aborted) @ 0 (0) --- +++ killed by SIGABRT (core dumped) +++ Process 21006 detached I'm going to update my rawhide box and test again before I punt this over to dbus.
At the moment I'm running an updated rawhide from 29/11 but I have the problem for a weeks now but I didn't have the time to inspect it until now. I think it happened when the final dbus was pushed. The c gtk program's don't have this problem, I think there is something wrong in the swt java bindings.
(In reply to comment #2) > The c gtk program's don't have this problem, I think there is something wrong in > the swt java bindings. Ok, if you could narrow it down more that would be great. Thanks.
John, Have you ever seen anything like this before? Thanks.
Bart, I worked around my problem doing this: * check if this file exists: 'ls -l /var/lib/dbus/machine-id' * it didn't on my system so I ran 'dbus-uuidgen --ensure' as root * the example app worked after that with the latest rawhide. Could you try that?
That didn't work. The file existed, I moved it to some other place and I ran dbus-uuidgen --ensure but that didn't change anything. :( I move my old machine-id back. Did I need to reboot or something like that before testing it?
You're not supposed to change that file in a live system (see man dbus-uuidgen for details). I only ran the dbus-uuidgen because the file didn't exist for me. But maybe try rebooting.
I tried that, but it didn't work.
Ok then there's nothing else I can tell you because it's working for me, sorry. Maybe John has some ideas.
What version of D-Bus and version of gnome-vfs2 are you running?
$ rpm -qa dbus dbus-1.0.1-2.fc7 $ rpm -qa gnome-vfs2 gnome-vfs2-2.16.2-2.fc7
Ok, I was finally able to update my box. It looks like threading is not enabled from the backtrace. I need to check with Alex to make sure gnome-vfs is calling dbus_threads_init_default.
Relevant backtrace (notice the (mutex=0x0) at #)5: #0 0x0079c410 in __kernel_vsyscall () #1 0x0011b85e in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #2 0x001176ec in _L_mutex_lock_83 () from /lib/libpthread.so.0 #3 0x0011723d in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x04e07efd in dbus_g_object_path_get_g_type () from /usr/lib/libdbus-glib-1.so.2 #5 0x051827ff in _dbus_mutex_lock (mutex=0x0) at dbus-threads.c:150 #6 0x0516b87d in _dbus_bus_notify_shared_connection_disconnected_unlocked ( connection=0x96ad0e8) at dbus-bus.c:353 #7 0x0516f53d in _dbus_connection_get_dispatch_status_unlocked ( connection=0x96ad0e8) at dbus-connection.c:3788 #8 0x05170813 in _dbus_connection_close_possibly_shared_and_unlock ( connection=0x96ad0e8) at dbus-connection.c:2685 #9 0x0516c2fd in internal_bus_get (type=DBUS_BUS_SESSION, private=0, error=0xbf82a0b4) at dbus-bus.c:448 #10 0x04109f8b in gnome_vfs_daemon_message_iter_get_file_info () from /usr/lib/libgnomevfs-2.so.0 #11 0x0412a74e in gnome_vfs_volume_monitor_client_shutdown_private () from /usr/lib/libgnomevfs-2.so.0 #12 0x0412a309 in gnome_vfs_volume_monitor_client_get_type () from /usr/lib/libgnomevfs-2.so.0 #13 0x03ceb64a in g_type_create_instance () from /lib/libgobject-2.0.so.0 #14 0x03cd2f32 in g_object_set () from /lib/libgobject-2.0.so.0 ---Type <return> to continue, or q <return> to quit--- #15 0x03cd0b8b in g_object_newv () from /lib/libgobject-2.0.so.0 #16 0x03cd16ef in g_object_new_valist () from /lib/libgobject-2.0.so.0 #17 0x03cd18a0 in g_object_new () from /lib/libgobject-2.0.so.0 #18 0x0412b0c4 in gnome_vfs_volume_monitor_unref () from /usr/lib/libgnomevfs-2.so.0 #19 0x0412b15a in gnome_vfs_get_volume_monitor () from /usr/lib/libgnomevfs-2.so.0 #20 0x03f303b4 in gtk_file_system_gnome_vfs_new ()
Well, we call dbus_g_thread_init()
I have some extra information, when I run it from a root shell I don't have this problem. Maybe because I don't have a session bus then.
Yes it is because gnome-vfs doesn't go through the D-Bus path. One thing I can't understand is why this happens only in Java and not other apps. Perhaps some other library is using D-Bus without knowing it needs to initialize threads and since Java is highly threaded it is causing problems. Does eclipse use libraries like avahi or HAL?
I can also recreate it with a simple example app that only starts a window frame and a menu item that "should" show a filedialog. So only plain java (gij and sun java) and swt (from rawhide and swt from eclipse.org).
I tried the latest swt build from the eclipse website but the results stay the same. I got a workaround now, starting eclipse like this: unset DBUS_SESSION_BUS_ADDRESS && eclipse but it pretty ugly.
The Eclipse SDK itself uses gnome-vfs (via SWT) but not HAL or avahi AFAIK. Since SWT itself is using gnome-vfs and can be used independently of the Eclipse platform, should it initialize D-Bus itself? Either way, I think this is an upstream bug and should probably be discussed at bugs.eclipse.org to involve the SWT developers. But I guess that would mean John and/or Alex have to create BZ accounts there <sigh>.
Interesting note. This is not happening in rawhide anymore. I am not sure what update might have fixed it here.
I'm running an up to date rawhide and I still have the problem :(
Ok, finally got the test program to run. It isn't crashing because for some reason dialog doesn't seem to be running the gnome-vfs plugin (I don't see my remote volumes). It is running it on C apps though. I'm going to update again and reboot to see if I can get this working.
(In reply to comment #22) > Ok, finally got the test program to run. It isn't crashing because for some > reason dialog doesn't seem to be running the gnome-vfs plugin (I don't see my > remote volumes). Maybe that's why it was working for me too.
Ok, reproducing the bug with D-Bus compiled with -O0 seems to point to a deadlock and not a crash on a NULL mutex: #0 0x00b29410 in __kernel_vsyscall () #1 0x0032585e in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #2 0x003216ec in _L_mutex_lock_83 () from /lib/libpthread.so.0 #3 0x0032123d in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x4e6bfefd in dbus_gmutex_lock (mutex=0x8ebaac8) at dbus-gthread.c:95 #5 0x007fd762 in _dbus_mutex_lock (mutex=0x8ebaac8) at dbus-threads.c:150 #6 0x007d35bc in _dbus_bus_notify_shared_connection_disconnected_unlocked ( connection=0x8ebe1b8) at dbus-bus.c:353 #7 0x007dcba6 in notify_disconnected_unlocked (connection=0x8ebe1b8) at dbus-connection.c:3788 #8 0x007dcd33 in _dbus_connection_get_dispatch_status_unlocked ( connection=0x8ebe1b8) at dbus-connection.c:3865 #9 0x007d9c46 in _dbus_connection_close_possibly_shared_and_unlock ( connection=0x8ebe1b8) at dbus-connection.c:2685 #10 0x007d83f7 in _dbus_connection_close_possibly_shared ( connection=0x8ebe1b8) at dbus-connection.c:1803 #11 0x007d397e in internal_bus_get (type=DBUS_BUS_SESSION, private=0, error=0xbf9a1650) at dbus-bus.c:448 #12 0x007d3a6a in dbus_bus_get (type=DBUS_BUS_SESSION, error=0xbf9a1650) at dbus-bus.c:515 #13 0x4e851f8b in _gnome_vfs_get_main_dbus_connection () ---Type <return> to continue, or q <return> to quit--- at gnome-vfs-dbus-utils.c:151 #14 0x4e87274e in setup_dbus_connection (client=0x8e97a60) at gnome-vfs-volume-monitor-client.c:380 #15 0x4e872309 in gnome_vfs_volume_monitor_client_init ( volume_monitor_client=0x8e97a60) at gnome-vfs-volume-monitor-client.c:252 #16 0x4f16664a in g_type_create_instance () from /lib/libgobject-2.0.so.0 #17 0x4f14df32 in g_object_set () from /lib/libgobject-2.0.so.0 #18 0x4f14bb8b in g_object_newv () from /lib/libgobject-2.0.so.0 #19 0x4f14c6ef in g_object_new_valist () from /lib/libgobject-2.0.so.0 #20 0x4f14c8a0 in g_object_new () from /lib/libgobject-2.0.so.0 #21 0x4e8730c4 in _gnome_vfs_get_volume_monitor_internal (create=1) at gnome-vfs-volume-monitor.c:317 #22 0x4e87315a in gnome_vfs_get_volume_monitor () at gnome-vfs-volume-monitor.c:342 #23 0x0018b3b4 in gtk_file_system_gnome_vfs_new () from /usr/lib/gtk-2.0/2.10.0/filesystems/libgnome-vfs.so #24 0x4f16664a in g_type_create_instance () from /lib/libgobject-2.0.so.0 #25 0x4f14df32 in g_object_set () from /lib/libgobject-2.0.so.0 #26 0x4f14bb8b in g_object_newv () from /lib/libgobject-2.0.so.0 #27 0x4f14c6ef in g_object_new_valist () from /lib/libgobject-2.0.so.0 #28 0x4f14c8a0 in g_object_new () from /lib/libgobject-2.0.so.0 ---Type <return> to continue, or q <return> to quit--- #29 0x0018b0d9 in gtk_file_system_gnome_vfs_new () from /usr/lib/gtk-2.0/2.10.0/filesystems/libgnome-vfs.so #30 0x001911a5 in fs_module_create () from /usr/lib/gtk-2.0/2.10.0/filesystems/libgnome-vfs.so #31 0x4f32339d in _gtk_file_system_module_create ( fs_module=<value optimized out>) at gtkfilesystem.c:1358 #32 0x4f323523 in IA__gtk_file_system_create ( file_system_name=0x8d933c8 "gnome-vfs") at gtkfilesystem.c:1397 #33 0x4f314074 in gtk_file_chooser_default_set_property (object=0x8eb1030, prop_id=4097, value=0xbf9a1f34, pspec=0x8dd0f00) at gtkfilechooserdefault.c:5065 #34 0x4f14e10c in g_object_set () from /lib/libgobject-2.0.so.0 #35 0x4f3179f1 in gtk_file_chooser_default_constructor (type=149603648, n_construct_properties=1, construct_params=0x8d93138) at gtkfilechooserdefault.c:4904 #36 0x4f14bb8b in g_object_newv () from /lib/libgobject-2.0.so.0 #37 0x4f14c799 in g_object_new_valist () from /lib/libgobject-2.0.so.0 #38 0x4f14c8a0 in g_object_new () from /lib/libgobject-2.0.so.0 #39 0x4f309808 in _gtk_file_chooser_default_new (file_system=0x0) at gtkfilechooserdefault.c:9372 #40 0x4f31c01c in gtk_file_chooser_widget_constructor (type=149613544, ---Type <return> to continue, or q <return> to quit--- n_construct_properties=1, construct_params=0x8eac518) at gtkfilechooserwidget.c:103 #41 0x4f14bb8b in g_object_newv () from /lib/libgobject-2.0.so.0 #42 0x4f14c6ef in g_object_new_valist () from /lib/libgobject-2.0.so.0 #43 0x4f14c8a0 in g_object_new () from /lib/libgobject-2.0.so.0 #44 0x4f3183bd in gtk_file_chooser_dialog_constructor (type=149531504, n_construct_properties=3, construct_params=0x8eacb90) at gtkfilechooserdialog.c:374 #45 0x4f14bb8b in g_object_newv () from /lib/libgobject-2.0.so.0 #46 0x4f14c799 in g_object_new_valist () from /lib/libgobject-2.0.so.0 #47 0x4f14c8a0 in g_object_new () from /lib/libgobject-2.0.so.0 #48 0x4f317ebe in gtk_file_chooser_dialog_new_valist ( title=<value optimized out>, parent=0x8cc0aa0, action=GTK_FILE_CHOOSER_ACTION_OPEN, backend=0x0, first_button_text=0x56f4db "gtk-cancel", varargs=0xbf9a26ac "������V") at gtkfilechooserdialog.c:569 #49 0x4f317f6c in IA__gtk_file_chooser_dialog_new (title=0x768958 "Open", parent=0x8cc0aa0, action=GTK_FILE_CHOOSER_ACTION_OPEN, first_button_text=0x56f4db "gtk-cancel") at gtkfilechooserdialog.c:614 #50 0x0056f3cf in Java_org_eclipse_swt_internal_gtk_OS__1gtk_1file_1chooser_1dialog_1new () from /usr/lib/libswt-pi-gtk-3235.so ---Type <return> to continue, or q <return> to quit--- #51 0x05d42e6b in org::eclipse::swt::internal::gtk::OS::_gtk_file_chooser_dialog_new () from /usr/lib/gcj/eclipse/org.eclipse.swt.gtk.linux.x86_3.2.1.v3235.jar.so #52 0x05d42f0f in org::eclipse::swt::internal::gtk::OS::gtk_file_chooser_dialog_new () from /usr/lib/gcj/eclipse/org.eclipse.swt.gtk.linux.x86_3.2.1.v3235.jar.so #53 0x05e333d5 in org::eclipse::swt::widgets::FileDialog::openChooserDialog () from /usr/lib/gcj/eclipse/org.eclipse.swt.gtk.linux.x86_3.2.1.v3235.jar.so #54 0x05e332f3 in org::eclipse::swt::widgets::FileDialog::open () from /usr/lib/gcj/eclipse/org.eclipse.swt.gtk.linux.x86_3.2.1.v3235.jar.so #55 0x01f616b7 in _Jv_strtod_r () from /usr/lib/libgcj.so.7rh #56 0x01f61454 in _Jv_strtod_r () from /usr/lib/libgcj.so.7rh #57 0x016c3541 in _Jv_InterpMethod::run () from /usr/lib/libgcj.so.7rh #58 0x016c71cb in _Jv_InterpMethod::run_normal () from /usr/lib/libgcj.so.7rh #59 0x01f6178d in _Jv_strtod_r () from /usr/lib/libgcj.so.7rh #60 0x05e97b74 in org::eclipse::swt::widgets::TypedListener::handleEvent () from /usr/lib/gcj/eclipse/org.eclipse.swt.gtk.linux.x86_3.2.1.v3235.jar.so #61 0x05e2b74d in org::eclipse::swt::widgets::EventTable::sendEvent () from /usr/lib/gcj/eclipse/org.eclipse.swt.gtk.linux.x86_3.2.1.v3235.jar.so #62 0x05e9a23f in org::eclipse::swt::widgets::Widget::sendEvent () ---Type <return> to continue, or q <return> to quit--- from /usr/lib/gcj/eclipse/org.eclipse.swt.gtk.linux.x86_3.2.1.v3235.jar.so #63 0x05e28ab0 in org::eclipse::swt::widgets::Display::runDeferredEvents () from /usr/lib/gcj/eclipse/org.eclipse.swt.gtk.linux.x86_3.2.1.v3235.jar.so #64 0x05e2791f in org::eclipse::swt::widgets::Display::readAndDispatch () from /usr/lib/gcj/eclipse/org.eclipse.swt.gtk.linux.x86_3.2.1.v3235.jar.so #65 0x01f616b7 in _Jv_strtod_r () from /usr/lib/libgcj.so.7rh #66 0x01f61454 in _Jv_strtod_r () from /usr/lib/libgcj.so.7rh #67 0x016c3541 in _Jv_InterpMethod::run () from /usr/lib/libgcj.so.7rh #68 0x016c71cb in _Jv_InterpMethod::run_normal () from /usr/lib/libgcj.so.7rh #69 0x01f6178d in _Jv_strtod_r () from /usr/lib/libgcj.so.7rh #70 0x01f616b7 in _Jv_strtod_r () from /usr/lib/libgcj.so.7rh #71 0x01f61454 in _Jv_strtod_r () from /usr/lib/libgcj.so.7rh #72 0x016c3541 in _Jv_InterpMethod::run () from /usr/lib/libgcj.so.7rh #73 0x016c711a in _Jv_InterpMethod::run_class () from /usr/lib/libgcj.so.7rh #74 0x01f6178d in _Jv_strtod_r () from /usr/lib/libgcj.so.7rh #75 0x016e0824 in gnu::java::lang::MainThread::call_main () from /usr/lib/libgcj.so.7rh #76 0x01745b07 in gnu::java::lang::MainThread::run () from /usr/lib/libgcj.so.7rh #77 0x016f060b in _Jv_ThreadRun () from /usr/lib/libgcj.so.7rh #78 0x016ab5fc in _Jv_RunMain () from /usr/lib/libgcj.so.7rh ---Type <return> to continue, or q <return> to quit--- #79 0x0019fa98 in main () from /usr/lib/libgij.so.7rh #80 0x001b7e5c in __libc_start_main () from /lib/libc.so.6 #81 0x08048481 in _Jv_RegisterClasses ()
I found the culprit. It is an SELinux issue combined with an error path in D-Bus that deadlocks. I need to fix that error path but I also need to investigate why SELinux is blocking Java from registering a connection on the bus. (gdb) print error->message $10 = 0x9b5bca8 "An SELinux policy prevents this sender from sending this message to this recipient (rejected message had interface \"org.freedesktop.DBus\" member \"Hello\" error name \"(unset)\" destination \"org.freedeskt"...
Dec 4 15:06:55 phuket dbus: Can't send to audit system: USER_AVC avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=19333 scontext=user_u:system_r:java_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=dbus : exe="/bin/dbus-daemon" (sauid=500, hostname=?, addr=?, terminal=?)
Fixed in selinux-policy-2.4.6-6
Woops. The SELinux bug is separate. I guess cloning makes the two depend on each other. Changing back to assigned as I try to fix this issue
*** Bug 218495 has been marked as a duplicate of this bug. ***
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp