I can't reproduce that. As this happens in lex_scan: Do you by chance have have re2c installed and are therefore running a different parser than what is committed in svn? anything else special on your system?

I have 

$ rpm -q re2c
re2c-0.13.5-2m.mo7.x86_64

It may be causing it. What version are you using?

BTW, I'm using rpm package but the spec is plain ./configure && make && make 
install. gcc is 

$ LC_ALL=C gcc -v
Using built-in specs.
Target: x86_64-momonga-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --with-bugurl=http://developer.momonga-
linux.org/kagemai/ --enable-bootstrap --enable-shared --enable-threads=posix --
enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-
libunwind-exceptions --enable-gnu-unique-object --enable-
languages=c,c++,objc,obj-c++,java,fortran --enable-java-awt=gtk --disable-dssi -
-with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-
multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-
ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic -
-with-arch_32=i686 --build=x86_64-momonga-linux
Thread model: posix
gcc version 4.4.4 20100630 (Momonga Linux 7 4.4.4-3m.mo7) (GCC)

I svn diffed source. No diff. So I suppose it would be other reason.

I've mailed internals since I thought PHP 5.4 and trunk was ok, but it turns out 
it didn't enabled zend.multibyte. There may be the same issue with 
zend.multibyte=on (if it can)

I'm getting the same on FreeBSD 9.0 and PHP 5.3.15:

[Fri Jul 27 13:15:16 2012]  Script:  '/home/zima/www/price/cron/filter.php'                                                              
/tmp/ports/.amd_mnt/faz/host/usr/ports/lang/php53/work/php-
5.3.15/ext/standard/base64.c(69) :  Freeing 0x81D7C35D0 (601 bytes), script=/$
/tmp/ports/.amd_mnt/faz/host/usr/ports/lang/php53/work/php-
5.3.15/Zend/zend_alloc.c(2734) : Actual location (location was relayed)

I can confirm,  but only on 5.3,  5.4 has no such issue

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

Strange, but after applying a patch from http://git.php.net/?p=php-src.git;a=commit;h=ef7286a42f0d85cc359f1d64678f859d6c3f832e and rebuilding everything the bug still persists. Is this a full 
patch or a last commit to close the problem?

Still I don't know how to craft the test case but I'll try. Right now it gives me:

[Mon Jul 30 13:00:16 2012]  Script:  '/home/price-/www/price09.com.ua/cron/_cat.php'
/tmp/ports/usr/ports/lang/php53/work/php-5.3.15/ext/standard/base64.c(69) :  Freeing 0x8171B5598 (601 bytes), script=/home/price-/www/price09.com.ua/cron/_cat.php
/tmp/ports/usr/ports/lang/php53/work/php-5.3.15/Zend/zend_alloc.c(2734) : Actual location (location was relayed)
[Mon Jul 30 13:00:16 2012]  Script:  '/home/price-/www/price09.com.ua/cron/_cat.php'
/tmp/ports/usr/ports/databases/php53-redis/work/nicolasff-phpredis-250e81b/library.c(718) :  Freeing 0x80DA67F80 (10 bytes), script=/home/price-/www/price09.com.ua/cron/_cat.php
=== Total 2 memory leaks detected ===

The output was effectively the same as before the patch.

@c.kworr the leak related to redis extension.