#29370 [Com]: Crash apache.exe (php5ts.dll)
ID: 29370
Comment by: ahtin at hot dot ee
Reported By: anthony dot debhian at only-for dot info
Status: Open
Bug Type: Reproducible crash
Operating System: Windows XP
PHP Version: 5.0.0
New Comment:
i got the same obscure crash with php 5.0 + apache 2.0.48 on win98se
with this code snippet:
-
db_fetch_row($s))
{
$x['birthday'].=$this->parse_tpl("k_links",$s2);
}
?>
no errors, just apache crash
Previous Comments:
[2004-07-25 03:34:02] anthony dot debhian at only-for dot info
Description:
The code crash apache.exe with php-5.0.0/apache-1.3.31 and
php-4.3.3/apache-1.3.27 (2 pc, 2 config)
The GET request does not appear in access.log and error.log.
this bug's odd, perhaps not important, but i send you feedback anyway.
Reproduce code:
---
$value) { if(is_array($array[$key])) {
$src.=$key; } }
return $src;
}
function funcfunc2($array,$test)
{
foreach($array['test'] as $key=>$value) { }
return $array;
}
$test['lol']['test1']="test1";
$test['lol']['test2']="test2";
$array=funcfunc($test);
$array=funcfunc2($array,"test");
?>
Expected result:
Just a fatal error.
--
Edit this bug report at http://bugs.php.net/?id=29370&edit=1
#23670 [Ver]: "implements" and "extends" cause Apache 2 crash
ID: 23670
User updated by: agoossens at olc dot sa dot edu dot au
Reported By: agoossens at olc dot sa dot edu dot au
Status: Verified
Bug Type:Zend Engine 2 problem
PHP Version: 5.0.0
Assigned To: helly
New Comment:
Modified my above e-mail address to reflect new changed address.
Previous Comments:
[2004-07-23 20:44:50] [EMAIL PROTECTED]
I have verified this bug with the following version, and reopened it.
PHP 5.0.0 (cli) (built: Jul 17 2004 16:32:19)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.0, Copyright (c) 1998-2004 Zend Technologies
with Zend Extension Manager v1.0.2, Copyright (c) 2003-2004, by
Zend Technologies
with Zend Optimizer v2.5.2, Copyright (c) 1998-2004, by Zend
Technologies
with Zend Debugger v3.5.0, Copyright (c) 1999-2004, by Zend
Technologies
[2003-06-01 12:29:01] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-05-17 15:15:37] [EMAIL PROTECTED]
Reclassify as ZE2 problem.
[2003-05-17 06:08:05] agoossens at olc dot sa dot edu dot au
Oh, and it was Apache 2.0.43 :)
[2003-05-17 06:04:20] agoossens at olc dot sa dot edu dot au
Greetings all,
The following code causes an Apache2 crash under XP Pro (with Service
Pack 1), using 5.0.0-dev (May 06, 2003):
class Driver_DB_MySQL implements iDB extends Driver_DB
{
}
However, if you take out the "implements iDB" or "extends Driver_DB"
statements, the code works fine. Normally under this condition you'd
expect PHP to throw a parser error (as is in the error log transcript
below).
Neither the interface iDB or the class Driver_DB have been defined yet.
However, even if they are defined, the crash still occurs (until you
remove one of the two statements, that is).
The Apache Error Log says the following:
[client 127.0.0.1] PHP Parse error: parse error, unexpected T_EXTENDS,
expecting '{' in C:\webroot\public_html\foo.php on line 2, referer:
http://localhost/
[Sat May 17 20:29:41 2003] [notice] Parent: child process exited with
status 3221225477 -- Restarting.
[Sat May 17 20:29:41 2003] [notice] Parent: Created child process 4776
No extra extensions have been enabled in php.ini.
Cheers.
-Adam.
--
Edit this bug report at http://bugs.php.net/?id=23670&edit=1
#23670 [Ver]: "implements" and "extends" cause Apache 2 crash
ID: 23670 User updated by: adamgoossens at users dot sourceforge dot net -Reported By: agoossens at olc dot sa dot edu dot au +Reported By: adamgoossens at users dot sourceforge dot net Status: Verified Bug Type:Zend Engine 2 problem PHP Version: 5.0.0 Assigned To: helly New Comment: Of course, it does help if I provide the new addressmy mistake. Also, I can no longer reproduce this bug with PHP5 final and Apache 2.0.49. The script terminates with the parse error as expected. Previous Comments: [2004-07-25 13:24:22] agoossens at olc dot sa dot edu dot au Modified my above e-mail address to reflect new changed address. [2004-07-23 20:44:50] [EMAIL PROTECTED] I have verified this bug with the following version, and reopened it. PHP 5.0.0 (cli) (built: Jul 17 2004 16:32:19) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.0.0, Copyright (c) 1998-2004 Zend Technologies with Zend Extension Manager v1.0.2, Copyright (c) 2003-2004, by Zend Technologies with Zend Optimizer v2.5.2, Copyright (c) 1998-2004, by Zend Technologies with Zend Debugger v3.5.0, Copyright (c) 1999-2004, by Zend Technologies [2003-06-01 12:29:01] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-05-17 15:15:37] [EMAIL PROTECTED] Reclassify as ZE2 problem. [2003-05-17 06:08:05] agoossens at olc dot sa dot edu dot au Oh, and it was Apache 2.0.43 :) 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/23670 -- Edit this bug report at http://bugs.php.net/?id=23670&edit=1
#28029 [NoF->Opn]: HTTP request failed!
ID: 28029
User updated by: coadmin at hostings dot pl
Reported By: coadmin at hostings dot pl
-Status: No Feedback
+Status: Open
Bug Type: URL related
Operating System: FreeBSD 4.9 and 5.2.1
PHP Version: 4CVS-2004-04-16 (stable)
New Comment:
Hello,
sorry I couldn't use --disable-all on productive machine. There are too
many commercial hostings accounts.
But...
My problem was suddenly resolved about month ago before compiling
PHP. It was very strange. I didn't do any changes in Apache or PHP.
>From one day up to now all is working correctly. There wasn't any HTTP
request failed!. Additionaly, I upgraded to 4.3.8 a week ago and there
is many many many less segfaults.
But... #2
On the other server (php 4.3.6) always was OK. After upgrade to PHP
4.3.8 I've again the same bug...
I really don't know what is it. Maybe it's OS releated? But as I see on
bug status, only 37.5% people, reproducting this bug has the same OS as
me.
There aren't segaults during HTTP request failed!, but there are other
segfaults releated to php engine.
Previous Comments:
[2004-07-19 01:00:06] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2004-07-11 22:01:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
And use EXACTLY this configure line:
# ./configure --with-apxs=/usr/local/apache/bin/apxs --disable-all
# make && make install
# /usr/local/apache/bin/apachectl stop && sleep 10
# /usr/local/apache/bin/apachectl start
Then test using the simplest script you could reproduce this problem
before.
[2004-05-24 04:25:00] joseph at xtremecorponline dot com
My mistake. fopen causes these errors when the filename passed to it
does not exist, or is corrupted, on the server. I hope that helps
narrow it down.
[2004-05-24 04:16:19] joseph at xtremecorponline dot com
Hello -
Running FreeBSD 4.9,PHP4.3.6.
I get the same errors, fopen causing segmentation fault, which then
interrupts the browser's SSL connection. I have a script that
thumbnails images on the fly. It's not all the time, but every once in
a while, fopen will cause this error:
[error] PHP Warning: fopen: failed to open stream: HTTP
in /usr/local/www/site/phpthumb.php on line 615
which is reported in my apache error log for the virtual host.
consequently, immediately after, in the apache error-log in apache
root, this error occurs:
child pid 43187 exit signal Segmentation fault (11) (note the PID #
is always different as the apache processes recycle)
The script file is 1200 lines long, I'm sure yuo dont want it all, but
here is the area of line 615 as the error shows. The code `if ($fp =
fopen($_REQUEST['src'], 'rb')) {` is line 615.
FreeBSD 4.9
Apache/1.3.29
PHP/4.3.6
mod_ssl/2.8.16
OpenSSL/0.9.6g
Am also running turck-mmcache 2.4.6
Please help with this. Am also more than willing to get you any info
you need to help troubleshoot as fast as possible.
[2004-05-09 11:35:57] coadmin at hostings dot pl
I'm still waiting for solution from PHP team.
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/28029
--
Edit this bug report at http://bugs.php.net/?id=28029&edit=1
#29349 [Com]: imagecreatefromstring segfaults (fix included)
ID: 29349
Comment by: adconrad at debian dot org
Reported By: k at ailis dot de
Status: Open
Bug Type: GD related
Operating System: Linux
PHP Version: 4CVS-2004-07-23 (stable)
New Comment:
As of the next upload to the Debian archive, we will be using the
following patch, which seems to clear up every php4-gd segfault bug
we've had reported:
--- php4-4.3.8/ext/gd/gd.c.orig 2004-07-24 06:00:25.0 -0600
+++ php4-4.3.8/ext/gd/gd.c 2004-07-24 06:10:38.0 -0600
@@ -1242,7 +1242,7 @@
#ifdef HAVE_GD_WBMP
else {
gdIOCtx *io_ctx;
- io_ctx = gdNewDynamicCtx (8, data);
+ io_ctx = gdNewDynamicCtxEx (8, data, 0);
if (io_ctx) {
if (getmbi((int(*)(void*))gdGetC, io_ctx) == 0
&& skipheader((int(*)(void*))gdGetC, io_ctx) == 0 ) {
#if HAVE_LIBGD204
@@ -1274,7 +1274,7 @@
gdImagePtr im;
gdIOCtx *io_ctx;
- io_ctx = gdNewDynamicCtx (Z_STRLEN_PP(data),
Z_STRVAL_PP(data));
+ io_ctx = gdNewDynamicCtxEx (Z_STRLEN_PP(data),
Z_STRVAL_PP(data), 0);
if (!io_ctx) {
return NULL;
@@ -1428,7 +1428,7 @@
goto out_err;
}
- io_ctx = gdNewDynamicCtx(buff_size, buff);
+ io_ctx = gdNewDynamicCtxEx(buff_size, buff, 0);
if(!io_ctx) {
php_error_docref(NULL TSRMLS_CC,
E_WARNING,"Cannot allocate GD IO context");
goto out_err;
Previous Comments:
[2004-07-24 14:08:46] adconrad at debian dot org
Also note that gdNewDynamicCtx is used 3 times in gd.c, not just once
as the patch would lead one to believe.
[2004-07-24 14:05:05] adconrad at debian dot org
Note that gdNewDynamicCtxEx was added in 2.0.21, so if this is used
unconditionally, PHP will need to depend on that version of libgd2.
(Also, this does appear to fix the segfaults being reported all over
the place for imagecreatefromstring with the external libgd2)
[2004-07-23 14:09:13] k at ailis dot de
I have searched the closed bug reports and it looks like
you will find the whole problem in #24174 (including a
backtrace). Your solution was to modify the bundled GD
library. In my opinion this is a very bad solution because
this does not fix the problem if you use the external GD
library. And it seems NOT to be a bug in GD! It's seems
more like a misuse of a GD-function. The external GD
library AND the bundled one can be used if you try my fix
and check if it does not break something else. It looks to
me that Boutell has created this *CtxEx function exactly
for people who want to control the memory-freeing
behaviour of the function so it might be the correct
solution.
[2004-07-23 13:50:20] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Please, provide a gdb backtrace.
[2004-07-23 12:01:03] k at ailis dot de
Description:
imagecreatefromstring segfaults when using the external GD library. The
bundled one works. As far as I understood this problem the
imagecreatefromstring function calls gdNewDynamicCTX and this function
frees some memory which don't have to be freed. Maybe this function was
changed in the bundled GD library. But this is not needed. Instead of
gdNewDynamicCtx the function gdNewDynamicCtxEx can be used. The
additional third parameter must be 0 so the function doesn't free the
memory. Doing in in that way imagecreatefromstring works again in the
external GD library and also in the bundled one. Here is a small patch,
but please take it with care. I don't really know what you are doing
there with all these memory freeing hacks. Maybe my patch creates a
memory leak. Don't know.
--- gd.c.orig 2004-07-23 11:24:51.0 +0200
+++ gd.c2004-07-23 11:31:10.0 +0200
@@ -1274,7 +1274,7 @@
gdImagePtr im;
gdIOCtx *io_ctx;
- io_ctx = gdNewDynamicCtx (Z_STRLEN_PP(data), Z_STRVAL_PP(data));
+ io_ctx = gdNewDynamicCtxEx (Z_STRLEN_PP(data), Z_STRVAL_PP(data),
0);
if (!io_ctx) {
return NULL;
Reproduce code:
---
Can't provide one. The bug seems to be very system dependend. It works
on some machines. On others it don't. It works for some image files.
With
#29373 [Opn->Bgs]: Possibly DOS exploit using get_headers function
ID: 29373 Updated by: [EMAIL PROTECTED] Reported By: zbuckholz at hotmail dot com -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Linux RedHat 9 PHP Version: 5.0.0 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php You've coded an infinite loop, those tend to exhaust resources. Previous Comments: [2004-07-25 07:59:54] zbuckholz at hotmail dot com Description: Short example below will cause complete exhaustion. Seems to cause loop of some sort. http://"; . $_SERVER['SERVER_NAME']); print_r(get_headers($server_name,true)); ?> from apache error log [Sat Jul 24 22:21:15 2004] [error] server reached MaxClients setting, consider raising the MaxClients setting Reproduce code: --- http://"; . $_SERVER['SERVER_NAME']); print_r(get_headers($server_name)); ?> Expected result: I expect to see what the documentation says I should see. But in the example code the $url is being provided to the get_headers function as a predefined string. Actual result: -- [Sat Jul 24 22:21:15 2004] [error] server reached MaxClients setting, consider raising the MaxClients setting -- Edit this bug report at http://bugs.php.net/?id=29373&edit=1
#29375 [NEW]: make test - Error 139
From: simone at ivg dot it Operating system: Linux PHP version: 4.3.8 PHP Bug Type: *Compile Issues Bug description: make test - Error 139 Description: when I compile php-4.3.8 , nothing wrong. But when I try to exec tests ( make test ) it returns : make: [test] Error 139 (ignored) My configure parameters are: ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --enable-safe-mode \ --enable-magic-quotes \ --with-openssl=/usr/local/ssl \ --enable-bcmath \ --enable-calendar \ --with-curl=/usr/local/src/curl-7.10.5 \ --enable-ftp \ --with-gd=/usr/local/src/gd-2.0.21 \ --with-jpeg-dir=/usr/local/src/jpeg-6b \ --with-png-dir=/usr/local/src/libpng-1.2.5 \ --with-freetype-dir=/usr/local/src/freetype-2.1.5 \ --with-gettext=/usr/local/src/gettext-0.13 \ --with-imap=/usr/local/src/imap-2002e \ --with-imap-ssl=/usr/local/ssl \ --enable-mbstring \ --enable-mbregex \ --with-mcrypt=/usr/local/src/libmcrypt-2.5.7 \ --with-mysql=/usr/local/mysql \ --with-jpeg-dir=/usr/local/src/jpeg-6b \ --with-png-dir=/usr/local/src/libpng-1.2.5 \ --with-tiff-dir=/usr/local/src/tiff-v3.5.7 \ --with-mm=/usr/local/src/mm-1.3.0 \ --enable-sockets \ --enable-sysvsem \ --enable-sysvshm \ --with-zip=/usr/local/src/zziplib-0.10.27 \ --enable-inline-optimization \ --enable-memory-limit \ --enable-zend-multibyte \ --with-tsrm-pthreads \ --with-zlib \ --with-zlib-dir=/usr/local/src/zlib-1.2.1 \ --enable-sigchild \ --enable-dbase \ --enable-dio \ --enable-exif \ --enable-ftp \ --enable-sysvmsg \ --with-pear \ --enable-dba \ --with-db4=/usr/local/BerkeleyDB.4.2 I suspect there are problems with BerkeleyDB ( if I remove last line, all seems ok ) but I cannot be more specific. -- Edit bug report at http://bugs.php.net/?id=29375&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29375&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29375&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29375&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29375&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29375&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29375&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29375&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29375&r=support Expected behavior: http://bugs.php.net/fix.php?id=29375&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29375&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29375&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29375&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29375&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29375&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29375&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29375&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29375&r=float
#29377 [NEW]: can't call constructor in class definition
From: php at vladathome dot com Operating system: Linux PHP version: 5.0.0 PHP Bug Type: Zend Engine 2 problem Bug description: can't call constructor in class definition Description: In most (all?) other OOP-oriented languages, it's a common paradigm to define a class and provide a static member of the class in the definition and initialize it with a new object of the class. This is commonly used to implement singletons which are a must for many projects. This doesn't seem to work with PHP5. Reproduce code: --- Expected result: Parse error: parse error, unexpected T_NEW in /u1/home/vlad/php/test/3.php on line 3 Actual result: -- created static member of the class with the initialized object -- Edit bug report at http://bugs.php.net/?id=29377&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29377&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29377&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29377&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29377&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29377&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29377&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29377&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29377&r=support Expected behavior: http://bugs.php.net/fix.php?id=29377&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29377&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29377&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29377&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29377&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29377&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29377&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29377&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29377&r=float
#29378 [NEW]: foreach() doesn't work with arrays returned by __get
From: chernyshevsky at hotmail dot com
Operating system: Windows 2000
PHP version: 5.0.0
PHP Bug Type: Zend Engine 2 problem
Bug description: foreach() doesn't work with arrays returned by __get
Description:
Not sure if this is a duplicate of #28444. It's certainly related.
Basically I was trying to loop through an array set earlier using __set
and retrieve through __get. Simple enough it seems, but the engine died
with an "Cannot access undefined property for object with overloaded
property access" fatal error.
Reproduce code:
---
class Object {
private $values;
function __set($name, $value) {
$this->values[$name] = $value;
}
function __get($name) {
return $this->values[$name];
}
}
$O = new Object;
$O->cows = array("Betty", "Agnes", "Jeff");
foreach($O->cows as $cow) {
echo "$cow";
}
Expected result:
Betty
Agnes
Jeff
Actual result:
--
Fatal error: Cannot access undefined property for object with overloaded
property access
--
Edit bug report at http://bugs.php.net/?id=29378&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29378&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29378&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29378&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29378&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29378&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29378&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29378&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29378&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29378&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29378&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29378&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29378&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29378&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29378&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29378&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29378&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29378&r=float
#29283 [Com]: Statement isn't valid anymore warning during executing prepared mysqi queries
ID: 29283
Comment by: dev at edwinchu dot info
Reported By: divisor at ad69 dot com
Status: Open
Bug Type: MySQL related
Operating System: FreeBSD 4.10
PHP Version: 5.0.0
New Comment:
Hi,
I have got the same problem. I am using PHP5 release with
MySQL4.1.3-beta.
The code is simple:
$mysqli = new mysqli(); // connected successfully
$stmt = $mysqli->prepare("SOME VALID QUERY");
$stmt->execute(); // No problem here
$mysqli2 = $mysqli;
$mysqli2->query("THE SAME QUERY"); // Still OK
$stmt2 = $mysqli2->prepare("THE SAME QUERY");
$stmt2->execute();
The last line failed and returning "Warning: Statement isn't valid
anymore in xxx".
Previous Comments:
[2004-07-21 16:24:11] divisor at ad69 dot com
it caused randomly on all statetments, prepare() was ok but execute()
failed:
if ($stmt=$DB->prepare("select something from table where name=?")) {
$stmt->bind_param('s',$name);
$stmt->execute(); // HERE PHP WRITE WARNING
// AND STMT COINTAIN NO DATA
variables stmt->error, stmt->errno are empty
that's strange but after removing lines 182-187 from
ext/mysqli/php_mysqli.h:
if (!strcmp((char *)__name, "mysqli_stmt")) {\
if (!((MYSQL_STMT *)__ptr)->mysql) {\
php_error(E_WARNING, "Statement isn't valid
anymore");\
RETURN_NULL();\
}\
}\
}
it started working without any problems. but of course this 'hack' of
php code isn't good ;)
[2004-07-21 10:03:11] [EMAIL PROTECTED]
Please provide a short script, where we can see where the
error occurs. Also try to catch the errormessages via
->stmt_error/errno properties.
[2004-07-20 20:17:08] divisor at ad69 dot com
sorry I've accidently provided wrong mysql version
of course it's mysql 4.1.3 beta
[2004-07-20 20:15:49] divisor at ad69 dot com
Description:
The problem is in CLI as well as in apache module
I have mysql 4.3.1 and php 5.0.0 installed, use mysqli interface to
work with mysql.
In different scripts in different places (mostly random) I get the
following error:
1) Warning message: Statement isn't valid anymore
2) Statetment result contains no data
Reproduce code:
---
appears in randomly different places, all like this:
($DB is mysqli object)
if ($stmt=$DB->prepare("select something from table where name=?")) {
$stmt->bind_param('s',$name);
$stmt->execute();
Expected result:
The same code worked fine on the second server running FreeBSD 5.2.1
without any problems. The main difference between 2 servers I think
that the first one (where bug appears) is a productional server with
many requests to apache/php/mysql, the second one is a development
server with no usage.
Actual result:
--
get Warning: Statement isn't valid anymore message and statetment isn't
executed
--
Edit this bug report at http://bugs.php.net/?id=29283&edit=1
#29371 [Opn->Csd]: php does not have gif support when compiled against gd 2.0.28
ID: 29371 Updated by: [EMAIL PROTECTED] Reported By: edman007x at mac dot com -Status: Open +Status: Closed Bug Type: GD related Operating System: Slackware-current PHP Version: 4.3.8 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. gif support will be in the next release, it was already added to CVS. Previous Comments: [2004-07-25 08:42:39] milan dot kerslager at pslib dot cz You have to patch PHP to get back GIF support. There is one patch available here: http://hyvatti.iki.fi/~jaakko/sw/ It seems that there are waiting patches in CVS. Afer QA they (possibly) will be included in the next release of PHP. [2004-07-25 05:57:39] edman007x at mac dot com Description: i downloaded gd 2.0.28 and compiled it, it has gif support, then i compiled php againt it, but php did not hav gif support -proof that gd has gif support [EMAIL PROTECTED]:~$ /usr/local/gd/bin/gdlib-config --all GD library 2.0.28 includedir: /usr/local/gd/include cflags: -I/usr/local/gd/include ldflags: -L/usr/lib -Wl,-rpath,/usr/lib -L/usr/X11R6/lib libs: -lXpm -lX11 -ljpeg -lfreetype -lpng12 -lz -lm libdir: /usr/local/gd/lib features: GD_XPM GD_JPEG GD_FREETYPE GD_PNG GD_GIF my configure command './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mysql' '--with-bz2' '--with-gd=/usr/local/gd' '--enable-ftp' '--with-mysql-sock' '--with-ttf' '--with-freetype-dir' '--with-t1lib' '--enable-calendar' '--with-jpeg-dir' '--with-png-dir' '--prefix=/usr/local/php' '--exec-prefix=/usr/local/php' '--with-zlib' '--disable-cgi' '--with-curl' '--with-openssl' Reproduce code: --- var_dump(gd_info()); Expected result: should show that there is gif read and write support Actual result: -- shows that there is no gif support -- Edit this bug report at http://bugs.php.net/?id=29371&edit=1
#29357 [Opn->Csd]: "constant already defined error" is messed up
ID: 29357
Updated by: [EMAIL PROTECTED]
Reported By: xuefer at 21cn dot com
-Status: Open
+Status: Closed
Bug Type: Unknown/Other Function
Operating System: linux&xp
PHP Version: 4.3.7
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:
[2004-07-23 21:22:50] xuefer at 21cn dot com
Description:
php -r 'define("a", 1); define("a", 1);'
Notice: Constant [EMAIL PROTECTED]@ already defined in Command line code on line
--
Edit this bug report at http://bugs.php.net/?id=29357&edit=1
#29364 [Opn->Bgs]: Causes compile failure
ID: 29364 Updated by: [EMAIL PROTECTED] Reported By: jwk at cbinc dot net -Status: Open +Status: Bogus Bug Type: mnoGoSearch related Operating System: Redhat 9 PHP Version: 4.3.8 New Comment: 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. Thank you for your interest in PHP. This error occurs due to a symbol conflict between the two underlying libraries, mysql & mnogosearch Previous Comments: [2004-07-24 13:50:06] jwk at cbinc dot net Description: When trying to compile PHP 4.3.8 or 5.0.0 with the mnogosearch extension (either the version with the stable tarball, the latest snapshot, or 1.91 from the mnogosearch.com website) the compile fails. Reproduce code: --- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-xml --enable-bcmath --enable-calendar --with-curl --enable-ftp --with-gd --with-jpeg-dir=/usr/local --with-png-dir=/usr --with-xpm-dir=/usr/X11R6 --with-gettext --with-mcrypt --enable-magic-quotes --with-mysql=/usr --enable-discard-path --with-pear --enable-sockets --enable-track-vars --with-ttf --with-freetype-dir=/usr --enable-gd-native-ttf --enable-versioning --with-zlib --with-mnogosearch make Expected result: To compile Actual result: -- It produces this error: /usr/lib/mysql/libmysqlclient.a(net.o)(.text+0x990): first defined here /usr/lib/mysql/libmysqlclient.a(net.o)(.text+0xc00): In function `net_request_file': : multiple definition of `net_request_file' /usr/lib/mysql/libmysqlclient.a(net.o)(.text+0xc00): first defined here collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 I ran configure without the --with-mnogosearch and it compiled and installed fine. -- Edit this bug report at http://bugs.php.net/?id=29364&edit=1
#29349 [Opn->Bgs]: imagecreatefromstring segfaults (fix included)
ID: 29349
Updated by: [EMAIL PROTECTED]
Reported By: k at ailis dot de
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: Linux
PHP Version: 4CVS-2004-07-23 (stable)
New Comment:
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.
Thank you for your interest in PHP.
This is a bug in the GD library, we recommend to always use
the bundled GD library, which as you've indicated does not
have this problem.
Previous Comments:
[2004-07-25 15:21:35] adconrad at debian dot org
As of the next upload to the Debian archive, we will be using the
following patch, which seems to clear up every php4-gd segfault bug
we've had reported:
--- php4-4.3.8/ext/gd/gd.c.orig 2004-07-24 06:00:25.0 -0600
+++ php4-4.3.8/ext/gd/gd.c 2004-07-24 06:10:38.0 -0600
@@ -1242,7 +1242,7 @@
#ifdef HAVE_GD_WBMP
else {
gdIOCtx *io_ctx;
- io_ctx = gdNewDynamicCtx (8, data);
+ io_ctx = gdNewDynamicCtxEx (8, data, 0);
if (io_ctx) {
if (getmbi((int(*)(void*))gdGetC, io_ctx) == 0
&& skipheader((int(*)(void*))gdGetC, io_ctx) == 0 ) {
#if HAVE_LIBGD204
@@ -1274,7 +1274,7 @@
gdImagePtr im;
gdIOCtx *io_ctx;
- io_ctx = gdNewDynamicCtx (Z_STRLEN_PP(data),
Z_STRVAL_PP(data));
+ io_ctx = gdNewDynamicCtxEx (Z_STRLEN_PP(data),
Z_STRVAL_PP(data), 0);
if (!io_ctx) {
return NULL;
@@ -1428,7 +1428,7 @@
goto out_err;
}
- io_ctx = gdNewDynamicCtx(buff_size, buff);
+ io_ctx = gdNewDynamicCtxEx(buff_size, buff, 0);
if(!io_ctx) {
php_error_docref(NULL TSRMLS_CC,
E_WARNING,"Cannot allocate GD IO context");
goto out_err;
[2004-07-24 14:08:46] adconrad at debian dot org
Also note that gdNewDynamicCtx is used 3 times in gd.c, not just once
as the patch would lead one to believe.
[2004-07-24 14:05:05] adconrad at debian dot org
Note that gdNewDynamicCtxEx was added in 2.0.21, so if this is used
unconditionally, PHP will need to depend on that version of libgd2.
(Also, this does appear to fix the segfaults being reported all over
the place for imagecreatefromstring with the external libgd2)
[2004-07-23 14:09:13] k at ailis dot de
I have searched the closed bug reports and it looks like
you will find the whole problem in #24174 (including a
backtrace). Your solution was to modify the bundled GD
library. In my opinion this is a very bad solution because
this does not fix the problem if you use the external GD
library. And it seems NOT to be a bug in GD! It's seems
more like a misuse of a GD-function. The external GD
library AND the bundled one can be used if you try my fix
and check if it does not break something else. It looks to
me that Boutell has created this *CtxEx function exactly
for people who want to control the memory-freeing
behaviour of the function so it might be the correct
solution.
[2004-07-23 13:50:20] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Please, provide a gdb backtrace.
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/29349
--
Edit this bug report at http://bugs.php.net/?id=29349&edit=1
#29368 [Opn->Csd]: The destructor is called when an exception is thrown from the constructor
ID: 29368 Updated by: [EMAIL PROTECTED] Reported By: fixxxer at php5 dot ru -Status: Open +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5.0.0 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: [2004-07-24 22:43:10] fixxxer at php5 dot ru Description: The destructor is called if throwing an exception from the constructor. This seems at least illogical and it's contrary to usual behaviour of alike languages like C++ where destructor is not called in this case. Reproduce code: --- Expected result: Inside constructor Caught exception! Actual result: -- Inside constructor Inside destructor Caught exception! -- Edit this bug report at http://bugs.php.net/?id=29368&edit=1
#29354 [Opn->Fbk]: Exception constructor marked as both public and protected
ID: 29354
Updated by: [EMAIL PROTECTED]
Reported By: Jared dot Williams1 at ntlworld dot com
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: Windows 2000/IIS
PHP Version: 5.0.0
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:
[2004-07-23 17:57:09] Jared dot Williams1 at ntlworld dot com
Description:
Exception class constructor when inspected via the Reflection api,
seems to be both marked a public and protected.
Reproduce code:
---
$exceptionClass = new ReflectionClass('Exception');
$exceptionConstructor = $exceptionClass->getConstructor();
var_dump($exceptionConstructor->isPublic());
var_dump($exceptionConstructor->isProtected());
Expected result:
bool(true) bool(false)
or
bool(false) bool(true)
Actual result:
--
bool(true) bool(true)
--
Edit this bug report at http://bugs.php.net/?id=29354&edit=1
#26603 [Com]: Request to add a few dbase functions
ID: 26603 Comment by: leonard at den dot ottolander dot nl Reported By: leonardjo at hetnet dot nl Status: Open Bug Type: Feature/Change Request Operating System: All PHP Version: 4.3.4 New Comment: Still patches cleanly (with an offset) against 4.3.8. Previous Comments: [2003-12-12 11:01:23] leonardjo at hetnet dot nl Description: This patch adds a few functions to the dbase functionality. To be more specific it defines the following functions: + PHP_FUNCTION(dbase_field_names); + PHP_FUNCTION(dbase_field_types); + PHP_FUNCTION(dbase_field_lengths); + PHP_FUNCTION(dbase_field_decimals); The function implementations are based on the code of the existing dbase functions. The patch was originally created against PHP-4.1.2, but still patches cleanly (with an offset) against 4.3.4. dbase-patch: http://www.ottolander.nl/opensource/dbase2mysql/php-dbase.patch.tgz -- Edit this bug report at http://bugs.php.net/?id=26603&edit=1
#29349 [Bgs->Opn]: imagecreatefromstring segfaults (fix included)
ID: 29349
User updated by: k at ailis dot de
Reported By: k at ailis dot de
-Status: Bogus
+Status: Open
Bug Type: GD related
Operating System: Linux
PHP Version: 4CVS-2004-07-23 (stable)
New Comment:
Narf... This is NOT a bug in the GD library. The function
you are using is freeing memory because this function is
MEANT to do exactly this because this function normally
deals with data which was allocated by GD itself. But you
are passing data to this function which was allocated by
YOU. Boutell has already dealt with this problem and has
created new functions which exactly suit your needs: The
gdImageCreateFrom*Ptr functions and also the
gdNewDynamicCtxEx function. RTFM:
* The new gdNewDynamicCtxEx function was added to
support the easy
implementation of the above functions and to
correct a design
problem which made life unpleasant for those
passing in memory not
originally allocated by gd to the gdNewDynamicCtx
function by
providing a way to specify that gd should never
free or reallocate
a particular block of memory. The gdNewDynamicCtx
function and its
relatives, although still exported for ABI
compatibility, are now
deprecated except for internal use, in favor of
[45]gdImageCreateFromPngPtr and its relatives.
So please stop putting your head in the sand and apply
Adam Conrad's patch or move to the new
gdImageCreateFrom*Ptr functions.
Previous Comments:
[2004-07-25 19:28:39] [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.
Thank you for your interest in PHP.
This is a bug in the GD library, we recommend to always use
the bundled GD library, which as you've indicated does not
have this problem.
[2004-07-25 15:21:35] adconrad at debian dot org
As of the next upload to the Debian archive, we will be using the
following patch, which seems to clear up every php4-gd segfault bug
we've had reported:
--- php4-4.3.8/ext/gd/gd.c.orig 2004-07-24 06:00:25.0 -0600
+++ php4-4.3.8/ext/gd/gd.c 2004-07-24 06:10:38.0 -0600
@@ -1242,7 +1242,7 @@
#ifdef HAVE_GD_WBMP
else {
gdIOCtx *io_ctx;
- io_ctx = gdNewDynamicCtx (8, data);
+ io_ctx = gdNewDynamicCtxEx (8, data, 0);
if (io_ctx) {
if (getmbi((int(*)(void*))gdGetC, io_ctx) == 0
&& skipheader((int(*)(void*))gdGetC, io_ctx) == 0 ) {
#if HAVE_LIBGD204
@@ -1274,7 +1274,7 @@
gdImagePtr im;
gdIOCtx *io_ctx;
- io_ctx = gdNewDynamicCtx (Z_STRLEN_PP(data),
Z_STRVAL_PP(data));
+ io_ctx = gdNewDynamicCtxEx (Z_STRLEN_PP(data),
Z_STRVAL_PP(data), 0);
if (!io_ctx) {
return NULL;
@@ -1428,7 +1428,7 @@
goto out_err;
}
- io_ctx = gdNewDynamicCtx(buff_size, buff);
+ io_ctx = gdNewDynamicCtxEx(buff_size, buff, 0);
if(!io_ctx) {
php_error_docref(NULL TSRMLS_CC,
E_WARNING,"Cannot allocate GD IO context");
goto out_err;
[2004-07-24 14:08:46] adconrad at debian dot org
Also note that gdNewDynamicCtx is used 3 times in gd.c, not just once
as the patch would lead one to believe.
[2004-07-24 14:05:05] adconrad at debian dot org
Note that gdNewDynamicCtxEx was added in 2.0.21, so if this is used
unconditionally, PHP will need to depend on that version of libgd2.
(Also, this does appear to fix the segfaults being reported all over
the place for imagecreatefromstring with the external libgd2)
[2004-07-23 14:09:13] k at ailis dot de
I have searched the closed bug reports and it looks like
you will find the whole problem in #24174 (including a
backtrace). Your solution was to modify the bundled GD
library. In my opinion this is a very bad solution because
this does not fix the problem if you use the external GD
library. And it seems NOT to be a bug in GD! It's seems
more like a misuse of a GD-function. The external GD
library AND the bundled one can be used if you try my fix
and check if it does not break something else. It looks to
me that Boutell has created this *CtxEx function exactly
for people who want to control the memory-freeing
behaviour of the function so it might be the correct
solution.
-
#29372 [Bgs->Opn]: destructor not called
ID: 29372
User updated by: mark at seventhcycle dot net
Reported By: mark at seventhcycle dot net
-Status: Bogus
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Fedora Core 2
PHP Version: 5.0.0
New Comment:
Interestingly, this follows the same behavior as
register_shutdown_function() does in php5, in that it can't send
anything out to the browser.
php4 can do this, though, and does properly print shutdown
information.
function shut()
{
echo "shutting down";
}
Previous Comments:
[2004-07-25 08:29:31] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You cannot use print, echo and friends in destructors because they are
executed after the output facility has been shutdown. Use unset($obj)
at the end of your script to force termination prior to starting
shutdown process.
[2004-07-25 07:55:31] mark at seventhcycle dot net
Description:
The destructor for any classes I make isn't being called. Here is a
diff of my php.ini to the distributed one.
/usr/local/lib#> diff php.ini php.ini-dist
120c120
< zlib.output_compression = On
---
> zlib.output_compression = Off
293c293
< log_errors = On
---
> log_errors = Off
340c340
< error_log = syslog
---
> ;error_log = syslog
373c373
< register_globals = On
---
> register_globals = Off
952c952
< session.use_trans_sid = 1
---
> session.use_trans_sid = 0
The reproduced code run below is live here:
http://seventhcycle.net/php/classtest.php
A copy of my phpinfo can be found here:
http://seventhcycle.net/php/phpinfo.php
Reproduce code:
---
Expected result:
construct
destruct
Actual result:
--
construct
--
Edit this bug report at http://bugs.php.net/?id=29372&edit=1
#29372 [Opn]: destructor not called
ID: 29372
User updated by: mark at seventhcycle dot net
Reported By: mark at seventhcycle dot net
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Fedora Core 2
PHP Version: 5.0.0
New Comment:
Sorry, the proper code posted would be:
function shut()
{
echo "shutting down";
}
register_shutdown_function("shut");
This prints out properly in php4. Is it a bug in php4, or a change of
functionality for php5?
Previous Comments:
[2004-07-25 20:58:20] mark at seventhcycle dot net
Interestingly, this follows the same behavior as
register_shutdown_function() does in php5, in that it can't send
anything out to the browser.
php4 can do this, though, and does properly print shutdown
information.
function shut()
{
echo "shutting down";
}
[2004-07-25 08:29:31] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You cannot use print, echo and friends in destructors because they are
executed after the output facility has been shutdown. Use unset($obj)
at the end of your script to force termination prior to starting
shutdown process.
[2004-07-25 07:55:31] mark at seventhcycle dot net
Description:
The destructor for any classes I make isn't being called. Here is a
diff of my php.ini to the distributed one.
/usr/local/lib#> diff php.ini php.ini-dist
120c120
< zlib.output_compression = On
---
> zlib.output_compression = Off
293c293
< log_errors = On
---
> log_errors = Off
340c340
< error_log = syslog
---
> ;error_log = syslog
373c373
< register_globals = On
---
> register_globals = Off
952c952
< session.use_trans_sid = 1
---
> session.use_trans_sid = 0
The reproduced code run below is live here:
http://seventhcycle.net/php/classtest.php
A copy of my phpinfo can be found here:
http://seventhcycle.net/php/phpinfo.php
Reproduce code:
---
Expected result:
construct
destruct
Actual result:
--
construct
--
Edit this bug report at http://bugs.php.net/?id=29372&edit=1
#29372 [Opn->Csd]: destructor not called
ID: 29372
Updated by: [EMAIL PROTECTED]
Reported By: mark at seventhcycle dot net
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
-Operating System: Fedora Core 2
+Operating System: *
PHP Version: 5.0.0
-Assigned To:
+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.
Whatever...this is fixed in cvs for 5.0.1
Previous Comments:
[2004-07-25 21:00:39] mark at seventhcycle dot net
Sorry, the proper code posted would be:
function shut()
{
echo "shutting down";
}
register_shutdown_function("shut");
This prints out properly in php4. Is it a bug in php4, or a change of
functionality for php5?
[2004-07-25 20:58:20] mark at seventhcycle dot net
Interestingly, this follows the same behavior as
register_shutdown_function() does in php5, in that it can't send
anything out to the browser.
php4 can do this, though, and does properly print shutdown
information.
function shut()
{
echo "shutting down";
}
[2004-07-25 08:29:31] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You cannot use print, echo and friends in destructors because they are
executed after the output facility has been shutdown. Use unset($obj)
at the end of your script to force termination prior to starting
shutdown process.
[2004-07-25 07:55:31] mark at seventhcycle dot net
Description:
The destructor for any classes I make isn't being called. Here is a
diff of my php.ini to the distributed one.
/usr/local/lib#> diff php.ini php.ini-dist
120c120
< zlib.output_compression = On
---
> zlib.output_compression = Off
293c293
< log_errors = On
---
> log_errors = Off
340c340
< error_log = syslog
---
> ;error_log = syslog
373c373
< register_globals = On
---
> register_globals = Off
952c952
< session.use_trans_sid = 1
---
> session.use_trans_sid = 0
The reproduced code run below is live here:
http://seventhcycle.net/php/classtest.php
A copy of my phpinfo can be found here:
http://seventhcycle.net/php/phpinfo.php
Reproduce code:
---
Expected result:
construct
destruct
Actual result:
--
construct
--
Edit this bug report at http://bugs.php.net/?id=29372&edit=1
#29349 [Opn->Bgs]: imagecreatefromstring segfaults (fix included)
ID: 29349
Updated by: [EMAIL PROTECTED]
Reported By: k at ailis dot de
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: Linux
PHP Version: 4CVS-2004-07-23 (stable)
New Comment:
The patch relies on a function only available in later
versions of GD, which not everyone has. The bundled GD has
no problem what so over and should be used.
Previous Comments:
[2004-07-25 20:54:32] k at ailis dot de
Narf... This is NOT a bug in the GD library. The function
you are using is freeing memory because this function is
MEANT to do exactly this because this function normally
deals with data which was allocated by GD itself. But you
are passing data to this function which was allocated by
YOU. Boutell has already dealt with this problem and has
created new functions which exactly suit your needs: The
gdImageCreateFrom*Ptr functions and also the
gdNewDynamicCtxEx function. RTFM:
* The new gdNewDynamicCtxEx function was added to
support the easy
implementation of the above functions and to
correct a design
problem which made life unpleasant for those
passing in memory not
originally allocated by gd to the gdNewDynamicCtx
function by
providing a way to specify that gd should never
free or reallocate
a particular block of memory. The gdNewDynamicCtx
function and its
relatives, although still exported for ABI
compatibility, are now
deprecated except for internal use, in favor of
[45]gdImageCreateFromPngPtr and its relatives.
So please stop putting your head in the sand and apply
Adam Conrad's patch or move to the new
gdImageCreateFrom*Ptr functions.
[2004-07-25 19:28:39] [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.
Thank you for your interest in PHP.
This is a bug in the GD library, we recommend to always use
the bundled GD library, which as you've indicated does not
have this problem.
[2004-07-25 15:21:35] adconrad at debian dot org
As of the next upload to the Debian archive, we will be using the
following patch, which seems to clear up every php4-gd segfault bug
we've had reported:
--- php4-4.3.8/ext/gd/gd.c.orig 2004-07-24 06:00:25.0 -0600
+++ php4-4.3.8/ext/gd/gd.c 2004-07-24 06:10:38.0 -0600
@@ -1242,7 +1242,7 @@
#ifdef HAVE_GD_WBMP
else {
gdIOCtx *io_ctx;
- io_ctx = gdNewDynamicCtx (8, data);
+ io_ctx = gdNewDynamicCtxEx (8, data, 0);
if (io_ctx) {
if (getmbi((int(*)(void*))gdGetC, io_ctx) == 0
&& skipheader((int(*)(void*))gdGetC, io_ctx) == 0 ) {
#if HAVE_LIBGD204
@@ -1274,7 +1274,7 @@
gdImagePtr im;
gdIOCtx *io_ctx;
- io_ctx = gdNewDynamicCtx (Z_STRLEN_PP(data),
Z_STRVAL_PP(data));
+ io_ctx = gdNewDynamicCtxEx (Z_STRLEN_PP(data),
Z_STRVAL_PP(data), 0);
if (!io_ctx) {
return NULL;
@@ -1428,7 +1428,7 @@
goto out_err;
}
- io_ctx = gdNewDynamicCtx(buff_size, buff);
+ io_ctx = gdNewDynamicCtxEx(buff_size, buff, 0);
if(!io_ctx) {
php_error_docref(NULL TSRMLS_CC,
E_WARNING,"Cannot allocate GD IO context");
goto out_err;
[2004-07-24 14:08:46] adconrad at debian dot org
Also note that gdNewDynamicCtx is used 3 times in gd.c, not just once
as the patch would lead one to believe.
[2004-07-24 14:05:05] adconrad at debian dot org
Note that gdNewDynamicCtxEx was added in 2.0.21, so if this is used
unconditionally, PHP will need to depend on that version of libgd2.
(Also, this does appear to fix the segfaults being reported all over
the place for imagecreatefromstring with the external libgd2)
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/29349
--
Edit this bug report at http://bugs.php.net/?id=29349&edit=1
#29167 [Opn->Fbk]: fopen works differently in a constructor vs. a destructor
ID: 29167 Updated by: [EMAIL PROTECTED] Reported By: kaspersv at privat dot dk -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.0.0 -Assigned To: +Assigned To: helly 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: [2004-07-15 18:25:27] [EMAIL PROTECTED] Nothing to do with fopen, but instead the shutdown order; reclassifying. [2004-07-15 09:12:46] [EMAIL PROTECTED] ATM you need to explicitly unset the object before script termination by using: unset($bugtest); [2004-07-14 23:44:15] kaspersv at privat dot dk Description: When I run the attached code on my machine, it creates a file called testing.txt in the directory where the php-file was located, containing the line "Constructor". And another file in the apache servers root directory also called testing.txt, containing the line "Destructor". Reproduce code: --- Expected result: A single file containing the two lines: Constructor Destructor -- Edit this bug report at http://bugs.php.net/?id=29167&edit=1
#29090 [Opn->Fbk]: Destructor Segfaults PHP5RC3
ID: 29090
Updated by: [EMAIL PROTECTED]
Reported By: derek at battams dot ca
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux 2.4
PHP Version: 5.0.0RC3
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:
[2004-07-17 19:28:57] derek at battams dot ca
This problem has carried over into the 5.0.0 final release.
[2004-07-11 05:47:01] derek at battams dot ca
Description:
PHP segfaults when trying to use the result of md5 or sha1 (tried md5
initally, then tried sha1 when code kept segfaulting) as a file name in
my destructor. Unfortunately, I can't reproduce the crash with a small
script (the class in question is part of a much larger system), but I
know how to elimite the segfault within the project's codebase. If I
remove the call to md5 in the sample code then there's no segfault (no
matter how hard I try). Once I put the md5 (or sha1) call back into
the destructor then the segfault returns immediately.
Reproduce code:
---
public function __destruct()
{
$cacheFile1 = BP_CACHE . "/" . md5($this->getDN());
$cacheFile2 = BP_CACHE . "/" .
md5($this->findAttribute("mail"));
if(!file_exists($cacheFile1) || !file_exists($cacheFile2) ||
!(is_link($cacheFile1) xor is_link($cacheFile2)))
if(file_exists($cacheFile1) && !is_link($cacheFile1))
{
if(file_exists($cacheFile2))
@unlink($cacheFile2);
@symlink(basename($cacheFile1), $cacheFile2);
}
else if(file_exists($cacheFile2) && !is_link($cacheFile2))
{
if(file_exists($cacheFile1))
@unlink($cacheFile1);
@symlink(basename($cacheFile2), $cacheFile1);
}
else
{
if(file_exists($cacheFile1))
@unlink($cacheFile1);
if(file_exists($cacheFile2))
@unlink($cacheFile2);
}
return;
}
Expected result:
Destructor returns with no segfault.
Actual result:
--
(gdb) bt
#0 0x081a3c99 in zend_hash_find (ht=0x4042cc5c,
arKey=0x4042c734 "cacheFile1", nKeyLength=11, pData=0x33303934)
at /tmp/php-5.0.0RC3/Zend/zend_hash.c:846
#1 0x081b74b6 in zend_fetch_var_address (opline=0x404323b8,
Ts=0xbfffe030,
type=0) at /tmp/php-5.0.0RC3/Zend/zend_execute.c:762
#2 0x081b9c5f in zend_fetch_r_handler (execute_data=0xbfffe6d0,
opline=0x404323b8, op_array=0x4042c25c)
at /tmp/php-5.0.0RC3/Zend/zend_execute.c:1994
#3 0x081b8a77 in execute (op_array=0x4042c25c)
at /tmp/php-5.0.0RC3/Zend/zend_execute.c:1389
#4 0x08194fa6 in zend_call_function (fci=0xbfffe850,
fci_cache=0xbfffe830)
at /tmp/php-5.0.0RC3/Zend/zend_execute_API.c:835
#5 0x081aa0c2 in zend_call_method (object_pp=0xbfffe8dc,
obj_ce=0x4042b824,
fn_proxy=0x0, function_name=0x81f9c04 "__destruct",
function_name_len=10,
retval_ptr_ptr=0x0, param_count=1078141880, arg1=0x0, arg2=0x0)
at /tmp/php-5.0.0RC3/Zend/zend_interfaces.c:79
#6 0x081ac3e1 in zend_objects_destroy_object (object=0x4043bf54,
handle=1078141880) at /tmp/php-5.0.0RC3/Zend/zend_objects.c:78
#7 0x081ae106 in zend_objects_store_call_destructors
(objects=0x82521d4)
at /tmp/php-5.0.0RC3/Zend/zend_objects_API.c:54
#8 0x0819428c in shutdown_executor ()
at /tmp/php-5.0.0RC3/Zend/zend_execute_API.c:209
#9 0x0819db09 in zend_deactivate () at
/tmp/php-5.0.0RC3/Zend/zend.c:819
#10 0x0816cdb5 in php_request_shutdown (dummy=0x0)
at /tmp/php-5.0.0RC3/main/main.c:1212
#11 0x081c3e8e in main (argc=2, argv=0xb6a4)
at /tmp/php-5.0.0RC3/sapi/cli/php_cli.c:1046
#12 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
Also, this from the debug enabled PHP binary:
[EMAIL PROTECTED] public_html]$ $R/php test.person.php
Warning: String is not zero-terminated
(
ZÌ*Ì*D) (source:
/tmp/php-5.0.0RC3/Zend/zend_execute_API.c:391) in Unknown on line 0
[Sat Jul 10 23:41:43 2004] Script: 'test.person.php'
---
/tmp/php-5.0.0RC3/Zend/zend_execute_API.c(391) : Block 0x4140E9D4
status:
/tmp/php-5.0.0RC3/Zend/zend_variables.c(45) : Actual location (location
was relayed)
Beginning: Cached (allocated on
/tmp/php-5.0.0RC3/main/streams/streams.c:1529, 69 bytes)
End: OK
---
--
Edit this bug report at http://bugs.php.net/?id=29090&edit=1
#29369 [Opn->Csd]: filename with double quotes cutted during upload
ID: 29369 Updated by: [EMAIL PROTECTED] Reported By: florian at angehrn dot com -Status: Open +Status: Closed Bug Type: *Directory/Filesystem functions Operating System: Linux PHP Version: 4.3.8 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: [2004-07-25 00:51:32] florian at angehrn dot com Description: if i upload a file which contains double quotes in it, the filename is cutted Reproduce code: --- Send this file: Expected result: input file: 0119"1.jpg content of $_FILES['userfile']['name']: 0119"1.jpg Actual result: -- input file: 0119"1.jpg content of $_FILES['userfile']['name']: 0119 -- Edit this bug report at http://bugs.php.net/?id=29369&edit=1
#27868 [Fbk->Opn]: segfault on apache and php5 cli (only with --disable-debug!)
ID: 27868
User updated by: blackei2k at gmx dot de
Reported By: blackei2k at gmx dot de
-Status: Feedback
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2004-04-07
New Comment:
Still there the segfault.
error.log of apache:
[Sun Jul 25 21:28:17 2004] [notice] child pid 11664 exit signal
Segmentation fault (11)
php configured like:
'./configure' '--disable-debug' '--disable-cli'
'--with-apxs=/usr/bin/apxs' '--disable-pear'
System tested on:
Linux baggy 2.4.21 #1 Fri Jun 27 21:24:38 CEST 2003 i686
PHP Version 5.1.0-dev
PHP API 20031224
PHP Extension 20040718
Zend Extension 220040718
Sorry stas, but this is still happening.
Previous Comments:
[2004-07-19 16:51:45] [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
can't reproduce with new PHP5, probably fixed
[2004-04-07 08:05:28] [EMAIL PROTECTED]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 20934)]
0x082a972d in zend_std_get_method (object=0x40e420bc,
method_name=0x40e4213c "zar", method_len=3)
at /usr/src/web/php/php5/Zend/zend_object_handlers.c:673
673 if (zend_hash_find(&zobj->ce->function_table,
lc_method_name, method_len+1, (void **)&fbc) == FAILURE) {
(gdb) bt
#0 0x082a972d in zend_std_get_method (object=0x40e420bc,
method_name=0x40e4213c "zar", method_len=3)
at /usr/src/web/php/php5/Zend/zend_object_handlers.c:673
#1 0x082b72c7 in zend_init_method_call_handler
(execute_data=0xbfffd800, opline=0x40e40420, op_array=0x40e35e54)
at /usr/src/web/php/php5/Zend/zend_execute.c:2505
#2 0x082b4a07 in execute (op_array=0x40e35e54) at
/usr/src/web/php/php5/Zend/zend_execute.c:1391
#3 0x0829a699 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/web/php/php5/Zend/zend.c:1057
#4 0x082686f6 in php_execute_script (primary_file=0xbbd0) at
/usr/src/web/php/php5/main/main.c:1630
#5 0x082c7a92 in main (argc=2, argv=0xbc54) at
/usr/src/web/php/php5/sapi/cli/php_cli.c:943
[2004-04-05 07:47:01] blackei2k at gmx dot de
I got a working (segfaulting) test-case here:
getMessage() . "\n";
}
return true;
}
}
$o = new bar;
$o->zar();
?>
Hope that helps
[2004-04-05 07:26:08] blackei2k at gmx dot de
Description:
I get a segfault while running a script of mine. Here what apache's
error.log says:
[Mon Apr 5 13:36:36 2004] [notice] child pid 2072 exit signal
Segmentation fault (11)
It happens when i call the function
set_common_vars() which is a method of a class. If i run var_dump($o)
($o being an instance of the class set_common_vars is a member of) the
script errors as it should withoot segfaulting.
The function ist defined as:
function sets_common_vars()
{
$this->strCat = (isset ($_GET['load']) ? $_GET['load'] :
'homepage');
$this->strGet = $_SERVER['PHP_SELF'] . '?' . 'load=' .
$strCat;
return true;
}
This is very strange. I tried to build up a test-case as i thought it
was related to the try {} catch blocks in the contructor, but it
wasn't. My test-case did it's work as it was supposed to. I'm not sure
what i can do, as the provided information above will most likely not
help much tracing the bug to its source.
As the new object model is based on ZE2 i have classified this as an
engine issue.
--
Edit this bug report at http://bugs.php.net/?id=27868&edit=1
#29370 [Com]: Crash apache.exe (php5ts.dll)
ID: 29370
Comment by: grayw at mail dot montclair dot edu
Reported By: anthony dot debhian at only-for dot info
Status: Open
Bug Type: Reproducible crash
Operating System: Windows XP
PHP Version: 5.0.0
New Comment:
Can you provide the 'crash' output? Since this is for windows, is
there anything relevant in the logs you can view from Event Viewer? In
there you would see any messages relating to an kernel, application, or
service crash?
Previous Comments:
[2004-07-25 12:42:55] ahtin at hot dot ee
i got the same obscure crash with php 5.0 + apache 2.0.48 on win98se
with this code snippet:
-
db_fetch_row($s))
{
$x['birthday'].=$this->parse_tpl("k_links",$s2);
}
?>
no errors, just apache crash
[2004-07-25 03:34:02] anthony dot debhian at only-for dot info
Description:
The code crash apache.exe with php-5.0.0/apache-1.3.31 and
php-4.3.3/apache-1.3.27 (2 pc, 2 config)
The GET request does not appear in access.log and error.log.
this bug's odd, perhaps not important, but i send you feedback anyway.
Reproduce code:
---
$value) { if(is_array($array[$key])) {
$src.=$key; } }
return $src;
}
function funcfunc2($array,$test)
{
foreach($array['test'] as $key=>$value) { }
return $array;
}
$test['lol']['test1']="test1";
$test['lol']['test2']="test2";
$array=funcfunc($test);
$array=funcfunc2($array,"test");
?>
Expected result:
Just a fatal error.
--
Edit this bug report at http://bugs.php.net/?id=29370&edit=1
#29349 [Bgs]: imagecreatefromstring segfaults (fix included)
ID: 29349
User updated by: k at ailis dot de
Reported By: k at ailis dot de
Status: Bogus
Bug Type: GD related
Operating System: Linux
PHP Version: 4CVS-2004-07-23 (stable)
New Comment:
Then why are you not modifying your configure system so it
checks to have at least GD 2.0.21 if the external GD lib
is used? If you are argumenting that everyone should use
the bundled GD lib anyway then you don't need to bother
with those poor users which are not having at least GD
2.0.21.
But if you don't want to "exclude" users of older GD
libraries and you think it's ok that these users are not
able to use some PHP functions without segfaults then you
can do some conditional compiling. In that way you can
help users by saying "Update to GD 2.0.21 or better and
recompile PHP OR use the bundled GD" instead of insisting
only on the usage of the bundled one.
But slowly the impression comes to me that you don't want
users to use the external GD. You are already no longer
giving support for the usage of the external one (At least
nothing else then the silly "use the bundled GD library"
response which does not respect the fact that the user may
have reasons to use the external library). So maybe you
should be consequential and remove compilation support for
the external GD completely. Then you have no longer to
deal with bug reports like this...
Previous Comments:
[2004-07-25 21:10:18] [EMAIL PROTECTED]
The patch relies on a function only available in later
versions of GD, which not everyone has. The bundled GD has
no problem what so over and should be used.
[2004-07-25 20:54:32] k at ailis dot de
Narf... This is NOT a bug in the GD library. The function
you are using is freeing memory because this function is
MEANT to do exactly this because this function normally
deals with data which was allocated by GD itself. But you
are passing data to this function which was allocated by
YOU. Boutell has already dealt with this problem and has
created new functions which exactly suit your needs: The
gdImageCreateFrom*Ptr functions and also the
gdNewDynamicCtxEx function. RTFM:
* The new gdNewDynamicCtxEx function was added to
support the easy
implementation of the above functions and to
correct a design
problem which made life unpleasant for those
passing in memory not
originally allocated by gd to the gdNewDynamicCtx
function by
providing a way to specify that gd should never
free or reallocate
a particular block of memory. The gdNewDynamicCtx
function and its
relatives, although still exported for ABI
compatibility, are now
deprecated except for internal use, in favor of
[45]gdImageCreateFromPngPtr and its relatives.
So please stop putting your head in the sand and apply
Adam Conrad's patch or move to the new
gdImageCreateFrom*Ptr functions.
[2004-07-25 19:28:39] [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.
Thank you for your interest in PHP.
This is a bug in the GD library, we recommend to always use
the bundled GD library, which as you've indicated does not
have this problem.
[2004-07-25 15:21:35] adconrad at debian dot org
As of the next upload to the Debian archive, we will be using the
following patch, which seems to clear up every php4-gd segfault bug
we've had reported:
--- php4-4.3.8/ext/gd/gd.c.orig 2004-07-24 06:00:25.0 -0600
+++ php4-4.3.8/ext/gd/gd.c 2004-07-24 06:10:38.0 -0600
@@ -1242,7 +1242,7 @@
#ifdef HAVE_GD_WBMP
else {
gdIOCtx *io_ctx;
- io_ctx = gdNewDynamicCtx (8, data);
+ io_ctx = gdNewDynamicCtxEx (8, data, 0);
if (io_ctx) {
if (getmbi((int(*)(void*))gdGetC, io_ctx) == 0
&& skipheader((int(*)(void*))gdGetC, io_ctx) == 0 ) {
#if HAVE_LIBGD204
@@ -1274,7 +1274,7 @@
gdImagePtr im;
gdIOCtx *io_ctx;
- io_ctx = gdNewDynamicCtx (Z_STRLEN_PP(data),
Z_STRVAL_PP(data));
+ io_ctx = gdNewDynamicCtxEx (Z_STRLEN_PP(data),
Z_STRVAL_PP(data), 0);
if (!io_ctx) {
return NULL;
@@ -1428,7 +1428,7 @@
goto out_err;
}
- io_ctx = gdNewDynamicCtx(buff_size, buff);
+ io_ctx = gdNewDynamicCtxEx(buff_size, buff, 0);
if(!io_ctx) {
php_error_docref(NULL TSRMLS_CC,
E_WARNING,"Canno
#29379 [NEW]: idea for speed/memory optimization
From: AgnussConsulting at yahoo dot com Operating system: GNU/Linux PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: idea for speed/memory optimization Description: A greate idea (long-term goal) for a PHP6 or 7 release. Summary: Keep as scripting language (mod_php6) with an optional 'encoder/decoder' or compiler (mod_php6c) (for purchase). Goals: 0. Increase PHP revenue. 1. Convince the rest of the non-believers that PHP is THE programming language to rule all browser-based programs, and more. 2. Decrease CPU cycles & memory. 3a. It's cooler. 3b. We hate to have a $9/hr person come in behind us and mess up our hard work, or even copy it and claim as their own. 4. Will increase commercial software development using PHP. (( I love GPL, but without commercial, GPL wouldn't mean shit. )) 5. How? I have no clue, but you're the Super-Gods and i know you can do it! Sincerely, Travis Tennies [EMAIL PROTECTED] 702-375-7983 -- Edit bug report at http://bugs.php.net/?id=29379&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29379&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29379&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29379&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29379&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29379&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29379&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29379&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29379&r=support Expected behavior: http://bugs.php.net/fix.php?id=29379&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29379&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29379&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29379&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29379&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29379&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29379&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29379&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29379&r=float
#29090 [Com]: Destructor Segfaults PHP5RC3
ID: 29090
Comment by: marcus at lucidix dot com
Reported By: derek at battams dot ca
Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux 2.4
PHP Version: 5.0.0RC3
New Comment:
Description:
We are experiencing a similar seg fault, also in zend_hash_find.
Two servers running Linux 2.4, Apache 1.3, MySQL 4.0, PHP 5.0 (also
tested with CVS php5-200407242230.tar.bz2) segfault.
However, our application runs without issues on Windows XP, Apache 2.0,
MySQL 4.0, PHP 5.0.0.
The class this error occurs in is also part of a much larger system. We
have not yet been able to isolate the exact line of code causing this.
Additionally, the behavior is not consistent. Seg faults occur 95% of
the time, but occasionally it will run.
A few differences to the original bug report: We are not using
destructors, and no calls to md5 are made. The only common code between
our two code snippets is file_exists().
Please note: The following code snippet will not work by itself.
Reproduce code:
---
function _findstoredproc($storedproc)
{
// load the list of modules installed
$modmgr = lxModules::singleton();
$modules = $modmgr->modulelist();
// prepend the "core" module
$core = array(
'name' => 'core',
'type' => 'global',
'path' => GLOBALDIR . '/src/'
);
array_unshift($modules, $core);
// scan each module
foreach($modules as $module)
{
// assemble the file name, using module directory, drv/, proc
name
and driver extension
$filename = $module['path'] . 'drv/' . $storedproc . '.' .
$this->db_driver;
// check if the "stored proc" exists
if (file_exists($filename))
{
return $filename;
}
}
return false;
}
Expected Result:
Function returns a filename or false.
Actual Result:
"The page cannot be displayed" as the Apache child process seg faults.
Apache Error Log:
-
/usr/local/src/php5-200407242230/main/streams/streams.c(1551) : Block
0x0838E678 status:
Beginning: Overrun (magic=0x4020F0E4, expected=0x7312F8DC)
End: Unknown
---
[Sun Jul 25 13:25:31 2004] Script:
'/home/marcus/public_html/webapp/trunk/index.lx'
---
/usr/local/src/php5-200407242230/Zend/zend_constants.c(33) : Block
0x404D9CA3 status:
/usr/local/src/php5-200407242230/Zend/zend_variables.c(39) : Actual
location (location was relayed)
Beginning: Overrun (magic=0x75622E6E, expected=0x7312F8DC)
[Sun Jul 25 13:25:32 2004] [notice] child pid 18603 exit signal
Segmentation fault (11)
GDB Backtrace:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 14684)]
0x4076c9e0 in zend_hash_find (ht=0x8235e6c, arKey=0x823c3dc "filename",
nKeyLength=9,
pData=0xbfffeaf4) at /usr/local/src/php-5.0.0/Zend/zend_hash.c:854
854 if ((p->h == h) && (p->nKeyLength ==
nKeyLength)) {
(gdb) bt
#0 0x4076c9e0 in zend_hash_find (ht=0x8235e6c, arKey=0x823c3dc
"filename", nKeyLength=9,
pData=0xbfffeaf4) at /usr/local/src/php-5.0.0/Zend/zend_hash.c:854
#1 0x4078920f in zend_fetch_var_address (opline=0x823bc38,
Ts=0x833ea5c, type=0)
at /usr/local/src/php-5.0.0/Zend/zend_execute.c:762
#2 0x4078c5ef in zend_fetch_r_handler (execute_data=0xbfffeb60,
opline=0x823bc38,
op_array=0x82b6fc4) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:1996
#3 0x4078acc4 in execute (op_array=0x82b6fc4) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:1391
#4 0x4078edd5 in zend_do_fcall_common_helper (execute_data=0xbfffec50,
opline=0x823e9c4,
op_array=0x823c064) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:2728
#5 0x4078f2ef in zend_do_fcall_by_name_handler
(execute_data=0xbfffec50, opline=0x823e9c4,
op_array=0x823c064) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:2810
#6 0x4078acc4 in execute (op_array=0x823c064) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:1391
#7 0x4078edd5 in zend_do_fcall_common_helper (execute_data=0xbfffed40,
opline=0x82655fc,
op_array=0x8266174) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:2728
#8 0x4078f2ef in zend_do_fcall_by_name_handler
(execute_data=0xbfffed40, opline=0x82655fc,
op_array=0x8266174) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:2810
#9 0x4078acc4 in execute (op_array=0x8266174) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:1391
#10 0x40756674 in zend_call_function (fci=0xbfffeeb0, fci_cache=0x0)
at /usr/local/src/php-5.0.0/Zend/zend_execute_API
#29370 [Opn]: Crash apache.exe (php5ts.dll)
ID: 29370
User updated by: anthony dot debhian at only-for dot info
Reported By: anthony dot debhian at only-for dot info
Status: Open
Bug Type: Reproducible crash
Operating System: Windows XP
PHP Version: 5.0.0
New Comment:
Unhandled exception in Apache.exe (PHP5TS.DLL): 0xC005: Access
Violation.
Offset: 7344
The error report display
C:\DOCUME~1\Anthony\LOCALS~1\Temp\WER689.tmp.dir00\Apache.exe.mdmp
C:\DOCUME~1\Anthony\LOCALS~1\Temp\WER689.tmp.dir00\appcompat.txt
No more info on the error report :-\ sorry
Previous Comments:
[2004-07-25 21:37:55] grayw at mail dot montclair dot edu
Can you provide the 'crash' output? Since this is for windows, is
there anything relevant in the logs you can view from Event Viewer? In
there you would see any messages relating to an kernel, application, or
service crash?
[2004-07-25 12:42:55] ahtin at hot dot ee
i got the same obscure crash with php 5.0 + apache 2.0.48 on win98se
with this code snippet:
-
db_fetch_row($s))
{
$x['birthday'].=$this->parse_tpl("k_links",$s2);
}
?>
no errors, just apache crash
[2004-07-25 03:34:02] anthony dot debhian at only-for dot info
Description:
The code crash apache.exe with php-5.0.0/apache-1.3.31 and
php-4.3.3/apache-1.3.27 (2 pc, 2 config)
The GET request does not appear in access.log and error.log.
this bug's odd, perhaps not important, but i send you feedback anyway.
Reproduce code:
---
$value) { if(is_array($array[$key])) {
$src.=$key; } }
return $src;
}
function funcfunc2($array,$test)
{
foreach($array['test'] as $key=>$value) { }
return $array;
}
$test['lol']['test1']="test1";
$test['lol']['test2']="test2";
$array=funcfunc($test);
$array=funcfunc2($array,"test");
?>
Expected result:
Just a fatal error.
--
Edit this bug report at http://bugs.php.net/?id=29370&edit=1
#29036 [Fbk->NoF]: imap with ssl not working on windows
ID: 29036 Updated by: [EMAIL PROTECTED] Reported By: josef dot spangler at rz dot uni-regensburg dot de -Status: Feedback +Status: No Feedback Bug Type: IMAP related Operating System: Windows PHP Version: 4.3.6 New Comment: No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2004-07-08 11:33:00] [EMAIL PROTECTED] It won't help much since we don't build the c-client library on windows with SSL support.. And the .dsp file should be edited too, did you to that? (give a diff for that if you did :) [2004-07-06 21:18:07] josef dot spangler at rz dot uni-regensburg dot de Description: The php_imap extension is unable to connect over ssl to an imap server. The reason is because the ssl engine is not initialized: In php_imap.c Line 435 the function ssl_onceonlyinit (); is not called on windows systems. The following fix will correct this: *** php_imap.c.org Thu Jan 15 01:36:08 2004 --- php_imap.c Thu May 06 13:28:30 2004 *** *** 427,438 #ifndef PHP_WIN32 auth_link(&auth_log); /* link in the log authenticator */ auth_link(&auth_md5); /* link in the cram-md5 authenticator */ #if HAVE_IMAP_KRB && defined(HAVE_IMAP_AUTH_GSS) auth_link(&auth_gss); /* link in the gss authenticator */ #endif #ifdef HAVE_IMAP_SSL ssl_onceonlyinit (); - #endif #endif --- 427,438 #ifndef PHP_WIN32 auth_link(&auth_log); /* link in the log authenticator */ auth_link(&auth_md5); /* link in the cram-md5 authenticator */ #if HAVE_IMAP_KRB && defined(HAVE_IMAP_AUTH_GSS) auth_link(&auth_gss); /* link in the gss authenticator */ #endif + #endif #ifdef HAVE_IMAP_SSL ssl_onceonlyinit (); #endif -- Edit this bug report at http://bugs.php.net/?id=29036&edit=1
#28141 [Fbk->NoF]: socket_read return type: false vs ""
ID: 28141
Updated by: [EMAIL PROTECTED]
Reported By: php at richardneill dot org
-Status: Feedback
+Status: No Feedback
Bug Type: Sockets related
Operating System: Linux
PHP Version: 5.0.0RC1
New Comment:
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2004-07-18 17:13:56] php2 at richardneill dot org
I've still got the same thing happening in PHP5.0.0(final)
I'm having some trouble with your example, so I'm using the attached
instead. It's basically copied from the php-sockets manual, but
slightly modified.
The key point: according to the documentation, when
(socket_read()===false), it means something has gone very wrong, i.e.
a fatal error. However, in practice, all this means is that the other
side has closed the connection.
I'm running this code as ./testsock.php
and the client is simply: netcat localhost
The problem is that, if netcat is killed with Ctrl-C, then the server
suffers a fatal error. I don't think that it should.
I've tried it under both version php-cli-4.3.7-4mdk (the current devel
version from Mandrake cooker) and php-5.0.0-cli which I just compiled.
In both cases, the same thing happens.
Regards
Richard
-
#!/usr/local/bin/php
[2004-07-18 14:29:51] [EMAIL PROTECTED]
I cannot reproduce the problem with latest PHP5. Can you provide a
*full* reproducing case.
My scripts are :
server:
client:
[2004-04-28 04:54:43] php at richardneill dot org
This is still present in RC2
[2004-04-25 06:56:24] php at richardneill dot org
Description:
According to the documentation, socket_read() can return:
1)A string - normal data
2)An empty string "" - the other end closed the connection
3)false - something went wrong.
But it seems to be returning false on connection close.
Reproduce code:
---
$buffer=socket_read($socket,2048,PHP_NORMAL_READ);
if ($buffer===false){
echo "Error: socket_read() failed: reason:
".socket_strerror(socket_last_error())." \n";
exit (1);
}elseif ($buffer==''){
echo "Socket $socket returned an empty string. Closing
connection\n";
socket_close($socket);
}else{
echo "Received data".trim($buffer)."\n";
}
Expected result:
I'm using netcat as a client, and then killing the netcat process with
Ctrl-C to simulate remote host disconnecting.
I expect to see the socket close.
Actual result:
--
Actually, the php script exits, because socket_read returns
false instead of "".
This may be a bug in the documentation for socket_read, rather than in
its behaviour.
Thanks for your help - Richard
--
Edit this bug report at http://bugs.php.net/?id=28141&edit=1
#29222 [Fbk->NoF]: php4.3.8 segfaults with apache2 (2.0.50)
ID: 29222 Updated by: [EMAIL PROTECTED] Reported By: formorer at debian dot org -Status: Feedback +Status: No Feedback Bug Type: Reproducible crash Operating System: Debian Woody/Sid PHP Version: 4.3.8 New Comment: No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2004-07-18 18:46:17] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2004-07-17 12:04:19] formorer at debian dot org Description: I create Backports of the Debian Sid packages for Woody. There I detected the following error with the apache2 module. Every call of a php call let apache2 (mpm-prefork) lets apache2 segfaulten, even sometimes if php4 is not called it segfaults. Another user of Debian Sid (no backports), has the same problem. Before monday I'm not able to provide you with a gdb backtrace, because I don't have my build environment available. But at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=259808 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=259659 are a few more informations and a backtrace. If somebody from Maintainers already reported that problem, I'm sorry for this bugreport, but this is really urgent. Actual result: -- -- Edit this bug report at http://bugs.php.net/?id=29222&edit=1
#29381 [NEW]: Data not inserting into MySQL Database
From: dj at cleancode dot org
Operating system: Red hat 9
PHP version: 4.3.8
PHP Bug Type: MySQL related
Bug description: Data not inserting into MySQL Database
Description:
When using mysql_query(), I can not insert a specific line into MySQL.
However, if I have PHP echo the string I'm trying to insert into the
database, and then copy and paste it into the mysql command line tool, it
inserts fine.
Reproduce code:
---
$conn = mysql_connect("localhost", "organizer", "organizer") or
die("Can't connecto to DB" . mysql_error());
mysql_select_db("Organizer") or die("Can't change DB: " .
mysql_error());
$currdate = time();
if ($taskarr['closed'] != "")
$closed_date = $currdate;
else
$closed_date = 0;
/* insert into database. */
$q = "INSERT INTO Tasks SET post_date = $currdate, closed_date =
$closed_date, last_edit = $currdate, subject = '" . $taskarr['subject'] .
"', body = '" . $taskarr['body'] . "';";
echo "$q";
mysql_query($q) or die("Couldn't insert data: " . mysql_error());
mysql_close();
Expected result:
The data should get inserted in the table
Actual result:
--
Doing a SELECT * FROM Tasks; shows nothing in the DB.
After performing this, mysql_query() returns fine... No error from
mysql_error() since mysql_query() does not return false.
To make matters more interesting, if I statically set $currdate, it works.
For instance:
$currdate = 1090793160;
The data gets inserted into the database properly. It seems if I use
time() or mktime() cause the issue...
--
Edit bug report at http://bugs.php.net/?id=29381&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29381&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29381&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29381&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29381&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29381&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29381&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29381&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29381&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29381&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29381&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29381&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29381&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29381&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29381&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29381&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29381&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29381&r=float
#28141 [NoF->Opn]: socket_read return type: false vs ""
ID: 28141
User updated by: php at richardneill dot org
Reported By: php at richardneill dot org
-Status: No Feedback
+Status: Open
Bug Type: Sockets related
Operating System: Linux
PHP Version: 5.0.0RC1
New Comment:
re-setting to open as requested by automatic email.
Sorry - I think I confused your system by commenting as another user
rather than as the original submitter.
Previous Comments:
[2004-07-26 01:00:05] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2004-07-18 17:13:56] php2 at richardneill dot org
I've still got the same thing happening in PHP5.0.0(final)
I'm having some trouble with your example, so I'm using the attached
instead. It's basically copied from the php-sockets manual, but
slightly modified.
The key point: according to the documentation, when
(socket_read()===false), it means something has gone very wrong, i.e.
a fatal error. However, in practice, all this means is that the other
side has closed the connection.
I'm running this code as ./testsock.php
and the client is simply: netcat localhost
The problem is that, if netcat is killed with Ctrl-C, then the server
suffers a fatal error. I don't think that it should.
I've tried it under both version php-cli-4.3.7-4mdk (the current devel
version from Mandrake cooker) and php-5.0.0-cli which I just compiled.
In both cases, the same thing happens.
Regards
Richard
-
#!/usr/local/bin/php
[2004-07-18 14:29:51] [EMAIL PROTECTED]
I cannot reproduce the problem with latest PHP5. Can you provide a
*full* reproducing case.
My scripts are :
server:
client:
[2004-04-28 04:54:43] php at richardneill dot org
This is still present in RC2
[2004-04-25 06:56:24] php at richardneill dot org
Description:
According to the documentation, socket_read() can return:
1)A string - normal data
2)An empty string "" - the other end closed the connection
3)false - something went wrong.
But it seems to be returning false on connection close.
Reproduce code:
---
$buffer=socket_read($socket,2048,PHP_NORMAL_READ);
if ($buffer===false){
echo "Error: socket_read() failed: reason:
".socket_strerror(socket_last_error())." \n";
exit (1);
}elseif ($buffer==''){
echo "Socket $socket returned an empty string. Closing
connection\n";
socket_close($socket);
}else{
echo "Received data".trim($buffer)."\n";
}
Expected result:
I'm using netcat as a client, and then killing the netcat process with
Ctrl-C to simulate remote host disconnecting.
I expect to see the socket close.
Actual result:
--
Actually, the php script exits, because socket_read returns
false instead of "".
This may be a bug in the documentation for socket_read, rather than in
its behaviour.
Thanks for your help - Richard
--
Edit this bug report at http://bugs.php.net/?id=28141&edit=1
#29382 [NEW]: crash by invalid Iterator returned from ArrayObject::getIterator()
From: su1d at phpclub dot net
Operating system: Win32
PHP version: 5CVS-2004-07-26 (dev)
PHP Bug Type: Reproducible crash
Bug description: crash by invalid Iterator returned from ArrayObject::getIterator()
Description:
Please, check the code.
P.S. When $this is returned instead of "null" you do get the correct error
message, but PHP still crashes.
P.P.S. What do we have Traversable interface for?
Reproduce code:
---
$line) {
echo "$idx: $line\n";
}
?>
Expected result:
Warning: Objects returned by ArrayObj::getIterator() must be traversable
or implement interface Iterator in ... on line 7
Actual result:
--
*SILENT CRASH*
--
Edit bug report at http://bugs.php.net/?id=29382&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29382&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29382&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29382&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29382&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29382&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29382&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29382&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29382&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29382&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29382&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29382&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29382&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29382&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29382&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29382&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29382&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29382&r=float
#29354 [Fbk->Opn]: Exception constructor marked as both public and protected
ID: 29354
User updated by: Jared dot Williams1 at ntlworld dot com
Reported By: Jared dot Williams1 at ntlworld dot com
-Status: Feedback
+Status: Open
Bug Type: Class/Object related
Operating System: Windows 2000/IIS
PHP Version: 5.0.0
New Comment:
Still reports the Exception constructor as both public & protected.
PHP Version 5.1.0-dev
System Windows NT WIN2KS 5.0 build 2195
Build Date Jul 26 2004 00:23:15
Previous Comments:
[2004-07-25 19:54:05] [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
[2004-07-23 17:57:09] Jared dot Williams1 at ntlworld dot com
Description:
Exception class constructor when inspected via the Reflection api,
seems to be both marked a public and protected.
Reproduce code:
---
$exceptionClass = new ReflectionClass('Exception');
$exceptionConstructor = $exceptionClass->getConstructor();
var_dump($exceptionConstructor->isPublic());
var_dump($exceptionConstructor->isProtected());
Expected result:
bool(true) bool(false)
or
bool(false) bool(true)
Actual result:
--
bool(true) bool(true)
--
Edit this bug report at http://bugs.php.net/?id=29354&edit=1
#29354 [Opn]: Exception constructor marked as both public and protected
ID: 29354
Updated by: [EMAIL PROTECTED]
Reported By: Jared dot Williams1 at ntlworld dot com
Status: Open
Bug Type: Class/Object related
Operating System: Windows 2000/IIS
PHP Version: 5.0.0
-Assigned To:
+Assigned To: helly
New Comment:
Are you using extension com_dotnet?
Previous Comments:
[2004-07-26 02:35:25] Jared dot Williams1 at ntlworld dot com
Still reports the Exception constructor as both public & protected.
PHP Version 5.1.0-dev
System Windows NT WIN2KS 5.0 build 2195
Build Date Jul 26 2004 00:23:15
[2004-07-25 19:54:05] [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
[2004-07-23 17:57:09] Jared dot Williams1 at ntlworld dot com
Description:
Exception class constructor when inspected via the Reflection api,
seems to be both marked a public and protected.
Reproduce code:
---
$exceptionClass = new ReflectionClass('Exception');
$exceptionConstructor = $exceptionClass->getConstructor();
var_dump($exceptionConstructor->isPublic());
var_dump($exceptionConstructor->isProtected());
Expected result:
bool(true) bool(false)
or
bool(false) bool(true)
Actual result:
--
bool(true) bool(true)
--
Edit this bug report at http://bugs.php.net/?id=29354&edit=1
#29354 [Opn->Fbk]: Exception constructor marked as both public and protected
ID: 29354
Updated by: [EMAIL PROTECTED]
Reported By: Jared dot Williams1 at ntlworld dot com
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: Windows 2000/IIS
PHP Version: 5.0.0
Assigned To: helly
Previous Comments:
[2004-07-26 03:18:46] [EMAIL PROTECTED]
Are you using extension com_dotnet?
[2004-07-26 02:35:25] Jared dot Williams1 at ntlworld dot com
Still reports the Exception constructor as both public & protected.
PHP Version 5.1.0-dev
System Windows NT WIN2KS 5.0 build 2195
Build Date Jul 26 2004 00:23:15
[2004-07-25 19:54:05] [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
[2004-07-23 17:57:09] Jared dot Williams1 at ntlworld dot com
Description:
Exception class constructor when inspected via the Reflection api,
seems to be both marked a public and protected.
Reproduce code:
---
$exceptionClass = new ReflectionClass('Exception');
$exceptionConstructor = $exceptionClass->getConstructor();
var_dump($exceptionConstructor->isPublic());
var_dump($exceptionConstructor->isProtected());
Expected result:
bool(true) bool(false)
or
bool(false) bool(true)
Actual result:
--
bool(true) bool(true)
--
Edit this bug report at http://bugs.php.net/?id=29354&edit=1
#28124 [Com]: Using MSSQL functions an empty string is returned as a space
ID: 28124
Comment by: gunther at ultraconsulting dot com
Reported By: cbunk at arescorporation dot com
Status: Bogus
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.6
New Comment:
I have the same problem! Using an older php_mssql.dll (3/13/2003 or so)
solved the problem for me, but might cause other problems. I have PHP
4.3.7 and 5.0.0 and it works fine under 4.3.2.
Here my bug comments:
A SELECT statement returns instead of an empty value for an empty
varchar field, a value containing a single space. Therefore using the
PHP empty() function will not work anymore.
Problem only happens with php_mssql.dll from year 2004 for PHP version
4.3.7 and 5.0.0. Using a previous dll from 3/13/03 (4.3.2-RC1) for
instance solves the problem ... but might cause others.
I guess we have to dig in the mssql extension code ...
Previous Comments:
[2004-05-12 07:13:39] kalf at unidial dot com dot au
This is not a bogus bug. We also have a similar problem. Returned
strings are being right padded with spaces. The fix for
http://bugs.php.net/bug.php?id=25777 has added a new bug (using
4.3.4)it appears. When comparing with newer versions of postgres (which
has stricter string comparison rules --pg7.2) this results is false
negatives.
[2004-04-23 17:44:23] [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.
Thank you for your interest in PHP.
This is the bug in the mssql library you are using.
P.S. This issue has been discussed in detail in earlier bug
reports about the same issue, please search the bug
archives.
[2004-04-23 16:15:45] cbunk at arescorporation dot com
Description:
When making a query on a MSSQL DB using mssql functions an extra space
is added to the end of output. This is causing trouble with scripts of
mine that check to see if the querried field is empty to determine
whether or not to display some text.
The bug mentioned at
http://bugs.php.net/bug.php?id=25777
describes the problem but was marked as bogus. I think when the fix
for http://bugs.php.net/bug.php?id=25777 was made it in advertently
left an extra space in results.
Reproduce code:
---
//once connected to the db
$sql="Select name from contacts";
$result=mssql_query($sql);
$row = mssql_fetch_array($result);
//assume there is one entry in the table
//with an empty string as the value for
//name
if (!empty($row["name"])){
echo "Name: " . $row["name"];
}else{
echo "Name value is empty";
}
Expected result:
Name value is empty
Actual result:
--
Name:
--
Edit this bug report at http://bugs.php.net/?id=28124&edit=1
#29383 [NEW]: A SELECT statement returns instead of an empty value, a value containing space
From: gunther at ultraconsulting dot com
Operating system: w2k
PHP version: 4.3.7
PHP Bug Type: MSSQL related
Bug description: A SELECT statement returns instead of an empty value, a value
containing space
Description:
A SELECT statement returns instead of an empty value for a varchar field,
a value containing a single space. Therefore using the empty() directive
will not work anymore.
Problem only happens with php_mssql.dll from year 2004 for PHP version
4.3.7 and 5.0.0. Using a previous dll from 3/13/03 (4.3.2-RC1) for
instance solves the problem ... but might cause others.
Reproduce code:
---
DB: "'.$db_name.'" connected');
} else {
print ("DB NOK ");
exit;
}
$query = 'SELECT * FROM mydb WHERE id = 1';
$result = mssql_query($query, $dbh);
{
if ($row = mssql_fetch_array($result, MSSQL_ASSOC)) {
print_r($row);
print("\n(" . $row['id'] . ')');
}
}
?>
Expected result:
...
()
Actual result:
--
...
( )
--
Edit bug report at http://bugs.php.net/?id=29383&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29383&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29383&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29383&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29383&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29383&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29383&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29383&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29383&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29383&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29383&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29383&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29383&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29383&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29383&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29383&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29383&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29383&r=float
#29132 [Com]: $_SERVER["PHP_AUTH_USER"] is not in headers anymore?
ID: 29132 Comment by: arthur at petraclc dot com Reported By: endrju at itrisinajumi dot lv Status: Closed Bug Type: *General Issues Operating System: FreeBSD 5.2.1 PHP Version: 5.0.0 New Comment: Jul 25, 2004. Downloaded the latest snapshot of PHP5.0.0 after experiencing the authication failure issue - while using HTTP authentication method in phpMyAdmin-2.5.7-pl1 With this current CVS release, I am unable to login into MySQL at all! Trying an older version of the CVSYour fizes are much appreciated! Previous Comments: [2004-07-23 03:38:45] neilcurry1 at hotmail dot com I just spend 2 days trying to sort this problem out, seeking help from http://phpmac.com/ also. I have downloaded the latest snapshot and build and installed. Everything OK now :) I think a new release to php 5 is needed to stop others pulling their hair out over this one. Neil [2004-07-21 17:00:33] tmeader at pobox dot com I've come across two other admins thus far who have been having this problem, and had no idea that it was PHP related. They spent at least 6 hours trying to debug their script before giving up for the day. This is a MAJOR bug, since it basically breaks ALL PHP scripts that use HTTP Auth. Can we PLEASE have a fast interim 5.0.1 to fix this? [2004-07-15 18:27:53] daviidu at everydns dot net This bug is quite serious actually and I would expect a lot of semi-clued people to not recognize it as a PHP bug or maybe only after wasting a lot of time. I would suggest a 5.0.1 release out the door ASAP. -davidu [2004-07-14 13:08:56] [EMAIL PROTECTED] 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. [2004-07-14 13:05:15] alex dot pagnoni at solarix dot it Stefan, I can confirm you that $_SERVER['PHP_AUTH_USER'] now works fine again with the latest php5 snapshot (php5-200407141030). 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/29132 -- Edit this bug report at http://bugs.php.net/?id=29132&edit=1
#29090 [Fbk->Opn]: Destructor Segfaults PHP5RC3
ID: 29090
User updated by: derek at battams dot ca
Reported By: derek at battams dot ca
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux 2.4
PHP Version: 5.0.0RC3
New Comment:
The snapshot build (200407260030) seems to fix this issue. My initial
tests are unable to reproduce the seg fault, but as my entire project
team runs through its tests then I'll know more (though it was my code
that was causing the seg fault and it's not seg faulting anymore so I'd
say it definitely looks promising).
Assuming this fix is good, is it safe to assume then that it will
appear in the 5.0.1 release? I ask, because phpinfo() on the snapshot
build shows 5.1.0-devel as the version. Finally, how stable are the
nightlies? I assume we'll be going live with our system before 5.0.1
is released (middle August).
Previous Comments:
[2004-07-25 21:51:54] marcus at lucidix dot com
Description:
We are experiencing a similar seg fault, also in zend_hash_find.
Two servers running Linux 2.4, Apache 1.3, MySQL 4.0, PHP 5.0 (also
tested with CVS php5-200407242230.tar.bz2) segfault.
However, our application runs without issues on Windows XP, Apache 2.0,
MySQL 4.0, PHP 5.0.0.
The class this error occurs in is also part of a much larger system. We
have not yet been able to isolate the exact line of code causing this.
Additionally, the behavior is not consistent. Seg faults occur 95% of
the time, but occasionally it will run.
A few differences to the original bug report: We are not using
destructors, and no calls to md5 are made. The only common code between
our two code snippets is file_exists().
Please note: The following code snippet will not work by itself.
Reproduce code:
---
function _findstoredproc($storedproc)
{
// load the list of modules installed
$modmgr = lxModules::singleton();
$modules = $modmgr->modulelist();
// prepend the "core" module
$core = array(
'name' => 'core',
'type' => 'global',
'path' => GLOBALDIR . '/src/'
);
array_unshift($modules, $core);
// scan each module
foreach($modules as $module)
{
// assemble the file name, using module directory, drv/, proc
name
and driver extension
$filename = $module['path'] . 'drv/' . $storedproc . '.' .
$this->db_driver;
// check if the "stored proc" exists
if (file_exists($filename))
{
return $filename;
}
}
return false;
}
Expected Result:
Function returns a filename or false.
Actual Result:
"The page cannot be displayed" as the Apache child process seg faults.
Apache Error Log:
-
/usr/local/src/php5-200407242230/main/streams/streams.c(1551) : Block
0x0838E678 status:
Beginning: Overrun (magic=0x4020F0E4, expected=0x7312F8DC)
End: Unknown
---
[Sun Jul 25 13:25:31 2004] Script:
'/home/marcus/public_html/webapp/trunk/index.lx'
---
/usr/local/src/php5-200407242230/Zend/zend_constants.c(33) : Block
0x404D9CA3 status:
/usr/local/src/php5-200407242230/Zend/zend_variables.c(39) : Actual
location (location was relayed)
Beginning: Overrun (magic=0x75622E6E, expected=0x7312F8DC)
[Sun Jul 25 13:25:32 2004] [notice] child pid 18603 exit signal
Segmentation fault (11)
GDB Backtrace:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 14684)]
0x4076c9e0 in zend_hash_find (ht=0x8235e6c, arKey=0x823c3dc "filename",
nKeyLength=9,
pData=0xbfffeaf4) at /usr/local/src/php-5.0.0/Zend/zend_hash.c:854
854 if ((p->h == h) && (p->nKeyLength ==
nKeyLength)) {
(gdb) bt
#0 0x4076c9e0 in zend_hash_find (ht=0x8235e6c, arKey=0x823c3dc
"filename", nKeyLength=9,
pData=0xbfffeaf4) at /usr/local/src/php-5.0.0/Zend/zend_hash.c:854
#1 0x4078920f in zend_fetch_var_address (opline=0x823bc38,
Ts=0x833ea5c, type=0)
at /usr/local/src/php-5.0.0/Zend/zend_execute.c:762
#2 0x4078c5ef in zend_fetch_r_handler (execute_data=0xbfffeb60,
opline=0x823bc38,
op_array=0x82b6fc4) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:1996
#3 0x4078acc4 in execute (op_array=0x82b6fc4) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:1391
#4 0x4078edd5 in zend_do_fcall_common_helper (execute_data=0xbfffec50,
opline=0x823e9c4,
op_array=0x823c064) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:2728
#5 0x4078f2ef in zend_do_fcall_by_
#29383 [Opn]: A SELECT statement returns instead of an empty value, a value containing space
ID: 29383
User updated by: gunther at ultraconsulting dot com
Reported By: gunther at ultraconsulting dot com
Status: Open
Bug Type: MSSQL related
Operating System: w2k
PHP Version: 4.3.7
New Comment:
php_mssql.dll up to PHP 4.3.3 is working fine, problem first started
with PHP 4.3.4
Previous Comments:
[2004-07-26 03:46:00] gunther at ultraconsulting dot com
Description:
A SELECT statement returns instead of an empty value for a varchar
field, a value containing a single space. Therefore using the empty()
directive will not work anymore.
Problem only happens with php_mssql.dll from year 2004 for PHP version
4.3.7 and 5.0.0. Using a previous dll from 3/13/03 (4.3.2-RC1) for
instance solves the problem ... but might cause others.
Reproduce code:
---
DB: "'.$db_name.'" connected');
} else {
print ("DB NOK ");
exit;
}
$query = 'SELECT * FROM mydb WHERE id = 1';
$result = mssql_query($query, $dbh);
{
if ($row = mssql_fetch_array($result, MSSQL_ASSOC)) {
print_r($row);
print("\n(" . $row['id'] . ')');
}
}
?>
Expected result:
...
()
Actual result:
--
...
( )
--
Edit this bug report at http://bugs.php.net/?id=29383&edit=1
#29090 [Opn->Csd]: Destructor Segfaults PHP5RC3
ID: 29090
Updated by: [EMAIL PROTECTED]
Reported By: derek at battams dot ca
-Status: Open
+Status: Closed
Bug Type: Reproducible crash
-Operating System: Linux 2.4
+Operating System: *
-PHP Version: 5.0.0RC3
+PHP Version: 5.0.0
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.
The fix will be in 5.0.1 and we hope to get it out very soon.
Previous Comments:
[2004-07-26 04:30:28] derek at battams dot ca
The snapshot build (200407260030) seems to fix this issue. My initial
tests are unable to reproduce the seg fault, but as my entire project
team runs through its tests then I'll know more (though it was my code
that was causing the seg fault and it's not seg faulting anymore so I'd
say it definitely looks promising).
Assuming this fix is good, is it safe to assume then that it will
appear in the 5.0.1 release? I ask, because phpinfo() on the snapshot
build shows 5.1.0-devel as the version. Finally, how stable are the
nightlies? I assume we'll be going live with our system before 5.0.1
is released (middle August).
[2004-07-25 21:51:54] marcus at lucidix dot com
Description:
We are experiencing a similar seg fault, also in zend_hash_find.
Two servers running Linux 2.4, Apache 1.3, MySQL 4.0, PHP 5.0 (also
tested with CVS php5-200407242230.tar.bz2) segfault.
However, our application runs without issues on Windows XP, Apache 2.0,
MySQL 4.0, PHP 5.0.0.
The class this error occurs in is also part of a much larger system. We
have not yet been able to isolate the exact line of code causing this.
Additionally, the behavior is not consistent. Seg faults occur 95% of
the time, but occasionally it will run.
A few differences to the original bug report: We are not using
destructors, and no calls to md5 are made. The only common code between
our two code snippets is file_exists().
Please note: The following code snippet will not work by itself.
Reproduce code:
---
function _findstoredproc($storedproc)
{
// load the list of modules installed
$modmgr = lxModules::singleton();
$modules = $modmgr->modulelist();
// prepend the "core" module
$core = array(
'name' => 'core',
'type' => 'global',
'path' => GLOBALDIR . '/src/'
);
array_unshift($modules, $core);
// scan each module
foreach($modules as $module)
{
// assemble the file name, using module directory, drv/, proc
name
and driver extension
$filename = $module['path'] . 'drv/' . $storedproc . '.' .
$this->db_driver;
// check if the "stored proc" exists
if (file_exists($filename))
{
return $filename;
}
}
return false;
}
Expected Result:
Function returns a filename or false.
Actual Result:
"The page cannot be displayed" as the Apache child process seg faults.
Apache Error Log:
-
/usr/local/src/php5-200407242230/main/streams/streams.c(1551) : Block
0x0838E678 status:
Beginning: Overrun (magic=0x4020F0E4, expected=0x7312F8DC)
End: Unknown
---
[Sun Jul 25 13:25:31 2004] Script:
'/home/marcus/public_html/webapp/trunk/index.lx'
---
/usr/local/src/php5-200407242230/Zend/zend_constants.c(33) : Block
0x404D9CA3 status:
/usr/local/src/php5-200407242230/Zend/zend_variables.c(39) : Actual
location (location was relayed)
Beginning: Overrun (magic=0x75622E6E, expected=0x7312F8DC)
[Sun Jul 25 13:25:32 2004] [notice] child pid 18603 exit signal
Segmentation fault (11)
GDB Backtrace:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 14684)]
0x4076c9e0 in zend_hash_find (ht=0x8235e6c, arKey=0x823c3dc "filename",
nKeyLength=9,
pData=0xbfffeaf4) at /usr/local/src/php-5.0.0/Zend/zend_hash.c:854
854 if ((p->h == h) && (p->nKeyLength ==
nKeyLength)) {
(gdb) bt
#0 0x4076c9e0 in zend_hash_find (ht=0x8235e6c, arKey=0x823c3dc
"filename", nKeyLength=9,
pData=0xbfffeaf4) at /usr/local/src/php-5.0.0/Zend/zend_hash.c:854
#1 0x4078920f in zend_fetch_var_address (opline=0x823bc38,
Ts=0x833ea5c, type=0)
at /usr/local/src/php-5.0.0/Zend/zend_execu
#29381 [Opn->Bgs]: Data not inserting into MySQL Database
ID: 29381
Updated by: [EMAIL PROTECTED]
Reported By: dj at cleancode dot org
-Status: Open
+Status: Bogus
Bug Type: MySQL related
Operating System: Red hat 9
PHP Version: 4.3.8
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Please read
http://dev.mysql.com/doc/mysql/en/Date_and_time_type_overview.html
and http://www.php.net/time
Previous Comments:
[2004-07-26 01:03:42] dj at cleancode dot org
Description:
When using mysql_query(), I can not insert a specific line into MySQL.
However, if I have PHP echo the string I'm trying to insert into the
database, and then copy and paste it into the mysql command line tool,
it inserts fine.
Reproduce code:
---
$conn = mysql_connect("localhost", "organizer", "organizer") or
die("Can't connecto to DB" . mysql_error());
mysql_select_db("Organizer") or die("Can't change DB: " .
mysql_error());
$currdate = time();
if ($taskarr['closed'] != "")
$closed_date = $currdate;
else
$closed_date = 0;
/* insert into database. */
$q = "INSERT INTO Tasks SET post_date = $currdate, closed_date =
$closed_date, last_edit = $currdate, subject = '" . $taskarr['subject']
. "', body = '" . $taskarr['body'] . "';";
echo "$q";
mysql_query($q) or die("Couldn't insert data: " . mysql_error());
mysql_close();
Expected result:
The data should get inserted in the table
Actual result:
--
Doing a SELECT * FROM Tasks; shows nothing in the DB.
After performing this, mysql_query() returns fine... No error from
mysql_error() since mysql_query() does not return false.
To make matters more interesting, if I statically set $currdate, it
works. For instance:
$currdate = 1090793160;
The data gets inserted into the database properly. It seems if I use
time() or mktime() cause the issue...
--
Edit this bug report at http://bugs.php.net/?id=29381&edit=1
#29336 [Com]: Segmentation fault
ID: 29336 Comment by: marcus at lucidix dot com Reported By: glorybox at s dot od dot ua Status: Feedback Bug Type: Session related Operating System: Linux 2.4.18-xfs-1.1 PHP Version: 5CVS-2004-07-22 (dev) New Comment: that patch fixes the problem for me. thanks! Previous Comments: [2004-07-23 09:13:29] [EMAIL PROTECTED] Please try this patch: http://tony2004.phpclub.net/dev/tmp/session.diff Does it happen with it too ? [2004-07-22 19:02:22] glorybox at s dot od dot ua Description: While starting session with session_start() PHP5 causes Apache to segfault. No changes were actually made to php.ini-dist Reproduce code: --- Expected result: Expected to start session. -- Edit this bug report at http://bugs.php.net/?id=29336&edit=1
#29223 [Opn]: PHP.exe crash after hundreads of requests of IMAP
ID: 29223 User updated by: lkp857 at yahoo dot com Reported By: lkp857 at yahoo dot com Status: Open Bug Type: IMAP related Operating System: Windows XP Pro PHP Version: 4.3.9 New Comment: I discover the error message: The instruction at 0x7c9059b1 referenced memory at 0x0014 The memory cannot be read. Previous Comments: [2004-07-22 17:58:12] lkp857 at yahoo dot com Im using Windows Version of PHP, so how to use a debugger except gdb...?? Visual C++ can?? [2004-07-22 08:23:24] [EMAIL PROTECTED] How to generate a gdb backtrace: http://bugs.php.net/bugs-generating-backtrace.php [2004-07-21 18:22:33] lkp857 at yahoo dot com what kind of trace? C++ debuging?? or the source code of php script? [2004-07-20 22:42:29] [EMAIL PROTECTED] Can you provide some trace of the crash? [2004-07-17 12:05:07] lkp857 at yahoo dot com Description: Currently im develping a script that can grab emails from pop3 server with PHP_IMAP.dll. A program written in C++ was created to automatically make 5 request at a time to PHP server that contain that script... 1) The bug that i discover is not from the C++ program that i wrote, the requests fine at 2-3 hours fetching, after a time when the network connection become slow, the IMAP seem not working properly, it crash the PHP.exe an error said that NTDLL.DLL : --- Faulting application php.exe, version 4.3.9.9, faulting module ntdll.dll, version 5.1.2600.114, fault address 0xb13b. 2) Is it the PHP error or the NTDLL.DLL got bugs in it? 3) I already set the IMAP_TIMEOUT for open, read, write, close but i seem not working after all. 4) Is it the memory buffer overflowed in PHP after a hundred of request to the PHP Server that running using WindowsXP Pro, Apache 2 and MySQL. -- Edit this bug report at http://bugs.php.net/?id=29223&edit=1
#29223 [Opn]: PHP.exe crash after hundreads of requests of IMAP
ID: 29223 User updated by: lkp857 at yahoo dot com Reported By: lkp857 at yahoo dot com Status: Open Bug Type: IMAP related Operating System: Windows XP Pro PHP Version: 4.3.9 New Comment: beside that, the apache also contain the error: (70007)The timeout specified has expired: ap_content_length_filter: apr_bucket_read() failed Previous Comments: [2004-07-26 07:58:43] lkp857 at yahoo dot com I discover the error message: The instruction at 0x7c9059b1 referenced memory at 0x0014 The memory cannot be read. [2004-07-22 17:58:12] lkp857 at yahoo dot com Im using Windows Version of PHP, so how to use a debugger except gdb...?? Visual C++ can?? [2004-07-22 08:23:24] [EMAIL PROTECTED] How to generate a gdb backtrace: http://bugs.php.net/bugs-generating-backtrace.php [2004-07-21 18:22:33] lkp857 at yahoo dot com what kind of trace? C++ debuging?? or the source code of php script? [2004-07-20 22:42:29] [EMAIL PROTECTED] Can you provide some trace of the crash? 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/29223 -- Edit this bug report at http://bugs.php.net/?id=29223&edit=1
#29335 [Fbk->Opn]: mysqli_fetch_array resulttype
ID: 29335
User updated by: mjs15451 at hotmail dot com
Reported By: mjs15451 at hotmail dot com
-Status: Feedback
+Status: Open
Bug Type: MySQL related
Operating System: Linux
PHP Version: 5.0.0
New Comment:
CREATE TABLE `mailbox` (
`username` varchar(255) NOT NULL default '',
`password` varchar(255) NOT NULL default '',
`name` varchar(255) NOT NULL default '',
`maildir` varchar(255) NOT NULL default '',
`quota` int(10) NOT NULL default '-1',
`domain` varchar(255) NOT NULL default '',
`created` datetime NOT NULL default '-00-00 00:00:00',
`modified` datetime NOT NULL default '-00-00 00:00:00',
`active` tinyint(4) NOT NULL default '1',
PRIMARY KEY (`username`),
KEY `username` (`username`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
INSERT INTO `mailbox` VALUES ('user1', 'testtest', 'User 1',
'example.com/user1/', 0, 'example.com', '2004-07-25 00:00:00',
'2004-07-25 00:00:00', 1);
INSERT INTO `mailbox` VALUES ('user2', 'testtest', 'User 2',
'example.com/user2/', 0, 'example.com', '2004-07-25 00:00:00',
'2004-07-25 00:00:00', 1);
";
}
$result = mysqli_query ($link, 'SELECT * FROM mailbox');
//Bad Code which doesn't print username
while ($row = mysqli_fetch_array ($result)){ //notice MYSQLI_BOTH,
MYSQL_ASSOC or MYSQLI_NUM missing
print "username:" . $row['username'] . ""; //username will not
output
}
?>
According to the docs on
http://us2.php.net/manual/en/function.mysqli-fetch-array.php:
mixed mysqli_fetch_array ( object result [, int resulttype])
The optional second argument resulttype is a constant indicating what
type of array should be produced from the current row data. The
possible values for this parameter are the constants MYSQLI_ASSOC,
MYSQLI_NUM, or MYSQLI_BOTH. By default the mysqli_fetch_array()
function will assume MYSQLI_BOTH for this parameter.
I don't see this happening with the second loop of this query. I am
running Linux kernel 2.4.22, Apache 2.0.50, PHP 5.0.0 and Mysql
4.1.3beta
Previous Comments:
[2004-07-23 18:07:37] [EMAIL PROTECTED]
I can't reproduce it.
please provide a short reproducable sample script.
[2004-07-22 18:25:46] mjs15451 at hotmail dot com
Description:
If a resulttype is not specified when looping through a query, the
resulting array from mysqli_fetch_array does not return any data.
MYSQLI_BOTH should be the default value for mysqli_fetch_array.
I'm also using MySQL 4.1.3beta
Reproduce code:
---
while ($row = mysqli_fetch_array($result)){
echo $row[0];
}
Expected result:
$row[0] should return the first column of the query.
Actual result:
--
The while loop executes for the number of rows returned in the query
but $row[0] does not return any data.
--
Edit this bug report at http://bugs.php.net/?id=29335&edit=1
