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.

<a href="http://www.pastebin.cz/43ef1b43ee1dbd"> here is the gdb output 
</a>

Proper link: http://www.pastebin.cz/43ef1b43ee1dbd

And obvious question: Does it crash without that 3rd party patch?

if by 3rd party patch you mean suhosin then yes, bud instead of the 
error message it segfaults.

Was the backtrace with or without the suhosin patch? (I'm guessing without?)

it was with suhosin patch compiled in but with USE_ZEND_ALLOC set to 0. 
I can post a test without suhosin but that will have to wait until 
night - I see this behaviour on a production machine so I can not allow 
php to segfault during work hours and I don't have a spare one to 
reproduce the problem.

You can't run the thing on command line..? I thought that's how you really meant it to be reproduced: # php -v ? (please don't reply before you have real feedback)

ok here
http://www.pastebin.cz/e9a52bce5e4288
is the gdb output on the core dump of php 5.2.11 without the suhosin patch with debugging symbols enabled.
If I remove mhash.so from the extensions php runs without problem. If mhash is enabled it produces the segmentation fault (heap overflow). Mhash package works normally and python mhash module works as well so from what I can see it is probably some kind of issue in php5-mhash. 

PS: And yes, I can run it from commandline but I had to recompile php without the suhosin patch included ;)

Well, running something does not require installing it:

# make && sapi/cli/php -v 

And are you somehow enabling ZTS too? And you're sure you're loading the mhash.so from the same build? (I can't reproduce this..)

I don't know about ZTS - I pasted the configure options below for you to see. I am sure that I load the correct modules. I recompiled php and extensions several times and tried removing it completly and compiling it again.  Is it possible that this is a FreeBSD bug rather than a php bug?

here is the configure command used to compile php
'./configure' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-reflection' '--program-prefix=' '--disable-cgi' '--with-apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL' '--enable-debug' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd7.2' (according to phpinfo() )

Please try using this snapshot:

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

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

And use the proper configure line without any extra:

# ./configure --disable-all --disable-cgi --with-mhash

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".