function exceptionHandler($e) {
	echo $e;
}
set_exception_handler('exceptionHandler');
throw new Exception('é');

This way, it works, the message is shown.

I can not reproduce this, both uncaught exception here(browser/bash).

thanks

Well, I don't know what could be... I installed PHP via apt-get, I'll try make a clean install from another source...

I can verify this (CLI seems fine; Apache 2 handler isn't):

HTTP/1.1 200 OK
Date: Mon, 05 Nov 2012 03:44:20 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.4.9-dev
Vary: Accept-Encoding
Content-Length: 101
Content-Type: text/html;charset=iso-8859-1

<br />
<b>Fatal error</b>:   in <b>/home/adamh/public_html/bugs/63426.php</b> on line <b>5</b><br />

hexdump output shows that the entire "Uncaught exception" message is missing:

00000000  48 54 54 50 2f 31 2e 31  20 32 30 30 20 4f 4b 0d  |HTTP/1.1 200 OK.|
00000010  0a 44 61 74 65 3a 20 4d  6f 6e 2c 20 30 35 20 4e  |.Date: Mon, 05 N|
00000020  6f 76 20 32 30 31 32 20  30 33 3a 33 39 3a 30 31  |ov 2012 03:39:01|
00000030  20 47 4d 54 0d 0a 53 65  72 76 65 72 3a 20 41 70  | GMT..Server: Ap|
00000040  61 63 68 65 2f 32 2e 32  2e 32 32 20 28 55 62 75  |ache/2.2.22 (Ubu|
00000050  6e 74 75 29 0d 0a 58 2d  50 6f 77 65 72 65 64 2d  |ntu)..X-Powered-|
00000060  42 79 3a 20 50 48 50 2f  35 2e 34 2e 39 2d 64 65  |By: PHP/5.4.9-de|
00000070  76 0d 0a 56 61 72 79 3a  20 41 63 63 65 70 74 2d  |v..Vary: Accept-|
00000080  45 6e 63 6f 64 69 6e 67  0d 0a 43 6f 6e 74 65 6e  |Encoding..Conten|
00000090  74 2d 4c 65 6e 67 74 68  3a 20 31 30 31 0d 0a 43  |t-Length: 101..C|
000000a0  6f 6e 74 65 6e 74 2d 54  79 70 65 3a 20 74 65 78  |ontent-Type: tex|
000000b0  74 2f 68 74 6d 6c 3b 63  68 61 72 73 65 74 3d 69  |t/html;charset=i|
000000c0  73 6f 2d 38 38 35 39 2d  31 0d 0a 0d 0a 3c 62 72  |so-8859-1....<br|
000000d0  20 2f 3e 0a 3c 62 3e 46  61 74 61 6c 20 65 72 72  | />.<b>Fatal err|
000000e0  6f 72 3c 2f 62 3e 3a 20  20 20 69 6e 20 3c 62 3e  |or</b>:   in <b>|
000000f0  2f 68 6f 6d 65 2f 61 64  61 6d 68 2f 70 75 62 6c  |/home/adamh/publ|
00000100  69 63 5f 68 74 6d 6c 2f  62 75 67 73 2f 36 33 34  |ic_html/bugs/634|
00000110  32 36 2e 70 68 70 3c 2f  62 3e 20 6f 6e 20 6c 69  |26.php</b> on li|
00000120  6e 65 20 3c 62 3e 35 3c  2f 62 3e 3c 62 72 20 2f  |ne <b>5</b><br /|
00000130  3e 0a                                             |>.|

Fixing package (sorry, should have been in the last comment). Guessing this is SAPI related for now, given CLI is fine, but I don't really have time to investigate further at present.

Hey, still can not with apache-2.2.22 :< 

Connection:Keep-Alive
Content-Length:235
Content-Type:text/html;charset=iso-8859-1
Date:Mon, 05 Nov 2012 04:08:36 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/0.9.8e-fips-rhel5 PHP/5.4.9-
dev
X-Powered-By:PHP/5.4.9-dev

Fatal error: Uncaught exception 'Exception' with message 'é' in

I'll try this in another computer with the same OS... But in mine, still the same, even after I installed from source...

Tried with lighttpd/1.4.28 and same results achieved.

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.

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

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/

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.

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)

If you disable "log_errors" (in apache or php.ini or via ini_set) the segfault disapear.

This behaves as expected.  @ab already explained the details.