scope-runner-dbus.py assert failure: *** Error in `/usr/bin/python3': free(): invalid next size (fast): 0x0000000001ca17b0 ***

StacktraceTop:
 __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7fd789926128 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
 malloc_printerr (ptr=<optimized out>, str=0x7fd7899261a0 "free(): invalid next size (fast)", action=1) at malloc.c:4965
 _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:3834
 __GI___libc_free (mem=<optimized out>) at malloc.c:2950
 _pygi_closure_handle () from /tmp/apport_sandbox_zFmgT3/usr/lib/python3/dist-packages/gi/_gi.cpython-35m-x86_64-linux-gnu.so

Status changed to 'Confirmed' because the bug affects multiple users.

Easily reproduced *once* per session in a live session. Doesn't seem to occur again unless one logs out/ in.
Also don't see on a real install so this comment may be of no value?

What reproduces here is to type some letters in the home Dash, then add a :
crash will then occur within a few sec.s or less

Actually can get to crash multiple times per session as long as search term before the ; is vastly different
So before crashed on ; when attempting to go manpages:compiz
Then again when trying calculator:2+2

(in any event expect terms with: no longer work see - https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1540519

The ; in prior comment should be : (- sorry to spam

It happened to me on a real install, when searching for "Limone sul Garda" with activated Wikipedia-scope and enabled online-search, but only on the first search.

Yeah, it also seems to occur upon *first use* of the Dash search per session

Idem top page but in a fresh installed ubu 16.04 LTS.
Happened after the upgrade of "ofono" and "telepathy-ring"
on Feb 12 2016.

Forgot to add the error such top of this page:
ProblemType: Crash
DistroRelease: Ubuntu 16.04
Package: unity-scopes-runner 7.1.4+15.10.20151002-0ubuntu2
ProcVersionSignature: Ubuntu 4.3.0-7.18-generic 4.3.3
Uname: Linux 4.3.0-7-generic x86_64
ApportVersion: 2.19.4-0ubuntu1
Architecture: amd64
AssertionMessage: *** Error in `/usr/bin/python3': free(): invalid next size (fast): 0x0000000001ca17b0 ***
CrashCounter: 1
CurrentDesktop: Unity
Date: Wed Jan 27 10:41:54 2016
Dependencies:

