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 791265 - Unable to pickle GLib.Error
Unable to pickle GLib.Error
Status: RESOLVED OBSOLETE
Product: pygobject
Classification: Bindings
Component: general
Git master
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2017-12-05 12:53 UTC by Sam Thursfield
Modified: 2018-04-05 16:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Example showing my attempt to return an exception from a 'multiprocessing' subprocess via a queue (1.69 KB, text/x-python)
2017-12-05 14:48 UTC, Sam Thursfield
Details

Description Sam Thursfield 2017-12-05 12:53:17 UTC
It's not possible to pickle GLib.Error instances.

This bit me hard in a specific situation where I was returning exceptions from a multiprocessing.Subprocess() using a queue. When the exception was a GLib.Error instance, my attempt to return the exception would silently fail and the subprocess would appear to have died for no reason.
Comment 1 Sam Thursfield 2017-12-05 12:53:39 UTC
Example of failure to pickle:

>>> from gi.repository import GLib
>>> import pickle
>>> pickle.dumps(GLib.Error("Example"))
Traceback (most recent call last):
  • File "<stdin>", line 1 in <module>
_pickle.PicklingError: Can't pickle <class 'GLib.GError'>: import of module 'GLib' failed

Comment 2 Christoph Reiter (lazka) 2017-12-05 12:59:33 UTC
Thanks. Can you provide a small example showing the problem with subprocess and queue?
Comment 3 Sam Thursfield 2017-12-05 14:48:00 UTC
Created attachment 365030 [details]
Example showing my attempt to return an exception from a 'multiprocessing' subprocess via a queue

Sure, here's an example -- slightly contrived but shows a scenario where I would want to be able to pass a GLib.Error from subprocess to a main process, and demonstrates that it doesn't work.

It's contrived in part because the main process doesn't try to handle the exception, so it could be "fixed" by just printing the traceback in the subprocess. But there are many cases where you want to do more with the exception in the main process than to just re-raise it, and none of that is easily possible if we can't get the exception into a Queue object.
Comment 4 Christoph Reiter (lazka) 2017-12-05 15:07:51 UTC
Thanks, to summarize:

* Using multiprocessing.Queue one can return exception instances to the parent process.
* Normal Python exceptions are picklable
* GLib.Error is an "exception" and is not picklable

Sounds reasonable.

----

import multiprocessing
from gi.repository import GLib

def add_queue(e):
    q = multiprocessing.Queue()
    q.put(e)
    print(repr(q.get()))

try:
    raise ValueError("foo")
except Exception as e:
    add_queue(e)

try:
    GLib.file_get_contents("")
except Exception as e:
    add_queue(e)
Comment 5 Sam Thursfield 2017-12-05 16:09:48 UTC
Thanks for summarizing a bit more clearly than I could :-)
Comment 6 GNOME Infrastructure Team 2018-01-10 21:01:12 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pygobject/issues/145.
Comment 7 Christoph Reiter (lazka) 2018-04-05 16:18:52 UTC
https://gitlab.gnome.org/GNOME/pygobject/merge_requests/54