Bug #16069 Updated: ICONV transliteration failure

From: Date: Sat, 06 Jul 2002 23:28:46 +0000
Subject: Bug #16069 Updated: ICONV transliteration failure
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-13339@lists.php.net to get a copy of this message
ID: 16069 Updated by: sniper@php.net Reported By: readjust@deneb.freemail.ne.jp -Status: Feedback +Status: Verified Bug Type: ICONV related Operating System: win32, Linux -PHP Version: 4.1.2 +PHP Version: 4.3.0-dev New Comment: Not fixed. (updated version too) Previous Comments: ------------------------------------------------------------------------ [2002-07-05 16:39:54] readjust@deneb.freemail.ne.jp I have just tried again with the HEAD. -------------------------------- $ ./buildconf $ ./configure --with-iconv=/usr/lib \ --prefix=/home/koizumi/local $ make $ make install $ /home/koizumi/local/bin/php -q test.php (13 lines printed) Segmentation fault -------------------------------- Backtrace: #0 0x401f2e8f in chunk_free (ar_ptr=0x402a6620, p=0x1c775d9f) at malloc.c:3225 #1 0x401f2bf4 in __libc_free (mem=0x81d1a48) at malloc.c:3154 #2 0x40035602 in libiconv_close () from /usr/lib/libiconv.so.2 #3 0x08062fe9 in php_iconv_string (in_p=0x81d17cc "", in_len=32, out=0xbfffd060, out_len=0xbfffd064, in_charset=0x81d66b4 "CP932", out_charset=0x81d0db4 "EUC-JP//TRANSLIT", err=0xbfffd068) at /home/koizumi/src/php4/ext/iconv/iconv.c:194 #4 0x0806308f in php_if_iconv (ht=3, return_value=0x81d0d24, this_ptr=0x0, return_value_used=1) at /home/koizumi/src/php4/ext/iconv/iconv.c:292 (gdb) select-frame 3 (gdb) print out_size $1 = 144 (gdb) print out_left $2 = 0 -------------------------------- Now I realized that what is to blame for segv. ------------------------------------------ *out_len = out_size - out_left; out_buffer[*out_len] = '\0'; icv_close(cd); ------------------------------------------ Here's the patch. (I'll resend this one if you think it better) =================================================================== RCS file: /repository/php4/ext/iconv/iconv.c,v retrieving revision 1.39 diff -u -r1.39 iconv.c --- iconv.c 28 Jun 2002 07:12:32 -0000 1.39 +++ iconv.c 5 Jul 2002 20:35:50 -0000 @@ -164,7 +164,7 @@ I added 15 extra bytes for safety. <yohgaki@php.net> */ out_size = in_len * sizeof(ucs4_t) + 16; - out_buffer = (char *) emalloc(out_size); + out_buffer = (char *) emalloc(out_size+1); *out = out_buffer; out_p = out_buffer; ============================================== THIS PATCH DOESN'T REALLY FIX THE BUG #16069. ------------------------------------------------------------------------ [2002-07-05 14:45:10] sniper@php.net Doesn't segfault with 4.3.0-dev. (linux) I guess this can be closed? ------------------------------------------------------------------------ [2002-05-27 23:15:09] readjust@deneb.freemail.ne.jp Sorry for bothering you again. I don't want to make things more complicated because I have no problem using PHP at the moment. Yasuo's libc iconv support looks quite o.k. I should say in some cases I ought to use libiconv as I've mentioned it before. libc iconv doesn't translit CP932 specific characters into the alternatives while converting them into other Japanese charset. So if you are dealing with libc iconv, you don't have to care about this for the first. errno in a kind of MSVCRT is handled as a thread local variable like glibc. ------------------------------------------------------------------------ [2002-05-27 18:21:16] yohgaki@php.net I think when recent Linux is used, there should be no such problem. i.e. When iconv is supported by libc, length of resulting string is correct. (Requires 4.2.0 or later) When libiconv is used, there will be problem since it just allocate org_string_len*sizeof(UCS4 width) which cannot be corret. (And inefficient memory use) So please note which iconv you're using. I may fix if libc iconv support is broken. PS: If errno is supported for libiconv (errno should be supported for all platforms we support), we just can get rid of code for libiconv support and use libc iconv support. ------------------------------------------------------------------------ [2002-05-26 19:59:10] readjust@deneb.freemail.ne.jp No, it doesn't for now, at least in my box. I tried with 4.3.0-dev and it resulted in segv. It seems because of buffer over run. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16069 -- Edit this bug report at http://bugs.php.net/?id=16069&edit=1

« previous php.bugs (#13339) next »