While using Evolution menus to export the address book, it's only possible to save in VCF format, so I had to go to the command line to export it to CSV. Every time I run I get a backtrace. It does seem to be exporting data correctly, but I don't know what causes the error, or what are the consequences. $ /usr/libexec/evolution/2.12/evolution-addressbook-export --format=csv --output=file.csv (evolution:3722): GLib-CRITICAL **: g_strv_length: assertion `str_array != NULL' failed *** glibc detected *** /usr/libexec/evolution/2.12/evolution-addressbook-export: free(): invalid pointer: 0x004a9824 *** ======= Backtrace: ========= /lib/libc.so.6[0xb74b16] /lib/libc.so.6(cfree+0x90)[0xb78030] /lib/libglib-2.0.so.0(g_free+0x31)[0x2785f1] /usr/libexec/evolution/2.12/evolution-addressbook-export[0x8049b98] /usr/libexec/evolution/2.12/evolution-addressbook-export[0x8049e31] /usr/libexec/evolution/2.12/evolution-addressbook-export[0x8049ec4] /usr/libexec/evolution/2.12/evolution-addressbook-export[0x804a0c6] /usr/libexec/evolution/2.12/evolution-addressbook-export[0x804a3c7] /usr/libexec/evolution/2.12/evolution-addressbook-export[0x8049545] /lib/libc.so.6(__libc_start_main+0xdc)[0xb21dec] /usr/libexec/evolution/2.12/evolution-addressbook-export[0x8049261] ======= Memory map: ======== 00110000-001a0000 r-xp 00000000 fd:00 1401028 /usr/lib/libgnomeui-2.so.0.1600.0 001a0000-001a3000 rwxp 0008f000 fd:00 1401028 /usr/lib/libgnomeui-2.so.0.1600.0 001a3000-001a4000 rwxp 001a3000 00:00 0 001a4000-001d4000 r-xp 00000000 fd:00 1394638 /usr/lib/libssl3.so 001d4000-001d6000 rwxp 00030000 fd:00 1394638 /usr/lib/libssl3.so 001d6000-001fb000 r-xp 00000000 fd:00 1395170 /usr/lib/libsmime3.so 001fb000-001fd000 rwxp 00025000 fd:00 1395170 /usr/lib/libsmime3.so 001fd000-00212000 r-xp 00000000 fd:00 1394344 /usr/lib/libnssutil3.so 00212000-00215000 rwxp 00014000 fd:00 1394344 /usr/lib/libnssutil3.so 00215000-00217000 r-xp 00000000 fd:00 1389646 /usr/lib/libplds4.so 00217000-00218000 rwxp 00002000 fd:00 1389646 /usr/lib/libplds4.so 00218000-0021c000 r-xp 00000000 fd:00 1390829 /usr/lib/libplc4.so 0021c000-0021d000 rwxp 00003000 fd:00 1390829 /usr/lib/libplc4.so 0021d000-00226000 r-xp 00000000 fd:00 852014 /lib/libnss_files-2.5.so 00226000-00227000 r-xp 00008000 fd:00 852014 /lib/libnss_files-2.5.so 00227000-00228000 rwxp 00009000 fd:00 852014 /lib/libnss_files-2.5.so 00246000-002e3000 r-xp 00000000 fd:00 854964 /lib/libglib-2.0.so.0.1200.3 002e3000-002e4000 rwxp 0009c000 fd:00 854964 /lib/libglib-2.0.so.0.1200.3 002e6000-00305000 r-xp 00000000 fd:00 854968 /lib/libexpat.so.0.5.0 00305000-00307000 rwxp 0001e000 fd:00 854968 /lib/libexpat.so.0.5.0 00309000-0032e000 r-xp 00000000 fd:00 1382645 /usr/lib/libpng12.so.0.10.0 0032e000-0032f000 rwxp 00024000 fd:00 1382645 /usr/lib/libpng12.so.0.10.0 00331000-00334000 r-xp 00000000 fd:00 1392339 /usr/lib/libXrandr.so.2.0.0 00334000-00335000 rwxp 00002000 fd:00 1392339 /usr/lib/libXrandr.so.2.0.0 00337000-00340000 r-xp 00000000 fd:00 1392351 /usr/lib/libXcursor.so.1.0.2 00340000-00341000 rwxp 00008000 fd:00 1392351 /usr/lib/libXcursor.so.1.0.2 00343000-00345000 r-xp 00000000 fd:00 1390698 /usr/lib/libXinerama.so.1.0.0 00345000-00346000 rwxp 00001000 fd:00 1390698 /usr/lib/libXinerama.so.1.0.0 00346000-0037c000 r-xp 00000000 fd:00 1389634 /usr/lib/libnspr4.so 0037c000-0037d000 rwxp 00036000 fd:00 1389634 /usr/lib/libnspr4.so 0037d000-0037f000 rwxp 0037d000 00:00 0 00390000-003a6000 r-xp 00000000 fd:00 854979 /lib/libselinux.so.1 003a6000-003a8000 rwxp 00015000 fd:00 854979 /lib/libselinux.so.1 003aa000-003bd000 r-xp 00000000 fd:00 854973 /lib/libnsl-2.5.so 003bd000-003be000 r-xp 00012000 fd:00 854973 /lib/libnsl-2.5.so 003be000-003bf000 rwxp 00013000 fd:00 854973 /lib/libnsl-2.5.so 003bf000-003c1000 rwxp 003bf000 00:00 0 003c3000-003ca000 r-xp 00000000 fd:00 1397758 /usr/lib/libpopt.so.0.0.0 003ca000-003cb000 rwxp 00006000 fd:00 1397758 /usr/lib/libpopt.so.0.0.0 003cd000-003d0000 r-xp 00000000 fd:00 854971 /lib/libcap.so.1.10 003d0000-003d1000 rwxp 00002000 fd:00 854971 /lib/libcap.so.1.10 003d3000-003d7000 r-xp 00000000 fd:00 854974 /lib/libgthread-2.0.so.0.1200.3 003d7000-003d8000 rwxp 00003000 fd:00 854974 /lib/libgthread-2.0.so.0.1200.3 003da000-00414000 r-xp 00000000 fd:00 854972 /lib/libdbus-1.so.3.2.0 00414000-00415000 rwxp 00039000 fd:00 854972 /lib/libdbus-1.so.3.2.0 00417000-00426000 r-xp 00000000 fd:00 854977 /lib/libresolv-2.5.so 00426000-00427000 r-xp 0000e000 fd:00 854977 /lib/libresolv-2.5.so 00427000-00428000 rwxp 0000f000 fd:00 854977 /lib/libresolv-2.5.so 00428000-0042a000 rwxp 00428000 00:00 0 00454000-0047b000 r-xp 00000000 fd:00 1382327 /usr/lib/libedataserver-1.2.so.7.1.0 0047b000-0047c000 rwxp 00027000 fd:00 1382327 /usr/lib/libedataserver-1.2.so.7.1.0 0047e000-004b0000 r-xp 00000000 fd:00 1392369 /usr/lib/libebook-1.2.so.9.1.0 004b0000-004b4000 rwxp 00032000 fd:00 1392369 /usr/lib/libebook-1.2.so.9.1.0 004b6000-00508000 r-xp 00000000 fd:00 1391348 /usr/lib/libcamel-1.2.so.0.0.0 00508000-0050b000 rwxp 00052000 fd:00 1391348 /usr/lib/libcamel-1.2.so.0.0.0 0050d000-00538000 r-xp 00000000 fd:00 1397750 /usr/lib/libedataserverui-1.Aborted
Correction, the data is not fully exported. There are a lot of entries missing.
(Looking at this out of "bug hunting" curiosity. Not sure what version this was reproduced under, assuming it's evolution-2.12.3-8.el5_2.3) I can reproduce the "g_strv_length: assertion" without much effort. However it's unclear whether or not it has anything to do with the invalid pointer. A core from a crash would help, but from the description: ... /usr/libexec/evolution/2.12/evolution-addressbook-export[0x8049b98] /usr/libexec/evolution/2.12/evolution-addressbook-export[0x8049e31] /usr/libexec/evolution/2.12/evolution-addressbook-export[0x8049ec4] /usr/libexec/evolution/2.12/evolution-addressbook-export[0x804a0c6] /usr/libexec/evolution/2.12/evolution-addressbook-export[0x804a3c7] /usr/libexec/evolution/2.12/evolution-addressbook-export[0x8049545] /lib/libc.so.6(__libc_start_main+0xdc)[0xb21dec] /usr/libexec/evolution/2.12/evolution-addressbook-export[0x8049261] ... Execution was 5 (6?) functions deep from main() before a problem in the export code, 6 (7?) if the problem is within glib. Assuming the root of the problem is not w/in glib, since the crash happens after partial output, my counting puts execution in e_contact_to_csv() evolution-2.12.3/addressbook/tools/evolution-addressbook-export-list-cards.c line 449 (somewhere). I can see a few possible invalid g_free()'s. AFAIK, the assertion message is coming from an empty (e.g. {"",\0}), or invalid strv array passed to g_strjoinv() at line 466: aline = g_strjoinv (COMMA_SEPARATOR, field_value_array); which implies field_value_array was malformed by e_contact_csv_get(). I'm not sure whether or not to continue along this debug-line or if something above is wrong. Any feedback?
Notes on stack: This must be main(): /usr/libexec/evolution/2.12/evolution-addressbook-export[0x8049545] This must be action_list_cards_init(&actctx): /usr/libexec/evolution/2.12/evolution-addressbook-export[0x804a3c7] This must be action_list_cards(contacts, p_actctx) b/c reporter indicated only a partial export was written to file before crash: /usr/libexec/evolution/2.12/evolution-addressbook-export[0x804a0c6] This must be output_n_cards_file(outputfile, contacts, length, 0, format) b/c the next call closes the file (i.e. all contents would have been written) /usr/libexec/evolution/2.12/evolution-addressbook-export[0x8049ec4] This could be e_contact_csv_get_header_line(pre_defined_fields), g_list_nth_data(contacts, i), or e_contact_get_csv(contact, pre_defined_fields) /usr/libexec/evolution/2.12/evolution-addressbook-export[0x8049e31] This one is a mystery to me at this point: /usr/libexec/evolution/2.12/evolution-addressbook-export[0x8049b98]
I'm doubting [0x8049e31] is e_contact_csv_get_header_line since reporter indicated more than one line was output. It can't be g_list_nth_data() b/c crash didn't happen in glib code from this frame (the next one). Therefor, it must be e_contact_get_csv(contact, pre_defined_fields). This means [0x8049b98] must be e_contact_to_csv(contact, csv_all_fields) since e_contact_get_csv() is really just a kind of "wrapper". There are only two calls to g_free in that function. The first one frees elements of the contact field value array, the other free's the array itself. The former case suggests a problem with e_contact_csv_get(contact, csv_field) returning something invalid (from switch(csv_field) or from escape_string()). The later case (freeing the array variable) seems less likely, unless the g_new0() call failed.
Actually, if I instrument one of the function calls made from within e_contact_csv_get() I can produce a similar glibc stack trace (WRT correct number of frames). Looking at those calls, starting with e_contact_address_free() for the hell of it.
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.
This bug being fixed is no-longer important for me in my current role. If it's important to anyone else, please speak up and explain.
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).