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 744690 - Gio.VolumeMonitor().get_connected_drives() crashes
Gio.VolumeMonitor().get_connected_drives() crashes
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: gio
unspecified
Other All
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
: 754830 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-02-18 08:22 UTC by Olav Vitters
Modified: 2017-03-28 08:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
overrides: warn on instantiation of Gio.VolumeMonitor (2.53 KB, patch)
2017-03-23 14:58 UTC, Christoph Reiter (lazka)
committed Details | Review

Description Olav Vitters 2015-02-18 08:22:57 UTC
Reported at https://plus.google.com/109637860626261571611/posts/GSea6jx1mnn

Crashes under Python 3 and Python 2.

$ python
Python 2.7.9 (default, Dec 14 2014, 10:12:16)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from gi.repository import Gio
>>> v=Gio.VolumeMonitor()
>>> v.get_connected_drives()
Segmentation fault (core dumped)
Comment 1 Cédric Bellegarde 2015-02-18 09:46:58 UTC
Can confirm here on archlinux
Comment 2 Emmanuele Bassi (:ebassi) 2015-02-18 14:26:19 UTC
GVolumeMonitor is a a singleton instance constructed through the g_volume_monitor_get() factory. you cannot use the Python constructor normal form `Gio.VolumeMonitor()` to create an instance.

use `Gio.VolumeMonitor.get()` instead:

Python 2.7.8 (default, Nov 10 2014, 08:19:18) 
[GCC 4.9.2 20141101 (Red Hat 4.9.2-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from gi.repository import Gio
>>> v = Gio.VolumeMonitor.get()
>>> v.get_connected_drives()
[<__main__.GProxyDrive object at 0x7f44609f31e0 (GProxyDrive at 0x14d0000)>, <__main__.GProxyDrive object at 0x7f44609f3230 (GProxyDrive at 0x14cf720)>, <__main__.GProxyDrive object at 0x7f44609f3280 (GProxyDrive at 0x14d0080)>]
>>> 

GVolumeMonitor is not abstract, for some reason, which would have probably caught you trying to use the constructor and raised an exception.

you also probably want to look at bug 675581, which deals with PyGObject disallowing construction of GObject instances without a public constructor.
Comment 3 Olav Vitters 2015-02-18 14:55:39 UTC
Python should never crash. IMO this is a dupe of that bug.

*** This bug has been marked as a duplicate of bug 675581 ***
Comment 4 Emmanuele Bassi (:ebassi) 2015-09-10 13:14:52 UTC
*** Bug 754830 has been marked as a duplicate of this bug. ***
Comment 5 Emmanuele Bassi (:ebassi) 2015-09-10 13:17:07 UTC
(In reply to Olav Vitters from comment #3)
> Python should never crash.

While ideally true, that's clearly not feasible. The lower layers of the platforms are written in C, and are not bindings-aware. We cannot turn assertion failures or simple segfaults into Python exceptions.

Python code that calls into native code will always retain the chance of a crash.
Comment 6 Matěj Cepl 2015-09-10 13:22:48 UTC
(In reply to Olav Vitters from comment #3)
> Python should never crash. IMO this is a dupe of that bug.
> 
> *** This bug has been marked as a duplicate of bug 675581 ***

No, it isn't a duplicate ... it is now mostly a request for the override in Python bindings to call .get() when Gio.VolumeMonitor() is being called.
Comment 7 Emmanuele Bassi (:ebassi) 2015-09-10 13:25:02 UTC
Re-assigning.
Comment 8 Christoph Reiter (lazka) 2017-03-23 14:58:08 UTC
Created attachment 348576 [details] [review]
overrides: warn on instantiation of Gio.VolumeMonitor

Gio.VolumeMonitor.get() should be used instead

----

I think returning a singleton would be confusing compared to how other types behave and would fail to return a subclass in case of subclassing.

This warnings should point users in the right direction at least and can be removed again if we find a better solution in the future.