GNOME Bugzilla – Bug 683817
Can't properly convert UCS2 string with \241 to UTF-8
Last modified: 2012-09-11 21:35:32 UTC
This appears to be reproducible quite well with Orange in Spain. " There is a problem with the charset, which finally leads to a SIGSEGV in g_utf8_validate called from parse_operator. The modem is a Bus 002 Device 003: ID 12d1:1001 Huawei Technologies Co., Ltd. E169/E620/E800 HSDPA Modem Kernel: 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux What happens: parse_operator gets called parse_operator (reply=0x674cc0 "+COPS: 0,0,\"Orange\241\",2", cur_charset=MM_MODEM_CHARSET_UCS2) at mm-generic-gsm.c:2856 after the regexep, correctly (gdb) p operator $1 = 0x67e2e0 "Orange\241" However, "Orange\241" is not UCS2 and therefore operator = mm_charset_take_and_convert_to_utf8 (operator, MM_MODEM_CHARSET_UCS2); returns 0x0 ! The variable "operator" is not being checked and this leads to a call of g_utf8_validate (str=0x0 (operator), max_len=-1, end=0x0) g_utf8_validate then hits the SIGSEGV. "
commit e07c2162d66ab1a2e938db48744fc00afd29c272 Author: Dan Williams <dcbw@redhat.com> Date: Tue Sep 11 16:36:16 2012 -0500 core: better handling of non-UCS2 conversions that should be UCS2 (bgo #683817) Some modems return the +COPS operator name in hex-encoded current character set (as set with +CSCS). Others return the operator name in ASCII when set to UCS2, while yet others return the ASCII name with trash at the end (*cough* Huawei *cough*). Handle that better by not crashing.