GNOME Bugzilla – Bug 741002
Unable to open addressbook with the bbdb (automatic contacts plugin)
Last modified: 2014-12-04 22:01:20 UTC
Created attachment 291950 [details] gdb output Hi, As per request from Milan Crha, I open a separate bug report for this. Original bug report: https://bugzilla.gnome.org/show_bug.cgi?id=734530 I have 3 address books configured, 1 local ('Personal', the default), and 2 Gmail address books. The one configured for automatic contacts is 'Personal'. Attached is the file generated by: gdb --batch /usr/lib/evolution/evolution-addressbook-factory --ex "r -w" --ex "t a a bt" --ex q | tee bt.txt The evolution-addressbook-factory exited normally, after evolution itself segfaulted (probably because of the original bug) Regards, Steven
Thanks for a bug report. The backtrace doesn't show any crash, while I thought it will, to cause the errors on the evolution side (which cause evolution's crash). Is there any delay between the message send and the evolution's crash? That would be the time to get addressbooks' factory backtrace, to see in what state it currently is. Could you try this, please: $ evolution; gdb --batch --ex "t a a bt" \ -pid=`pidof evolution-calendar-factory` &>bt.txt Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only). The command is one long line. It'll run evolution and when the evolution will crash it'll capture backtrace of the running evolution-addressbook-factory, hopefully showing it in some odd state. Debuginfo package for evolution-data-server highly welcome.
Created attachment 292026 [details] evolution-calendar-factory backtrace Hi, Attached the file generated by this command: evolution; gdb --batch --ex "t a a bt" -pid=`pidof evolution-calendar-factory` | tee bt.txt The evolution segfault appears a bit later than I expected, but I'm guessing that adding the new contacts would be an asynchronous process? evolution-calendar-factory itself doesn't segfault. I'll attach the console output from that same evolution session as well. regards, Steven
Created attachment 292027 [details] evolution console output
(In reply to comment #2) > Attached the file generated by this command: > evolution; gdb --batch --ex "t a a bt" -pid=`pidof evolution-calendar-factory` > | tee bt.txt Oops, this is embarrassing. I was talking about the address book factory, but then wrote the command with the calendar factory. My fault, I'm sorry for that. The pidof sub-command should have evolution-addressbook-factory argument instead. > The evolution segfault appears a bit later than I expected, but I'm guessing > that adding the new contacts would be an asynchronous process? That is correct. The time it spends between the message was sent and its crash could be that the address book factory was busy. I noticed in your log from bug #734530 comment #3 this runtime critical warning: > (evolution:3223): evolution-util-WARNING **: name_selector_get_client_cb: > Unable to connect to 'Contacts': Timeout was reached which usually happens when the address book factory is stuck with something and doesn't respond. That's why I wanted to follow-up here. Thinking of it, maybe the reason for that timeout was that the evolution itself was running under valgrind. The later log there shows that the address book finally started properly. If that's true, then my investigation requests to you are useless. The log from comment #3 here doesn't show any timeouts, which brought me to the idea of the uselessness of the investigation. Could I ask you to try to get the backtrace of the addressbook factory instead, just to verify that it works properly? Also, if the delay between send and the crash is long enough, then get the backtrace during that delay too, which should show what the address book does right before the crash of evolution. I suppose it'll show lookups in books marked for autocompletion.
Created attachment 292095 [details] evolution-addressbook-factory backtrace Hi, Correct backtrace this time :) I should have noticed the mistake. As before, I'll add the evolution console log as well. I was looking at these lines: (evolution:3980): evolution-util-WARNING **: name_selector_get_client_cb: Unable to connect to 'Contacts': Failed to obtain an access token for 'Contacts': No credentials found in the keyring It appears 2 times, right when I re-enabled automatic contacts, but those are from my Gmail accounts, not the 'personal' default addressbook that gets selected. This time the segfault appeared while waiting for input of my GPG key's password (I see the evolution windows dissappearing as I typed it in). Looking at your patch from the previous bug report... since you're inside the 'if' block, that means an error has occurred, right? So why is the error message '(null)'? Also, looking at my evolution console logs, shouldn't the segfault occur sooner, since I'm seeing the message from the patch twice, as well as another one? From the original report: """ ** (evolution:6621): WARNING **: bbdb: Failed to get addressbook client : (null) ** (evolution:6621): WARNING **: bbdb: Failed to get addressbook client : (null) sending : EHLO pc-steven sending : STARTTLS ** (evolution:6621): WARNING **: bbdb: Failed to add new contact: (null) sending : EHLO pc-steven [New Thread 0x7fff167fc700 (LWP 6715)] [New Thread 0x7fff59ffb700 (LWP 6729)] [New Thread 0x7fff2d6de700 (LWP 6730)] [Thread 0x7fff167fc700 (LWP 6715) exited] Program received signal SIGSEGV, Segmentation fault. """ So I currently don't think your patch solves that particular segfault, but may very well solve another problem. I didn't have a chance to test it though. Disclaimer: I'm not familiar with the evolution code and it's been years since I wrote any C/C++ code. Regards, Steven
Created attachment 292096 [details] evolution console output
Thanks for the update. The first message with "Failed to get addressbook client :" shows a correct GError, then this is freed, but the variable was not nullified. That's what the patch fixes, thus the "GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory." is not triggered. When this GLib warning happens then the passed-in GError is left as is, in this case pointing to an already freed memory, which can point to anything. It: a) should crash on a dereference of the pointer to a freed memory; b) can point to an overwritten memory, which is NULL in your case (the error->message is NULL, where the 'error' is the freed memory). After this the freed memory is freed again, which can free something what is part of another object, thus it crashes only after the other object is accessed, which can happen sooner or later. In other words, the fix is correct. The addressbook factory backtrace shows a free of the backend, due to the evolution's crash. That is correct, as far as I can tell. Thanks for your help with the confirmation of this.
Hi, Thank you once again for the patch and giving me a better look on things. You are of course correct, it is me who needs a vacation :) Regards, Steven