Cannot replicate the bug on Linux using the latest CVS, possibly a BSD only issue. Can you reproduce the crash using PHP's CLI sapi?
The backtrace does not indicate the the crash is the result of PHP code, but rather something in Apache code(?).

got a php dump finally:
gdb `which php` php.core.1
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
Core was generated by `php'.
Program terminated with signal 10, Bus error.
Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.10...done.
Loaded symbols for /usr/local/lib/mysql/libmysqlclient.so.10
Reading symbols from /usr/local/lib/libming.so.3...done.
Loaded symbols for /usr/local/lib/libming.so.3
Reading symbols from /usr/lib/libm.so.2...done.
Loaded symbols for /usr/lib/libm.so.2
Reading symbols from /usr/local/lib/libgd.so.2...done.
Loaded symbols for /usr/local/lib/libgd.so.2
Reading symbols from /usr/local/lib/libfreetype.so.9...done.
Loaded symbols for /usr/local/lib/libfreetype.so.9
Reading symbols from /usr/local/lib/libpng.so.5...done.
Loaded symbols for /usr/local/lib/libpng.so.5
Reading symbols from /usr/lib/libz.so.2...done.
Loaded symbols for /usr/lib/libz.so.2
Reading symbols from /usr/local/lib/libjpeg.so.9...done.
Loaded symbols for /usr/local/lib/libjpeg.so.9
Reading symbols from /usr/lib/libcrypt.so.2...done.
Loaded symbols for /usr/lib/libcrypt.so.2
Reading symbols from /usr/lib/libc.so.5...done.
Loaded symbols for /usr/lib/libc.so.5
Reading symbols from /usr/libexec/ld-elf.so.1...done.
Loaded symbols for /usr/libexec/ld-elf.so.1
#0  _efree (ptr=0x0, __zend_filename=0x0, __zend_lineno=0, __zend_orig_filename=0x0, __zend_orig_lineno=0)
    at /usr/ports/www/mod_php4/work/php-4.3.0/Zend/zend_alloc.c:215
215             CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size);
(gdb) bt
#0  _efree (ptr=0x0, __zend_filename=0x0, __zend_lineno=0, __zend_orig_filename=0x0, __zend_orig_lineno=0)
    at /usr/ports/www/mod_php4/work/php-4.3.0/Zend/zend_alloc.c:215
#1  0x0806c127 in ftp_chdir (ftp=0xffffffdc, dir=0x0) at /usr/ports/www/mod_php4/work/php-4.3.0/ext/ftp/ftp.c:425
#2  0x080693e2 in zif_ftp_chdir (ht=0, return_value=0x8244724, this_ptr=0x0, return_value_used=0)
    at /usr/ports/www/mod_php4/work/php-4.3.0/ext/ftp/php_ftp.c:299
#3  0x0817a56b in execute (op_array=0x823f000) at /usr/ports/www/mod_php4/work/php-4.3.0/Zend/zend_execute.c:1596
#4  0x0817a788 in execute (op_array=0x8237080) at /usr/ports/www/mod_php4/work/php-4.3.0/Zend/zend_execute.c:1640
#5  0x0817a788 in execute (op_array=0x82201a4) at /usr/ports/www/mod_php4/work/php-4.3.0/Zend/zend_execute.c:1640
#6  0x0816990c in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /usr/ports/www/mod_php4/work/php-4.3.0/Zend/zend.c:864
#7  0x0813919b in php_execute_script (primary_file=0xbfbffb64) at /usr/ports/www/mod_php4/work/php-4.3.0/main/main.c:1582
#8  0x08180183 in main (argc=2, argv=0xbfbffbc4) at /usr/ports/www/mod_php4/work/php-4.3.0/sapi/cli/php_cli.c:753
#9  0x080647f5 in _start ()
(gdb) frame 3
#3  0x0817a56b in execute (op_array=0x823f000) at /usr/ports/www/mod_php4/work/php-4.3.0/Zend/zend_execute.c:1596
1596                                                            ((zend_internal_function *) EX(function_state).function)->
handler(EX(opline)->extended_value, EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC)
;

this is broken with following configurations:

FreeBSD 5 RELEASE 0# php-4.2.3(release)
FreeBSD 5 RELEASE 0# php-4.3.0(release)
FreeBSD 5 RELEASE 0# php-4.3.1-dev (current snap)
FreeBSD 4.7 RELEASE 0# php-4.3.1-dev (current snap)

but works on:
FreeBSD 4.7 RELEASE 0# php-4.3.0 (release)
FreeBSD 4.5 RELEASE 0# php-4.3.0 (release)

I'm trying to understand the problem you're having, but I'm seeing some slightly conflicting information so I'd like to figure out if I'm reading you incorrectly...

Running the following script using the php CLI executable, what is the *exact* output? (I'm just using ftp.kerneli.org as a known public ftp server for the sake of example)

<?php
  $fp = ftp_connect("ftp.kerneli.org");
  var_dump($fp);
  ftp_login($fp, "anonymous","ntrujillo@cox.net");
  var_dump($fp);
  var_dump(ftp_nlist($fp,"/"));
  var_dump($fp);
?>

Don't take this request as demeaning or belittleing, I'm just trying to approach this problem one step at a time.

Note: be sure to grab the latest snapshot (Dated after: Feb 13, 2003 21:00 GMT) before you try this out, I've just recently fixed a segfault in the ftp extension which *may* be related.

Correction, the fix I referred to above didn't make it into the "Feb 13, 2003 22:30 GMT" snapshot, grab one that comes *after* that (i.e. Feb 14, 2003 00:30 GMT)

pollita,

    This script only breaks in http method, as the cli returns the desired output(snafu). The Httpd child dies with a segfault. This appears to only occur on the OS's listed on the main 4.3 distro of PHP as well as alot of the snaps I've tried.


currently running FreeBSD 4.7-RELEASE #0: Wed Feb 12 19:59:59 GMT 2003 with php4.3.0 release (very stable).


thanks for your time, as I will try the current snap tomorrow.

I have a feeling, at this point, that while the new snapshot will stop your segfault, it'll still not behave in the way you expect it to.

Try this seemingly unrelated script via your httpd server:

<?php
  $fp = tmpfile();
  fwrite($fp, "This is a test.\n");
  rewind($fp);
  fpassthru($fp);
  fclose($fp);
?>
  
Ideally you should see "This is a test" in your browser... if not....well... does it show an error?

the tmpfile(); test works without flaw.

Okay, great... I believe I've got the problem nailed down, I just need the results of using that updated snapshot to be 100% certain.  In the meantime I'll start putting together the patch and with luck this should be working by this time tomorrow.

excellent, expect some results by 9:00am PMT.

still broken using php4-STABLE-200302141630.tar.bz2 (the latest snap).

pollita,

    I patched the file and recompiled. The simple script you gave me returned 0 results in web mode.(via httpd).A more complex script in Cli mode actually produced the best results (lengthy):

http://www.kelvinbeats.com/pollita/

<?
$fFp=ftp_connect("ahost.withalot.ofdirs");
ftp_login($fFp,'user','pw');
print_r(ftp_rawlist($fFp,'/');
ftp_close($fFp);
?>

So after browsing via httpd there was absolutely nothing in /etc/22052.log ? And only after running via CLI did items appear?

The log results I'm seeing suggest there was a segfault (or other failure to complete) during the second call (the NLST command was sent but no successful response was received) and several immediate failures at the end.

I think in order to fully diagnose this I'll have to install FreeBSD 5.0 locally so that I can run deeper tests myself.

This means the fix won't make it into 4.3.1, but it should be ready well before 4.3.2 and you can pick it up in a snapshot at any time after I find and fix the problem.

One more piece of feedback....

What httpd server (and version) are you running against and is PHP compiled statically or as a dynamic module?  What does your configure line look like?

This is built as a loadable module from the freebsd ports  
collection : mod_php4  
http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/mod_php4/  
Configure args look like:  
  
LIB_DEPENDS+=   gd.2:${PORTSDIR}/graphics/gd  
LIB_DEPENDS+=   freetype.9:${PORTSDIR}/print/freetype2  
LIB_DEPENDS+=   png.5:${PORTSDIR}/graphics/png  
LIB_DEPENDS+=   jpeg.9:${PORTSDIR}/graphics/jpeg  
CONFIGURE_ARGS+=--with-gd=${LOCALBASE} \  
                --enable-gd-native-ttf \  
                --with-freetype-dir=${LOCALBASE} \  
                --with-jpeg-dir=${LOCALBASE} \  
                --with-png-dir=${LOCALBASE}  
CONFIGURE_ARGS+=--with-zlib  
CONFIGURE_ARGS+=--with-bz2=/usr  
LIB_DEPENDS+=    
mysqlclient.10:${PORTSDIR}/databases/mysql323-client  
CONFIGURE_ARGS+=--with-mysql=${LOCALBASE}  
LIB_DEPENDS+=   expat.4:${PORTSDIR}/textproc/expat2  
CONFIGURE_ARGS+=--with-expat-dir=${LOCALBASE}  
LIB_DEPENDS+=   xml2.5:${PORTSDIR}/textproc/libxml2  
CONFIGURE_ARGS+=--with-dom=${LOCALBASE}  
CONFIGURE_ARGS+=--enable-ftp  
LIB_DEPENDS+=   ming.3:${PORTSDIR}/graphics/ming  
CONFIGURE_ARGS+=--with-ming=${LOCALBASE}  
CONFIGURE_ARGS+=--enable-sockets  
CONFIGURE_ARGS+=--enable-debug  
CONFIGURE_ARGS+=--enable-tran  
  
httpd server is apache 1.3.27. also built from the FreeBSD  
5 ports collection.

I hate to say this... but I just cannot reproduce this bug.  I've installed FreeBSD 5.0 on a Pentium2-233, Apache 1.3.27, and a PHP 4.3 snapshot php4-STABLE-200302190030.tar.gz as a DSO (via --with-apxs).

Using:

<?php
  $fp = ftp_connect("ftp.us.debian.org");
  var_dump($fp);
  ftp_login($fp, "anonymous", "pollita@php.net");
  var_dump($fp);
  var_dump(ftp_rawlist($fp, "/debian/pool/main/p"));
  var_dump($fp);
  ftp_close($fp);
?>

and get the listing of 488 files that is expected with no segfaults or other errors.

There's clearly something 'special' about your installations which is triggering this bug to occur.

Can you list any deviations from a standard install that are used on your server(s)?  You never mentioned what architecture you're running on?  Is it x86 or something else?  Are you using NIS? clustering? Do you have any firewalling enabled?  Recall that FTP connections use a separate command stream and data stream.  Do other ftp_* commands work as expected?  ftp_get() would be a good one to test.

Pollita,  
	I believe this is a pretty generic install, no  
NIS,NFS,firewall, or clustering.  
notes on setup::  
arch:i386  
mobo:MSI pro5 i850 chipset  
proc:P4 1.8ghz 512k l2 cache  
ram:512mb 800mhz rdram  
disc:80gb cheetah 4 ATA-100  
acd0: CD-RW <CD-RW BCE2410IM> at ata0-master UDMA33  
acd1: DVD-ROM <JLMS DVD-ROM LTD-166S> at ata0-slave UDMA33  
The only 'special' thing that is different is audio support 
compiled into custom kernel. 
			Hope this helps :)

Please generate a new backtrace using the script pollita@php.net gave and the latest snapshot from today.
(I can not reproduce this either, on linux)

If the backtrace is exactly same as the one you posted
earlier, don't add it, just mention that fact. :)

there is a diff in the /ext/domxml that is preventing patch-ext_domxml_config.m4 from cvs in freebsd port to apply cleanly. I'll let you know as soon as this is fixed in the cvs port

Ok. Let's keep this at 'Feedback' status until you can
get it to work.

This is still broken, however unable to reproduce ftp_* type httpd or php core dump. I'm not too sure if this is related, but Pollita's tmp log file method only appends the directory info in CLI mode . .. ....thanks for your time, and sorry for the delay.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip


And do it without patching it!

This is still broken. What is this about openBSD patches.

developer confirms that this is working on an identical environment.  user issue, not a php bug.