Red Hat Bugzilla – Bug 867149
[abrt] gnome-boxes-3.6.1-1.fc18: strlen: Process /usr/libexec/gnome-boxes-search-provider was killed by signal 11 (SIGSEGV)
Last modified: 2012-11-23 02:47:56 EST
Version-Release number of selected component:
libreport version: 2.0.16
:Thread no. 1 (8 frames)
: #0 strlen at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:50
: #1 g_strdup at gstrfuncs.c:363
: #2 boxes_search_provider_GetResultMetas_co at /extra-data/checkout/gnome/gnome-boxes/src/gnome-boxes-search-provider.vala:116
: #3 g_simple_async_result_complete at gsimpleasyncresult.c:775
: #4 complete_in_idle_cb_for_thread at gsimpleasyncresult.c:843
: #9 g_main_context_iteration at gmain.c:3351
: #10 g_application_run at gapplication.c:1620
: #11 _vala_main at /extra-data/checkout/gnome/gnome-boxes/src/gnome-boxes-search-provider.vala:197
Created attachment 628419 [details]
Created attachment 628420 [details]
Created attachment 628421 [details]
Created attachment 628422 [details]
Created attachment 628423 [details]
Created attachment 628424 [details]
Created attachment 628425 [details]
Created attachment 628426 [details]
Created attachment 628427 [details]
Created attachment 628428 [details]
Created attachment 628429 [details]
/extra-data/checkout/gnome/gnome-boxes/src/gnome-boxes-search-provider.vala:116 is foreach (var id in ids), and vala indeed generates a g_strdup when doing the iteration. As g_strdup handles NULL string, this probably means we ended up with an invalid string in this list.
I couldn't spot something wrong in there though :( Any chance you can catch this crash in valgrind?
Any chance you can catch this crash in valgrind?
I dont know what that means :( I am new to fedora and new on repporting bugs.
Ok, never mind then, thanks for the bug report and your answer ;) Is it an issue you can reproduce whenever you want, or did it occur only once?
I get it when I do a reboot. It started after latest update where gnome-boxes were updated.
I dosent seem to have any impact on my system, as it is working as usaual.
Just updated gnome-boxes to 18.104.22.168-1.fc18 and no ABRT when rebooting.
*** Bug 868186 has been marked as a duplicate of this bug. ***
Created attachment 632271 [details]
+ /* We have to put this in a separate file because vala does not seem to honor "owned"
should be 'separate method'
Did I understand correctly that the issue is that we are calling async methods from the dbus callback, and that vala does not copy the callback arguments in this case, which means they don't stay alive for the whole duration of the async method calls, hence the use of 'owned' to force the copy? If yes, ACK, otherwise I'll have to go back reviewing ;)
> Did I understand correctly that the issue is that we are calling async methods
> from the dbus callback, and that vala does not copy the callback arguments in
> this case, which means they don't stay alive for the whole duration of the
> async method calls, hence the use of 'owned' to force the copy?
Yes, this is exactly the problem, which then gets extra complicated by a valac bug that makes calling methods with "owned" arguments not work in the generated dbus wrapper method.
Pushed to git, will be fixed in next minor release.
*** Bug 872970 has been marked as a duplicate of this bug. ***
gnome-boxes-3.6.2-1.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gnome-boxes-3.6.2-1.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
gnome-boxes-3.6.2-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.