[PHP-DEV] Bug #14709 Updated: segmentation fault
ID: 14709
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: XSLT related
Operating System: Linux 2.4.3-12 (Apache/1.3.20)
PHP Version: 4.1.0
New Comment:
Recompiling Apache fixed the problem. Thanks for the tip.
Previous Comments:
[2001-12-31 10:40:26] [EMAIL PROTECTED]
You probably compiled apache with the builtin expat lite, please
re-install apache using the same expat that sablotron uses.
[2001-12-27 01:06:46] [EMAIL PROTECTED]
[Note: PHP version is 4.1.1 -- the drop-down box has 4.1.0 as latest
version]
Script:
?
$processor = xslt_create();
$args = array();
$args[ '/xml' ] = '?xml version=1.0?root /';
$args[ '/xsl' ] = '?xml version=1.0?root /';
for( $i = 0; $i 1000; ++$i )
{
if( !$result = xslt_process( $processor, 'arg:/xml', 'arg:/xsl',
NULL, $args ) )
{
echo 'failed';
}
}
xslt_free( $processor );
echo 'done';
?
Config line:
'./configure' '--with-config-file-path=/etc' '--with-pgsql'
'--with-apxs=/usr/apache/bin/apxs' '--with-xml' '--enable-xslt'
'--with-xslt-sablot' '--with-mysql=no' '--with-gd' '--enable-debug'
Description:
When I visit this script, and hit refresh (several times) Apache
terminates with a segmentation fault. The bug appears to be random
because there are times when the script finishes without a crash.
Backtrace:
#0 __libc_free (mem=0x2) at malloc.c:3036
#1 0x0809ab8e in hashTableDestroy () at eval.c:41
#2 0x08099b4d in dtdDestroy () at eval.c:41
#3 0x0809425d in XML_ParserFree () at eval.c:41
#4 0x40370e4a in TreeConstructer::parseDataLineUsingExpat
(this=0xbfffdd90, S=@0x811cff8, t=0x8130520,
d=0x81304c0) at parser.cpp:126
#5 0x40383034 in Tree::parse (this=0x8130520, S=@0x811cff8,
d=0x81304c0) at tree.cpp:600
#6 0x40375951 in Processor::addLineParse (this=0x811d0a8, S=@0x811cff8,
newTree=@0x811d0a8,
absolute=@0xbfffde40, isXSL=0) at guard.h:157
#7 0x4037602e in Processor::readTreeFromURI (this=0x811d0a8,
S=@0x811cff8, newTree=@0x811d0a8,
location=@0xbfffdf10, base=@0xbfffdef0, isXSL=0) at proc.cpp:602
#8 0x40373d91 in Processor::open (this=0x811d0a8, S=@0x811cff8,
sheetURI=0x811dadc arg:/xsl,
inputURI=0x811dc14 arg:/xml) at proc.cpp:277
#9 0x40379633 in SablotRunProcessor (processor_=0x811d0a8,
sheetURI=0x811dadc arg:/xsl,
inputURI=0x811dc14 arg:/xml, resultURI=0x402d9683 arg:/_result,
params=0x0, arguments=0x811dc54)
at sablot.cpp:407
#10 0x402af84a in zif_xslt_process (ht=5, return_value=0x811db5c,
this_ptr=0x0, return_value_used=1)
at sablot.c:514
#11 0x401dcca1 in execute (op_array=0x81123a4) at
./zend_execute.c:1590
#12 0x401ed66c in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at zend.c:814
#13 0x401ff82a in php_execute_script (primary_file=0xb6e0) at
main.c:1307
#14 0x401fa65a in apache_php_module_main (r=0x810a034,
display_source_mode=0) at sapi_apache.c:90
#15 0x401fb4c8 in send_php (r=0x810a034, display_source_mode=0,
filename=0x810f5e4 /home/apache/html/geeba/crash.php) at
mod_php4.c:575
#16 0x401fb535 in send_parsed_php (r=0x810a034) at mod_php4.c:590
#17 0x0806a7ff in ap_invoke_handler () at eval.c:41
#18 0x0807e5eb in process_request_internal () at eval.c:41
#19 0x0807e64c in ap_process_request () at eval.c:41
#20 0x08075a9d in child_main () at eval.c:41
#21 0x08075c48 in make_child () at eval.c:41
#22 0x08075dbc in startup_children () at eval.c:41
#23 0x0807640f in standalone_main () at eval.c:41
#24 0x08076c37 in main () at eval.c:41
#25 0x4008f177 in __libc_start_main (main=0x8076898 main, argc=2,
ubp_av=0xbb14,
init=0x804ed14 _init, fini=0x80abac0 _fini, rtld_fini=0x4000e184
_dl_fini, stack_end=0xbb0c)
at ../sysdeps/generic/libc-start.c:129
Hope this helps. Thank you very much,
Valeriy
Edit this bug report at http://bugs.php.net/?id=14709edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14794 Updated: misleading warning with regard to 'allow_call_time_pass_reference'
ID: 14794 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Summary: xml_set_object() should take object by-reference Status: Open Old Bug Type: XML related Bug Type: Feature/Change Request Operating System: Linux 2.4 / Apache 1.3 PHP Version: 4.1.1 New Comment: Ok, I am really embarassed now, because xml_set_object() does take object by reference. The warning message is misleading though. It convinced me that the parameter was passed by value. But rather, it should say '.. - argument passed according to the function spec', which, in this case, is by-reference. Thanks! Previous Comments: [2002-01-02 02:19:32] [EMAIL PROTECTED] I am getting the following warning after I switched to 'php.ini-recommended': Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of xml_set_object()... Apparently, xml_set_object() takes an object by value, which renders this functionality useless: The only way it's any good is when the object is passed by reference, so that the event-receiving object is the same instance that was passed as a parameter to xml_set_object() call. Otherwise, there is no way for a copied object to pass parsed data out to the caller of xml_set_object() (without global variables, of course). Please fix xml_set_object() to take an object by reference. Thanks. Edit this bug report at http://bugs.php.net/?id=14794edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14794 Updated: misleading warning with regard to 'allow_call_time_pass_reference'
ID: 14794 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Summary: xml_set_object() should take object by-reference Status: Open Bug Type: Feature/Change Request Operating System: Linux 2.4 / Apache 1.3 PHP Version: 4.1.1 New Comment: Ok, I am really embarassed now, because xml_set_object() does take object by reference. The warning message is misleading though. It convinced me that the parameter was passed by value. But rather, it should say '.. - argument passed according to the function spec', which, in this case, is by-reference. Thanks! Previous Comments: [2002-01-02 03:28:52] [EMAIL PROTECTED] Ok, I am really embarassed now, because xml_set_object() does take object by reference. The warning message is misleading though. It convinced me that the parameter was passed by value. But rather, it should say '.. - argument passed according to the function spec', which, in this case, is by-reference. Thanks! [2002-01-02 02:19:32] [EMAIL PROTECTED] I am getting the following warning after I switched to 'php.ini-recommended': Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of xml_set_object()... Apparently, xml_set_object() takes an object by value, which renders this functionality useless: The only way it's any good is when the object is passed by reference, so that the event-receiving object is the same instance that was passed as a parameter to xml_set_object() call. Otherwise, there is no way for a copied object to pass parsed data out to the caller of xml_set_object() (without global variables, of course). Please fix xml_set_object() to take an object by reference. Thanks. Edit this bug report at http://bugs.php.net/?id=14794edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14794 Updated: misleading warning with regard to 'allow_call_time_pass_reference'
ID: 14794 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Summary: xml_set_object() should take object by-reference Status: Open Bug Type: Feature/Change Request Operating System: Linux 2.4 / Apache 1.3 PHP Version: 4.1.1 New Comment: Ok, I am really embarassed now, because xml_set_object() does take object by reference. The warning message is misleading though. It convinced me that the parameter was passed by value. But rather, it should say '.. - argument passed according to the function spec', which, in this case, is by-reference. Thanks! Previous Comments: [2002-01-02 03:28:55] [EMAIL PROTECTED] Ok, I am really embarassed now, because xml_set_object() does take object by reference. The warning message is misleading though. It convinced me that the parameter was passed by value. But rather, it should say '.. - argument passed according to the function spec', which, in this case, is by-reference. Thanks! [2002-01-02 03:28:52] [EMAIL PROTECTED] Ok, I am really embarassed now, because xml_set_object() does take object by reference. The warning message is misleading though. It convinced me that the parameter was passed by value. But rather, it should say '.. - argument passed according to the function spec', which, in this case, is by-reference. Thanks! [2002-01-02 02:19:32] [EMAIL PROTECTED] I am getting the following warning after I switched to 'php.ini-recommended': Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of xml_set_object()... Apparently, xml_set_object() takes an object by value, which renders this functionality useless: The only way it's any good is when the object is passed by reference, so that the event-receiving object is the same instance that was passed as a parameter to xml_set_object() call. Otherwise, there is no way for a copied object to pass parsed data out to the caller of xml_set_object() (without global variables, of course). Please fix xml_set_object() to take an object by reference. Thanks. Edit this bug report at http://bugs.php.net/?id=14794edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14794: xml_set_object() should take object by-reference
From: [EMAIL PROTECTED] Operating system: Linux 2.4 / Apache 1.3 PHP version: 4.1.1 PHP Bug Type: XML related Bug description: xml_set_object() should take object by-reference I am getting the following warning after I switched to 'php.ini-recommended': Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of xml_set_object()... Apparently, xml_set_object() takes an object by value, which renders this functionality useless: The only way it's any good is when the object is passed by reference, so that the event-receiving object is the same instance that was passed as a parameter to xml_set_object() call. Otherwise, there is no way for a copied object to pass parsed data out to the caller of xml_set_object() (without global variables, of course). Please fix xml_set_object() to take an object by reference. Thanks. -- Edit bug report at: http://bugs.php.net/?id=14794edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14709: segmentation fault
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.3-12 (Apache/1.3.20)
PHP version: 4.1.0
PHP Bug Type: XSLT related
Bug description: segmentation fault
[Note: PHP version is 4.1.1 -- the drop-down box has 4.1.0 as latest
version]
Script:
?
$processor = xslt_create();
$args = array();
$args[ '/xml' ] = '?xml version=1.0?root /';
$args[ '/xsl' ] = '?xml version=1.0?root /';
for( $i = 0; $i 1000; ++$i )
{
if( !$result = xslt_process( $processor, 'arg:/xml', 'arg:/xsl',
NULL, $args ) )
{
echo 'failed';
}
}
xslt_free( $processor );
echo 'done';
?
Config line:
'./configure' '--with-config-file-path=/etc' '--with-pgsql'
'--with-apxs=/usr/apache/bin/apxs' '--with-xml' '--enable-xslt'
'--with-xslt-sablot' '--with-mysql=no' '--with-gd' '--enable-debug'
Description:
When I visit this script, and hit refresh (several times) Apache terminates
with a segmentation fault. The bug appears to be random because there are
times when the script finishes without a crash.
Backtrace:
#0 __libc_free (mem=0x2) at malloc.c:3036
#1 0x0809ab8e in hashTableDestroy () at eval.c:41
#2 0x08099b4d in dtdDestroy () at eval.c:41
#3 0x0809425d in XML_ParserFree () at eval.c:41
#4 0x40370e4a in TreeConstructer::parseDataLineUsingExpat
(this=0xbfffdd90, S=@0x811cff8, t=0x8130520,
d=0x81304c0) at parser.cpp:126
#5 0x40383034 in Tree::parse (this=0x8130520, S=@0x811cff8, d=0x81304c0)
at tree.cpp:600
#6 0x40375951 in Processor::addLineParse (this=0x811d0a8, S=@0x811cff8,
newTree=@0x811d0a8,
absolute=@0xbfffde40, isXSL=0) at guard.h:157
#7 0x4037602e in Processor::readTreeFromURI (this=0x811d0a8, S=@0x811cff8,
newTree=@0x811d0a8,
location=@0xbfffdf10, base=@0xbfffdef0, isXSL=0) at proc.cpp:602
#8 0x40373d91 in Processor::open (this=0x811d0a8, S=@0x811cff8,
sheetURI=0x811dadc arg:/xsl,
inputURI=0x811dc14 arg:/xml) at proc.cpp:277
#9 0x40379633 in SablotRunProcessor (processor_=0x811d0a8,
sheetURI=0x811dadc arg:/xsl,
inputURI=0x811dc14 arg:/xml, resultURI=0x402d9683 arg:/_result,
params=0x0, arguments=0x811dc54)
at sablot.cpp:407
#10 0x402af84a in zif_xslt_process (ht=5, return_value=0x811db5c,
this_ptr=0x0, return_value_used=1)
at sablot.c:514
#11 0x401dcca1 in execute (op_array=0x81123a4) at ./zend_execute.c:1590
#12 0x401ed66c in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at zend.c:814
#13 0x401ff82a in php_execute_script (primary_file=0xb6e0) at
main.c:1307
#14 0x401fa65a in apache_php_module_main (r=0x810a034,
display_source_mode=0) at sapi_apache.c:90
#15 0x401fb4c8 in send_php (r=0x810a034, display_source_mode=0,
filename=0x810f5e4 /home/apache/html/geeba/crash.php) at
mod_php4.c:575
#16 0x401fb535 in send_parsed_php (r=0x810a034) at mod_php4.c:590
#17 0x0806a7ff in ap_invoke_handler () at eval.c:41
#18 0x0807e5eb in process_request_internal () at eval.c:41
#19 0x0807e64c in ap_process_request () at eval.c:41
#20 0x08075a9d in child_main () at eval.c:41
#21 0x08075c48 in make_child () at eval.c:41
#22 0x08075dbc in startup_children () at eval.c:41
#23 0x0807640f in standalone_main () at eval.c:41
#24 0x08076c37 in main () at eval.c:41
#25 0x4008f177 in __libc_start_main (main=0x8076898 main, argc=2,
ubp_av=0xbb14,
init=0x804ed14 _init, fini=0x80abac0 _fini, rtld_fini=0x4000e184
_dl_fini, stack_end=0xbb0c)
at ../sysdeps/generic/libc-start.c:129
Hope this helps. Thank you very much,
Valeriy
--
Edit bug report at: http://bugs.php.net/?id=14709edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12686: --with-sablot breaks the build
From: [EMAIL PROTECTED] Operating system: RedHat 7.0 PHP version: 4.0CVS-2001-08-09 PHP Bug Type: Compile Failure Bug description: --with-sablot breaks the build Having I updated my php4, this is what I get: /bin/sh /home/cvsroot/php4/libtool --silent --mode=compile gcc -I. -I/home/cvsroot/php4/ext/sablot -I/home/cvsroot/php4/main -I/home/cvsroot/php4 -I/usr/local/apache/include -I/home/cvsroot/php4/Zend -I/home/cvsroot/php4/ext/xml/expat -DLINUX=22 -DUSE_HSREGEX -DUSE_EXPAT -DNO_DL_NEEDED -I/home/cvsroot/php4/TSRM -g -O2 -prefer-pic -c sablot.c sablot.c:217: parse error before `*' sablot.c: In function `php_rshutdown_sablot': sablot.c:251: `SABLOTG_HANDLE' undeclared (first use in this function) sablot.c:251: (Each undeclared identifier is reported only once sablot.c:251: for each function it appears in.) sablot.c: In function `_php_sablot_error': sablot.c:1352: `SABLOTG_HANDLE' undeclared (first use in this function) make[3]: *** [sablot.lo] Error 1 make[3]: Leaving directory `/home/cvsroot/php4/ext/sablot' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/cvsroot/php4/ext/sablot' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cvsroot/php4/ext' make: *** [all-recursive] Error 1 -- Edit bug report at: http://bugs.php.net/?id=12686edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11910: Invalid XML declaration generated, missing '?' before the closing ''
From: [EMAIL PROTECTED] Operating system: Linux Redhat 7.0 PHP version: 4.0.4pl1 PHP Bug Type: Sablotron XSL Bug description: Invalid XML declaration generated, missing '?' before the closing 'gt;' This bug was found with Sablotron 0.60. When a stylesheet is using: ... xsl:output method=xml version=1.0 encoding=UTF-8 omit-xml-declaration=no / ... The resulting XML will have the following declaration: ?xml version=1.0 encoding=UTF-8 ... Notice that according to XML 1.0 the declaration should end with '?', not just ''. So the '?' is missing, hence the resulting XML document is not well-formed. Thanks. -- Edit Bug report at: http://bugs.php.net/?id=11910edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10166: read_exif_data loads whole image into memory
From: [EMAIL PROTECTED]
Operating system: Linux 2.2
PHP version: 4.0 Latest CVS (04/04/2001)
PHP Bug Type: Performance problem
Bug description: read_exif_data loads whole image into memory
Some users observed that read_exif_data is too slow with 1MB image files, which is a
typical size for digital camera output. I looked into the implementation
(ext/exif/exif.c) and it looks like the whole compressed image data is always read
into memory, even though read_exif_data should be concerned with just the file header.
Here's a line from function read_exif_data:
PRE
ret = php_read_jpeg_exif(ImageInfo, (*p_name)-value.str.val,1);
/PRE
The last parameter (ReadAll=1), causes the whole image data loaded into memory inside
function scan_JPEG_header:
PRE
if (ReadAll) {
int cp, ep, size;
/* Determine how much file is left. */
cp = ftell(infile);
fseek(infile, 0, SEEK_END);
ep = ftell(infile);
fseek(infile, cp, SEEK_SET);
size = ep-cp;
Data = (uchar *)malloc(size);
if (Data == NULL) {
php_error(E_ERROR,"could not allocate data for entire image");
}
got = fread(Data, 1, size, infile);
if (got != size) {
php_error(E_ERROR,"could not read the rest of the image");
}
Sections[*SectionsRead].Data = Data;
Sections[*SectionsRead].Size = size;
Sections[*SectionsRead].Type = PSEUDO_IMAGE_MARKER;
(*SectionsRead)++;
/*
*HaveAll = 1;
*/
}
return TRUE;
/PRE
I believe the line above should be changed to feed 0 as value of parameter ReadAll.
Thanks.
V
--
Edit Bug report at: http://bugs.php.net/?id=10166edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9673 Updated: Relative paths in require(), require_once(), include(), include_once()
ID: 9673 User Update by: [EMAIL PROTECTED] Status: Analyzed Bug Type: Scripting Engine problem Description: Relative paths in require(), require_once(), include(), include_once() We are talking about all four functions here, not just include(). The resemblance of require() to the #include directive, as documented: quoteThe require() statement replaces itself with the specified file, much like the C preprocessor's #include works./quote If it's a "known issue", are there any plans to fix it? Thanks. Previous Comments: --- [2001-03-15 09:08:11] [EMAIL PROTECTED] First, PHP include() is in no way related or was promised to relate to C preprocessor directives, so no wonder it behaves differently. Now, all relative pathes are resolved against the current directory of the including script (which is the directory where it's located). This is a known issue. Use include_pathes in the meantime. --- [2001-03-10 16:45:48] [EMAIL PROTECTED] Here is an example of how relative paths are currently resolved with cascading inclusions (command line is 'php /home/joe/a.php'): File '/home/joe/a.php': ?php # this include works as expected, # locating '/home/joe/include/b.inc' include_once( 'include/b.inc' ); ? File '/home/joe/include/b.inc': ?php # this include will assume '/home/joe/c.inc', but # not '/home/joe/include/c.inc', as one may expect =( include_once( 'c.inc' ); ? File '/home/joe/include/c.inc': ?php echo 'hello'; ? The way all four functions [require(), require_once(), include(), include_once()] resolve relative paths is counter-intuitive and unproductive with large directory structures, because some trickery is required to fix this problem. Not to mention that it hurts to see a different behavior from C-preprocessor #include directives. If you don't believe me, then see comments to the include() function... --- Full Bug description available at: http://bugs.php.net/?id=9673 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9673: Relative paths in require(), require_once(), include(), include_once()
From: [EMAIL PROTECTED] Operating system: RedHat Linux 7.0 PHP version: 4.0.1pl2 PHP Bug Type: Scripting Engine problem Bug description: Relative paths in require(), require_once(), include(), include_once() Here is an example of how relative paths are currently resolved with cascading inclusions (command line is 'php /home/joe/a.php'): File '/home/joe/a.php': ?php # this include works as expected, # locating '/home/joe/include/b.inc' include_once( 'include/b.inc' ); ? File '/home/joe/include/b.inc': ?php # this include will assume '/home/joe/c.inc', but # not '/home/joe/include/c.inc', as one may expect =( include_once( 'c.inc' ); ? File '/home/joe/include/c.inc': ?php echo 'hello'; ? The way all four functions [require(), require_once(), include(), include_once()] resolve relative paths is counter-intuitive and unproductive with large directory structures, because some trickery is required to fix this problem. Not to mention that it hurts to see a different behavior from C-preprocessor #include directives. If you don't believe me, then see comments to the include() function... -- Edit Bug report at: http://bugs.php.net/?id=9673edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
