abrt version: 1.1.14
Attached file: backtrace
comment: I am actually uncertain as to how reprodusaable this is because I don't recieve .VCF files on a regular basis. This is probably the only one I have recieved in the last 12 months.
reason: Process /usr/libexec/e-addressbook-factory was killed by signal 11 (SIGSEGV)
release: Fedora release 14 (Laughlin)
How to reproduce
1. adding(importing) a .VCF contact to my contacts database
Created attachment 462563 [details]
Thanks for a bug report. Could you check whether your imported contact has a line with UID, please? Because it seems it doesn't. Thanks in advance.
Thread 1 (Thread 18790):
#0 g_variant_is_trusted (value=0x0) at gvariant-core.c:600
#1 0x0018d18f in g_variant_builder_add_value (builder=0xb63ff0a0, value=0x0) at gvariant.c:2932
#2 0x0018ea4a in g_variant_valist_new (str=0xb63ff130, app=0xb63ff14c) at gvariant.c:3928
#3 0x0018ecc9 in g_variant_new_va (format_string=0x9e2055 ")", endptr=0x0, app=0xb63ff14c) at gvariant.c:4083
#4 0x0018ed7f in g_variant_new (format_string=0x9e2053 "(s)") at gvariant.c:4023
#5 0x009d9c78 in e_gdbus_book_complete_add_contact (object=0x9f2d618, invocation=0x9f0b120, out_uid=0x0) at e-gdbus-egdbusbook.c:2713
#6 0x009d55d8 in e_data_book_respond_create (book=0x9f11620 [EDataBook], opid=2, error=0x0, contact=0x0) at e-data-book.c:488
#7 0x009cda92 in _e_book_backend_create_contact (backend=0x9f288a8 [EBookBackendGoogle], book=0x9f11620 [EDataBook], opid=2, vcard=0xa2d7500 "BEGIN:VCARD\r\nVERSION:3.0\r\nFN:Diaspora\r\nN:Diaspora;;;;\r\nPROFILE:VCARD\r\nADR;TYPE=OTHER:;;731 Market Street\\,Floor 3;San Francisco;California;94101;\r\n USA\r\nORG:Diaspora\r\nURL:http://www.joindiaspora.com\r\n"...) at e-book-backend-sync.c:377
#8 0x009d0ac7 in e_book_backend_create_contact (backend=0x9f288a8 [EBookBackendGoogle], book=0x9f11620 [EDataBook], opid=2, vcard=0xa2d7500 "BEGIN:VCARD\r\nVERSION:3.0\r\nFN:Diaspora\r\nN:Diaspora;;;;\r\nPROFILE:VCARD\r\nADR;TYPE=OTHER:;;731 Market Street\\,Floor 3;San Francisco;California;94101;\r\n USA\r\nORG:Diaspora\r\nURL:http://www.joindiaspora.com\r\n"...) at e-book-backend.c:380
#9 0x009d4d0d in operation_thread (data=0x9f2d690, user_data=0x0) at e-data-book.c:115
#10 0x0017c3a1 in g_thread_pool_thread_proxy (data=0x9f20c00) at gthreadpool.c:319
#11 0x00179bd0 in g_thread_create_proxy (data=0x9f2c9f0) at gthread.c:1897
thread = 0x9f2c9f0
#12 0x007b7f19 in start_thread () from /lib/libpthread-2.12.90.so
#13 0x006ccc5e in clone () from /lib/libc-2.12.90.so
It does not appear to have one. Is that a problem I should make the sender aware of?
ADR:;;731 Market Street,Floor 3;San Francisco;California;94101;USA
(In reply to comment #3)
> It does not appear to have one. Is that a problem I should make the sender
> aware of?
Thanks for the update. I thought UID is mandatory, but reading RFC 2426 it turned out it isn't, thus this is evolution bug.
I moved this upstream as . Please see  for any further updates.
Interesting, I cannot reproduce this, I tried to import it through File->Import and also with "Save in Address Book" from the message preview, but no luck, it doesn't want to crash for me.
When looking around the code it seems to me like there was some issue with the address book itself, and it didn't return an error, which lead to the crash. Thus I've few questions:
a) how are you importing this vCard, please?
b) to what address book type are you importing it? (local, Google, LDAP,...)
c) could you try to run the e-addressbook-factory from a console and capture
the output of it, to see what it actually does there, please? You can do that
- make sure evolution is not running, same as e-addressbook-factory
- on one terminal run:
$ /usr/libexec/e-addressbook-factory &>e.log
- on other terminal run:
- then try to reproduce the crash and when it's done review the e.log file
it may show us some interesting things.
Thanks in advance.
The .vcf file was included as a download link in an email. When I clicked the link to download the file, a window popped up on my desktop asking if I want to save it or import it into Evolution's Contacts. I chose import and received a crash notification. Evolution was not running at the time.
After receiving the inquiery about the "uid", I downloaded the file to my desktop to check out the question.
After you told me you couldn't reproduce it, I tried just dbl-clicking on the file to see what kind of behavior I received (without Evolution running). I got the same Evolution import windows as before and I got the same crash notification as I did originally.
I then opened Evolution and imported the .vcf using Import from the menus. The .vcf seemed to be imported properly.
Now that it's been imported once though, I seem to be able to import it as often as I want by dbl-clicking it. As long as Evolution is not running. If Evolution is up and running, dbl-clicking appears to do nothing. I currently have 3 entries in Contacts for Diasporia.
Yup, it works for me without any issue too, after I imported in from the UI :(
What is the addressbook you are importing this to, please? I sit On This Computer/Personal or some Google or WebDAV or...
OS Release: Fedora release 14 (Laughlin)
How to reproduce
when: every time i want to send an email
1. write email
2. send it out
3. certifikate fault comes up
4. press ok, it will delivered
server connection is using ssl, only happens if certificat is less trustable (hint window)
I have Evolution set to where the default address book is my Google one.
Hi Maik, did ABRT choose this bug? Your description doesn't sound like anything with vcf import. What do you mean with "less trustable"?
Also, after change from upstream bug  this may not happen again. And it doesn't. I can reproduce it with actual master when importing to google calendar, the message on e-addressbook-console is:
> libebookbackendgoogle-CRITICAL **: e_book_backend_google_create_contact:
> assertion `priv->service' failed
> libebook-CRITICAL **: e_contact_get_const: assertion `E_IS_CONTACT (contact)'
The second makes sense, it's due to the 'contact' variable being NULL. I'm moving back to the upstream bug. Thanks for the clarification.
*** Bug 663479 has been marked as a duplicate of this bug. ***
*** Bug 704411 has been marked as a duplicate of this bug. ***