with a non-debug build; we'd get:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 140044069608296 bytes) in Unknown on line 0

and:

kernel: traps: php-fpm[12013] general protection ip:61b538 sp:7fffb5870ab0 error:0 in php-fpm[400000+7b1000]

I couldn't reproduce that issue at the command line nor via 3v4l.org

http://3v4l.org/Sqbeg

Are there any further environment specific things one needs to respect to reproduce?

Could this depend on php-fpm somehow? That seems to be 100% broken here

Also; please tail your error-log while testing this; I have confirmed the messages on 2 machines (1 of them it also outputs the exception, but also the exhausted message in the error-log)

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

I reproduced this error with php5.6.0 and php5.6.5.
The bug occures only if html_errors is set to true, and the exception is displayed (not catched).

Test script (encoded in iso-8859-1) :
   ini_set('html_errors', true);
   throw new Exception('société');

I still can't reproduce this.

I have this script:

   <?php
   ini_set('html_errors', true);
   throw new Exception('société');

I have converted it to iso-8859-1:

$ file test.php
test.php: PHP script, ISO-8859 text

$ php test.php
<br />
<b>Fatal error</b>:   in <b>/test/test.php</b> on line <b>3</b><br />

It is also clean in Valgrind. Can you reproduce this in current releases of PHP 5.5 or 5.6 from the command line?

@samuel_carriere; are you also using fpm? I could never reproduce this through the cli, but fpm was pretty consistent.

Even with the html-error set, it won't crash on 3v4l either (through cli): http://3v4l.org/fgplv

Getting same error in 5.6.17-0+deb8u1.

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)

The same error still occurs in PHP 5.6.29-0+deb8u1 (running as mod_php on Apache 2.4.10).

Test script:
-----
<?php
throw new Exception('täst');
-----

With html_errors set to On this produces a segfault with:

[Fri Jan 27 13:38:10.259970 2017] [core:notice] [pid 6] AH00052: child pid 29 exit signal Segmentation fault (11)

Setting html_errors to Off does not produce a segfault but an expected error:

[Fri Jan 27 13:38:46.035301 2017] [:error] [pid 30] [client x.x.x.x:43227] PHP Fatal error:  Uncaught exception 'Exception' with message 't\xe4st' in /var/www/html/test.php:3\nStack trace:\n#0 {main}\n  thrown in /var/www/html/test.php on line 3

Note that this bug will therefore not occur when being run on CLI as the value for html_errors is hardcoded to Off there.

Also note that it does not matter if the Exception is caught in a surrounding try-catch block or not.