GNOME Bugzilla – Bug 660519
goa-daemon segfaults with configured accounts
Last modified: 2012-08-14 13:10:02 UTC
goa-daemon 3.2.0.1 segfaults as soon as there are accounts configured (accounts.conf from 'earlier' installs...) Backtrace: (replaced my email address with <my gmail address here>) Program received signal SIGSEGV, Segmentation fault. 0x00007ffff65e6c0f in __strlen_sse42 () from /lib64/libc.so.6 (gdb) bt full
+ Trace 228649
A debugging session is active. Inferior 1 [process 11685] will be killed. Quit anyway? (y or n) y
Do you still have the ~/.config/goa-1.0/accounts.conf that was causing the crashes? There are no secrets (like passwords) in this file.
Created attachment 210648 [details] My olf accounts.conf
Old file uploaded... did not try if with current goa it would still crash.
goa doesn't support twitter -> Ubuntu bug ?
It's well possible that this file was from a time that the twitter backend was enabled in the openSUSE builds of g-o-a (which, yes, was in the first versions of g-o-a an option at least... never worked though). Either way: crashing on that is a no-go! So I don't agree on claiming it to be a downstream bug.
GOA does support Twitter, but being a desktop application it is hard for us to carry a secret key as compared to Web applications. Therefore all services requiring such secrets (Twitter being one) were disabled by default and their keys removed. commit c16341e940baa65f6f743596eba1d33aef7a8cdf Author: David Zeuthen <davidz@redhat.com> Date: Tue May 31 11:33:14 2011 -0400 Strip out API keys and disable services without API keys This leaves us with only the Google provider. Other providers can be added back in the future once TOS etc. for the provider in question have been properly reviewed. Signed-off-by: David Zeuthen <davidz@redhat.com> (Recently it has been possible to use Facebook and Windows Live without carrying any secrets alongwith Google.)
(In reply to comment #3) > Old file uploaded... did not try if with current goa it would still crash. Sorry for the delay. I tried to reproduce the crashes on current (ie. 3.5.x) GOA and failed. Given that I have not touched this part of the code in the recent past, and that the bug was filed against 3.2.x, I suspect that this got quite a while ago. I am closing this, but feel free to reopen if you manage to reproduce it. Thanks for the report, and, once again, sorry for the delayed response.