GNOME Bugzilla – Bug 703952
[xls] Text encoding problem
Last modified: 2018-05-22 14:00:33 UTC
Segfault in __memcpy_ssse3_back when exporting to xls. Git versions of glib, goffice, gnumeric, libgsf and libxml2. Test case: http://jutaky.com/fuzzing/gnumeric_case_8646_725_2xls.gnumeric Segfault triggered by opening the test case with gnumeric and using Save As and saving as xls. Alternatively running "ssconvert gnumeric_case_8646_725_2xls.gnumeric out.xls". Backtrace from ssconvert: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff335d650 in __memcpy_ssse3_back () from /usr/lib/libc.so.6 (gdb) bt
+ Trace 232219
-- Juha Kylmänen Research Assistant, OUSPG
The issue is that in msole_metadata_write_string we are converting a string using g_convert_with_iconv but fail to check whether the conversion is successful. In this case the function returns a null pointer with bytes_written=1. I don't know how to fix this correctly.
Crash fixed. Keeping open because this happened in the writing phase. Why do we have bogus metadata there?
Morten, what do you mean with "bogus metadata"? If you check txt with g_utf8_validate you see that it is indeed valid, i.e. g_utf8_validate (txt, -1, NULL) returns true. The problem is that the conversion from UTF8 to CP1252 fails, not that the UTF8 code is invalid.
Hmm... Not bogus then. That, of course, just leaves the question of why CP1252 is being used. And if there's anything we can do about it.
When libreoffice saves this file as xls it seems to use UTF-8 for most parts and CP1252 for the first part. At least according to gsf_msole_iconv_open_codepage_for_import when we open that file.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/226.