ExecutablePath: /usr/share/unity-scopes/scope-runner-dbus.py
InstallationDate: Installed on 2015-04-30 (271 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
InterpreterPath: /usr/bin/python3.5
PackageArchitecture: all
ProcCmdline: /usr/bin/python3 /usr/share/unity-scopes/scope-runner-dbus.py -s info/calculator.scope
Signal: 6
SourcePackage: libunity
StacktraceTop:
 __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7fd789926128 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
 malloc_printerr (ptr=<optimised out>, str=0x7fd7899261a0 "free(): invalid next size (fast)", action=1) at malloc.c:4965
 _int_free (av=<optimised out>, p=<optimised out>, have_lock=0) at malloc.c:3834
 __GI___libc_free (mem=<optimised out>) at malloc.c:2950
 ?? () from /usr/lib/python3/dist-packages/gi/_gi.cpython-35m-x86_64-linux-gnu.so
SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2:
Title: scope-runner-dbus.py assert failure: *** Error in `/usr/bin/python3': free(): invalid next size (fast): 0x0000000001ca17b0 ***
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm audio cdrom dip libvirtd lpadmin plugdev sambashare sudo

The bug happened after work Gnome Color Chooser and Work Firefox changing styles.

On my side, the error only shows once per session, yes, but… my request also never works as expected, ever.

I just want to use the unity-scope-calculator as usual — “Dashing” for calc:1+2 — but it doesn't work, neither the first time nor the next ones. Is this scope obsolete? Or is it supposed to still work?

If the whole scope-runner-dbus.py thing is affected, it means this problem is affecting all Python scopes, that is:

$ ls -l /usr/share/unity-scopes/*/*_daemon.py
-rw-r--r-- 1 root root 7028 mar 28 2014 /usr/share/unity-scopes/calculator/unity_calculator_daemon.py
-rw-r--r-- 1 root root 10731 jui 23 2013 /usr/share/unity-scopes/chromiumbookmarks/unity_chromiumbookmarks_daemon.py
-rw-r--r-- 1 root root 10087 jui 23 2013 /usr/share/unity-scopes/colourlovers/unity_colourlovers_daemon.py
-rw-r--r-- 1 root root 9772 mar 28 2014 /usr/share/unity-scopes/devhelp/unity_devhelp_daemon.py
-rwxr-xr-x 1 root root 25607 mar 18 2014 /usr/share/unity-scopes/facebook/unity_facebook_daemon.py
-rw-r--r-- 1 root root 8922 aoû 9 2013 /usr/share/unity-scopes/firefoxbookmarks/unity_firefoxbookmarks_daemon.py
-rwxr-xr-x 1 root root 26075 mar 18 2014 /usr/share/unity-scopes/flickr/unity_flickr_daemon.py
-rwxr-xr-x 1 root root 13883 nov 25 11:34 /usr/share/unity-scopes/gdrive/unity_gdrive_daemon.py
-rwxr-xr-x 1 root root 6939 mar 24 2014 /usr/share/unity-scopes/manpages/unity_manpages_daemon.py
-rw-r--r-- 1 root root 8485 jui 23 2013 /usr/share/unity-scopes/openclipart/unity_openclipart_daemon.py
-rwxr-xr-x 1 root root 21877 mar 18 2014 /usr/share/unity-scopes/picasa/unity_picasa_daemon.py
-rwxr-xr-x 1 root root 24576 mar 18 2014 /usr/share/unity-scopes/shotwell/unity_shotwell_daemon.py
-rw-r--r-- 1 root root 8213 mar 28 2014 /usr/share/unity-scopes/texdoc/unity_texdoc_daemon.py
-rw-r--r-- 1 root root 8574 jui 23 2013 /usr/share/unity-scopes/tomboy/unity_tomboy_daemon.py
-rw-r--r-- 1 root root 8993 jui 23 2013 /usr/share/unity-scopes/virtualbox/unity_virtualbox_daemon.py
-rw-r--r-- 1 root root 9967 jui 23 2013 /usr/share/unity-scopes/yelp/unity_yelp_daemon.py
-rw-r--r-- 1 root root 11082 jui 23 2013 /usr/share/unity-scopes/zotero/unity_zotero_daemon.py

I forgot to mention: I rely on on the Python scopes infrastructure to work as expected to endorse the deployment of this Xenial LTS over 400 computers in the NGO I'm working for… Since I love Ubuntu and advocate for it at work, if you need any more tests, it will be my pleasure to volunteer!

Per the bug mentioned in comment 8 use of : in the Dash does not produce the expected results

Sent from BlueMail

On Mar 11, 2016, 6:25 PM, at 6:25 PM, "Jean Christophe André" <email address hidden> wrote:
>On my side, the error only shows once per session, yes, but… my request
>also never works as expected, ever.
>
>I just want to use the unity-scope-calculator as usual — “Dashing” for
>calc:1+2 — but it doesn't work, neither the first time nor the next
>ones. Is this scope obsolete? Or is it supposed to still work?
>
>If the whole scope-runner-dbus.py thing is affected, it means this
>problem is affecting all Python scopes, that is:
>
>$ ls -l /usr/share/unity-scopes/*/*_daemon.py
>-rw-r--r-- 1 root root 7028 mar 28 2014
>/usr/share/unity-scopes/calculator/unity_calculator_daemon.py
>-rw-r--r-- 1 root root 10731 jui 23 2013
>/usr/share/unity-scopes/chromiumbookmarks/unity_chromiumbookmarks_daemon.py
>-rw-r--r-- 1 root root 10087 jui 23 2013
>/usr/share/unity-scopes/colourlovers/unity_colourlovers_daemon.py
>-rw-r--r-- 1 root root 9772 mar 28 2014
>/usr/share/unity-scopes/devhelp/unity_devhelp_daemon.py
>-rwxr-xr-x 1 root root 25607 mar 18 2014
>/usr/share/unity-scopes/facebook/unity_facebook_daemon.py
>-rw-r--r-- 1 root root 8922 aoû 9 2013
>/usr/share/unity-scopes/firefoxbookmarks/unity_firefoxbookmarks_daemon.py
>-rwxr-xr-x 1 root root 26075 mar 18 2014
>/usr/share/unity-scopes/flickr/unity_flickr_daemon.py
>-rwxr-xr-x 1 root root 13883 nov 25 11:34
>/usr/share/unity-scopes/gdrive/unity_gdrive_daemon.py
>-rwxr-xr-x 1 root root 6939 mar 24 2014
>/usr/share/unity-scopes/manpages/unity_manpages_daemon.py
>-rw-r--r-- 1 root root 8485 jui 23 2013
>/usr/share/unity-scopes/openclipart/unity_openclipart_daemon.py
>-rwxr-xr-x 1 root root 21877 mar 18 2014
>/usr/share/unity-scopes/picasa/unity_picasa_daemon.py
>-rwxr-xr-x 1 root root 24576 mar 18 2014
>/usr/share/unity-scopes/shotwell/unity_shotwell_daemon.py
>-rw-r--r-- 1 root root 8213 mar 28 2014
>/usr/share/unity-scopes/texdoc/unity_texdoc_daemon.py
>-rw-r--r-- 1 root root 8574 jui 23 2013
>/usr/share/unity-scopes/tomboy/unity_tomboy_daemon.py
>-rw-r--r-- 1 root root 8993 jui 23 2013
>/usr/share/unity-scopes/virtualbox/unity_virtualbox_daemon.py
>-rw-r--r-- 1 root root 9967 jui 23 2013
>/usr/share/unity-scopes/yelp/unity_yelp_daemon.py
>-rw-r--r-- 1 root root 11082 jui 23 2013
>/usr/share/unity-scopes/zotero/unity_zotero_daemon.py
>
>--
>You received this bug notification because you are subscribed to the
>bug
>report.
>https://bugs.launchpad.net/bugs/1538471
>
>Title:
> scope-runner-dbus.py assert failure: *** Error in `/usr/bin/python3':
> free(): invalid next size (fast): 0x0000000001ca17b0 ***
>
>Status in libunity package in Ubuntu:
> Confirmed
>
>Bug description:
> No idea what happened.
>
> ProblemType: Crash
> DistroRelease: Ubuntu 16.04
> Package: unity-scopes-runner 7.1.4+15.10.20151002-0ubuntu2
> ProcVersionSignature: Ubuntu 4.3.0-7.18-generic 4.3.3
> Uname: Linux 4.3.0-7-generic x86_64
> ApportVersion: 2.19.4-0ubuntu1
> Architecture: amd64
>AssertionMessage: *** Error in `/usr/bin/python3': free(): invalid next
>size (fast): 0x0000000001ca1...

I had this when I searched the first time for baobab in an upgrade to 16.04.

UbuntuKylin 16.04 have the same problem

I was able to trigger the segfault just by running the scope from a terminal using the command line found in the dbus service activation file. For example:

    /usr/bin/python3 /usr/share/unity-scopes/scope-runner-dbus.py -s info/calculator.scope

When run, I get the following error message:

    *** Error in `/usr/bin/python3': free(): invalid next size (fast): 0x0000000000cb77e0 ***

Attached is a stack trace with symbols for the relevant libraries available. The inner call here is a to the overriden get_scopes() implementation of the Python UnityScopeLoader subclass.

Frames #8 and #9 are the libffi stubs to marshal this function call. Frame #7 is the function that takes the libffi function call data and calls a Python function, converting the arguments as needed.

While frame #6 says it is the same function, it looks to actually be an inlined version of _invoke_state_clear, which is called right at the end of _pygi_closure_handle. So at this point, the Python implementation of get_scopes() has finished running, and it is trying to clean up afterwards.

So, I'm not sure exactly what is causing this. While the crash is occurring in the python3-gi package, I suspect that it is innocent: this particular code path would be hit many times in programs using these bindings. It's behaviour is dependent on the gobject-introspection typelibs though, so I wonder if they've changed.

The libunity code base hasn't changed in any meaningful way for a long time, but there is a new version of Vala in Xenial (0.30.1, compared with 0.28.1 in Wily). It is possible that it did something to change the typelib.

And sure enough. If I copy the /usr/lib/girepository-1.0/Unity-7.0.typelib file from the latest Wily package of gir1.2-unity-5.0 onto my Xenial system, the Python scope runs correctly. I haven't investigated what exactly is different in the typelib or why it changed though.

That also seems to do the trick for manpages:
Hopefully this gets squared away as man pages in help is very useful & a
nice way for users to access man's

On 03/23/2016 05:19 AM, James Henstridge wrote:
> And sure enough. If I copy the
> /usr/lib/girepository-1.0/Unity-7.0.typelib file from the latest Wily
> package of gir1.2-unity-5.0 onto my Xenial system, the Python scope runs
> correctly. I haven't investigated what exactly is different in the
> typelib or why it changed though.
>

So, the XML version of the gir information in /usr/share/gir-1.0/Unity-7.0.gir appears to be identical between the Wily and Xenial, so I think Vala is off the hook.

Instead, it seems to be g-ir-compiler producing different output from the same XML file between Wily and Xenial. The gobject-introspection packages have been updated from 1.44 to 1.46, so the cause is likely somewhere in that batch of changes.

One last comment: I tried downloading upstream pygobject 3.20.0 (which was released two days ago), and the scopes run fine using the Xenial typelib.

So I think the underlying problem is that we've got a problem of version skew, with the versions of gobject-introspection and pygobject currently in Xenial being incompatible. We either need to downgrade gobject-introspection (and rebuild typelibs for any affected packages), or upgrade pygobject.

Not sure if this helps but it appears this problem only occurs on a 64-bit system. I did a Xenial 32-bit installation recently and the Python scopes (I tested calc: and manpages:) worked properly. On a Xenial 64-bit installation, even with the very last updates (especially the recent libunity-core), it still crashes.

After having installed 2 identical VM (PXE + preseed), with the only difference being the architecture (32-bit vs 64-bit), I can now confirm that the Python scopes are working on a 32-bit install and crashing on a 64-bit install, with exactly the same requests made on both sides (calc:1+1, man:calc).

Status changed to 'Confirmed' because the bug affects multiple users.

Thanks for the investigation. I uploaded the new pygobject to fix this.

(@pitti, sorry for doing this without consulting you - I was pinged a few times about this bug and checked the changes which seemed to be bugfix)

I ticked the mark to search for online results in Dash, and immediately searched for something in Dash. The I saw the error message.

This bug was fixed in the package pygobject - 3.20.0-0ubuntu1

---------------
pygobject (3.20.0-0ubuntu1) xenial; urgency=medium

  * New upstream release.
  * Fixes scope-runner-dbus.py crash (LP: #1538471)
  * debian/patches/0001-test_gerror_novalue-Don-t-define-an-error-the-test-d.patch:
    Take patch from upstream bug to fix a test failure.

 -- Iain Lane <email address hidden> Thu, 24 Mar 2016 18:07:32 +0000

> @pitti, sorry for doing this without consulting you

Please don't apologize for doing great work :-) I haven't really worked on pygobject for two years now. Thanks for fixing this!

I confirm the Python scopes are now, after having applied the pygobject update, working on a Xenial 64-bit system and still working (= no regression) on a 32-bit one. Thanks!