Hide Forgot
Description of problem: Upon starting evolution for the first time since upgrade, the migration fails when it tries to upgrade list contacts. It always fails at exactly 12%. See attachment for screenshot of where it gets stuck. Version-Release number of selected component (if applicable): How reproducible: Happens every time Steps to Reproduce: 1.Try migrating list contacts 2.Fails at 12% for me. 3. Actual results: Gets stuck Expected results: Should proceed Additional info: Why oh why did I upgrade?
Created attachment 107682 [details] screenshot of where things get hung up.
This bug is rather troublesome - I can't get evolution past it so I can't use evolution at all. Does anyone know of a way to just get it to move on without trying migration?
Please can you try running evolution from a command line, and see if any additional debug output appears there. Can you also see if the evolution-data-server-1.0 process is still running when the migration gets stuck? Thanks.
The output of evolution-2.0 from the commandline is below: ============================== loading error file /usr/share/evolution/2.0/errors/calendar-errors.xml loading error file /usr/share/evolution/2.0/errors/mail-errors.xml loading error file /usr/share/evolution/2.0/errors/addressbook-errors.xml loading error file /usr/share/evolution/2.0/errors/filter-errors.xml loading error file /usr/share/evolution/2.0/errors/shell-errors.xml loading error file /usr/share/evolution/2.0/errors/mail-composer-errors.xml loading error file /usr/share/evolution/2.0/errors/e-system-errors.xml (evolution-2.0:10233): e-error.c-WARNING **: No parent set, or default parent available for error dialog (evolution-2.0:10233): e-error.c-WARNING **: No parent set, or default parent available for error dialog addressbook_migrate (1.4.0) trying to migrate from /home/dmk/evolution/addressbook-sources.xml found 2 contact servers to migrate trying to migrate completion folders ========================= This last message happens somewhat before the actual freeze. Yes the data server is running when the freeze happens: /usr/libexec/evolution-data-server-1.0 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_InterfaceCheck --oaf-ior-fd=50
Re comment #4; the last debug message you get is from the function migrate_completion_folders, which happens before the dialog is launched. Evolution appears to be stuck somewhere inside the function migrate_contact_lists_for_local_folders (context, on_this_computer); So it looks like it's getting stuck somewhere inside this latter function (without outputting any more debug info) Please can you stop evolution and then restart it at at terminal by typing: strace evolution This will generate large amounts of debug information; please can you attach it (or the last few pages thereof) to this bug report. Thanks
Thanks for taking an interest in this. This bug is definitely a show stopper for me, so I appreciate the time. The strace output will be attached shortly.
Created attachment 107749 [details] compressed strace of evolution run with the problem
Is there anything else I can do to help debug this problem? I tried looking at the strace info, but it was over my head.
Please can you run: gconftool-2 --get /apps/evolution/addressbook/sources What architecture are you running on?
Created attachment 107868 [details] output of "gconftool-2 --get /apps/evolution/addressbook/sources >addressbook_sources.txt" Attached is the output from gconftool-2. I am running on a Dell Inspiron 1150 with a pentium 4 processor. I am using FC3 with all the updates.
Try running: evolution --force-shutdown then try making a backup copy of the file: ~/.gconf/apps/evolution/addressbook/%gconf.xml Then run gconf-editor, and browse to /apps/evolution/addressbook select the "source" key and select "Edit key...". You should see a list containing two values that look like XML files, one for "On this Computer", one for "LDAP servers". Try deleting the second one. Now try running evolution again, and see if the migration gets any further. If this again fails, go back to the top, try deleting the other value, and try again.
OK. I did as you said. I first removed the LDAP entry and reran. It got further - 30% before it hung. Then I went to edit the key again and noticed that it had put back the LDAP entry by itself. I assume this is normal. So I then deleted the first local computer entry, leaving the ldap entry and reran. 66% this time. So then I removed them both and this got me back to 12% again. Then I tried removing all ldap entries from the file ~/evolution/addressbook-sources.xml (I don't really care about them). This made no change, even if I removed the LDAP entry in gconf, so it appears likely that the problem is in moving over the local contacts.
Please can you install the evolution-debuginfo package, then run evolution inside gdb, and generate a stack backtrace at the point where it gets stuck. See this page for more information on how to do this: http://fedora.linux.duke.edu/wiki/index.cgi/StackTraces I believe it's stuck somewhere inside a loop inside migrate_contact_lists_for_local_folders, so hopefully a backtrace will reveal where.
Created attachment 108014 [details] Back trace of evolution when it gets stuck from gdb Here is the backtrace you wanted. I started the file a bit before it gets stuck just so you would have some context. From "thread apply all bt" onward is the trace.
Please install the evolution-data-server-debuginfo and evolution-debuginfo packages, and regenerate the backtrace you supplied in comment #14. You should be able to find these packages here: ftp://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/debug/
Created attachment 108015 [details] New back trace with correct debuginfo rpm's By mistake I installed the rawhide debuginfo rpms, which probably explains some of the problems in that last trace. I also added the data server debuginfo rpm for this trace.
Was this last backtrace ok?
I updated to evolution-2.0.3-2, which did not fix the problem.
Hi. I have had the same problem on Debian, I think. Here is the bug report and my suggestion for a turnaround : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288262
Thanks for the info. Your solution of moving the evolution directory after mail import will get the mail, but unfortunately the information that I have in my contacts is really important to me and I would like to hold on to it. Apparently fixing this bug is a target for 2.0.4, so I am hoping that will come out relatively soon.
My final workaround for this was, following Olivier's comments, to first let evolution move over all the old mail. It would then get stuck at the contacts migration. Then I forced evolution to shutdown with: evolution --force-shutdown Then I was able to copy my old evolution contacts folder to a redhat 9 machine and open the contacts there. I exported those contacts as a vcf file. I copied that vcf file back to the FC3 machine. Then I removed the half done contacts migration from the new .evolution folder: rm ~/.evolution/addressbook/local/system/* rm ~/.evolution/addressbook/local/1204953917.6377.0\@me Then I restarted evolution. Click continue and wait. Then I had to delete some extraneous contacts folders. Then I imported the vcf file that I created earlier.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
Closing per lack of response to previous request for information. This bug was originally filed against a much earlier version of Fedora Core, and significant changes have taken place since the last version for which this bug is confirmed. Note that FC3 and FC4 are supported by Fedora Legacy for security fixes only. Please install a still supported version and retest. If it still occurs on FC5 or FC6, please reopen and assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier.