Description of problem: When opening any file dialog boxes (either to load a document, import a text file or insert a picture), OOo Writer takes ages to render the file dialog (for inserting a drawing, it takes almost a minute to generate the open dialog and then it's an empty box) Version-Release number of selected component (if applicable): 2.4.0.8-12 How reproducible: Always Steps to Reproduce: 1. load a document 2. insert a picture 3. Actual results: Very slow response time and then it hangs Expected results: Open dialog boxes should open quickly and insert quickly Additional info: I've not noticed this on my x86 box. I've got the hardware acceleration switched off and not rendering via OpenGL
The file dialog is not specific to OOo. Personally I definitely don't see a minute to create it, for me on x86_64 and i386 its almost instantaneous.
Is there any way to check where the problem is from?
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
What ever the problem was, it's not in OOo3
Same problem on i386 with any application using gtk file dialog: openoffice, evince, epiphany, firefox I also see this problem with the desktop wallpaper chooser application at startup (right-clicking on desktop and clicking on "Changing desktop background" takes 1min unless no open dialog is shown)
I used strace with evince to see what might be the cause and during the hang up, the application tries to connect to the socket /home/<user>/.beagle/socket which fails with error EAGAIN. Then the application do a nanosleep and try again (during 20-30s) Killing beagle (or killing beagle/restarting it) fixes the problem (until the computer is rebooted)
I see this too, but I don't have beagle installed. Anyone using VNC? I see this in a VNC session, but not in a console session.
Changing component to gvfs. The culprit seems to be libgiohal-volume-monitor. This is a work-around: chmod 0 /usr/lib*/gio/modules/libgiohal-volume-monitor.so
It happens here: hal_pool_new at hal-pool.c:356 if (libhal_get_all_devices_with_properties (pool->priv->hal_ctx, A strace of hald at this point reveals an AccessDenied error due to SELinux: 1214476036.206310 write(8, "/freedesktop/Hal/devices/usb_device_1d6b_1_0000_00_1d_2\0\v\0\0\0info.parent\0\1s\0\0*\0\0\0/org/freedesktop/Hal/devices/pci_8086_268a\0\0\0\0\0\0\32\0\0\0usb_device.device_protocol\0\1i\0\0\0\0\0\0\0\22\0\0\0usb_device.version\0\1d\0\0\0\0\0\0\0\232\231\231\231\231\231\361?\24\0\0\0usb_device.vendor_id\0\1i\0k\35\0\0\32\0\0\0usb_device.is_self_powered\0\1b\0\0\0\1\0\0\0\25\0\0\0usb_device.product_id\0\1i\0\0\0\0\1\0\0\0\0\0\0\0\26\0\0\0usb_device.can_wake_up\0\1b\0\0\0\1\0\0\0\0\0\0\0\22\0\0\0linux.hotplug_type\0\1i\0\0\0\2\0\0\0\21\0\0\0usb_"..., 33512) = 33512 1214476036.206412 munmap(0x7f6f8570c000, 270336) = 0 1214476036.206450 poll([{fd=5, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLPRI}, {fd=13, events=POLLIN}, {fd=17, events=POLLIN}, {fd=16, events=POLLIN}, {fd=14, events=POLLIN}, {fd=18, events=POLLIN}, {fd=7, events=POLLIN}, {fd=10, events=POLLIN}, {fd=15, events=0}, {fd=8, events=POLLIN, revents=POLLIN}], 13, 14794) = 1 1214476036.207746 read(8, "l\3\1\1\274\0\0\0\"\0\0\0m\0\0\0\6\1s\0\4\0\0\0:1.0\0\0\0\0\4\1s\0\'\0\0\0org.freedesktop.DBus.Error.AccessDenied\0\5\1u\0\254\1\0\0\10\1g\0\1s\0\0\7\1s\0\24\0\0\0org.freedesktop.DBus\0\0\0\0\267\0\0\0An SELinux policy prevents this sender from sending this message to this recipient (rejected message had interface \"(unset)\" member \"(unset)\" error name \"(unset)\" destination \":1.70\")\0", 2048) = 316 and audit.log has this: type=USER_AVC msg=audit(1214476036.207:216): user pid=2637 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.70 spid=2708 tpid=1337 scontext=system_u:system_r:hald_t:s0 tcontext=unconfined_u:system_r:unconfined_notrans_t:s0 tclass=dbus : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' Seems like the VNC server might be running in the wrong security context (unconfined_notrans_t)? My VNC session gets started from 'service vncserver start'.
Further evidence that the VNC session security context is wrong: 'setenforce 0' makes the file chooser dialogs fast again.
# audit2allow -M mypol -l -i /var/log/audit/audit.log # semodule -i mypol.pp Fixed in selinux-policy-3.3.1-72.fc9.noarch
Probably there are two differents bugs: * One when beagle is installed and beagle socket file is stalled * One when running from a VNC session Please don't forget the first case (which was the original case)
selinux-policy-3.3.1-72.fc9 fixes the VNC part of this at least. Laurent, can you verify that there is still a bug remaining?