Thanks for your report. It doesn't see to be google-specific. Can you provide please more info, link to the original report, some info when this happens, how it can be reproduced...?

I can reproduce, no need for additional info. This is probably related to GTask port. It happens if you don't answer "Volume is busy" dialog within 2 seconds...

==14620== Invalid read of size 8
==14620==    at 0x56D0330: g_type_check_instance_cast (gtype.c:4052)
==14620==    by 0x4E479C1: on_show_processes_reply (gvfsbackend.c:879)
==14620==    by 0x53588CA: g_task_return_now (gtask.c:1148)
==14620==    by 0x53589E6: g_task_return (gtask.c:1206)
==14620==    by 0x5359A1D: g_task_return_error (gtask.c:1780)
==14620==    by 0x5359AE4: g_task_return_new_error (gtask.c:1814)
==14620==    by 0x5093BF1: show_processes_reply (gmountsource.c:743)
==14620==    by 0x53588CA: g_task_return_now (gtask.c:1148)
==14620==    by 0x53589E6: g_task_return (gtask.c:1206)
==14620==    by 0x5359461: g_task_return_pointer (gtask.c:1604)
==14620==    by 0x53B119B: reply_cb (gdbusproxy.c:2596)
==14620==    by 0x53588CA: g_task_return_now (gtask.c:1148)
==14620==  Address 0x13c10da0 is 0 bytes inside a block of size 208 free'd
==14620==    at 0x4C2EDAC: free (vg_replace_malloc.c:530)
==14620==    by 0x594E8A1: g_free (gmem.c:194)
==14620==    by 0x5968D31: g_slice_free1 (gslice.c:1136)
==14620==    by 0x56CC768: g_type_free_instance (gtype.c:1943)
==14620==    by 0x56B60D1: g_object_unref (gobject.c:3351)
==14620==    by 0x4E4798E: complete_unmount_with_op (gvfsbackend.c:871)
==14620==    by 0x4E47ABA: on_update_processes_timeout (gvfsbackend.c:907)
==14620==    by 0x5947F9C: g_timeout_dispatch (gmain.c:4650)
==14620==    by 0x594611E: g_main_dispatch (gmain.c:3177)
==14620==    by 0x5946FCF: g_main_context_dispatch (gmain.c:3830)
==14620==    by 0x59471B4: g_main_context_iterate (gmain.c:3903)
==14620==    by 0x59475DB: g_main_loop_run (gmain.c:4099)
==14620==  Block was alloc'd at
==14620==    at 0x4C2DBAB: malloc (vg_replace_malloc.c:299)
==14620==    by 0x594E738: g_malloc (gmem.c:99)
==14620==    by 0x5968AF5: g_slice_alloc (gslice.c:1025)
==14620==    by 0x5968B35: g_slice_alloc0 (gslice.c:1051)
==14620==    by 0x56CC345: g_type_create_instance (gtype.c:1848)
==14620==    by 0x56B244B: g_object_new_internal (gobject.c:1799)
==14620==    by 0x56B2A62: g_object_new_with_properties (gobject.c:1967)
==14620==    by 0x56B1FFC: g_object_new (gobject.c:1639)
==14620==    by 0x5357CED: g_task_new (gtask.c:696)
==14620==    by 0x4E47D33: g_vfs_backend_unmount_with_operation (gvfsbackend.c:996)
==14620==    by 0x4E592D2: try (gvfsjobunmount.c:266)
==14620==    by 0x4E4CA27: g_vfs_job_try (gvfsjob.c:215)

(In reply to Ondrej Holy from comment #2)
> I can reproduce, no need for additional info. This is probably related to
> GTask port. It happens if you don't answer "Volume is busy" dialog within 2
> seconds...

Nope, it happens if you don't answer the dialog and g_vfs_daemon_has_blocking_processes return FALSE in on_update_processes_timeout... but it seems that this bug was here also before GTask port, or GTask releases the data earlier.

Created attachment 369382 [details] [review]
backend: Fix crashes when "Volume is busy" prompt is shown

Backend crashes in on_show_processes_reply callback if the async call
has been completed over on_update_processes_timeout in the meantime
because it releases GTask data (i.e. "Volume is busy" prompt is being
shown and blocking operations have been finished). Increase reference
count for GTask to avoid this crash.

Sorry for not providing the extra information, we don't have user reports including a description just automatic error reports, the corresponding launchpad bug is https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1753741

that fix missed 1.36 it looks like :/ can we get it commited before .1?

Yes, it will be part of .1. I've made an addition testing and revised my proposed fix. Let's rather simplify the handling instead of adding additional reference. During the testing, I've also found one issue in debug output when unmounting. I will attach patches...

Created attachment 369727 [details] [review]
gvfsjobunmount: Do not print send_reply debug twice

Debug from send_reply is printed once from GVfsJobUnmount and once
from GVfsJobDBus, which is confusing and redundant, let's remove th
one from GVfsJobUnmount.

Created attachment 369728 [details] [review]
backend: Fix crashes when "Volume is busy" prompt is shown

Backend crashes in on_show_processes_reply callback if
g_vfs_backend_unmount_with_operation async call has been completed
over on_update_processes_timeout in the meantime and releases GTask
data (i.e. "Volume is busy" prompt is being shown and blocking
operations have been finished).

This patch simplify the handling. With this patch, the async call
is completed only from one place, on_show_processes_reply. If there
are no more processes, g_mount_source_abort is called from
on_update_processes_timeout only and the reply is handled by
on_show_processes_reply consequently. This prevents the crashes.

Just a note that client side ensures that on_show_processes_reply is
called only once.

Attachment 369727 [details] pushed as 22e16dc - gvfsjobunmount: Do not print send_reply debug twice
Attachment 369728 [details] pushed as 7c27d2b - backend: Fix crashes when "Volume is busy" prompt is shown

I still get a crash when trying to eject a busy usb disk.

+ Trace 238542

Did you apply the patch manually? Because the first release which contains this fix is 1.36.1 which I have released yesterday...