Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.

after turning on STREAMS_DEBUG I've got better core:

#0  0x08088603 in _php_stream_free (stream=0x45c22290, close_options=11, tsrm_ls=0x8523d68)
    at /home/wmeler/rpm/BUILD/aris-1.6/php/main/streams.c:294
#1  0x0808b12f in stream_resource_regular_dtor (rsrc=0x46c50910, tsrm_ls=0x8523d68)
    at /home/wmeler/rpm/BUILD/aris-1.6/php/main/streams.c:2291
#2  0x080ad2e2 in list_entry_destructor (ptr=0x46c50910) at /home/wmeler/rpm/BUILD/aris-1.6/php/Zend/zend_list.c:177
#3  0x080ab8e0 in zend_hash_del_key_or_index (ht=0x8862ccc, arKey=0x0, nKeyLength=0, h=5, flag=1)
    at /home/wmeler/rpm/BUILD/aris-1.6/php/Zend/zend_hash.c:514
#4  0x080ad0a4 in _zend_list_delete (id=5, tsrm_ls=0x8523d68)
    at /home/wmeler/rpm/BUILD/aris-1.6/php/Zend/zend_list.c:56
#5  0x080a5ac2 in _zval_dtor (zvalue=0x46c502d8, 
    __zend_filename=0x8199080 "/home/wmeler/rpm/BUILD/aris-1.6/php/Zend/zend_execute_API.c", __zend_lineno=291)
    at /home/wmeler/rpm/BUILD/aris-1.6/php/Zend/zend_variables.c:69
#6  0x0809e27e in _zval_ptr_dtor (zval_ptr=0x45c01010, 
    __zend_filename=0x8195c60 "/home/wmeler/rpm/BUILD/aris-1.6/php/Zend/zend_execute.h", __zend_lineno=96)
    at /home/wmeler/rpm/BUILD/aris-1.6/php/Zend/zend_execute_API.c:291
#7  0x080bbcbd in execute (op_array=0x429d5ee0, tsrm_ls=0x8523d68)
    at /home/wmeler/rpm/BUILD/aris-1.6/php/Zend/zend_execute.h:96

The function called from PHP userspace was fclose. 
I also found in log 1069 msg looks like:

stream_alloc: socket:0x43d64f08 persistent=(null)

and only 48 msg pairs like:

stream_free: socket:0x4849caf8[(null)] in_free=0 opts=00000003
stream_free: socket:0x4849caf8[(null)] preserve_handle=0 release_cast=1 remove_rsrc=1

I also got about 40 core dumps.

If you want more information please describe what kind of information you want.

Thanks for the detailed trace;
A short self-contained reproducing script would help a great deal here also.
Also, it seems that you are running a thread-safe build; could you let us know the configure line you used, and also the version of PHP (are you really using the PHP_4_3 branch of cvs?).

PHP is taken from snaps.php.net : php4-STABLE-200307081130

'./configure' \
'--with-thttpd=../thttpd' \
'--enable-experimental-zts' \
'--with-tsrm-pthreads' \
'--with-regex=system' \
'--with-mysql=/usr' \
'--with-oci8=/opt/oracle' \
'--with-ldap=/opt/iplanet' \
'--with-mhash' \
'--enable-ftp' \
'--with-zlib' \
'--with-gdbm' \
'--with-gettext' \
'--with-xml' \
'--enable-debug' \
"$@"

I've patched thttpd and PHP so it worked fine together in ZTS. I haven't touched streams. It worked until streams were introduced (4.3?). 

BTW are memory and fds freed if there is no msg in log like "stream_free ...."

I think I won't be able to write short script which reproduct this error because it isn't on each request :(.

You should reduce the configure options to bare minimum,
try with this configure line:

# ./configure --with-thttpd=../thttpd --disable-all --enable-debug

Why do you enable the ZTS anyway?
Also, using --with-regex=system is not wise unless you
REALLY know what you're doing. And Oracle has it's own ldap functions, it's known problem that those might conflict with other ldap libraries. Just point the --with-ldap to the same as you do with --with-oci8.

I enable ZTS, because I use threads. I have one IO thread  and more PHP threads. As I said, it isn't pure thttpd and PHP. My web server has quite nice architecture - I have queues, processors, queue overflow control etc.

About configure parameters - I use the same compilation on another web aplications and it is working well. Difference is that they don't use socket streams. They use oci8 and ldap without any problems. As far I know oracle ldap functions doesn't perform well and we use iplanet libraries with success. No problems with that.

I can reduce config.nice by only few modules (ftp zlib gdbm gettext xml). Others are needed by my app.

Anyway - don't you think that these STREAM_DEBUG messages are strange?

Assigned to the father of streams. :)

So, you patched your web server, you patched PHP and compiled it in the unsupported maintainer thread-safe mode and expect me to fix the segfault? :-)

Maybe its better for you to ask questions on the internals list if you are developing your own SAPI.

Not a bug in any of the supported PHP configurations, so we are not going to fix it.

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

There are sill some issues with streams.
Now pfsockopen causes segfaults on php4-STABLE-200307280730 :

./configure ---disable-all --enable-debug

....


./make

.....


./sapi/cli/php -r '$f=pfsockopen("www.php.net",80,$errno,$errmsg,2);fputs($f,"SHIT\r\n\r\n");fpassthru($f);fclose($f);'

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>301 Moved Permanently</TITLE>
</HEAD><BODY>
<H1>Moved Permanently</H1>
The document has moved <A HREF="http://www.php.net/">here</A>.<P>
</BODY></HTML>
Segmentation fault (core dumped)



./gdb -c core sapi/php/cli
bt
#0  0x40128c25 in __libc_free (mem=0x816c038) at malloc.c:3155
#1  0x80f8edb in zend_hash_apply_deleter (ht=0x8143314, p=0x816c148)
    at /tmp/php4-STABLE-200307280730/Zend/zend_hash.c:601
#2  0x80f90ea in zend_hash_graceful_reverse_destroy (ht=0x8143314)
    at /tmp/php4-STABLE-200307280730/Zend/zend_hash.c:664
#3  0x80fab99 in zend_destroy_rsrc_list (ht=0x8143314)
    at /tmp/php4-STABLE-200307280730/Zend/zend_list.c:233
#4  0x80f30fb in zend_shutdown ()
    at /tmp/php4-STABLE-200307280730/Zend/zend.c:555
#5  0x80c284b in php_module_shutdown ()
    at /tmp/php4-STABLE-200307280730/main/main.c:1281
#6  0x8109c73 in main (argc=3, argv=0xbffff974)
    at /tmp/php4-STABLE-200307280730/sapi/cli/php_cli.c:877
#7  0x400c4507 in __libc_start_main (main=0x81091b8 <main>, argc=3,
    ubp_av=0xbffff974, init=0x8059760 <_init>, fini=0x810a250 <_fini>,
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff96c)
    at ../sysdeps/generic/libc-start.c:129


And I think you really should review php_stream_close usage. I'm sure that pclose function would cause the same problems as fclose caused before. All places that user can make reference to resource should use zend_list_delete.

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

If you find any more streams related bugs please open a seperate report, it'll be much easier for us to track bugs that way :).