GNOME Bugzilla – Bug 570366
Mounting phone via Bluetooth fails with OOM error
Last modified: 2015-03-04 15:38:30 UTC
(Separated from bug 570193, please check it for reference). Mounting obex locations sometimes fail with Out of memory error. Hit rate is only about 5-10%. Steps to reproduce: 1. Spawn /usr/libexec/gvfsd-obexftp host=[<phone_MAC_address>] 2. When the phone asks you to authorize your client, decline (I already did pairing, phone is just asking me to confirm every action). 3. Repeat until gvfsd-obexftp crashes with OOM error Environment: Fedora rawhide, BT USB stick, connecting to the Sony Ericsson K750i phone. gvfs trunk rev. 2194 dbus-1.2.4.4permissive-1.fc11.i386 obex-data-server 0.4.3svn (trunk rev. 2496); tested also with obex-data-server-0.4.1-1.fc10.i386, same issue (gdb) r host=[00:16:20:D1:B7:65] Starting program: /usr/libexec/gvfsd-obexftp host=[00:16:20:D1:B7:65] [Thread debugging using libthread_db enabled] setting 'host' to '[00:16:20:D1:B7:65]' Added new job source 0x8073810 (GVfsBackendObexftp) Queued new job 0x8075c18 (GVfsJobMount) [New Thread 0xb7de4b70 (LWP 7404)] + do_mount ** ERROR **: Out of memory aborting... Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 0xb7de4b70 (LWP 7404)] IA__g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, format=0x14a968 "Out of memory", args1=0xb7de408c "�����Z\a\b8�\006\b") at gmessages.c:503 503 g_private_set (g_log_depth, GUINT_TO_POINTER (depth)); (gdb) t a a bt
+ Trace 212180
Thread 2 (Thread 0xb7de4b70 (LWP 7404))
Created attachment 127843 [details] Valgrind log - invalid read/write, no crash this time hit rate of this issue = 5% Run with G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind /usr/libexec/gvfsd-obexftp host=[00:16:20:D1:B7:65]
Committed in b92794937d748c013609675d331c47d175c6f0f4 Could you please test whether this fixes the problem, and backport to gnome-2-28 (and F12) when done?
Created attachment 151261 [details] backtrace of the crash Unfortunately, the problem still persists. Though it's much harder to hit the error now (approx. 1% hit rate).
The snippet of code in dbus-glib is: message = dbus_g_proxy_marshal_args_to_message (proxy, method, args); if (!message) goto oom; if (!dbus_connection_send_with_reply (priv->manager->connection, message, &pending, timeout)) goto oom; Any chance you could check which one of them fails?
I've added some prints into dbus-gproxy.c: 1. dbus_g_proxy_call() is called with method 'CreateBluetoothSession' 2. dbus_g_proxy_marshal_args_to_message() properly returns non-NULL message 3. dbus_connection_send_with_reply() then fails Looking at the sources, I still can't find anything suspicious, the private DBus connection pointer is properly passed in to dbus_g_proxy_call() and there are no calls in between. Also the system is in idle, nothing else is touching the device, Nautilus is not running (no autorun or polling).
How to reproduce quickly and without bluetooth: 1. in do_mount(), put _exit(0); after the dbus_g_proxy_call ("CreateBluetoothSession" ...) test - i.e. quit the backend with zero return value if the first dbus call succeeds, in the other case (OOM) g_error() will abort with return value 1 2. compile gvfs 3. run in terminal: while (/tmp/gvfs/daemon/gvfsd-obexftp host=[00:16:20:D1:B7:65]); do echo -n; done
Obexftp backend has been obsoleted in GNOME 3.10, because it is incompatible with Bluez 5, however limited bluetooth support is currently built-in in GNOME desktop.