After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 756105 - Responding with empty array causes daemon to crash
Responding with empty array causes daemon to crash
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: daemon
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
: 756885 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-10-06 06:19 UTC by Tristan Van Berkom
Modified: 2015-10-20 23:15 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Use specific array type for GVariantBuilder (1.03 KB, patch)
2015-10-06 06:19 UTC, Tristan Van Berkom 		committed Details | Review

Description Tristan Van Berkom 2015-10-06 06:19:56 UTC 
Created attachment 312702 [details] [review]
Use specific array type for GVariantBuilder

While trying to run gnome-session on system I'm still trying to put together, still running in a VM, I ran into this crash.

The crash occurs in gvfsdaemon.c:handle_list_monitor_implementations(), whenever we try to return an empty vector (i.e. there are no monitor implementations) - the crash is due to passing a null variant to the dbus response, which errors out while expecting a variant of type 'a(ssbia{sv})'.

Granted, the system is not quite configured properly yet, and I'm not sure that there is any "monitor implementations" present in the VM or not, I'm quite sure that the gfvsd crash is undesirable.

The attached patch ensures that a properly initialized GVariant is passed instead, so that the daemon properly responds with an empty vector instead of crashing (or aborting).
Comment 1 Ondrej Holy 2015-10-06 07:45:11 UTC 
Comment on attachment 312702 [details] [review]
Use specific array type for GVariantBuilder

The patch looks good to me, however it shouldn't happen that there are no monitor implementations... don't you see any *.monitor files in $(datadir)/gvfs/remote-volume-monitors directory?
Comment 2 Tristan Van Berkom 2015-10-06 09:20:12 UTC 
(In reply to Ondrej Holy from comment #1)
> Comment on attachment 312702 [details] [review] [review]
> Use specific array type for GVariantBuilder
> 
> The patch looks good to me, however it shouldn't happen that there are no
> monitor implementations... don't you see any *.monitor files in
> $(datadir)/gvfs/remote-volume-monitors directory?

No I don't see any, as I have not yet built/installed any.

I am basically trying to put together a firmware from scratch, this work may evolve into a sort of continuous integration build; hopefully outputting a disk image / live CD of the latest bleeding edge GNOME built directly from git.

So yes, the next step is to build these volume monitors (and provide some of the dependencies for gvfs to build some of it's own monitors), the crash/abort is just something one discovers during this process :)
Comment 3 Ondrej Holy 2015-10-06 09:28:31 UTC 
Ok then, thanks for the patch!
Comment 4 Ondrej Holy 2015-10-06 09:28:37 UTC 
Comment on attachment 312702 [details] [review]
Use specific array type for GVariantBuilder

commit 77805a9871fcf53e99ccece6509faea77fcf93b4
Comment 5 Ross Lagerwall 2015-10-20 23:15:12 UTC 
*** Bug 756885 has been marked as a duplicate of this bug. ***