#33227 [Opn->Fbk]: zend_strtod() broken on big-endian arm
ID: 33227 Updated by: [EMAIL PROTECTED] Reported By: jbparsons at ucdavis dot edu -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: "unslung" - www.nslu2-linux.org PHP Version: 5.0.4 New Comment: See lines 126-133 in zend_strtod.c Previous Comments: [2005-06-03 03:44:43] jbparsons at ucdavis dot edu Description: On big-endian arm systems, php sometimes crashes (infinite loop) inside zend_strtod(). The problem seems to be the code at line 261 of zend_strtod.c, which apparently assumes that every arm system has little-endian integers: #if defined(IEEE_LITTLE_ENDIAN) + defined(VAX) + defined(__arm__) #define Storeinc(a,b,c) (((unsigned short *)a)[1] = (unsigned short)b, \ ((unsigned short *)a)[0] = (unsigned short)c, a++) #else #define Storeinc(a,b,c) (((unsigned short *)a)[0] = (unsigned short)b, \ ((unsigned short *)a)[1] = (unsigned short)c, a++) #endif Reproduce code: --- Expected result: startend Actual result: -- (gdb) run Starting program: /share/hdd/data/home/jp30/t/php foo.php start [...minutes pass, then Ctrl-C is pressed...] Program received signal SIGINT, Interrupt. 0x00146528 in zend_strtod () (gdb) bt #0 0x00146528 in zend_strtod () Cannot access memory at address 0x4 -- Edit this bug report at http://bugs.php.net/?id=33227&edit=1
#33226 [Opn->WFx]: php 5.0.4 no longer detects endianness when cross-compiling
ID: 33226 Updated by: [EMAIL PROTECTED] Reported By: jbparsons at ucdavis dot edu -Status: Open +Status: Wont fix -Bug Type: *Compile Issues +Bug Type: Compile Failure Operating System: linux PHP Version: 5.0.4 New Comment: Yes, life is hard sometimes. If you can provide a reliable way to detect endianness when cross-compiling, feel free to send a patch. Previous Comments: [2005-06-03 02:32:18] jbparsons at ucdavis dot edu Description: php 5.0.3 and earlier used AC_C_BIGENDIAN during configuration to detect the endianness of the target system. This autoconf macro is capable of detecting the endianness of many systems even when cross-compiling. php 5.0.4 now uses AC_TRY_RUN instead, which means that it is no longer able to detect the endianness of a target, and it must instead be configured manually. This makes it harder to configure php correctly when building for embedded systems, such as the Linksys nslu2, where this problem was noticed. -- Edit this bug report at http://bugs.php.net/?id=33226&edit=1
#33192 [Opn->Fbk]: failure to pass certificate in handshake of openssl related transport sockets
ID: 33192
Updated by: [EMAIL PROTECTED]
Reported By: justin dot d dot allen at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Sockets related
Operating System: linux(slackware)
PHP Version: 5.0.4(latest snapshot)
New Comment:
Looks to me like you want to be using sslv3:// instead of tls:// there
(just based on your server output).
Use ssl:// for automatic v2 or v3 support. Only use tls:// when the
server can only speak tls; it's a different dialect of SSL.
The context options for openssl, including tls, are all bundled under
the name "ssl".
I think your code should probably look more like this:
$c = stream_context_create(array(
"ssl" => array(
"local_cert" => "sec.pem",
... other options ...
)
);
$s = stream_socket_client("sslv3://.", ., $c);
Previous Comments:
[2005-06-03 02:54:18] justin dot d dot allen at gmail dot com
so I added php_error_docref displays to the certfile and passphrase
GET_VER_OPT sections of php_SSL_new_from_context and recieved no
display from either.
It seems that the variables aren't getting parsed, but truthfuly, I'm
hacking with very broad swings on that one... and, I haven't at all
looked at the inner workings of the GET_VER_OPT macro.
[2005-06-02 20:48:27] justin dot d dot allen at gmail dot com
crap... ignore that... forgot to change SSL_do_handshake() to
SSL_connect() when took out SSL_set_connect_state()... so I can connect
using what seems to be the same connection method in C.
[2005-06-02 20:12:48] justin dot d dot allen at gmail dot com
am also able to connect with c code
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static int password_callback(char* buf, int num, int verify, void*
data) {
strncpy(buf, (char*)(data),num);
buf[num -1] = '\0';
return (strlen(buf));
}
int main() {
char *certfile = "sec.pem";
SSL_METHOD* meth;
SSL_CTX* ctx;
SSL_library_init();
SSL_load_error_strings();
meth=TLSv1_method();
ctx=SSL_CTX_new(meth);
SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL);
SSL_CTX_set_cipher_list(ctx, "DEFAULT");
if (SSL_CTX_use_certificate_chain_file(ctx,certfile) != 1)
perror("error loading cert");
if (SSL_CTX_use_PrivateKey_file(ctx, certfile,SSL_FILETYPE_PEM) !=
1)
perror("error loading key");
SSL_CTX_set_default_passwd_cb_userdata(ctx, (void*)"qwerty");
SSL_CTX_set_default_passwd_cb(ctx, password_callback);
SSL* ssl = SSL_new(ctx);
int sd = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in sa;
memset(&sa, '\0', sizeof(sa));
sa.sin_family = AF_INET;
sa.sin_addr.s_addr = inet_addr("206.127.2.49");
sa.sin_port= htons(1234);
connect(sd, (struct sockaddr*) &sa, sizeof(sa));
getpeername(sd,(struct sockaddr*) &sa,(socklen_t*)(sizeof(sa)));
SSL_set_fd(ssl, sd);
SSL_set_connect_state(ssl);
int state = SSL_do_handshake(ssl);
if (state!=1) {
SSL_get_error(ssl,state);
ERR_print_errors_fp(stderr);
return 0;
}
sleep(15);
return 1;
}
which if I'm right in assuming SSL *php_SSL_new_from_context(SSL_CTX
*ctx, php_stream *stream TSRMLS_DC) in /ext/openssl/openssl.c is the
context creator should be logically the same thing.
actually I looked at the methods and if I take out the
SSL_set_connect_state() and switch the method to TSLv1_client_method()
I get the errors out of C... so it looks like it's in my openssl
libraries...
I'm running 0.9.7g, which is the latest stable... I'll try the snapshot
and see if that helps... I'll let you know if it does but after that, if
it doesn't, I'll probably bug openSSL about it cause it seems to be
their deal...
I will say my workaround(which I had previously thought was just
different syntax) worked for me in C... but I can see where you would
want to keep all CTX settings in php_SSL_new_from_context and not put
them in php_openssl_setup_crypto where you set up the methods... it's
alot cleaner that way
[2005-06-01 00:35:48] justin dot d dot allen at gmail dot com
installed php5-latest.tar.gz
am now getting the same error from server
but error from client is the same SSL error with added warnings
Warning: stream_socket_client(): SSL operation failed with code 1.
OpenSSL Error messages:
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure in ssl.conector.php on line 17
Warning: stream_socket_client(): Failed to enable crypto in
ssl.conector.php on line 17
Warning: stream_socket_client(): unable to connect to tls://host:port
(Unknown error) in ssl.conector.php on line 17
(0)
still no certificate passed
#33227 [NEW]: zend_strtod() broken on big-endian arm
From: jbparsons at ucdavis dot edu Operating system: "unslung" - www.nslu2-linux.org PHP version: 5.0.4 PHP Bug Type: Reproducible crash Bug description: zend_strtod() broken on big-endian arm Description: On big-endian arm systems, php sometimes crashes (infinite loop) inside zend_strtod(). The problem seems to be the code at line 261 of zend_strtod.c, which apparently assumes that every arm system has little-endian integers: #if defined(IEEE_LITTLE_ENDIAN) + defined(VAX) + defined(__arm__) #define Storeinc(a,b,c) (((unsigned short *)a)[1] = (unsigned short)b, \ ((unsigned short *)a)[0] = (unsigned short)c, a++) #else #define Storeinc(a,b,c) (((unsigned short *)a)[0] = (unsigned short)b, \ ((unsigned short *)a)[1] = (unsigned short)c, a++) #endif Reproduce code: --- Expected result: startend Actual result: -- (gdb) run Starting program: /share/hdd/data/home/jp30/t/php foo.php start [...minutes pass, then Ctrl-C is pressed...] Program received signal SIGINT, Interrupt. 0x00146528 in zend_strtod () (gdb) bt #0 0x00146528 in zend_strtod () Cannot access memory at address 0x4 -- Edit bug report at http://bugs.php.net/?id=33227&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33227&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33227&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33227&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33227&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33227&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33227&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33227&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33227&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33227&r=support Expected behavior: http://bugs.php.net/fix.php?id=33227&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33227&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33227&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33227&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33227&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33227&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33227&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33227&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33227&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33227&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33227&r=mysqlcfg
#33192 [Opn]: failure to pass certificate in handshake of openssl related transport sockets
ID: 33192
User updated by: justin dot d dot allen at gmail dot com
Reported By: justin dot d dot allen at gmail dot com
Status: Open
Bug Type: Sockets related
Operating System: linux(slackware)
PHP Version: 5.0.4(latest snapshot)
New Comment:
so I added php_error_docref displays to the certfile and passphrase
GET_VER_OPT sections of php_SSL_new_from_context and recieved no
display from either.
It seems that the variables aren't getting parsed, but truthfuly, I'm
hacking with very broad swings on that one... and, I haven't at all
looked at the inner workings of the GET_VER_OPT macro.
Previous Comments:
[2005-06-02 20:48:27] justin dot d dot allen at gmail dot com
crap... ignore that... forgot to change SSL_do_handshake() to
SSL_connect() when took out SSL_set_connect_state()... so I can connect
using what seems to be the same connection method in C.
[2005-06-02 20:12:48] justin dot d dot allen at gmail dot com
am also able to connect with c code
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static int password_callback(char* buf, int num, int verify, void*
data) {
strncpy(buf, (char*)(data),num);
buf[num -1] = '\0';
return (strlen(buf));
}
int main() {
char *certfile = "sec.pem";
SSL_METHOD* meth;
SSL_CTX* ctx;
SSL_library_init();
SSL_load_error_strings();
meth=TLSv1_method();
ctx=SSL_CTX_new(meth);
SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL);
SSL_CTX_set_cipher_list(ctx, "DEFAULT");
if (SSL_CTX_use_certificate_chain_file(ctx,certfile) != 1)
perror("error loading cert");
if (SSL_CTX_use_PrivateKey_file(ctx, certfile,SSL_FILETYPE_PEM) !=
1)
perror("error loading key");
SSL_CTX_set_default_passwd_cb_userdata(ctx, (void*)"qwerty");
SSL_CTX_set_default_passwd_cb(ctx, password_callback);
SSL* ssl = SSL_new(ctx);
int sd = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in sa;
memset(&sa, '\0', sizeof(sa));
sa.sin_family = AF_INET;
sa.sin_addr.s_addr = inet_addr("206.127.2.49");
sa.sin_port= htons(1234);
connect(sd, (struct sockaddr*) &sa, sizeof(sa));
getpeername(sd,(struct sockaddr*) &sa,(socklen_t*)(sizeof(sa)));
SSL_set_fd(ssl, sd);
SSL_set_connect_state(ssl);
int state = SSL_do_handshake(ssl);
if (state!=1) {
SSL_get_error(ssl,state);
ERR_print_errors_fp(stderr);
return 0;
}
sleep(15);
return 1;
}
which if I'm right in assuming SSL *php_SSL_new_from_context(SSL_CTX
*ctx, php_stream *stream TSRMLS_DC) in /ext/openssl/openssl.c is the
context creator should be logically the same thing.
actually I looked at the methods and if I take out the
SSL_set_connect_state() and switch the method to TSLv1_client_method()
I get the errors out of C... so it looks like it's in my openssl
libraries...
I'm running 0.9.7g, which is the latest stable... I'll try the snapshot
and see if that helps... I'll let you know if it does but after that, if
it doesn't, I'll probably bug openSSL about it cause it seems to be
their deal...
I will say my workaround(which I had previously thought was just
different syntax) worked for me in C... but I can see where you would
want to keep all CTX settings in php_SSL_new_from_context and not put
them in php_openssl_setup_crypto where you set up the methods... it's
alot cleaner that way
[2005-06-01 00:35:48] justin dot d dot allen at gmail dot com
installed php5-latest.tar.gz
am now getting the same error from server
but error from client is the same SSL error with added warnings
Warning: stream_socket_client(): SSL operation failed with code 1.
OpenSSL Error messages:
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure in ssl.conector.php on line 17
Warning: stream_socket_client(): Failed to enable crypto in
ssl.conector.php on line 17
Warning: stream_socket_client(): unable to connect to tls://host:port
(Unknown error) in ssl.conector.php on line 17
(0)
still no certificate passed
stream_socket_enable_crypto makes no difference
[2005-05-31 07:22:24] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
stream_socket_enable_crypto() was added in PHP 5.1-dev,
it's not (and will not be) in PHP 5.0.x
[2005-05-31 05:36:42] justin dot d dot allen at gmail dot com
line that was truncated on exapmle source is
if (!fp =
stream_sockect_client("tls://host:port",$errno,$errstr,30,STREAM_CLIENT_CONNECT/*|STREAM_CLIENT_ASY
#33226 [NEW]: php 5.0.4 no longer detects endianness when cross-compiling
From: jbparsons at ucdavis dot edu Operating system: linux PHP version: 5.0.4 PHP Bug Type: *Compile Issues Bug description: php 5.0.4 no longer detects endianness when cross-compiling Description: php 5.0.3 and earlier used AC_C_BIGENDIAN during configuration to detect the endianness of the target system. This autoconf macro is capable of detecting the endianness of many systems even when cross-compiling. php 5.0.4 now uses AC_TRY_RUN instead, which means that it is no longer able to detect the endianness of a target, and it must instead be configured manually. This makes it harder to configure php correctly when building for embedded systems, such as the Linksys nslu2, where this problem was noticed. -- Edit bug report at http://bugs.php.net/?id=33226&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33226&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33226&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33226&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33226&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33226&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33226&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33226&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33226&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33226&r=support Expected behavior: http://bugs.php.net/fix.php?id=33226&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33226&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33226&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33226&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33226&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33226&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33226&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33226&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33226&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33226&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33226&r=mysqlcfg
#33225 [NEW]: PHP sends multiple Status headers
From: phpbugs at thequod dot de
Operating system:
PHP version: 5.0.4
PHP Bug Type: CGI related
Bug description: PHP sends multiple Status headers
Description:
Multiple "Status" lines get send when
using "header('Location: url')", which produces an
additional 302 (REDIRECT) status code.
This causes FastCGI (at least) to produce a 500 Internal
Server Error:
FastCGI: comm with server "/path/to/fcgi-starter" aborted:
error parsing headers: duplicate header 'status'
Documentation
(http://us2.php.net/manual/en/function.header.php) says:
Note: The HTTP status header line will always be the
first sent to the client [[NOT TRUE! - reproduce: echo
"" | php5/bin/php-fcgi]],
regardless of the
actual header() call being the first or not. The status
may be overridden by calling header() with a new status
line at any time unless the HTTP headers have already been
sent [[NOT TRUE! - this bug]].
---
configure (both PHP5 and PHP4):
./configure --enable-memory-limit
--enable-force-cgi-redirect \
--enable-track-vars --with-pcre-regex --with-mysql
--without-sqlite \
--with-zlib --with-bz2 --enable-mbstring --with-openssl
--enable-exif \
--with-dom=shared --with-ttf=shared --with-gd=shared
--enable-calendar \
--with-iconv --enable-inline-optimization
--enable-gd-native-ttf \
--with-ldap --with-ldap-sasl \
--with-gettext \
--without-mm --enable-fastcgi --prefix=/home/daniel/php5
Reproduce code:
---
$ cat << "?>" | php5/bin/php-fcgi
http://www.example.org' );
?>
Expected result:
Status: 301
Content-type: text/html
X-Powered-By: PHP/5.0.4
Location: http://www.example.org
Actual result:
--
Status: 302
Content-type: text/html
X-Powered-By: PHP/5.0.4
Status: 301
Location: http://www.example.org
--
Edit bug report at http://bugs.php.net/?id=33225&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33225&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33225&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33225&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33225&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33225&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33225&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33225&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33225&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33225&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33225&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33225&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33225&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33225&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33225&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33225&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33225&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33225&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33225&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33225&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33225&r=mysqlcfg
#28605 [Asn->Csd]: bug21523.phpt test never end (-mieee fixes it..)
ID: 28605 Updated by: [EMAIL PROTECTED] Reported By: tbp at poly dot polytechnique dot fr -Status: Assigned +Status: Closed Bug Type: Math related Operating System: Compaq Tru64 UNIX v5.1 PHP Version: 5CVS, 4CVS (2005-03-21) Assigned To: helly New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-04-18 13:14:13] tbp at poly dot polytechnique dot fr You are right "-mieee" gcc option, fix this test problem: [EMAIL PROTECTED]:/Admin/SRC/Apache/php4-STABLE-200504061830]# sapi/cli/php ext/standard/tests/math/bug21523.phpt --TEST-- Bug #21523 number_format tries to allocate negative amount of memory --FILE-- string(2775) "-2,000.0! 0! 0! 0" OK--EXPECT-- string(2775) "-2,000.0! 000
#33222 [Asn->Csd]: segmentation fault when trying to run curl_close from the handler function
ID: 33222 Updated by: [EMAIL PROTECTED] Reported By: public at grik dot net -Status: Assigned +Status: Closed Bug Type: cURL related Operating System: * PHP Version: 5.*, 4.* Assigned To: tony2001 New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-06-02 21:44:08] [EMAIL PROTECTED] Assigned to myself. Patch pending. [2005-06-02 19:10:52] public at grik dot net Segmentation fault persists curl_version(): Array ( [version_number] => 462336 [age] => 2 [features] => 540 [ssl_version_number] => 0 [version] => 7.14.0 [host] => i686-pc-linux-gnu [ssl_version] => OpenSSL/0.9.7a [libz_version] => 1.1.4 [protocols] => Array ( [0] => ftp [1] => gopher [2] => telnet [3] => dict [4] => ldap [5] => http [6] => file [7] => https [8] => ftps ) ) [2005-06-02 18:40:53] public at grik dot net CURL Informationlibcurl/7.12.0 it's not old, I upgraded it not so long ago, and manual says PHP5 requires 7.10.5 trying to upgrade to CURL 7.14 [2005-06-02 18:07:19] [EMAIL PROTECTED] What is the version of cURL used? What if you try to upgrade it to the latest available from http://curl.haxx.se/download.html ? [2005-06-02 17:20:47] public at grik dot net Program received signal SIGSEGV, Segmentation fault. 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "") at transfer.c:890 890 } The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/33222 -- Edit this bug report at http://bugs.php.net/?id=33222&edit=1
#33142 [Bgs]: Session info not getting saved correctly
ID: 33142 User updated by: jkump at everestgt dot com Reported By: jkump at everestgt dot com Status: Bogus Bug Type: Session related Operating System: Solaris 9 PHP Version: 5.0.4 New Comment: This problem occurs when simplexml_load_string is used within the session. Previous Comments: [2005-05-26 19:40:44] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. This is not a support forum where you ask how to use PHP.. (Thre is no bug here, sessions work just fine) [2005-05-26 02:35:43] jkump at everestgt dot com That is fine. I will try that but, this is the error that I am getting when I come back in and nothing is available in the $_SESSION superglobal. [24-May-2005 16:06:22] PHP Warning: session_start() [function.session-start]: Node no longer exists in /export/home/httpd/corp/my_everestkc_net/modules/BillOnline/session.class.php on line 64 [24-May-2005 16:06:22] PHP Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /export/home/httpd/corp/my_everestkc_net/modules/BillOnline/session.class.php:64) in /export/home/httpd/corp/my_everestkc_net/modules/BillOnline/session.class.php on line 64 [24-May-2005 16:06:22] PHP Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /export/home/httpd/corp/my_everestkc_net/modules/BillOnline/session.class.php:64) in /export/home/httpd/corp/my_everestkc_net/modules/BillOnline/session.class.php on line 64 These show up on the second trip into the code. I cant initialize the session again. When I assign stuff to $_SESSION['foo'] and then exit the script. come back into the script via a link on the page. The session is no longer valid and the $_SESSION info is gone. The code works correctly in php 4.3.11. and it fails on 5.0.4. I can try and setup an external area so you can see what is happening. THanks [2005-05-26 00:37:20] [EMAIL PROTECTED] Use 'isset($_SESSION['foo'])' and it will work just fine. (you're setting it to non-false value..) [2005-05-25 18:57:15] jkump at everestgt dot com Description: When using session_start() and coming into the page a second time. The $_SESSION[] information is not getting saved correctly. When returing to the page in an appropriate amount of time the session_start functions says the node no lionger exists. Works correctly in php 4.3.11 but not in 5.0.4 Reproduce code: --- Expected result: secnd time called should say found. Actual result: -- Get warning messages about node no longer valid. -- Edit this bug report at http://bugs.php.net/?id=33142&edit=1
#16079 [Com]: Allow '.' (concat) operator on static strings
ID: 16079
Comment by: pornel at despammed dot com
Reported By: steve dot venable at lmco dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 4.1.1
New Comment:
Not fixed in latest snapshot (PHP5.1.0-dev). I was about to file
bugreport about:
class Test1 {
const test1 = 'foo'.'bar';
}
class Test2 {
static $test2 = array('foo'.'bar');
}
define('foo','foo');
class Test3 {
const test3 = foo.'bar';
}
Workaround is to use define() for all string concatenation and then
using these constants as initializers.
Previous Comments:
[2002-03-14 14:01:32] steve dot venable at lmco dot com
I can understand requiring constants for static initialization. But
can the parser be modified to support operators on constants for static
initializations? This is especially true for long strings which I can't
even break at the end of line for readability. (I almost submitted this
as a bug :)
Examples:
$v = 1 + 2; // Okay
static $s = 1 + 2; // Fails parse
$v = "this long "
."string"; // Okay
static $s = "this long "
."string"; // Fails parse
Since only constants are involved the parser could collapse the
expression without difficulty. This makes the code much more readable
(again thinking of very long strings). In my case I'm building an
array of error messages and don't want the array build to occur
everytime the function is called, hence I made it static.
--
Edit this bug report at http://bugs.php.net/?id=16079&edit=1
#33222 [Opn->Asn]: segmentation fault when trying to run curl_close from the handler function
ID: 33222 Updated by: [EMAIL PROTECTED] Reported By: public at grik dot net -Status: Open +Status: Assigned Bug Type: cURL related Operating System: * PHP Version: 5.*, 4.* -Assigned To: +Assigned To: tony2001 New Comment: Assigned to myself. Patch pending. Previous Comments: [2005-06-02 19:10:52] public at grik dot net Segmentation fault persists curl_version(): Array ( [version_number] => 462336 [age] => 2 [features] => 540 [ssl_version_number] => 0 [version] => 7.14.0 [host] => i686-pc-linux-gnu [ssl_version] => OpenSSL/0.9.7a [libz_version] => 1.1.4 [protocols] => Array ( [0] => ftp [1] => gopher [2] => telnet [3] => dict [4] => ldap [5] => http [6] => file [7] => https [8] => ftps ) ) [2005-06-02 18:40:53] public at grik dot net CURL Informationlibcurl/7.12.0 it's not old, I upgraded it not so long ago, and manual says PHP5 requires 7.10.5 trying to upgrade to CURL 7.14 [2005-06-02 18:07:19] [EMAIL PROTECTED] What is the version of cURL used? What if you try to upgrade it to the latest available from http://curl.haxx.se/download.html ? [2005-06-02 17:20:47] public at grik dot net Program received signal SIGSEGV, Segmentation fault. 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "") at transfer.c:890 890 } [2005-06-02 17:17:18] public at grik dot net backtrace: (gdb) bt #0 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "") at transfer.c:890 #1 0x403aaf56 in Transfer (conn=0x81f584c) at transfer.c:1480 #2 0x403ab94a in Curl_perform (data=0x81f7b7c) at transfer.c:1985 #3 0x403ac175 in curl_easy_perform (curl=0x81f7b7c) at easy.c:378 #4 0x4002c3d2 in zif_curl_exec (ht=1, return_value=0x81f55dc, this_ptr=0x0, return_value_used=0) at /usr/src/web/php5-STABLE-200505161036/ext/curl/interface.c:1261 #5 0x0814a267 in zend_do_fcall_common_helper (execute_data=0xbfffc610, opline=0x81f5068, op_array=0x81f09a4) at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2747 #6 0x0814a8c8 in zend_do_fcall_handler (execute_data=0xbfffc610, opline=0x81f5068, op_array=0x81f09a4) at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2881 #7 0x08147188 in execute (op_array=0x81f09a4) at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:1417 #8 0x081239fe in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php5-STABLE-200505161036/Zend/zend.c:1080 #9 0x080e5323 in php_execute_script (primary_file=0xbfffe9e0) at /usr/src/web/php5-STABLE-200505161036/main/main.c:1646 #10 0x08153187 in main (argc=4, argv=0xbfffea84) at /usr/src/web/php5-STABLE-200505161036/sapi/cgi/cgi_main.c:1582 #11 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/33222 -- Edit this bug report at http://bugs.php.net/?id=33222&edit=1
#33192 [Opn]: failure to pass certificate in handshake of openssl related transport sockets
ID: 33192
User updated by: justin dot d dot allen at gmail dot com
Reported By: justin dot d dot allen at gmail dot com
Status: Open
Bug Type: Sockets related
Operating System: linux(slackware)
PHP Version: 5.0.4(latest snapshot)
New Comment:
crap... ignore that... forgot to change SSL_do_handshake() to
SSL_connect() when took out SSL_set_connect_state()... so I can connect
using what seems to be the same connection method in C.
Previous Comments:
[2005-06-02 20:12:48] justin dot d dot allen at gmail dot com
am also able to connect with c code
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static int password_callback(char* buf, int num, int verify, void*
data) {
strncpy(buf, (char*)(data),num);
buf[num -1] = '\0';
return (strlen(buf));
}
int main() {
char *certfile = "sec.pem";
SSL_METHOD* meth;
SSL_CTX* ctx;
SSL_library_init();
SSL_load_error_strings();
meth=TLSv1_method();
ctx=SSL_CTX_new(meth);
SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL);
SSL_CTX_set_cipher_list(ctx, "DEFAULT");
if (SSL_CTX_use_certificate_chain_file(ctx,certfile) != 1)
perror("error loading cert");
if (SSL_CTX_use_PrivateKey_file(ctx, certfile,SSL_FILETYPE_PEM) !=
1)
perror("error loading key");
SSL_CTX_set_default_passwd_cb_userdata(ctx, (void*)"qwerty");
SSL_CTX_set_default_passwd_cb(ctx, password_callback);
SSL* ssl = SSL_new(ctx);
int sd = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in sa;
memset(&sa, '\0', sizeof(sa));
sa.sin_family = AF_INET;
sa.sin_addr.s_addr = inet_addr("206.127.2.49");
sa.sin_port= htons(1234);
connect(sd, (struct sockaddr*) &sa, sizeof(sa));
getpeername(sd,(struct sockaddr*) &sa,(socklen_t*)(sizeof(sa)));
SSL_set_fd(ssl, sd);
SSL_set_connect_state(ssl);
int state = SSL_do_handshake(ssl);
if (state!=1) {
SSL_get_error(ssl,state);
ERR_print_errors_fp(stderr);
return 0;
}
sleep(15);
return 1;
}
which if I'm right in assuming SSL *php_SSL_new_from_context(SSL_CTX
*ctx, php_stream *stream TSRMLS_DC) in /ext/openssl/openssl.c is the
context creator should be logically the same thing.
actually I looked at the methods and if I take out the
SSL_set_connect_state() and switch the method to TSLv1_client_method()
I get the errors out of C... so it looks like it's in my openssl
libraries...
I'm running 0.9.7g, which is the latest stable... I'll try the snapshot
and see if that helps... I'll let you know if it does but after that, if
it doesn't, I'll probably bug openSSL about it cause it seems to be
their deal...
I will say my workaround(which I had previously thought was just
different syntax) worked for me in C... but I can see where you would
want to keep all CTX settings in php_SSL_new_from_context and not put
them in php_openssl_setup_crypto where you set up the methods... it's
alot cleaner that way
[2005-06-01 00:35:48] justin dot d dot allen at gmail dot com
installed php5-latest.tar.gz
am now getting the same error from server
but error from client is the same SSL error with added warnings
Warning: stream_socket_client(): SSL operation failed with code 1.
OpenSSL Error messages:
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure in ssl.conector.php on line 17
Warning: stream_socket_client(): Failed to enable crypto in
ssl.conector.php on line 17
Warning: stream_socket_client(): unable to connect to tls://host:port
(Unknown error) in ssl.conector.php on line 17
(0)
still no certificate passed
stream_socket_enable_crypto makes no difference
[2005-05-31 07:22:24] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
stream_socket_enable_crypto() was added in PHP 5.1-dev,
it's not (and will not be) in PHP 5.0.x
[2005-05-31 05:36:42] justin dot d dot allen at gmail dot com
line that was truncated on exapmle source is
if (!fp =
stream_sockect_client("tls://host:port",$errno,$errstr,30,STREAM_CLIENT_CONNECT/*|STREAM_CLIENT_ASYNC_CONNECT*/,$fc))
{
[2005-05-31 03:36:49] justin dot d dot allen at gmail dot com
Description:
Have been unable to get a socket_stream_client() to pass the
certificate whose path is specified by stream_context_create().
also stream_socket_enable_crypto() is an unknown function.
Reproduce code:
---
array(
'passphrase'=>'***',
'allow_self_signed'=>'TRUE',
'local_
#33224 [Opn->Fbk]: require_once includes the same file again even if path/filename is identical
ID: 33224
Updated by: [EMAIL PROTECTED]
Reported By: ypae at hotmail dot com
-Status: Open
+Status: Feedback
-Bug Type: Unknown/Other Function
+Bug Type: Scripting Engine problem
Operating System: Windows 2003 Server
PHP Version: 5.0.4
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Previous Comments:
[2005-06-02 17:16:47] ypae at hotmail dot com
Description:
When I created a lib.inc.php that has a few functions defined (e.g.
getmicrocode(), myfunction()) and try to include it on several files
with require_once, it somehow included more than once even though the
end result of 'path/filename' is identical.
My understanding of require_once limitation on Windows (or non-POSIX)
platform was that if you have mixed case with the same file name, it
will be included again. Another words, as long as you have identical
"path/filename" as part of require_once statement, it should include
only once.
As a result, since you cannot redeclare the same function within the
page, you get:
Fatal error: Cannot redeclare "functionname()" (previously declared
in...
Reproduce code:
---
For example,
On lib.inc.php:
===
myfunction1()
{ echo "hello!";}
myfunction2()
{ echo "hello again!";}
On index.php
$_my_absolute_path = 'c:/inetpub/wwwroot/';
require_once($_my_absolute_path.'lib.inc.php');
require_once($_my_absolute_path.'template.inc.php');
on template.inc.php
===
$_my_absolute_path = 'c:/inetpub/wwwroot/';
require_once($_my_absolute_path.'lib.inc.php'); // Just in case someone
didn't call this previously
The realistic code is quite complex:
A require_once B and C
B require_once C and *D*
C require_once *D*
and *D* causes redeclare issue when I load A.
Expected result:
the second attempt to include lib.inc.php by using require_once should
be ignored because it was already loaded.
The same code running on Linux works perfectly and it used to be fine
on PHP 4.3.10
But right after I rebuild the server with PHP 5.0.4, I got the
following error:
Fatal error: Cannot redeclare myfunction1() (previously declared in...
Actual result:
--
the second attempt to include lib.inc.php by using require_once WAS
performed and it causes error.
--
Edit this bug report at http://bugs.php.net/?id=33224&edit=1
#33175 [Opn->Bgs]: cant cross compiling arm linux
ID: 33175 Updated by: [EMAIL PROTECTED] Reported By: esteban at correo dot unam dot mx -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: linux PHP Version: 4CVS-2005-05-28 (stable) New Comment: We really don't support cross compiling. You really need to know what you're doing yourself and know how to do it. In this case: You need a compiler that sets __arm__ Previous Comments: [2005-06-02 19:29:04] esteban at correo dot unam dot mx If I try with php5-200506021430, I need the correct vesion of the libxml2 if I want to configure with the pear and xml options but if I disable this options and compile I have the same error. [2005-06-02 00:39:13] [EMAIL PROTECTED] DO NOT use --host! And do not paste any more long configure outputs here if not asked for.. Try again, WITHOUT it and this time using FRESH sources. (get the latest PHP 5 snapshot!) [2005-05-31 17:12:00] esteban at correo dot unam dot mx I'm compiling under i686-pc-linux (fedora core 1) and I want to run in AEL (Arcom Embebed Linux) with arm linux and kernel 2.4.26 plataform. I'm using toolchain of arcom for cross compiling and qemu like a processor emulator in my build pc, with the options: >--target=arm-linux \ >--host=arm-linux \ >--build=i686-pc-linux Part of configure is: loading cache ./config.cache checking host system type... i686-pc-linux-gnu checking for gcc... (cached) arm-linux-gcc checking whether the C compiler (arm-linux-gcc -I/opt/arcom/arm-linux/include ) works... yes checking whether the C compiler (arm-linux-gcc -I/opt/arcom/arm-linux/include ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether arm-linux-gcc accepts -g... (cached) yes checking whether arm-linux-gcc and cc understand -c and -o together... (cached) yes checking how to run the C preprocessor... (cached) arm-linux-gcc -E checking for AIX... no checking if compiler supports -R... (cached) no checking if compiler supports -Wl,-rpath,... (cached) yes checking for re2c... (cached) exit 0; checking whether ln -s works... (cached) yes checking for mawk... (cached) gawk checking for bison... (cached) bison -y checking bison version... 1.875 (ok) checking for flex... (cached) flex checking for yywrap in -lfl... (cached) yes checking lex output file root... (cached) lex.yy checking whether yytext is a pointer... (cached) yes checking for working const... (cached) yes checking flex version... 2.5.4 (ok) checking whether byte ordering is bigendian... (cached) no checking whether to force non-PIC code in shared modules... yes checking for pthreads_cflags... (cached) checking for pthreads_lib... (cached) but it's happening what I already described you. Do you really think is just a configuration problem? :$ What about '--without-pear' option? If I change zend_strtod.c file how I already described you and use the option --enable-sockes for configure, the php info page and an simple program with sockets works but i don´t know the possible problems if I work with this environment And thanks a lot for your answers [2005-05-31 08:43:51] [EMAIL PROTECTED] Under what OS/platform are you compiling ? And _for_ what OS/platform? I think you've simply using the wrong configure options, see ./configure --help and options --target and --build (--host is something else) [2005-05-31 01:45:26] esteban at correo dot unam dot mx HI !! For this test I used php-4.3.11 I edited the file zend_strtod.c changing the line: #if defined(IEEE_LITTLE_ENDIAN) + defined(IEEE_BIG_ENDIAN) + defined(VAX) + defined(IBM) != 1 for #if defined(IEEE_BIG_ENDIAN) + defined(VAX)\ + defined(IBM) != 1 when I compiled it finished Ok then I ran the command "make install" but this ocurred Installing PEAR environment: /flashcard/usr/local/php-arm/lib/php/ qemu: uncaught target signal 11 (Segmentation fault) - exiting make[1]: *** [install-pear-installer] Error 245 make: *** [install-pear] Error 2 Next I configured php with this line: >CC="arm-linux-gcc" \ >CXX="arm-linux-g++" \ >CFLAGS="-I/opt/arcom/arm-linux/include" \ >LIBS="-L/opt/arcom/arm-linux/lib" \ >RANLIB="arm-linux-ranlib" >./configure '--prefix=/flashcard/usr/local/php-arm \ >--with-pgsql=/flashcard/usr/local/pg7.4.8-arm >--with-apxs=/flashcard/usr/local/apache-arm/bin/apxs \ >--without-pear --without-mysql --host=arm-linux \ >--build=i386-linux' SEE the '--without-pear' option after I executed "make" and "make install" commands this compile and run fine. NOW my question is: This option how affects the performance o
#33192 [Opn]: failure to pass certificate in handshake of openssl related transport sockets
ID: 33192
User updated by: justin dot d dot allen at gmail dot com
Reported By: justin dot d dot allen at gmail dot com
Status: Open
Bug Type: Sockets related
Operating System: linux(slackware)
PHP Version: 5.0.4(latest snapshot)
New Comment:
am also able to connect with c code
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static int password_callback(char* buf, int num, int verify, void*
data) {
strncpy(buf, (char*)(data),num);
buf[num -1] = '\0';
return (strlen(buf));
}
int main() {
char *certfile = "sec.pem";
SSL_METHOD* meth;
SSL_CTX* ctx;
SSL_library_init();
SSL_load_error_strings();
meth=TLSv1_method();
ctx=SSL_CTX_new(meth);
SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL);
SSL_CTX_set_cipher_list(ctx, "DEFAULT");
if (SSL_CTX_use_certificate_chain_file(ctx,certfile) != 1)
perror("error loading cert");
if (SSL_CTX_use_PrivateKey_file(ctx, certfile,SSL_FILETYPE_PEM) !=
1)
perror("error loading key");
SSL_CTX_set_default_passwd_cb_userdata(ctx, (void*)"qwerty");
SSL_CTX_set_default_passwd_cb(ctx, password_callback);
SSL* ssl = SSL_new(ctx);
int sd = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in sa;
memset(&sa, '\0', sizeof(sa));
sa.sin_family = AF_INET;
sa.sin_addr.s_addr = inet_addr("206.127.2.49");
sa.sin_port= htons(1234);
connect(sd, (struct sockaddr*) &sa, sizeof(sa));
getpeername(sd,(struct sockaddr*) &sa,(socklen_t*)(sizeof(sa)));
SSL_set_fd(ssl, sd);
SSL_set_connect_state(ssl);
int state = SSL_do_handshake(ssl);
if (state!=1) {
SSL_get_error(ssl,state);
ERR_print_errors_fp(stderr);
return 0;
}
sleep(15);
return 1;
}
which if I'm right in assuming SSL *php_SSL_new_from_context(SSL_CTX
*ctx, php_stream *stream TSRMLS_DC) in /ext/openssl/openssl.c is the
context creator should be logically the same thing.
actually I looked at the methods and if I take out the
SSL_set_connect_state() and switch the method to TSLv1_client_method()
I get the errors out of C... so it looks like it's in my openssl
libraries...
I'm running 0.9.7g, which is the latest stable... I'll try the snapshot
and see if that helps... I'll let you know if it does but after that, if
it doesn't, I'll probably bug openSSL about it cause it seems to be
their deal...
I will say my workaround(which I had previously thought was just
different syntax) worked for me in C... but I can see where you would
want to keep all CTX settings in php_SSL_new_from_context and not put
them in php_openssl_setup_crypto where you set up the methods... it's
alot cleaner that way
Previous Comments:
[2005-06-01 00:35:48] justin dot d dot allen at gmail dot com
installed php5-latest.tar.gz
am now getting the same error from server
but error from client is the same SSL error with added warnings
Warning: stream_socket_client(): SSL operation failed with code 1.
OpenSSL Error messages:
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure in ssl.conector.php on line 17
Warning: stream_socket_client(): Failed to enable crypto in
ssl.conector.php on line 17
Warning: stream_socket_client(): unable to connect to tls://host:port
(Unknown error) in ssl.conector.php on line 17
(0)
still no certificate passed
stream_socket_enable_crypto makes no difference
[2005-05-31 07:22:24] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
stream_socket_enable_crypto() was added in PHP 5.1-dev,
it's not (and will not be) in PHP 5.0.x
[2005-05-31 05:36:42] justin dot d dot allen at gmail dot com
line that was truncated on exapmle source is
if (!fp =
stream_sockect_client("tls://host:port",$errno,$errstr,30,STREAM_CLIENT_CONNECT/*|STREAM_CLIENT_ASYNC_CONNECT*/,$fc))
{
[2005-05-31 03:36:49] justin dot d dot allen at gmail dot com
Description:
Have been unable to get a socket_stream_client() to pass the
certificate whose path is specified by stream_context_create().
also stream_socket_enable_crypto() is an unknown function.
Reproduce code:
---
array(
'passphrase'=>'***',
'allow_self_signed'=>'TRUE',
'local_cert'=>'sec.pem'
)
));
if (!$fp =
stream_socket_client("tls://host:port",$errno,$errstr,30,STREAM_CLIENT_CONNECT/*|STREAM_CLIENT_ASYNC_CONNE$
echo "$errstr ($errno)\n";
} else {
//stream_socket_enable_crypto($fp,true,STREAM_SOCKET_CRYPTO_METHOD_TLS_CLIENT);
sleep(30);
}
?>
Expected result:
expect to
#33175 [Fbk->Opn]: cant cross compiling arm linux
ID: 33175 User updated by: esteban at correo dot unam dot mx Reported By: esteban at correo dot unam dot mx -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: linux PHP Version: 4CVS-2005-05-28 (stable) New Comment: If I try with php5-200506021430, I need the correct vesion of the libxml2 if I want to configure with the pear and xml options but if I disable this options and compile I have the same error. Previous Comments: [2005-06-02 00:39:13] [EMAIL PROTECTED] DO NOT use --host! And do not paste any more long configure outputs here if not asked for.. Try again, WITHOUT it and this time using FRESH sources. (get the latest PHP 5 snapshot!) [2005-05-31 17:12:00] esteban at correo dot unam dot mx I'm compiling under i686-pc-linux (fedora core 1) and I want to run in AEL (Arcom Embebed Linux) with arm linux and kernel 2.4.26 plataform. I'm using toolchain of arcom for cross compiling and qemu like a processor emulator in my build pc, with the options: >--target=arm-linux \ >--host=arm-linux \ >--build=i686-pc-linux Part of configure is: loading cache ./config.cache checking host system type... i686-pc-linux-gnu checking for gcc... (cached) arm-linux-gcc checking whether the C compiler (arm-linux-gcc -I/opt/arcom/arm-linux/include ) works... yes checking whether the C compiler (arm-linux-gcc -I/opt/arcom/arm-linux/include ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether arm-linux-gcc accepts -g... (cached) yes checking whether arm-linux-gcc and cc understand -c and -o together... (cached) yes checking how to run the C preprocessor... (cached) arm-linux-gcc -E checking for AIX... no checking if compiler supports -R... (cached) no checking if compiler supports -Wl,-rpath,... (cached) yes checking for re2c... (cached) exit 0; checking whether ln -s works... (cached) yes checking for mawk... (cached) gawk checking for bison... (cached) bison -y checking bison version... 1.875 (ok) checking for flex... (cached) flex checking for yywrap in -lfl... (cached) yes checking lex output file root... (cached) lex.yy checking whether yytext is a pointer... (cached) yes checking for working const... (cached) yes checking flex version... 2.5.4 (ok) checking whether byte ordering is bigendian... (cached) no checking whether to force non-PIC code in shared modules... yes checking for pthreads_cflags... (cached) checking for pthreads_lib... (cached) but it's happening what I already described you. Do you really think is just a configuration problem? :$ What about '--without-pear' option? If I change zend_strtod.c file how I already described you and use the option --enable-sockes for configure, the php info page and an simple program with sockets works but i don´t know the possible problems if I work with this environment And thanks a lot for your answers [2005-05-31 08:43:51] [EMAIL PROTECTED] Under what OS/platform are you compiling ? And _for_ what OS/platform? I think you've simply using the wrong configure options, see ./configure --help and options --target and --build (--host is something else) [2005-05-31 01:45:26] esteban at correo dot unam dot mx HI !! For this test I used php-4.3.11 I edited the file zend_strtod.c changing the line: #if defined(IEEE_LITTLE_ENDIAN) + defined(IEEE_BIG_ENDIAN) + defined(VAX) + defined(IBM) != 1 for #if defined(IEEE_BIG_ENDIAN) + defined(VAX)\ + defined(IBM) != 1 when I compiled it finished Ok then I ran the command "make install" but this ocurred Installing PEAR environment: /flashcard/usr/local/php-arm/lib/php/ qemu: uncaught target signal 11 (Segmentation fault) - exiting make[1]: *** [install-pear-installer] Error 245 make: *** [install-pear] Error 2 Next I configured php with this line: >CC="arm-linux-gcc" \ >CXX="arm-linux-g++" \ >CFLAGS="-I/opt/arcom/arm-linux/include" \ >LIBS="-L/opt/arcom/arm-linux/lib" \ >RANLIB="arm-linux-ranlib" >./configure '--prefix=/flashcard/usr/local/php-arm \ >--with-pgsql=/flashcard/usr/local/pg7.4.8-arm >--with-apxs=/flashcard/usr/local/apache-arm/bin/apxs \ >--without-pear --without-mysql --host=arm-linux \ >--build=i386-linux' SEE the '--without-pear' option after I executed "make" and "make install" commands this compile and run fine. NOW my question is: This option how affects the performance of php ? And I want to run a web application with sockets and sessions, is this posible with this option ? Finally I want to know if my report is considered like a bug or not. THANKS :D [2005-05-28 23:52:
#33222 [Fbk->Opn]: segmentation fault when trying to run curl_close from the handler function
ID: 33222 User updated by: public at grik dot net Reported By: public at grik dot net -Status: Feedback +Status: Open Bug Type: cURL related Operating System: Linux RH9 PHP Version: 5.0.4 New Comment: Segmentation fault persists curl_version(): Array ( [version_number] => 462336 [age] => 2 [features] => 540 [ssl_version_number] => 0 [version] => 7.14.0 [host] => i686-pc-linux-gnu [ssl_version] => OpenSSL/0.9.7a [libz_version] => 1.1.4 [protocols] => Array ( [0] => ftp [1] => gopher [2] => telnet [3] => dict [4] => ldap [5] => http [6] => file [7] => https [8] => ftps ) ) Previous Comments: [2005-06-02 18:45:03] [EMAIL PROTECTED] Ok, waiting for you to provide info. [2005-06-02 18:40:53] public at grik dot net CURL Informationlibcurl/7.12.0 it's not old, I upgraded it not so long ago, and manual says PHP5 requires 7.10.5 trying to upgrade to CURL 7.14 [2005-06-02 18:07:19] [EMAIL PROTECTED] What is the version of cURL used? What if you try to upgrade it to the latest available from http://curl.haxx.se/download.html ? [2005-06-02 17:20:47] public at grik dot net Program received signal SIGSEGV, Segmentation fault. 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "") at transfer.c:890 890 } [2005-06-02 17:17:18] public at grik dot net backtrace: (gdb) bt #0 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "") at transfer.c:890 #1 0x403aaf56 in Transfer (conn=0x81f584c) at transfer.c:1480 #2 0x403ab94a in Curl_perform (data=0x81f7b7c) at transfer.c:1985 #3 0x403ac175 in curl_easy_perform (curl=0x81f7b7c) at easy.c:378 #4 0x4002c3d2 in zif_curl_exec (ht=1, return_value=0x81f55dc, this_ptr=0x0, return_value_used=0) at /usr/src/web/php5-STABLE-200505161036/ext/curl/interface.c:1261 #5 0x0814a267 in zend_do_fcall_common_helper (execute_data=0xbfffc610, opline=0x81f5068, op_array=0x81f09a4) at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2747 #6 0x0814a8c8 in zend_do_fcall_handler (execute_data=0xbfffc610, opline=0x81f5068, op_array=0x81f09a4) at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2881 #7 0x08147188 in execute (op_array=0x81f09a4) at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:1417 #8 0x081239fe in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php5-STABLE-200505161036/Zend/zend.c:1080 #9 0x080e5323 in php_execute_script (primary_file=0xbfffe9e0) at /usr/src/web/php5-STABLE-200505161036/main/main.c:1646 #10 0x08153187 in main (argc=4, argv=0xbfffea84) at /usr/src/web/php5-STABLE-200505161036/sapi/cgi/cgi_main.c:1582 #11 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/33222 -- Edit this bug report at http://bugs.php.net/?id=33222&edit=1
#33222 [Opn->Fbk]: segmentation fault when trying to run curl_close from the handler function
ID: 33222
Updated by: [EMAIL PROTECTED]
Reported By: public at grik dot net
-Status: Open
+Status: Feedback
Bug Type: cURL related
Operating System: Linux RH9
PHP Version: 5.0.4
New Comment:
Ok, waiting for you to provide info.
Previous Comments:
[2005-06-02 18:40:53] public at grik dot net
CURL Informationlibcurl/7.12.0
it's not old, I upgraded it not so long ago, and manual says PHP5
requires 7.10.5
trying to upgrade to CURL 7.14
[2005-06-02 18:07:19] [EMAIL PROTECTED]
What is the version of cURL used?
What if you try to upgrade it to the latest available from
http://curl.haxx.se/download.html ?
[2005-06-02 17:20:47] public at grik dot net
Program received signal SIGSEGV, Segmentation fault.
0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "")
at transfer.c:890
890 }
[2005-06-02 17:17:18] public at grik dot net
backtrace:
(gdb) bt
#0 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "")
at transfer.c:890
#1 0x403aaf56 in Transfer (conn=0x81f584c) at transfer.c:1480
#2 0x403ab94a in Curl_perform (data=0x81f7b7c) at transfer.c:1985
#3 0x403ac175 in curl_easy_perform (curl=0x81f7b7c) at easy.c:378
#4 0x4002c3d2 in zif_curl_exec (ht=1, return_value=0x81f55dc,
this_ptr=0x0,
return_value_used=0)
at /usr/src/web/php5-STABLE-200505161036/ext/curl/interface.c:1261
#5 0x0814a267 in zend_do_fcall_common_helper
(execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2747
#6 0x0814a8c8 in zend_do_fcall_handler (execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2881
#7 0x08147188 in execute (op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:1417
#8 0x081239fe in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend.c:1080
#9 0x080e5323 in php_execute_script (primary_file=0xbfffe9e0)
at /usr/src/web/php5-STABLE-200505161036/main/main.c:1646
#10 0x08153187 in main (argc=4, argv=0xbfffea84)
at /usr/src/web/php5-STABLE-200505161036/sapi/cgi/cgi_main.c:1582
#11 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
[2005-06-02 16:55:14] public at grik dot net
Description:
When I try to close CURL connection from the function, registered as a
handler for the output (header or body), PHP crashes.
Reproduce code:
---
http://www.yahoo.com/";);
curl_setopt($ch, CURLOPT_HEADERFUNCTION, 'header_callback');
curl_exec($ch);
curl_close($ch);
function header_callback($ch, $string){
echo $string;
curl_close($ch);
return strlen($string);
}
?>
Expected result:
HTTP/1.1 200 OK
Actual result:
--
HTTP/1.1 200 OK
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=33222&edit=1
#33222 [Fbk->Opn]: segmentation fault when trying to run curl_close from the handler function
ID: 33222
User updated by: public at grik dot net
Reported By: public at grik dot net
-Status: Feedback
+Status: Open
Bug Type: cURL related
Operating System: Linux RH9
PHP Version: 5.0.4
New Comment:
CURL Informationlibcurl/7.12.0
it's not old, I upgraded it not so long ago, and manual says PHP5
requires 7.10.5
trying to upgrade to CURL 7.14
Previous Comments:
[2005-06-02 18:07:19] [EMAIL PROTECTED]
What is the version of cURL used?
What if you try to upgrade it to the latest available from
http://curl.haxx.se/download.html ?
[2005-06-02 17:20:47] public at grik dot net
Program received signal SIGSEGV, Segmentation fault.
0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "")
at transfer.c:890
890 }
[2005-06-02 17:17:18] public at grik dot net
backtrace:
(gdb) bt
#0 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "")
at transfer.c:890
#1 0x403aaf56 in Transfer (conn=0x81f584c) at transfer.c:1480
#2 0x403ab94a in Curl_perform (data=0x81f7b7c) at transfer.c:1985
#3 0x403ac175 in curl_easy_perform (curl=0x81f7b7c) at easy.c:378
#4 0x4002c3d2 in zif_curl_exec (ht=1, return_value=0x81f55dc,
this_ptr=0x0,
return_value_used=0)
at /usr/src/web/php5-STABLE-200505161036/ext/curl/interface.c:1261
#5 0x0814a267 in zend_do_fcall_common_helper
(execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2747
#6 0x0814a8c8 in zend_do_fcall_handler (execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2881
#7 0x08147188 in execute (op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:1417
#8 0x081239fe in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend.c:1080
#9 0x080e5323 in php_execute_script (primary_file=0xbfffe9e0)
at /usr/src/web/php5-STABLE-200505161036/main/main.c:1646
#10 0x08153187 in main (argc=4, argv=0xbfffea84)
at /usr/src/web/php5-STABLE-200505161036/sapi/cgi/cgi_main.c:1582
#11 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
[2005-06-02 16:55:14] public at grik dot net
Description:
When I try to close CURL connection from the function, registered as a
handler for the output (header or body), PHP crashes.
Reproduce code:
---
http://www.yahoo.com/";);
curl_setopt($ch, CURLOPT_HEADERFUNCTION, 'header_callback');
curl_exec($ch);
curl_close($ch);
function header_callback($ch, $string){
echo $string;
curl_close($ch);
return strlen($string);
}
?>
Expected result:
HTTP/1.1 200 OK
Actual result:
--
HTTP/1.1 200 OK
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=33222&edit=1
#33222 [Opn->Fbk]: segmentation fault when trying to run curl_close from the handler function
ID: 33222
Updated by: [EMAIL PROTECTED]
Reported By: public at grik dot net
-Status: Open
+Status: Feedback
Bug Type: cURL related
Operating System: Linux RH9
PHP Version: 5.0.4
New Comment:
What is the version of cURL used?
What if you try to upgrade it to the latest available from
http://curl.haxx.se/download.html ?
Previous Comments:
[2005-06-02 17:20:47] public at grik dot net
Program received signal SIGSEGV, Segmentation fault.
0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "")
at transfer.c:890
890 }
[2005-06-02 17:17:18] public at grik dot net
backtrace:
(gdb) bt
#0 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "")
at transfer.c:890
#1 0x403aaf56 in Transfer (conn=0x81f584c) at transfer.c:1480
#2 0x403ab94a in Curl_perform (data=0x81f7b7c) at transfer.c:1985
#3 0x403ac175 in curl_easy_perform (curl=0x81f7b7c) at easy.c:378
#4 0x4002c3d2 in zif_curl_exec (ht=1, return_value=0x81f55dc,
this_ptr=0x0,
return_value_used=0)
at /usr/src/web/php5-STABLE-200505161036/ext/curl/interface.c:1261
#5 0x0814a267 in zend_do_fcall_common_helper
(execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2747
#6 0x0814a8c8 in zend_do_fcall_handler (execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2881
#7 0x08147188 in execute (op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:1417
#8 0x081239fe in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend.c:1080
#9 0x080e5323 in php_execute_script (primary_file=0xbfffe9e0)
at /usr/src/web/php5-STABLE-200505161036/main/main.c:1646
#10 0x08153187 in main (argc=4, argv=0xbfffea84)
at /usr/src/web/php5-STABLE-200505161036/sapi/cgi/cgi_main.c:1582
#11 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
[2005-06-02 16:55:14] public at grik dot net
Description:
When I try to close CURL connection from the function, registered as a
handler for the output (header or body), PHP crashes.
Reproduce code:
---
http://www.yahoo.com/";);
curl_setopt($ch, CURLOPT_HEADERFUNCTION, 'header_callback');
curl_exec($ch);
curl_close($ch);
function header_callback($ch, $string){
echo $string;
curl_close($ch);
return strlen($string);
}
?>
Expected result:
HTTP/1.1 200 OK
Actual result:
--
HTTP/1.1 200 OK
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=33222&edit=1
#33222 [Opn]: segmentation fault when trying to run curl_close from the handler function
ID: 33222
User updated by: public at grik dot net
Reported By: public at grik dot net
Status: Open
Bug Type: cURL related
Operating System: Linux RH9
PHP Version: 5.0.4
New Comment:
Program received signal SIGSEGV, Segmentation fault.
0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "")
at transfer.c:890
890 }
Previous Comments:
[2005-06-02 17:17:18] public at grik dot net
backtrace:
(gdb) bt
#0 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "")
at transfer.c:890
#1 0x403aaf56 in Transfer (conn=0x81f584c) at transfer.c:1480
#2 0x403ab94a in Curl_perform (data=0x81f7b7c) at transfer.c:1985
#3 0x403ac175 in curl_easy_perform (curl=0x81f7b7c) at easy.c:378
#4 0x4002c3d2 in zif_curl_exec (ht=1, return_value=0x81f55dc,
this_ptr=0x0,
return_value_used=0)
at /usr/src/web/php5-STABLE-200505161036/ext/curl/interface.c:1261
#5 0x0814a267 in zend_do_fcall_common_helper
(execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2747
#6 0x0814a8c8 in zend_do_fcall_handler (execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2881
#7 0x08147188 in execute (op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:1417
#8 0x081239fe in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend.c:1080
#9 0x080e5323 in php_execute_script (primary_file=0xbfffe9e0)
at /usr/src/web/php5-STABLE-200505161036/main/main.c:1646
#10 0x08153187 in main (argc=4, argv=0xbfffea84)
at /usr/src/web/php5-STABLE-200505161036/sapi/cgi/cgi_main.c:1582
#11 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
[2005-06-02 16:55:14] public at grik dot net
Description:
When I try to close CURL connection from the function, registered as a
handler for the output (header or body), PHP crashes.
Reproduce code:
---
http://www.yahoo.com/";);
curl_setopt($ch, CURLOPT_HEADERFUNCTION, 'header_callback');
curl_exec($ch);
curl_close($ch);
function header_callback($ch, $string){
echo $string;
curl_close($ch);
return strlen($string);
}
?>
Expected result:
HTTP/1.1 200 OK
Actual result:
--
HTTP/1.1 200 OK
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=33222&edit=1
#33222 [NEW]: segmentation fault when trying to run curl_close from the handler function
From: public at grik dot net
Operating system: Linux RH9
PHP version: 5.0.4
PHP Bug Type: cURL related
Bug description: segmentation fault when trying to run curl_close from the
handler function
Description:
When I try to close CURL connection from the function, registered as a
handler for the output (header or body), PHP crashes.
Reproduce code:
---
http://www.yahoo.com/";);
curl_setopt($ch, CURLOPT_HEADERFUNCTION, 'header_callback');
curl_exec($ch);
curl_close($ch);
function header_callback($ch, $string){
echo $string;
curl_close($ch);
return strlen($string);
}
?>
Expected result:
HTTP/1.1 200 OK
Actual result:
--
HTTP/1.1 200 OK
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=33222&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33222&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33222&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33222&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33222&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33222&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33222&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33222&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33222&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33222&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33222&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33222&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33222&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33222&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33222&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33222&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33222&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33222&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33222&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33222&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33222&r=mysqlcfg
#33214 [Asn->Csd]: [PATCH] odbc_next_result does not signal SQL errors
ID: 33214
Updated by: [EMAIL PROTECTED]
Reported By: rich at kastle dot com
-Status: Assigned
+Status: Closed
Bug Type: ODBC related
Operating System: Windows XP
PHP Version: 5.*, 4.*
Assigned To: kalowsky
New Comment:
This bug has been fixed in CVS.
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2005-06-01 17:35:46] rich at kastle dot com
Description:
(This bug is in all versions of PHP since 4.*; the patch is against PHP
5.0.4)
If a 2-statement SQL batch is executed, where the first SQL statement
completes correctly but the second SQL statement yeilds an error, there
is no error indication given by odbc_next_result; you simply get FALSE.
I have a patch to correct this:
--- ext/odbc/php_odbc.c~2005-01-18 10:07:10.0 -0500
+++ ext/odbc/php_odbc.c 2005-06-01 11:01:25.176471600 -0400
@@ -2439,5 +2463,8 @@
RETURN_TRUE;
}
- else {
+ else if(rc == SQL_NO_DATA_FOUND) {
+ RETURN_FALSE;
+ } else {
+ odbc_sql_error(result->conn_ptr, result->stmt,
"SQLMoreResults");
RETURN_FALSE;
}
--
Edit this bug report at http://bugs.php.net/?id=33214&edit=1
#33222 [Opn]: segmentation fault when trying to run curl_close from the handler function
ID: 33222
User updated by: public at grik dot net
Reported By: public at grik dot net
Status: Open
Bug Type: cURL related
Operating System: Linux RH9
PHP Version: 5.0.4
New Comment:
backtrace:
(gdb) bt
#0 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "")
at transfer.c:890
#1 0x403aaf56 in Transfer (conn=0x81f584c) at transfer.c:1480
#2 0x403ab94a in Curl_perform (data=0x81f7b7c) at transfer.c:1985
#3 0x403ac175 in curl_easy_perform (curl=0x81f7b7c) at easy.c:378
#4 0x4002c3d2 in zif_curl_exec (ht=1, return_value=0x81f55dc,
this_ptr=0x0,
return_value_used=0)
at /usr/src/web/php5-STABLE-200505161036/ext/curl/interface.c:1261
#5 0x0814a267 in zend_do_fcall_common_helper
(execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2747
#6 0x0814a8c8 in zend_do_fcall_handler (execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2881
#7 0x08147188 in execute (op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:1417
#8 0x081239fe in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend.c:1080
#9 0x080e5323 in php_execute_script (primary_file=0xbfffe9e0)
at /usr/src/web/php5-STABLE-200505161036/main/main.c:1646
#10 0x08153187 in main (argc=4, argv=0xbfffea84)
at /usr/src/web/php5-STABLE-200505161036/sapi/cgi/cgi_main.c:1582
#11 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
Previous Comments:
[2005-06-02 16:55:14] public at grik dot net
Description:
When I try to close CURL connection from the function, registered as a
handler for the output (header or body), PHP crashes.
Reproduce code:
---
http://www.yahoo.com/";);
curl_setopt($ch, CURLOPT_HEADERFUNCTION, 'header_callback');
curl_exec($ch);
curl_close($ch);
function header_callback($ch, $string){
echo $string;
curl_close($ch);
return strlen($string);
}
?>
Expected result:
HTTP/1.1 200 OK
Actual result:
--
HTTP/1.1 200 OK
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=33222&edit=1
#33224 [NEW]: require_once includes the same file again even if path/filename is identical
From: ypae at hotmail dot com
Operating system: Windows 2003 Server
PHP version: 5.0.4
PHP Bug Type: Unknown/Other Function
Bug description: require_once includes the same file again even if
path/filename is identical
Description:
When I created a lib.inc.php that has a few functions defined (e.g.
getmicrocode(), myfunction()) and try to include it on several files with
require_once, it somehow included more than once even though the end
result of 'path/filename' is identical.
My understanding of require_once limitation on Windows (or non-POSIX)
platform was that if you have mixed case with the same file name, it will
be included again. Another words, as long as you have identical
"path/filename" as part of require_once statement, it should include only
once.
As a result, since you cannot redeclare the same function within the page,
you get:
Fatal error: Cannot redeclare "functionname()" (previously declared in...
Reproduce code:
---
For example,
On lib.inc.php:
===
myfunction1()
{ echo "hello!";}
myfunction2()
{ echo "hello again!";}
On index.php
$_my_absolute_path = 'c:/inetpub/wwwroot/';
require_once($_my_absolute_path.'lib.inc.php');
require_once($_my_absolute_path.'template.inc.php');
on template.inc.php
===
$_my_absolute_path = 'c:/inetpub/wwwroot/';
require_once($_my_absolute_path.'lib.inc.php'); // Just in case someone
didn't call this previously
The realistic code is quite complex:
A require_once B and C
B require_once C and *D*
C require_once *D*
and *D* causes redeclare issue when I load A.
Expected result:
the second attempt to include lib.inc.php by using require_once should be
ignored because it was already loaded.
The same code running on Linux works perfectly and it used to be fine on
PHP 4.3.10
But right after I rebuild the server with PHP 5.0.4, I got the following
error:
Fatal error: Cannot redeclare myfunction1() (previously declared in...
Actual result:
--
the second attempt to include lib.inc.php by using require_once WAS
performed and it causes error.
--
Edit bug report at http://bugs.php.net/?id=33224&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33224&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33224&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33224&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33224&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33224&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33224&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33224&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33224&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33224&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33224&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33224&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33224&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33224&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33224&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33224&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33224&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33224&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33224&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33224&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33224&r=mysqlcfg
#33214 [Opn->Asn]: [PATCH] odbc_next_result does not signal SQL errors
ID: 33214
Updated by: [EMAIL PROTECTED]
Reported By: rich at kastle dot com
-Status: Open
+Status: Assigned
Bug Type: ODBC related
Operating System: Windows XP
PHP Version: 5.*, 4.*
-Assigned To:
+Assigned To: kalowsky
Previous Comments:
[2005-06-01 17:35:46] rich at kastle dot com
Description:
(This bug is in all versions of PHP since 4.*; the patch is against PHP
5.0.4)
If a 2-statement SQL batch is executed, where the first SQL statement
completes correctly but the second SQL statement yeilds an error, there
is no error indication given by odbc_next_result; you simply get FALSE.
I have a patch to correct this:
--- ext/odbc/php_odbc.c~2005-01-18 10:07:10.0 -0500
+++ ext/odbc/php_odbc.c 2005-06-01 11:01:25.176471600 -0400
@@ -2439,5 +2463,8 @@
RETURN_TRUE;
}
- else {
+ else if(rc == SQL_NO_DATA_FOUND) {
+ RETURN_FALSE;
+ } else {
+ odbc_sql_error(result->conn_ptr, result->stmt,
"SQLMoreResults");
RETURN_FALSE;
}
--
Edit this bug report at http://bugs.php.net/?id=33214&edit=1
#33220 [Opn->Asn]: Denial of service through imagecreatefromgif()
ID: 33220 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at pureftpd dot org -Status: Open +Status: Assigned Bug Type: GD related Operating System: any PHP Version: 5.0.4 -Assigned To: +Assigned To: pajoye Previous Comments: [2005-06-02 15:11:16] phpbugs at pureftpd dot org Description: The following (invalid) picture triggers an infinite loop in gdImageCreateFromGif() with 100% CPU usage. Tested on Linux and OpenBSD, PHP4 with GD 1 and PHP5 with built-in GD. Reproduce code: --- Get kaboom-gd.gif from ftp://ftp.00f.net/misc/kaboom-gd.gif Expected result: No 100% CPU usage. Actual result: -- 100% CPU usage, infinite loop. -- Edit this bug report at http://bugs.php.net/?id=33220&edit=1
#33201 [Opn->Asn]: segfault in _emalloc called from php_mssql_get_column_content_with_type
ID: 33201
Updated by: [EMAIL PROTECTED]
Reported By: skissane at iips dot mq dot edu dot au
-Status: Open
+Status: Assigned
Bug Type: MSSQL related
Operating System: Linux
PHP Version: 5.0.4
-Assigned To:
+Assigned To: fmk
Previous Comments:
[2005-06-01 04:22:30] skissane at iips dot mq dot edu dot au
I have tried with latest snapshot.
When PHP is complied with --enable-debug, it works fine, although it
complains with messages like the following:
---
/mnt/golum-c/LinuxOverflow/php5-STABLE-200506010035/ext/mssql/php_mssql.c(193)
: Block 0x08304430 status:
/mnt/golum-c/LinuxOverflow/php5-STABLE-200506010035/Zend/zend_variables.c(45)
: Actual location (location was relayed)
Beginning: OK (allocated on
/mnt/golum-c/LinuxOverflow/php5-STABLE-200506010035/ext/mssql/php_mssql.c:881,
19 bytes)
End: Overflown (magic=0x2A8FCC00 instead of 0x2A8FCC84)
1 byte(s) overflown
However, when PHP is not compiled with --enable-debug, I get a SEGV
again, with the following backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 31750)]
0x40283bef in _int_malloc () from /lib/i686/libc.so.6
(gdb) bt
#0 0x40283bef in _int_malloc () from /lib/i686/libc.so.6
#1 0x402852ac in malloc () from /lib/i686/libc.so.6
#2 0x0814fe48 in _emalloc (size=1077090752) at
/mnt/golum-c/LinuxOverflow/php5-STABLE-200506010035/Zend/zend_alloc.c:182
#3 0x08085e76 in php_mssql_get_column_content_with_type
(mssql_ptr=0x8274cc4, offset=1077090752, result=0x82876dc,
column_type=1077088260)
at
/mnt/golum-c/LinuxOverflow/php5-STABLE-200506010035/ext/mssql/php_mssql.c:881
#4 0x08086707 in _mssql_fetch_batch (mssql_ptr=0x8274cc4,
result=0x826fa7c, retvalue=-1)
at
/mnt/golum-c/LinuxOverflow/php5-STABLE-200506010035/ext/mssql/php_mssql.c:1108
#5 0x08086b86 in zif_mssql_query (ht=33, return_value=0x8274f34,
this_ptr=0x0, return_value_used=1)
at
/mnt/golum-c/LinuxOverflow/php5-STABLE-200506010035/ext/mssql/php_mssql.c:1229
#6 0x0817daae in zend_do_fcall_common_helper (execute_data=0xbfffd4b0,
opline=0x8273e60, op_array=0x826f9ec)
at
/mnt/golum-c/LinuxOverflow/php5-STABLE-200506010035/Zend/zend_execute.c:2747
#7 0x0817b036 in execute (op_array=0x826f9ec) at
/mnt/golum-c/LinuxOverflow/php5-STABLE-200506010035/Zend/zend_execute.c:1417
#8 0x08160c1b in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at
/mnt/golum-c/LinuxOverflow/php5-STABLE-200506010035/Zend/zend.c:1084
#9 0x08133a2b in php_execute_script (primary_file=0xb870) at
/mnt/golum-c/LinuxOverflow/php5-STABLE-200506010035/main/main.c:1646
#10 0x081844d8 in main (argc=2, argv=0xb8f4) at
/mnt/golum-c/LinuxOverflow/php5-STABLE-200506010035/sapi/cli/php_cli.c:946
#11 0x40236912 in __libc_start_main () from /lib/i686/libc.so.6
[2005-05-31 14:17:28] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-05-31 13:53:08] skissane at iips dot mq dot edu dot au
Description:
Segmentation fault.
Reproduce code:
---
","","");
$i = mssql_query("SELECT * FROM MSSQLTrace_99",$q);
while (mssql_fetch_row($i) !== FALSE);
Where the MSSQLTrace_99 table is created by the following MSSQL script
(a bit too big for a bug database):
http://www.iips.mq.edu.au/php_mssql_bug.txt
Expected result:
No output.
Actual result:
--
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 29878)]
0x40440bef in _int_malloc () from /lib/i686/libc.so.6
(gdb) bt
#0 0x40440bef in _int_malloc () from /lib/i686/libc.so.6
#1 0x404422ac in malloc () from /lib/i686/libc.so.6
#2 0x0815ac58 in _emalloc (size=1078913472) at
/home/skissane/php-5.0.4/Zend/zend_alloc.c:182
#3 0x0809151e in php_mssql_get_column_content_with_type
(mssql_ptr=0x827079c, offset=1078913472, result=0x828319c,
column_type=1078910980)
at /home/skissane/php-5.0.4/ext/mssql/php_mssql.c:877
#4 0x08091daf in _mssql_fetch_batch (mssql_ptr=0x827079c,
result=0x826b5cc, retvalue=-1) at
/home/skissane/php-5.0.4/ext/mssql/php_mssql.c:1104
#5 0x0809222e in zif_mssql_query (ht=33, return_value=0x8270a54,
this_ptr=0x0, return_value_used=1) at
/home/skissane/php-5.0.4/ext/mssql/php_mssql.c:1225
#6 0x081882ce in zend_do_fcall_common_helper (execute_data=0xbfffd510,
opline=0x826f980, op_array=0x826b53c)
at /home/skissane/php-5.0.4/Zend/zend_execute.c:2727
#7 0x081858ca in execute (op_array=0x826b53c) at
/home/skissane/php-5.0.4/Zend/zend_execute.c:1406
#8 0x0816b79f in zend_execute_scripts (type=8, retval=0x0,
file
#33221 [NEW]: Varchar >255 not supported
From: graham1 dot simpson at hsbcib dot com Operating system: Linux Redhat AS 3.0 PHP version: 5.0.4 PHP Bug Type: Sybase-ct (ctlib) related Bug description: Varchar >255 not supported Description: PHP client application truncates text/varchar columns to 255 chars, even when compiled with a new Sybase CT open client. - I think this is more of a feature enhancement request rather than a bug per se. - Load the form mentioned belowin your web browser and add data until bigger than 255. My environment is php 5.0.4 under apache 2.0.48 with --with-sybase-ct option compiled in. The version of open client is 12.5.1. which supports large varchars. Reproduce code: --- To reproduce: % catEOT In isql: use tempdb go create table gsi (Key1 varchar(1500)) go insert gsi values ("somevalue") go Expected result: Ideally, I would expect to get my row returned when bigger than 255 characters. Actual result: -- As the PHP client cannot handle varchars > 255, a server error is generated informing that a truncation has occurred: Warning: sybase_query() [function.sybase-query]: Sybase: Server message: Character or binary data returned from Adaptive Server has been truncated. The client application does not support more than 255 bytes of data as a result column or output parameter. (severity 10, procedure N/A) in /home/sybase/public_html/testform.php on line 20 -- Edit bug report at http://bugs.php.net/?id=33221&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33221&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33221&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33221&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33221&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33221&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33221&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33221&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33221&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33221&r=support Expected behavior: http://bugs.php.net/fix.php?id=33221&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33221&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33221&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33221&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33221&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33221&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33221&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33221&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33221&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33221&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33221&r=mysqlcfg
#31222 [Asn->Bgs]: ocicommit not working
ID: 31222 Updated by: [EMAIL PROTECTED] Reported By: amonw at hotmail dot com -Status: Assigned +Status: Bogus Bug Type: OCI8 related Operating System: * PHP Version: 4CVS-2005-04-04 Assigned To: tony2001 New Comment: Tested and replied to you. ocicommit() works fine as I've already told you before. Even if there is an issue, it has nothing to do with ocicommit() and oci8. Previous Comments: [2005-05-25 06:36:18] amonw at hotmail dot com I've built a test system and sent the information about it to [EMAIL PROTECTED] You can ssh2 to it and reproduce the problem. Thank you. [2005-05-23 10:13:25] [EMAIL PROTECTED] I can't fix something that I can't reproduce. ocicommit() works just PERFECTLY for me and for others, and the version of PHP doesn't really matter here. [2005-05-23 04:42:23] amonw at hotmail dot com I tried php5 yesterday and the problem doesn't exists. So can you fix it in php4? Thanks. [2005-05-18 00:14:03] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip We really need to know if this is fixed in HEAD, so please try the snapshot. Nobody is telling you should put it on PRODUCTION machine. You do have some test/dev machines?! [2005-05-17 07:09:52] amonw at hotmail dot com I've tried the newest version of php4 but it can't solve my problem. Please refer to my last 2 comments. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/31222 -- Edit this bug report at http://bugs.php.net/?id=31222&edit=1
#33220 [NEW]: Denial of service through imagecreatefromgif()
From: phpbugs at pureftpd dot org Operating system: any PHP version: 5.0.4 PHP Bug Type: GD related Bug description: Denial of service through imagecreatefromgif() Description: The following (invalid) picture triggers an infinite loop in gdImageCreateFromGif() with 100% CPU usage. Tested on Linux and OpenBSD, PHP4 with GD 1 and PHP5 with built-in GD. Reproduce code: --- Get kaboom-gd.gif from ftp://ftp.00f.net/misc/kaboom-gd.gif Expected result: No 100% CPU usage. Actual result: -- 100% CPU usage, infinite loop. -- Edit bug report at http://bugs.php.net/?id=33220&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33220&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33220&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33220&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33220&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33220&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33220&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33220&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33220&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33220&r=support Expected behavior: http://bugs.php.net/fix.php?id=33220&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33220&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33220&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33220&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33220&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33220&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33220&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33220&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33220&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33220&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33220&r=mysqlcfg
#33218 [Fbk->Csd]: Apache crash on declaring a private methode __destruct with debug_backtrace
ID: 33218 User updated by: robo47 at robo47 dot net Reported By: robo47 at robo47 dot net -Status: Feedback +Status: Closed Bug Type: Reproducible crash Operating System: Linux and Windows PHP Version: 5.0.4 New Comment: Okay thx, tested the Windows CVS-Build and it worked without an Error. greetz robo47 Previous Comments: [2005-06-02 11:45:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip I can't reproduce this, so it might be fixed already. [2005-06-02 11:34:10] robo47 at robo47 dot net Description: The following Code was testet on a Suse 9.0 Server (PHP 5.0.4) and on a local Windows-machine(PHP 5.0.2) and it crashs the Apache Webserver: The Error Occurs when i want to use my error-handler (the posted version is a minimized version with only relevant parts) and i set the __destruct-function as an private, not as a public methode. Using the standard-errorhandler the following Error is shown: Warning: Call to private testclass::__destruct() from context '' during shutdown ignored in Unknown on line 0 Reproduce code: --- Expected result: The Output of debug_backtrace(); should appear Actual result: -- On Windows-machine the Apache crashs and restarts with this Entry in the apache-errorlog: [Thu Jun 02 11:23:11 2005] [notice] Parent: child process exited with status 1073807364 -- Restarting. the linux-machine shows the following in the apache-errorlog: [Wed Jun 01 17:49:21 2005] [notice] child pid 26331 exit signal Segmentation fault (11) -- Edit this bug report at http://bugs.php.net/?id=33218&edit=1
#33218 [Opn->Fbk]: Apache crash on declaring a private methode __destruct with debug_backtrace
ID: 33218 Updated by: [EMAIL PROTECTED] Reported By: robo47 at robo47 dot net -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Linux and Windows PHP Version: 5.0.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip I can't reproduce this, so it might be fixed already. Previous Comments: [2005-06-02 11:34:10] robo47 at robo47 dot net Description: The following Code was testet on a Suse 9.0 Server (PHP 5.0.4) and on a local Windows-machine(PHP 5.0.2) and it crashs the Apache Webserver: The Error Occurs when i want to use my error-handler (the posted version is a minimized version with only relevant parts) and i set the __destruct-function as an private, not as a public methode. Using the standard-errorhandler the following Error is shown: Warning: Call to private testclass::__destruct() from context '' during shutdown ignored in Unknown on line 0 Reproduce code: --- Expected result: The Output of debug_backtrace(); should appear Actual result: -- On Windows-machine the Apache crashs and restarts with this Entry in the apache-errorlog: [Thu Jun 02 11:23:11 2005] [notice] Parent: child process exited with status 1073807364 -- Restarting. the linux-machine shows the following in the apache-errorlog: [Wed Jun 01 17:49:21 2005] [notice] child pid 26331 exit signal Segmentation fault (11) -- Edit this bug report at http://bugs.php.net/?id=33218&edit=1
#33218 [NEW]: Apache crash on declaring a private methode __destruct with debug_backtrace
From: robo47 at robo47 dot net Operating system: Linux and Windows PHP version: 5.0.4 PHP Bug Type: Reproducible crash Bug description: Apache crash on declaring a private methode __destruct with debug_backtrace Description: The following Code was testet on a Suse 9.0 Server (PHP 5.0.4) and on a local Windows-machine(PHP 5.0.2) and it crashs the Apache Webserver: The Error Occurs when i want to use my error-handler (the posted version is a minimized version with only relevant parts) and i set the __destruct-function as an private, not as a public methode. Using the standard-errorhandler the following Error is shown: Warning: Call to private testclass::__destruct() from context '' during shutdown ignored in Unknown on line 0 Reproduce code: --- Expected result: The Output of debug_backtrace(); should appear Actual result: -- On Windows-machine the Apache crashs and restarts with this Entry in the apache-errorlog: [Thu Jun 02 11:23:11 2005] [notice] Parent: child process exited with status 1073807364 -- Restarting. the linux-machine shows the following in the apache-errorlog: [Wed Jun 01 17:49:21 2005] [notice] child pid 26331 exit signal Segmentation fault (11) -- Edit bug report at http://bugs.php.net/?id=33218&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33218&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33218&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33218&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33218&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33218&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33218&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33218&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33218&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33218&r=support Expected behavior: http://bugs.php.net/fix.php?id=33218&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33218&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33218&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33218&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33218&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33218&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33218&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33218&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33218&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33218&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33218&r=mysqlcfg
