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.

Additional to the backtrace: Does this always happen or "randomly" which MPM are you using?

1- This incident happens always with this script (above)
2- MPM is prefork
3- Here the backtrace :

db) r -X -f /home/www/conf/httpd-infres1.conf
Starting program: /local/packages/apache22/bin/httpd -X -f /home/www/conf/httpd-infres1.conf
warning: Lowest section in /usr/lib/libdl.so.1 is .hash at 000000b4
warning: Lowest section in /usr/lib/libpthread.so.1 is .dynamic at 00000074
[New LWP 1]
[New LWP 2]
[LWP 2 exited]
[New LWP 2]
[Sat Feb 06 23:41:28 2010] [warn] module php5_module is already loaded, skipping
[Sat Feb 06 23:41:28 2010] [warn] module dav_svn_module is already loaded, skipping
[Sat Feb 06 23:41:28 2010] [warn] module authz_svn_module is already loaded, skipping
[New LWP 3]
[LWP 3 exited]
[New LWP 3]
[Sat Feb 06 23:41:34 2010] [warn] module php5_module is already loaded, skipping
[Sat Feb 06 23:41:34 2010] [warn] module dav_svn_module is already loaded, skipping
[Sat Feb 06 23:41:34 2010] [warn] module authz_svn_module is already loaded, skipping

Program received signal SIGSEGV, Segmentation fault.
0xfeb320d0 in strlen () from /usr/lib/libc.so.1
(gdb) bt
#0  0xfeb320d0 in strlen () from /usr/lib/libc.so.1
#1  0xfe4c3c44 in zif_crypt (ht=1, return_value=0x4bc248, return_value_ptr=0x0, this_ptr=0x0, 
    return_value_used=1) at /infres/admin1/install/php-5.2.12/ext/standard/crypt.c:165
#2  0xfe66c96c in zend_do_fcall_common_helper_SPEC (execute_data=0xffbfe990)
    at /infres/admin1/install/php-5.2.12/Zend/zend_vm_execute.h:200
#3  0xfe675018 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xffbfe990)
    at /infres/admin1/install/php-5.2.12/Zend/zend_vm_execute.h:1740
#4  0xfe66c284 in execute (op_array=0x4bbb78)
    at /infres/admin1/install/php-5.2.12/Zend/zend_vm_execute.h:92
#5  0xfe634aa8 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /infres/admin1/install/php-5.2.12/Zend/zend.c:1134
#6  0xfe5b05c4 in php_execute_script (primary_file=0xffbff028)
    at /infres/admin1/install/php-5.2.12/main/main.c:2036
#7  0xfe6eba8c in php_handler (r=0x5f8dd0)
    at /infres/admin1/install/php-5.2.12/sapi/apache2handler/sapi_apache2.c:637
#8  0x000444f0 in ap_run_handler (r=0x5f8dd0) at config.c:157
#9  0x0004496c in ap_invoke_handler (r=0x5f8dd0) at config.c:372
#10 0x0008fa8c in ap_process_request (r=0x5f8dd0) at http_request.c:282
#11 0x0008cbf8 in ap_process_http_connection (c=0x5ed038) at http_core.c:190
#12 0x0004ac9c in ap_run_process_connection (c=0x5ed038) at connection.c:43
#13 0x000bf14c in child_main (child_num_arg=0) at prefork.c:662
#14 0x000bf334 in make_child (s=0x124398, slot=0) at prefork.c:702
#15 0x000bf928 in ap_mpm_run (_pconf=0x11e4b0, plog=0x113400, s=0x124398) at prefork.c:978
#16 0x00031700 in main (argc=4, argv=0xffbff67c) at main.c:740
(gdb) frame 3
#3  0xfe675018 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xffbfe990)
    at /infres/admin1/install/php-5.2.12/Zend/zend_vm_execute.h:1740
1740            return zend_do_fcall_common_helper_SPEC(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU);

It just means crypt() returns NULL because some error happens. Is the command line PHP same version as the Apache module?

And does this crash as well:

<?php echo crypt("bar", "12"); ?>

1- Same version of PHP for Apache module and client command line :

   PHP 5.2.12 (cli) (built: Feb  6 2010 22:50:58) (DEBUG)
   Copyright (c) 1997-2009 The PHP Group
   Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

2- With your suggested script, the request do nothing appearant,
   no new page (always the previous page) and enters in an infinite
   timeout (no cpu).

3- In my mine, I don't suspect PHP, but I would like understand 
   why this function doesn't work. I suspect the environment when
   I was building PHP, Apache, libapr* on this system.
   It works on an another server under Solaris9 with httpd-2.0.63 and
   php-5.2.9 and even on an other machine that I doesn't manage and
   I don't know architecture and OS but which is running httd-2.2.14
   and php-5.2.12 like me.

Try compare what the cli binary is linked with and what the apache module is linked with. And also, depending if there are static libraries involved, the order of libs matters as well. And you should try compiling the apache module again, this time with minimum configure options. And if crypt() works then, try adding the remaining options one by one to see which causes the problem. It's possible this is only a problem with your system involved..

Sorry to re-open, I know I have not do all things you have suggested.

An answer to  the comparaison of dependencies between php command and libphp.so is interesting :

diff ldd-cmdphp ldd-libphp
21d20
<       libgcrypt.so.11 =>       /usr/lib/libgcrypt.so.11
25d23
<       libgpg-error.so.0 =>     /usr/lib/libgpg-error.so.0

No static libraries involved

ldd libphp5.so
        libz.so =>       /usr/lib/libz.so
        libexslt.so.0 =>         /usr/lib/libexslt.so.0
        libexpat.so.1 =>         /usr/local/lib/libexpat.so.1
        librt.so.1 =>    /usr/lib/librt.so.1
        libmysqlclient.so.16 =>  /infres/mysql/5.1.30/lib/mysql/libmysqlclient.so.16
        libmcrypt.so.4 =>        /usr/local/lib/libmcrypt.so.4
        libltdl.so.7 =>  /usr/local/lib/libltdl.so.7
        libldap-2.4.so.2 =>      /usr/local/lib/libldap-2.4.so.2
        liblber-2.4.so.2 =>      /usr/local/lib/liblber-2.4.so.2
        libintl.so.8 =>  /usr/local/lib/libintl.so.8
        libgd.so.2 =>    /usr/local/lib/libgd.so.2
        libt1.so.5 =>    /usr/local/lib/libt1.so.5
        libfreetype.so.6 =>      /usr/local/lib/libfreetype.so.6
        libX11.so.6.2 =>         /usr/local/X11R6/lib/libX11.so.6.2
        libXpm.so.4.11 =>        /usr/lib/libXpm.so.4.11
        libpng12.so.0 =>         /usr/lib/libpng12.so.0
        libdb-4.5.so =>  /usr/local/lib/libdb-4.5.so
        libgdbm.so.3 =>  /usr/local/lib/libgdbm.so.3
        libbz2.so.1.0 =>         /usr/local/lib/libbz2.so.1.0
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        libm.so.2 =>     /usr/lib/libm.so.2
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libcurl.so.3 =>  /usr/local/lib/libcurl.so.3
        libssl.so.0.9.8 =>       /usr/local/lib/libssl.so.0.9.8
        libcrypto.so.0.9.8 =>    /usr/local/ssl/lib/libcrypto.so.0.9.8
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libxslt.so.1 =>  /usr/lib/libxslt.so.1
        libxml2.so.2 =>  /usr/lib/libxml2.so.2
        libiconv.so.2 =>         /usr/local/lib/libiconv.so.2
        libc.so.1 =>     /usr/lib/libc.so.1
        libgcc_s.so.1 =>         /usr/local/gcc3/lib/libgcc_s.so.1
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libmd.so.1 =>    /usr/lib/libmd.so.1
        libgen.so.1 =>   /usr/lib/libgen.so.1
        libm.so.1 =>     /usr/lib/libm.so.1
        libX11.so.4 =>   /usr/lib/libX11.so.4
        libjpeg.so.62 =>         /usr/lib/libjpeg.so.62
        libfontconfig.so.1 =>    /usr/lib/libfontconfig.so.1
        libXext.so.0 =>  /usr/lib/libXext.so.0
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libscf.so.1 =>   /usr/lib/libscf.so.1
        libexpat.so.0 =>         (file not found)
        libdoor.so.1 =>  /usr/lib/libdoor.so.1
        libuutil.so.1 =>         /usr/lib/libuutil.so.1
        /platform/SUNW,T5140/lib/libc_psr.so.1
        /platform/SUNW,T5140/lib/libmd_psr.so.1

Apache compilation options :

./configure --prefix=/usr/local/apache22 --enable-so --enable-cgi --enable-cgid --enable-rewrite --enable-speling --enable-info --enable-deflate --enable-headers --enable-vhost-alias --enable-dav --enable-dav-fs --enable-ssl --with-ssl=/usr/local/ssl --enable-proxy --enable-proxy-connect --enable-proxy-ftp --enable-proxy-http --enable-ldap --with-ldap --enable-authnz-ldap --enable-expires

Apache runtime :

LD_LIBRARY_PATH=/usr/local/apache22/lib:/usr/local/apache22/modules:/usr/local/apr/lib:/usr/local/ssl/lib:/usr/local/gcc3/lib:/usr/local/lib:$LD_LIBRARY_PATH

Did you compile both the same time, ie. using same configure options? And it's CLI that has the libs and does not crash? Are different php.ini files used for both? Does both load same extensions? Are any shared extensions loaded? 

Yes, the both was compiled at same time using:
./configure --options_stuff...
make
make install

ls -l /usr/local/apache22/bin/php /usr/local/apache22/modules//libphp5.so
-rwxr-xr-x   1 root     root     21154620 Feb  7 22:24 /usr/local/apache22/bin/php*
-rwxr-xr-x   1 root     other    21697020 Feb  7 22:24 /usr/local/apache22/modules//libphp5.so*

Only one unique php.ini

2 scripts :
1- cryptok.php:  <?php $foo = crypt("bar", "12"); echo "$foo"; ?>
2- cryptbad.php: <?php $foo = crypt("bar"); echo "$foo"; ?>

With CLI: both scripts pass

1- scriptok  works in module apache mode
2- scriptbad crashes in module apache mode (segmentation fault)

Results seem differents about crypt algorithm:
1- scriptok  gives: 12.rYi7YWzJVI
2- scriptbad gives: $1$F4XSe/ks$7fQgb9k8xu.gzJOK0QHzO/

Can you try using the same LD_LIBRARY_PATH when running CLI as oyur doing with Apache? Can you check whether ldd reports other libs when using CLI with this path?

Areyou running CLI and apache as the same user from the same environment or are there different users/environments used?

# change LD_LIBRARY_PATH for CLI to be thes same as Apache
echo $LD_LIBRARY_PATH 
/usr/local/apache22/lib:/usr/local/apache22/modules:/usr/local/apr/lib:/usr/local/gcc3/lib:/usr/local/lib

is now le same as apache running.

ldd /usr/local/apache22/modules/libphp5.so |sort >ldd-libphp
ldd /usr/local/apache22/bin/php |sort >ldd-cmdphp
diff ldd-cmdphp ldd-libphp
<nothing> 

CLI is running under root
Apache is running under nobody (as usual)

Same environment about LD_LIBRARY_PATH

mode CLI: both scripts work
mode apache:
   cryptok.php (with salt) works
   cryptbad.php (without salt) crashes

Duplicate of #51059

Hm no, can't be the same bug. 5.2.12 uses Solaris implementation of crypt. David, can you look at it pls?

The same bug occured with php-5.2.13 and still with php-5.2.14
not with php-5.3.2 and 5.3.3

I do not have access to Solaris10 machines anymore.

I have teh same problem, but only if i use crypt with a hash (second parameter). The browser crash endless, PHP 5.3.1 at windows, Apache/2.2.14

Does this still happen with any of the actively supported PHP
versions[1]?

[1] <http://php.net/supported-versions.php>

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.