Bug #48147 [Com]: iconv with //IGNORE cuts the string
Edit report at https://bugs.php.net/bug.php?id=48147&edit=1 ID: 48147 Comment by: ezy...@php.net Reported by:kulakov74 at yandex dot ru Summary:iconv with //IGNORE cuts the string Status: Feedback Type: Bug Package:ICONV related Operating System: Linux PHP Version:5.*, 6CVS (2009-05-05) Block user comment: N Private report: N New Comment: I submitted an updated bug to glibc, which correctly describes the incorrect behavior in glibc http://sourceware.org/bugzilla/show_bug.cgi?id=13541 The facts of the matter are as follows: 1) glibc has inconsistent behavior about what the EILSEQ error code is supposed to mean, between its documentation and its behavior 2) glibc and libiconv have different behavior 3) A user of PHP who would like to use iconv to convert between two character sets while ignoring malformed characters *cannot do so* with the most recent versions of PHP (5.4+). (Trust me, I've tried.) In old versions of PHP, this functionality was available. Thus, this bug is a regression. If you want to blame upstream, that's fine by me, but I'm not optimistic on glibc getting updated any time in the near future, and there is a well understood (and implemented elsewhere) fix which gives us the correct behavior. Previous Comments: [2012-01-08 12:33:12] paj...@php.net To me it looks like there is no bug (as stated in the redhat issues). Also even if there was one, it would not be a PHP bug but iconv's. Or do you have any information that shows that PHP is causing this problem here? ---- [2011-12-23 00:49:31] ezy...@php.net I think I understand how to fix this bug, without modifying glibc. We need to modify our invocation of iconv in order to mirror the behavior of iconv_prog.c:process_block() when the '-c' flag is set (if we mimic the code closely enough, we also get an extra bonus of sensible block processing behavior, which is better than the horrible over-allocation iconv does right now). In particular, we need to handle the EILSEQ error code correctly. ---- [2011-12-18 22:34:38] ezy...@php.net Upstream bugs: http://sources.redhat.com/bugzilla/show_bug.cgi?id=13517 http://sources.redhat.com/bugzilla/show_bug.cgi?id=13518 ---- [2011-12-18 19:37:53] ezy...@php.net Not broken in latest version of libiconv ezyang@javelin:~/Desktop/libiconv-1.14/src$ ./iconv_no_i18n --version iconv (GNU libiconv 1.14) Copyright (C) 2000-2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Bruno Haible. ezyang@javelin:~/Desktop/libiconv-1.14/src$ ./iconv_no_i18n -f utf-8 -t iso-8859-1//IGNORE ~/iconv.html | wc -c 15312 ezyang@javelin:~/Desktop/libiconv-1.14/src$ iconv -f utf-8 -t iso-8859-1//IGNORE ~/iconv.html | wc -c iconv: illegal input sequence at position 8168 8157 [2009-05-07 13:58:21] j...@php.net We still can't fix bugs in glibc iconv implementation. Try this on command line and you get same results: # iconv -f utf-8 -t iso-8859-1 iconv.html > /dev/null iconv: illegal input sequence at position 3589 # iconv -f utf-8 -t iso-8859-1//IGNORE iconv.html > /dev/null iconv: illegal input sequence at position 8168 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 https://bugs.php.net/bug.php?id=48147 -- Edit this bug report at https://bugs.php.net/bug.php?id=48147&edit=1
#46656 [Opn]: Crash on array allocation/gc
ID: 46656
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: win32 only - Windows Vista
PHP Version: 5.3CVS-2008-11-24 (snap)
New Comment:
Some new information about reproducing:
I have been able to reproduce on another machine, but not without a
little bit of coaxing. In particular, these conditions must be met:
* PHPT tests must be set up. If they are skipped, the segfault does not
occur.
* `php tests/index.php` --flush must be run with a PHP 5.2 version,
prior to running `php tests/index.php` with a PHP 5.3 snap. The segfault
does not occur on a cold run of the test suite.
It might be possible to reproduce on Linux; I'm currently
reconstructing the experimental setup and will report back.
Previous Comments:
[2008-11-25 17:49:07] [EMAIL PROTECTED]
Nope, I cannot reproduce on the latest 5.3 snap on Ubuntu Linux
Intrepid.
[2008-11-25 08:37:04] [EMAIL PROTECTED]
Can you reproduce this on a real OS, like some Linux for example?
[2008-11-24 00:38:39] [EMAIL PROTECTED]
Description:
I am getting a crash on the following code:
class SimpleMock {
// ...
function SimpleMock() {
$this->actions = new SimpleCallSchedule();
$this->expectations = new SimpleCallSchedule();
$this->call_counts = array();
$this->expected_counts = array(); // here
$this->max_counts = array();
$this->expected_args = array();
$this->expected_args_at = array();
$this->getCurrentTestCase()->tell($this);
}
Which is quite strange, because allocating an array shouldn't cause a
crash! Here is the stack dump:
Thread 0 - System ID 4752
Entry point php+2af2
Create time 11/23/2008 7:29:25 PM
Time spent in user mode 0 Days 0:0:3.73
Time spent in kernel mode 0 Days 0:0:1.669
Function Arg 1 Arg 2 Arg 3 Source
php5!zend_hash_apply+5 1008ff40 1008fe0d
php5!gc_collect_cycles+2fc 04895474 00c0eb10 04ab4898
php5!gc_collect_cycles+24d 04ab0ab8 04ab4898 105286f0
php5!gc_collect_cycles+4b 04ab4898 1008cfaa 04ab4898
php5!gc_zval_possible_root+ce
PHP5!ZEND_HASH_APPLY+5WARNING - DebugDiag was not able to locate debug
symbols for php5.dll, so the information below may be incomplete.
In
php__PID__4896__Date__11_23_2008__Time_07_30_05PM__248__Second_Chance_Exception_C005.dmp
the assembly instruction at php5!zend_hash_apply+5 in
C:\Software\PHP\versions\5.3.0alpha3-dev\php5.dll from The PHP Group has
caused an access violation exception (0xC005) when trying to read
from memory location 0x0026 on thread 0
I might be doing something wrong with regards to setting up the
backtrace, since it's complaining about php5.dll even though I do have
php5.dbg in my path. If you need a better backtrace, I can see what I
can do.
If you're interested in attempting to reproduce this, the configuration
is fairly standard. Use the instructions here
to setup the HTML Purifier
development environment, and run the full test suite. (It doesn't work
if you try to run just the test that PHP dies on, or try to run it by
parts.)
--
Edit this bug report at http://bugs.php.net/?id=46656&edit=1
#46656 [NEW]: Crash on array allocation/gc
From: [EMAIL PROTECTED]
Operating system: Windows Vista
PHP version: 5.3CVS-2008-11-24 (snap)
PHP Bug Type: Reproducible crash
Bug description: Crash on array allocation/gc
Description:
I am getting a crash on the following code:
class SimpleMock {
// ...
function SimpleMock() {
$this->actions = new SimpleCallSchedule();
$this->expectations = new SimpleCallSchedule();
$this->call_counts = array();
$this->expected_counts = array(); // here
$this->max_counts = array();
$this->expected_args = array();
$this->expected_args_at = array();
$this->getCurrentTestCase()->tell($this);
}
Which is quite strange, because allocating an array shouldn't cause a
crash! Here is the stack dump:
Thread 0 - System ID 4752
Entry point php+2af2
Create time 11/23/2008 7:29:25 PM
Time spent in user mode 0 Days 0:0:3.73
Time spent in kernel mode 0 Days 0:0:1.669
Function Arg 1 Arg 2 Arg 3 Source
php5!zend_hash_apply+5 1008ff40 1008fe0d
php5!gc_collect_cycles+2fc 04895474 00c0eb10 04ab4898
php5!gc_collect_cycles+24d 04ab0ab8 04ab4898 105286f0
php5!gc_collect_cycles+4b 04ab4898 1008cfaa 04ab4898
php5!gc_zval_possible_root+ce
PHP5!ZEND_HASH_APPLY+5WARNING - DebugDiag was not able to locate debug
symbols for php5.dll, so the information below may be incomplete.
In
php__PID__4896__Date__11_23_2008__Time_07_30_05PM__248__Second_Chance_Exception_C005.dmp
the assembly instruction at php5!zend_hash_apply+5 in
C:\Software\PHP\versions\5.3.0alpha3-dev\php5.dll from The PHP Group has
caused an access violation exception (0xC005) when trying to read from
memory location 0x0026 on thread 0
I might be doing something wrong with regards to setting up the backtrace,
since it's complaining about php5.dll even though I do have php5.dbg in my
path. If you need a better backtrace, I can see what I can do.
If you're interested in attempting to reproduce this, the configuration is
fairly standard. Use the instructions here
to setup the HTML Purifier
development environment, and run the full test suite. (It doesn't work if
you try to run just the test that PHP dies on, or try to run it by parts.)
--
Edit bug report at http://bugs.php.net/?id=46656&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46656&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46656&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46656&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46656&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46656&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46656&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46656&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46656&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46656&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46656&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46656&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46656&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46656&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46656&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46656&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46656&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46656&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46656&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46656&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46656&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46656&r=mysqlcfg
