Version: (using KDE 3.5.9) Installed from: Debian testing/unstable Packages When creating "Custom fields" for contacts, field names containing non-ASCII characters are mishandled, and this leads to crashes in KAddressBook and even in KMail and Kopete. To reproduce: 1, Create a new contact. 2, Create a custom field (with default settings). Include a non-ASCII character in the name of the field. Mine will be simply "á". Write some text in the field. 3, Save the addressbook. The std.vcf file now contains something like: -------------------------------- BEGIN:VCARD^ CLASS:PUBLIC^ FN:A A^ N:A;A;;;^ NAME:A A^ UID:ttfu3GI0KM^ VERSION:3.0^ X-KADDRESSBOOK-á:bogus field^ END:VCARD^ -------------------------------- 4, Exit KAddressBook. 5, Start KAddressBook, modify something in the addressbook, save and exit. The std.vcf file now contains: -------------------------------- X-KADDRESSBOOK-á:bogus field^ -------------------------------- 6, Repeat the last step. -------------------------------- X-KADDRESSBOOK-Ã.¡:bogus field^ -------------------------------- 7, Repeat the last step. -------------------------------- X-KADDRESSBOOK-Ã.Â.Ã.¡:bogus field -------------------------------- The number of "Ã."s is doubled every time. My std.vcf has grown >300M, causing >1G of memory usage and eventually std::bad_alloc crashes in KAddressBook, KMail and Kopete. Things are worse if the user deletes the custom field, because the bogus line remains in the file and grows while the user does not even know the bogus custom field exists. The user is likely to delete the custom field as it is mis-read from the file and its value is not shown in the contact's Custom field list.
I can confirm this bug in KDE 3.5.9 installed from Ubuntu packages. A 188kb vcard file grew to over 1.3 MB, which would crash Kontact (and KAddressBook if opened seperatly), and would sometimes lock up the whole OS. In my case, Hebrew characters were turned into this: ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ (repeats) I cannot use Kontact until this is fixed. Read: I must downgrade my OS until this is fixed. There is no workaround, as I have much critical data in the custom fields.
I found a workaround: 1) Close Kontact and KAddressBook. 2) Open the original, non-damaged vcf file in Kate. 3) Replace all instances of "X-KADDRESSBOOK-<customFieldNameUTF8>" with "X-KADDRESSBOOK-<customFieldNameASCII>". Note that the new field name must be all lower-case ASCII letters. ASCII to not get hit with the bug, and lower case to have your data show up automatically. For some reason I was having trouble with uppercase letters (details below). 4) rm ~/.kde/share/config/kaddressbookrc and /.kde/share/apps/kabc/ 5) Open Kontact and import the modified file. 6) Open a contact for editing and create the custom fields. 7) Close the contact. This was easier than running Kontact in an older OS in VirtualBox. I can live with the field names in ASCII for now.
Something similar occures with included images of the contacts - the Line PHOTO;ENCODING=b;TYPE=image/jpeg:/9j/4 ... enlarges sometimes after opening the std.vcf file with kadressbook.
I confirm this bug on Gentoo Linux stable kde-base/kdepim-3.5.9-r1. It caused KMail to use over 1.5 GiB of RAM at start-up, about 850 MiB at run-time and over 2 GiB at shutdown and finally crash with std::bad_alloc. Also in ~/.kde/share/apps/kabc there have been many files with funny names: std.vcf std.vcf__19 std.vcf__7 std.vcf__0 std.vcf_2 std.vcf__8 std.vcf_1 std.vcf__2 std.vcf__9 std.vcf__1 std.vcf__20 std.vcfBfZUPb.new std.vcf__11 std.vcf2pOIrc.new std.vcfCFUa6b.new std.vcf__12 std.vcf_3 std.vcfgnTZMb.new std.vcf__13 std.vcf__3 std.vcfLkHHsa.new std.vcf__14 std.vcf_4 std.vcfS16Mtb.new std.vcf__15 std.vcf_5 std.vcfusBg2a.new std.vcf__16 std.vcf_6 std.vcfyPAvYa.new std.vcf__17 std.vcf__6 std.vcf__18 std.vcf_7 which altogether consumed over 1.6 GiB disk space. The workaround works for me. Now my std.vcf is only 6128 bytes and KMail uses at most 33 MiB of RAM.
I can confirm this bug. It makes kaddressbook, korganizer, kopete or korgac consume all the memory (Mem + Swap) on a 4-Gig Mem + 2 GigSwap Machine until the process is killed from OS.
Hej, that has been fixed in recent versions (3.5 and 4.0) Ciao, Tobias
Can someone independently confirm that the bug is not present in KDE 3.5.10? I am unable to experiment at the moment. Thanks.
The development of the old KAddressBook will be discontinued for KDE 4.4. Since the new application has the same name, but a completly new code base we close all bug reports against the old version and ask the submitters to resend there reports against the new product.