Bug #63426 [Com]: Can't throw exceptions with accentued chars coded in latin1/ISO-8859-1

Edit report at https://bugs.php.net/bug.php?id=63426&edit=1 ID: 63426 Comment by: nauruhn at autoaid dot de Reported by: rick dot hjpbarcelos at gmail dot com Summary: Can't throw exceptions with accentued chars coded in latin1/ISO-8859-1 Status: Verified Type: Bug Package: *Unicode Issues Operating System: Linux/Ubuntu 12.10 PHP Version: 5.4Git-2012-11-03 (snap) Block user comment: N Private report: N New Comment: Getting same error. Environment ------------ System: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4 (2016-02-29) x86_64 PHP: PHP Version 5.6.17-0+deb8u1 PHP Modules: /etc/php5/apache2/conf.d/05-apcu.ini, /etc/php5/apache2/conf.d/05-opcache.ini, /etc/php5/apache2/conf.d/10-mysqlnd.ini, /etc/php5/apache2/conf.d/10-pdo.ini, /etc/php5/apache2/conf.d/20-apcu.ini, /etc/php5/apache2/conf.d/20-curl.ini, /etc/php5/apache2/conf.d/20-imagick.ini, /etc/php5/apache2/conf.d/20-intl.ini, /etc/php5/apache2/conf.d/20-json.ini, /etc/php5/apache2/conf.d/20-mcrypt.ini, /etc/php5/apache2/conf.d/20-mysql.ini, /etc/php5/apache2/conf.d/20-mysqli.ini, /etc/php5/apache2/conf.d/20-pdo_mysql.ini, /etc/php5/apache2/conf.d/20-readline.ini, /etc/php5/apache2/conf.d/20-twig.ini, /etc/php5/apache2/conf.d/20-xdebug.ini Default Charset: UTF-8 Apache: Apache/2.4.10 (Debian) Apache Modules: core mod_so mod_watchdog http_core mod_log_config mod_logio mod_version mod_unixd mod_access_compat mod_alias mod_auth_basic mod_authn_core mod_authn_file mod_authz_core mod_authz_host mod_authz_user mod_autoindex mod_cgi mod_deflate mod_dir mod_env mod_fcgid mod_filter mod_headers mod_mime prefork mod_negotiation mod_php5 mod_proxy mod_proxy_fcgi mod_rewrite mod_setenvif mod_socache_shmcb mod_ssl mod_status Test ------------ <?php throw new Exception(iconv(ini_get('default_charset'), 'ISO-8859-1', 'ß')); Apache Log ------------ [Thu Mar 10 17:06:32.162353 2016] [core:notice] [pid 865] AH00052: child pid 2033 exit signal Segmentation fault (11) Previous Comments: ------------------------------------------------------------------------ [2016-01-06 20:40:25] chealer at gmail dot com I am getting Apache child segfaults when running... trigger_error("é"); ...in a ISO-8859-1-encoded file under Debian 8 (Apache 2.4.10-10+deb8u3, PHP 5.6.14+dfsg-0+deb8u1). My test script contains nothing but the above statement. In a file encoded with UTF-8, the statement works fine. But otherwise, I get the strangest behavior. Initially, XDebug displays garbage such as: Notice: in /var/www/html/tests/testMinimal.php on line 2 Notice: ������ in /var/www/html/tests/testMinimal.php on line 2 Notice: P����� in /var/www/html/tests/testMinimal.php on line 2 or Notice: p����� in /var/www/html/tests/testMinimal.php on line The precise string varies, but at some point, the script starts crashing. From that point, it *seems* all executions of the script cause a child segfault, until Apache is restarted. But I could be getting that because my browser constantly hits the same broken child. I still haven't identified exactly what triggers this change (children breaking). But it seems I managed to find something sufficient - opening the homepage of our travel Intranet site. That homepage loads normally, but after, it seems all executions of trigger_error() with non-ASCII characters cause children to segfault. My particular problem may be more than that reported here, but I failed to find a report of mine. ------------------------------------------------------------------------ [2015-07-24 19:21:28] chealer at gmail dot com Thank you very much for the explanation, ab@php.net. This happens with WampServer 2.5 (PHP 5.5.12 on Apache 2.4.9). It appears this issue is not limited to exceptions. If I call PDO::prepare() incorrectly (don't ask me how - that's what I was trying to debug), I get the following: Warning: PDO::prepare(): in [...] Presumably, PDO::prepare() triggers a warning using misencoded text. Due to the same issue ab@php.net described, PHP ends up displaying nothing rather than a misencoded string. This is probably a PDO::prepare() bug, but it is made much worse by this issue. This is quite an awful issue - getting errors without descriptions. Why wouldn't ENT_SUBSTITUTE or ENT_IGNORE be used? At least, when this happens, PHP should display a warning explaining that the message was not encoded properly. For PHP 5.6, this can probably be worked around setting default_charset. See https://www.saotn.org/php-56-default_charset-change-may-break-html-output/ ------------------------------------------------------------------------ [2013-07-25 19:18:45] ab@php.net The reason it's cannot be fixed is complex is simple. Since 5.4 the PHP's internal encoding is UTF-8, where it was latin1 before. Everything else has almost no change. Every error message to show in HTML context needs to have the entities converted. For that the same functionality as in htmlspecialchars() is used. Where before PHP 5.4 it was forced to use latin1, now it's forced to use UTF8. There is per design. Using header() with content-type or default_charset affects merely only the senging of the content-type header. Thus, you use error text in latin1, but UTF-8 will be used to convert entities, and that will die at the first invalid char. The relevant place in the code: http://lxr.php.net/xref/PHP_5_4/main/main.c#1083 , subsequently determine_charset() will deliver UTF8 for the conversion charset. That's the reason why your accent char is swallowed. And that's the reason why Hui couldn't reproduce this - if you look at his post earlier, indeed latin1 is sent in content-type, but obviously an UTF-8 encoded PHP script used, so the error message is "Fatal error: Uncaught exception 'Exception' with message 'é' in ...". The current condition however doesn't enforce you to have scripts in UTF-8, in your script encoded in latin you still could throw the exception using utf8_encode('é'). The reason it works with CLI is because no HTML entities have to be encoded, so the chars are passed as is to the output. This all actually means this issue was always there, but it was in favour of users with default iso-8859-1. Now users with default UTF-8 do profit. Looking through the codes to solving this might require more global intrusion than required just by this ticket. For htmlspecialchars() behaviour change see also bug #61354 ------------------------------------------------------------------------ [2013-06-05 19:37:43] rick dot hjpbarcelos at gmail dot com Tried with PHP 5.4 built-in server and got this on my terminal: [code] [Wed Jun 5 21:32:08 2013] PHP Fatal error: Uncaught exception 'Exception' with message '�' in /var/www/test2.php:9 Stack trace: #0 {main} thrown in /var/www/test2.php on line 9 [Wed Jun 5 21:32:08 2013] 127.0.0.1:55116 [200]: /test2.php - Uncaught exception 'Exception' with message '�' in /var/www/test2.php:9 Stack trace: #0 {main} thrown in /var/www/test2.php on line 9 [/code] But in the browser, still the same problem. ------------------------------------------------------------------------ [2013-05-30 13:30:15] rick dot hjpbarcelos at gmail dot com Tried with lighttpd/1.4.28 and same results achieved. ------------------------------------------------------------------------ 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=63426 -- Edit this bug report at https://bugs.php.net/bug.php?id=63426&edit=1