Creating duplicate contact via edit crashes Evolution

Bug #846159 reported by Jim Patterson on 2011-09-10
22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
evolution (Ubuntu)
Undecided
Unassigned

Bug Description

I was trying to fix a mis-spelled contact, and changed the name to the correct name. I already have another contact entry under the correct name in the contact list with different information attached. As soon as I Apply the corrected contact entry, Evolution dies, with no warning or message box.

The contact list is a view onto my GMail contacts.

No changes end up being applied. When I bring up Evolution again, the unedited contact still exists.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: evolution 3.1.5-0ubuntu2
ProcVersionSignature: Ubuntu 3.0.0-10.16-generic 3.0.4
Uname: Linux 3.0.0-10-generic x86_64
NonfreeKernelModules: fglrx
Architecture: amd64
CheckboxSubmission: fc2d0c1a9f7a9107c5104c45d6ee1b22
CheckboxSystem: 4ed15c40009aa6f7770f606350a390a2
Date: Fri Sep 9 21:53:39 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
ProcEnviron:
 LANGUAGE=en_CA:en
 PATH=(custom, user)
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: evolution
UpgradeStatus: Upgraded to oneiric on 2011-09-05 (4 days ago)

My suggestion as to the cause of this crash may be off base. I tried to fix the entries another way, by transferring the information from one entry to another, then deleting the first entry. As soon as I Apply a change on the other entry, it crashed. Perhaps it's a more general GMail contact bug. I'll attempt to get some more extensive debug info on the crash.

I realized that I have unapplied updates. I've done so, to 3.1.91-0ubuntu1, but it still happens.

Attaching gdb traceback and --debug log, in case it helps.

Output from 'evolution --debug=...'

Seems my second test case is more similar to the first than I thought. It was still creating a duplicate key, just on another field (home email). I did not actually remove the field from the first record when doing that - if I do delete it before setting it in the second, things are fine. So it does in fact seem to be linked to handling a duplicate entry, which it seems can occur in any of several indeed fields.

Launchpad Janitor (janitor) wrote :

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

Changed in evolution (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers