Unable to reproduce with 5.5.3 or 5.6.0-dev on Debian 7 or OSX using PHP CLI 
(unable to test with Apache at present).

Piotr do you get the same results using the CLI? What other modules do you have 
loaded?

A backtrace of the coredump might also be useful.

No, the problem does not seem to persit when run in CLI mode. The code behaves exactly as it should.

Here's a var_dump(get_loaded_extensions()): 
  0 => string 'Core' (length=4)
  1 => string 'date' (length=4)
  2 => string 'ereg' (length=4)
  3 => string 'libxml' (length=6)
  4 => string 'openssl' (length=7)
  5 => string 'pcre' (length=4)
  6 => string 'zlib' (length=4)
  7 => string 'bcmath' (length=6)
  8 => string 'bz2' (length=3)
  9 => string 'calendar' (length=8)
  10 => string 'ctype' (length=5)
  11 => string 'dba' (length=3)
  12 => string 'dom' (length=3)
  13 => string 'hash' (length=4)
  14 => string 'fileinfo' (length=8)
  15 => string 'filter' (length=6)
  16 => string 'ftp' (length=3)
  17 => string 'gettext' (length=7)
  18 => string 'SPL' (length=3)
  19 => string 'iconv' (length=5)
  20 => string 'json' (length=4)
  21 => string 'mbstring' (length=8)
  22 => string 'session' (length=7)
  23 => string 'standard' (length=8)
  24 => string 'posix' (length=5)
  25 => string 'Reflection' (length=10)
  26 => string 'Phar' (length=4)
  27 => string 'shmop' (length=5)
  28 => string 'SimpleXML' (length=9)
  29 => string 'soap' (length=4)
  30 => string 'sockets' (length=7)
  31 => string 'exif' (length=4)
  32 => string 'sysvmsg' (length=7)
  33 => string 'sysvsem' (length=7)
  34 => string 'sysvshm' (length=7)
  35 => string 'tokenizer' (length=9)
  36 => string 'wddx' (length=4)
  37 => string 'xml' (length=3)
  38 => string 'xmlreader' (length=9)
  39 => string 'xmlwriter' (length=9)
  40 => string 'zip' (length=3)
  41 => string 'apache2handler' (length=14)
  42 => string 'PDO' (length=3)
  43 => string 'curl' (length=4)
  44 => string 'imap' (length=4)
  45 => string 'memcached' (length=9)
  46 => string 'pdo_pgsql' (length=9)
  47 => string 'pgsql' (length=5)
  48 => string 'readline' (length=8)
  49 => string 'redis' (length=5)
  50 => string 'mhash' (length=5)
  51 => string 'Zend OPcache' (length=12)
  52 => string 'xdebug' (length=6)

Unfortunately the coredump does not get created - any ideas on how i might force the generation of one?

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

The above has guidance on creating a backtrace, but please disable Zend Optimizer and XDebug first.

As requested i disabled XDebug and Zend Optimizer. All of a sudden the code acts properly and as expected. I managed to narrow the problem down to Zend Optimizer. If it's activated the problem occurs, once disabled everything goes back to normal. Here's a gdb backtrace with Zend Optimizer on:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff41313b7 in ?? () from /usr/lib/apache2/modules/libphp5.so
(gdb) bt
#0  0x00007ffff41313b7 in ?? () from /usr/lib/apache2/modules/libphp5.so
#1  0x00007ffff41154f8 in execute_ex () from /usr/lib/apache2/modules/libphp5.so
#2  0x00007ffff40a8059 in zend_execute_scripts () from /usr/lib/apache2/modules/libphp5.so
#3  0x00007ffff404651c in php_execute_script () from /usr/lib/apache2/modules/libphp5.so
#4  0x00007ffff4158a4a in ?? () from /usr/lib/apache2/modules/libphp5.so
#5  0x00005555555964b0 in ap_run_handler (r=0x7ffff52b16c8) at config.c:159
#6  0x00005555555968fb in ap_invoke_handler (r=r@entry=0x7ffff52b16c8) at config.c:377
#7  0x00005555555a609c in ap_internal_redirect (new_uri=<optimized out>, r=<optimized out>) at http_request.c:554
#8  0x00007fffefb50908 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so
#9  0x00005555555964b0 in ap_run_handler (r=0x7ffff52bc0a0) at config.c:159
#10 0x00005555555968fb in ap_invoke_handler (r=r@entry=0x7ffff52bc0a0) at config.c:377
#11 0x00005555555a6a28 in ap_process_request (r=r@entry=0x7ffff52bc0a0) at http_request.c:282
#12 0x00005555555a38d8 in ap_process_http_connection (c=0x7ffff7dff290) at http_core.c:190
#13 0x000055555559ce80 in ap_run_process_connection (c=0x7ffff7dff290) at connection.c:43
#14 0x000055555559d268 in ap_process_connection (c=c@entry=0x7ffff7dff290, csd=<optimized out>) at connection.c:190
#15 0x00005555555ab646 in child_main (child_num_arg=child_num_arg@entry=0) at prefork.c:667
#16 0x00005555555abd5e in make_child (s=0x7ffff7fea818, slot=0) at prefork.c:712
#17 0x00005555555ac4e2 in ap_mpm_run (_pconf=_pconf@entry=0x7ffff7ff0028, plog=<optimized out>, s=s@entry=0x7ffff7fea818) at prefork.c:988
#18 0x000055555558124e in main (argc=2, argv=0x7fffffffe5c8) at main.c:755

I hope this helps.

Please try using this snapshot:

  http://snaps.php.net/php5.5-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

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.