#37671 [Csd->Opn]: MySQLi extension fails to recognize BIT colums
ID: 37671 User updated by: squasar at eternalviper dot net Reported By: squasar at eternalviper dot net -Status: Closed +Status: Open Bug Type: MySQLi related Operating System: * -PHP Version: 5.1.4 +PHP Version: 5.2 CVS Assigned To: iliaa New Comment: I updated to the latest 5.2 branch on CVS and run the exact test code I submitted again. The result: long(0) refcount(1) long(0) refcount(1) long(0) refcount(1) long(0) refcount(1) I don't know what one of us is doing wrong. Tested on both big-endian and little-endian systems. Could it be a 32-bit vs. 64-bit issue? Previous Comments: [2006-06-20 20:54:29] [EMAIL PROTECTED] With latest CVS your code returns the following results: long(1) refcount(1) long(0) refcount(1) long(1) refcount(1) long(0) refcount(1) [2006-06-08 06:27:06] squasar at eternalviper dot net That sample from the manual is irrelevant. Re-examine the reproduce code I provided. It FAILS using the patch that was applied to CVS; the result is always zero regardless of the values in the column, even though it's a BIT(1). [2006-06-07 13:08:32] [EMAIL PROTECTED] BIT[(M)] A bit-field type. M indicates the number of bits per value, from 1 to 64. The default is 1 if M is omitted. (From MySQL manual) [2006-06-07 04:43:39] squasar at eternalviper dot net The patch applied to CVS does NOT fix the bug. The CVS patch folds BIT handling into LONG types. This does not work; BIT columns take a 64-bit type, NOT a 32-bit type. Please re- examine the patch I supplied, which folds BIT handling into LONGLONG types. [2006-06-04 14:57:14] [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. 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/37671 -- Edit this bug report at http://bugs.php.net/?id=37671&edit=1
#37671 [Csd->Opn]: MySQLi extension fails to recognize BIT colums
ID: 37671
User updated by: squasar at eternalviper dot net
Reported By: squasar at eternalviper dot net
-Status: Closed
+Status: Open
Bug Type: MySQLi related
Operating System: *
PHP Version: 5.1.4
New Comment:
That sample from the manual is irrelevant. Re-examine the
reproduce code I provided. It FAILS using the patch that was
applied to CVS; the result is always zero regardless of the
values in the column, even though it's a BIT(1).
Previous Comments:
[2006-06-07 13:08:32] [EMAIL PROTECTED]
BIT[(M)]
A bit-field type. M indicates the number of bits per value,
from 1 to 64. The default is 1 if M is omitted.
(From MySQL manual)
[2006-06-07 04:43:39] squasar at eternalviper dot net
The patch applied to CVS does NOT fix the bug. The CVS patch
folds BIT handling into LONG types. This does not work; BIT
columns take a 64-bit type, NOT a 32-bit type. Please re-
examine the patch I supplied, which folds BIT handling into
LONGLONG types.
[2006-06-04 14:57:14] [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.
[2006-06-02 20:03:38] squasar at eternalviper dot net
With apologies for all the extra comments, here is a
somewhat better patch that allows for arbitrary values in a
BIT column. However, I do not believe this is ideal for a
bitfield type.
Index: ext/mysqli/mysqli_api.c
===
RCS file: /repository/php-src/ext/mysqli/mysqli_api.c,v
retrieving revision 1.118.2.22
diff -u -r1.118.2.22 mysqli_api.c
--- ext/mysqli/mysqli_api.c 5 Apr 2006 12:17:08 -
1.118.2.22
+++ ext/mysqli/mysqli_api.c 2 Jun 2006 20:02:17 -
@@ -303,10 +303,13 @@
break;
case MYSQL_TYPE_LONGLONG:
+#ifdef FIELD_TYPE_BIT
+ case MYSQL_TYPE_BIT:
+#endif
stmt->result.buf[ofs].type =
IS_STRING;
stmt->result.buf[ofs].buflen
= sizeof(my_ulonglong);
stmt->result.buf[ofs].val =
(char *)emalloc(stmt->result.buf[ofs].buflen);
- bind[ofs].buffer_type =
MYSQL_TYPE_LONGLONG;
+ bind[ofs].buffer_type =
col_type;
bind[ofs].buffer = stmt-
>result.buf[ofs].val;
bind[ofs].is_null = &stmt-
>result.is_null[ofs];
bind[ofs].buffer_length =
stmt->result.buf[ofs].buflen;
@@ -693,7 +696,11 @@
ZVAL_DOUBLE
(stmt->result.vars[i], *(double *)stmt->result.buf[i].val);
break;
case IS_STRING:
- if (stmt-
>stmt->bind[i].buffer_type == MYSQL_TYPE_LONGLONG) {
+ if (stmt-
>stmt->bind[i].buffer_type == MYSQL_TYPE_LONGLONG
+#ifdef FIELD_TYPE_BIT
+
|| stmt->stmt->bind[i].buffer_type == MYSQL_TYPE_BIT
+#endif
+ ) {
my_bool uns= (stmt->stmt->fields[i].flags & UNSIGNED_FLAG)?
1:0;
llval= *(my_ulonglong *) stmt->result.buf[i].val;
#if SIZEOF_LONG==8
----------------
[2006-06-02 19:48:58] squasar at eternalviper dot net
Further note: The given patch only applies to code which
assumes that a BIT field is being used as a flag field (i.e. a
BIT(1) column). For larger BIT fields the patch is
insufficient.
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/37671
--
Edit this bug report at http://bugs.php.net/?id=37671&edit=1
#37671 [Csd->Opn]: MySQLi extension fails to recognize BIT colums
ID: 37671
User updated by: squasar at eternalviper dot net
Reported By: squasar at eternalviper dot net
-Status: Closed
+Status: Open
Bug Type: MySQLi related
Operating System: *
PHP Version: 5.1.4
New Comment:
The patch applied to CVS does NOT fix the bug. The CVS patch
folds BIT handling into LONG types. This does not work; BIT
columns take a 64-bit type, NOT a 32-bit type. Please re-
examine the patch I supplied, which folds BIT handling into
LONGLONG types.
Previous Comments:
[2006-06-04 14:57:14] [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.
[2006-06-02 20:03:38] squasar at eternalviper dot net
With apologies for all the extra comments, here is a
somewhat better patch that allows for arbitrary values in a
BIT column. However, I do not believe this is ideal for a
bitfield type.
Index: ext/mysqli/mysqli_api.c
===
RCS file: /repository/php-src/ext/mysqli/mysqli_api.c,v
retrieving revision 1.118.2.22
diff -u -r1.118.2.22 mysqli_api.c
--- ext/mysqli/mysqli_api.c 5 Apr 2006 12:17:08 -
1.118.2.22
+++ ext/mysqli/mysqli_api.c 2 Jun 2006 20:02:17 -
@@ -303,10 +303,13 @@
break;
case MYSQL_TYPE_LONGLONG:
+#ifdef FIELD_TYPE_BIT
+ case MYSQL_TYPE_BIT:
+#endif
stmt->result.buf[ofs].type =
IS_STRING;
stmt->result.buf[ofs].buflen
= sizeof(my_ulonglong);
stmt->result.buf[ofs].val =
(char *)emalloc(stmt->result.buf[ofs].buflen);
- bind[ofs].buffer_type =
MYSQL_TYPE_LONGLONG;
+ bind[ofs].buffer_type =
col_type;
bind[ofs].buffer = stmt-
>result.buf[ofs].val;
bind[ofs].is_null = &stmt-
>result.is_null[ofs];
bind[ofs].buffer_length =
stmt->result.buf[ofs].buflen;
@@ -693,7 +696,11 @@
ZVAL_DOUBLE
(stmt->result.vars[i], *(double *)stmt->result.buf[i].val);
break;
case IS_STRING:
- if (stmt-
>stmt->bind[i].buffer_type == MYSQL_TYPE_LONGLONG) {
+ if (stmt-
>stmt->bind[i].buffer_type == MYSQL_TYPE_LONGLONG
+#ifdef FIELD_TYPE_BIT
+
|| stmt->stmt->bind[i].buffer_type == MYSQL_TYPE_BIT
+#endif
+ ) {
my_bool uns= (stmt->stmt->fields[i].flags & UNSIGNED_FLAG)?
1:0;
llval= *(my_ulonglong *) stmt->result.buf[i].val;
#if SIZEOF_LONG==8
--------------------
[2006-06-02 19:48:58] squasar at eternalviper dot net
Further note: The given patch only applies to code which
assumes that a BIT field is being used as a flag field (i.e. a
BIT(1) column). For larger BIT fields the patch is
insufficient.
--------------------
[2006-06-02 05:03:15] squasar at eternalviper dot net
The pasted reproduce code is syntactically incorrect. Here
is the correct version:
query( "CREATE TABLE IF NOT EXISTS test_me
( test_col BIT NOT NULL )" );
$DATABASE->query( "INSERT INTO test_me VALUES ( 1 ), ( 0 ),
( 1 ), ( 0 )" );
( $statement = $DATABASE->prepare( "SELECT test_col FROM
test_me" ) );
$statement->execute();
$statement->bind_result( $bits );
while ( $statement->fetch() === TRUE )
debug_zval_dump( $bits );
$statement->close();
?>
------------
[2006-06-02 05:01:19] squasar at eternalviper dot net
Description:
When attempting to use MySQLi prepared statements with BIT
columns, an "unrecognized column type" error is thrown. Here
is a working patch. I do not know if this is an ideal
implementation:
A working patch:
Index: ext/mysqli/mysqli_api.c
===
RCS file: /repository/php-src/ext/mysqli/mysqli_api.c,v
retrieving revision 1.118.2.22
diff -u -r1.118.2.22 mysqli_api.c
--- ext/my
#37671 [Asn]: MySQLi extension fails to recognize BIT colums
ID: 37671
User updated by: squasar at eternalviper dot net
Reported By: squasar at eternalviper dot net
Status: Assigned
Bug Type: MySQLi related
Operating System: *
PHP Version: 5.1.4
Assigned To: georg
New Comment:
With apologies for all the extra comments, here is a
somewhat better patch that allows for arbitrary values in a
BIT column. However, I do not believe this is ideal for a
bitfield type.
Index: ext/mysqli/mysqli_api.c
===
RCS file: /repository/php-src/ext/mysqli/mysqli_api.c,v
retrieving revision 1.118.2.22
diff -u -r1.118.2.22 mysqli_api.c
--- ext/mysqli/mysqli_api.c 5 Apr 2006 12:17:08 -
1.118.2.22
+++ ext/mysqli/mysqli_api.c 2 Jun 2006 20:02:17 -
@@ -303,10 +303,13 @@
break;
case MYSQL_TYPE_LONGLONG:
+#ifdef FIELD_TYPE_BIT
+ case MYSQL_TYPE_BIT:
+#endif
stmt->result.buf[ofs].type =
IS_STRING;
stmt->result.buf[ofs].buflen
= sizeof(my_ulonglong);
stmt->result.buf[ofs].val =
(char *)emalloc(stmt->result.buf[ofs].buflen);
- bind[ofs].buffer_type =
MYSQL_TYPE_LONGLONG;
+ bind[ofs].buffer_type =
col_type;
bind[ofs].buffer = stmt-
>result.buf[ofs].val;
bind[ofs].is_null = &stmt-
>result.is_null[ofs];
bind[ofs].buffer_length =
stmt->result.buf[ofs].buflen;
@@ -693,7 +696,11 @@
ZVAL_DOUBLE
(stmt->result.vars[i], *(double *)stmt->result.buf[i].val);
break;
case IS_STRING:
- if (stmt-
>stmt->bind[i].buffer_type == MYSQL_TYPE_LONGLONG) {
+ if (stmt-
>stmt->bind[i].buffer_type == MYSQL_TYPE_LONGLONG
+#ifdef FIELD_TYPE_BIT
+
|| stmt->stmt->bind[i].buffer_type == MYSQL_TYPE_BIT
+#endif
+ ) {
my_bool uns= (stmt->stmt->fields[i].flags & UNSIGNED_FLAG)?
1:0;
llval= *(my_ulonglong *) stmt->result.buf[i].val;
#if SIZEOF_LONG==8
Previous Comments:
--------------------
[2006-06-02 19:48:58] squasar at eternalviper dot net
Further note: The given patch only applies to code which
assumes that a BIT field is being used as a flag field (i.e. a
BIT(1) column). For larger BIT fields the patch is
insufficient.
--------------------
[2006-06-02 05:03:15] squasar at eternalviper dot net
The pasted reproduce code is syntactically incorrect. Here
is the correct version:
query( "CREATE TABLE IF NOT EXISTS test_me
( test_col BIT NOT NULL )" );
$DATABASE->query( "INSERT INTO test_me VALUES ( 1 ), ( 0 ),
( 1 ), ( 0 )" );
( $statement = $DATABASE->prepare( "SELECT test_col FROM
test_me" ) );
$statement->execute();
$statement->bind_result( $bits );
while ( $statement->fetch() === TRUE )
debug_zval_dump( $bits );
$statement->close();
?>
------------
[2006-06-02 05:01:19] squasar at eternalviper dot net
Description:
When attempting to use MySQLi prepared statements with BIT
columns, an "unrecognized column type" error is thrown. Here
is a working patch. I do not know if this is an ideal
implementation:
A working patch:
Index: ext/mysqli/mysqli_api.c
===
RCS file: /repository/php-src/ext/mysqli/mysqli_api.c,v
retrieving revision 1.118.2.22
diff -u -r1.118.2.22 mysqli_api.c
--- ext/mysqli/mysqli_api.c 5 Apr 2006 12:17:08 -
1.118.2.22
+++ ext/mysqli/mysqli_api.c 2 Jun 2006 04:59:44 -
@@ -303,10 +303,13 @@
break;
case MYSQL_TYPE_LONGLONG:
+#ifdef FIELD_TYPE_BIT
+ case MYSQL_TYPE_BIT:
+#endif
stmt->result.buf[ofs].type =
IS_STRING;
stmt->result.buf[ofs].buflen
= sizeof(my_ulonglong);
stmt->result.buf[ofs].val =
(char *)emalloc(stmt->result.buf[ofs].buflen);
- bind[ofs].buffer_type =
MYSQL_TYPE_LONGLONG;
+ bind[ofs].buffer_type =
col_type;
#37671 [Asn]: MySQLi extension fails to recognize BIT colums
ID: 37671
User updated by: squasar at eternalviper dot net
Reported By: squasar at eternalviper dot net
Status: Assigned
Bug Type: MySQLi related
Operating System: *
PHP Version: 5.1.4
Assigned To: georg
New Comment:
Further note: The given patch only applies to code which
assumes that a BIT field is being used as a flag field (i.e. a
BIT(1) column). For larger BIT fields the patch is
insufficient.
Previous Comments:
[2006-06-02 05:03:15] squasar at eternalviper dot net
The pasted reproduce code is syntactically incorrect. Here
is the correct version:
query( "CREATE TABLE IF NOT EXISTS test_me
( test_col BIT NOT NULL )" );
$DATABASE->query( "INSERT INTO test_me VALUES ( 1 ), ( 0 ),
( 1 ), ( 0 )" );
( $statement = $DATABASE->prepare( "SELECT test_col FROM
test_me" ) );
$statement->execute();
$statement->bind_result( $bits );
while ( $statement->fetch() === TRUE )
debug_zval_dump( $bits );
$statement->close();
?>
------------
[2006-06-02 05:01:19] squasar at eternalviper dot net
Description:
When attempting to use MySQLi prepared statements with BIT
columns, an "unrecognized column type" error is thrown. Here
is a working patch. I do not know if this is an ideal
implementation:
A working patch:
Index: ext/mysqli/mysqli_api.c
===
RCS file: /repository/php-src/ext/mysqli/mysqli_api.c,v
retrieving revision 1.118.2.22
diff -u -r1.118.2.22 mysqli_api.c
--- ext/mysqli/mysqli_api.c 5 Apr 2006 12:17:08 -
1.118.2.22
+++ ext/mysqli/mysqli_api.c 2 Jun 2006 04:59:44 -
@@ -303,10 +303,13 @@
break;
case MYSQL_TYPE_LONGLONG:
+#ifdef FIELD_TYPE_BIT
+ case MYSQL_TYPE_BIT:
+#endif
stmt->result.buf[ofs].type =
IS_STRING;
stmt->result.buf[ofs].buflen
= sizeof(my_ulonglong);
stmt->result.buf[ofs].val =
(char *)emalloc(stmt->result.buf[ofs].buflen);
- bind[ofs].buffer_type =
MYSQL_TYPE_LONGLONG;
+ bind[ofs].buffer_type =
col_type;
bind[ofs].buffer = stmt-
>result.buf[ofs].val;
bind[ofs].is_null = &stmt-
>result.is_null[ofs];
bind[ofs].buffer_length =
stmt->result.buf[ofs].buflen;
@@ -713,6 +716,11 @@
}
else {
ZVAL_LONG(stmt->result.vars[i], llval);
}
+#ifdef FIELD_TYPE_BIT
+ } else if
(stmt->stmt->bind[i].buffer_type == MYSQL_TYPE_BIT) {
+
llval = *(my_ulonglong *)stmt->result.buf[i].val;
+
ZVAL_BOOL(stmt->result.vars[i], llval == 0 ? 0 : 1);
+#endif
} else {
ZVAL_STRINGL(stmt->result.vars[i], stmt->result.buf[i].val,
stmt->result.buf[i].buflen, 1);
}
Reproduce code:
---
query( "CREATE TABLE test( test_col BIT NOT NULL )" );
$DATABASE->query( "INSERT INTO test VALUES ( 1, 0, 1, 0 )" );
$statement = $DATABASE->prepare( "SELECT test_col FROM test" );
$statement->execute();
$statement->bind_result( $bits );
while ( $statement->fetch() === TRUE )
debug_zval_dump( $bits );
$statement->close();
?>
Expected result:
bool(true) refcount(1)
bool(false) refcount(1)
bool(true) refcount(1)
bool(false) refcount(1)
Actual result:
--
Warning: mysqli_stmt::bind_result(): Server returned unknown
type 16. Probably your client library is incompatible with the
server version you use! in - on line 8
NULL refcount(1)
NULL refcount(1)
NULL refcount(1)
NULL refcount(1)
--
Edit this bug report at http://bugs.php.net/?id=37671&edit=1
#37671 [Opn]: MySQLi extension fails to recognize BIT colums
ID: 37671
User updated by: squasar at eternalviper dot net
Reported By: squasar at eternalviper dot net
Status: Open
Bug Type: MySQLi related
Operating System: *
PHP Version: 5.1.4
New Comment:
The pasted reproduce code is syntactically incorrect. Here
is the correct version:
query( "CREATE TABLE IF NOT EXISTS test_me
( test_col BIT NOT NULL )" );
$DATABASE->query( "INSERT INTO test_me VALUES ( 1 ), ( 0 ),
( 1 ), ( 0 )" );
( $statement = $DATABASE->prepare( "SELECT test_col FROM
test_me" ) );
$statement->execute();
$statement->bind_result( $bits );
while ( $statement->fetch() === TRUE )
debug_zval_dump( $bits );
$statement->close();
?>
Previous Comments:
------------
[2006-06-02 05:01:19] squasar at eternalviper dot net
Description:
When attempting to use MySQLi prepared statements with BIT
columns, an "unrecognized column type" error is thrown. Here
is a working patch. I do not know if this is an ideal
implementation:
A working patch:
Index: ext/mysqli/mysqli_api.c
===
RCS file: /repository/php-src/ext/mysqli/mysqli_api.c,v
retrieving revision 1.118.2.22
diff -u -r1.118.2.22 mysqli_api.c
--- ext/mysqli/mysqli_api.c 5 Apr 2006 12:17:08 -
1.118.2.22
+++ ext/mysqli/mysqli_api.c 2 Jun 2006 04:59:44 -
@@ -303,10 +303,13 @@
break;
case MYSQL_TYPE_LONGLONG:
+#ifdef FIELD_TYPE_BIT
+ case MYSQL_TYPE_BIT:
+#endif
stmt->result.buf[ofs].type =
IS_STRING;
stmt->result.buf[ofs].buflen
= sizeof(my_ulonglong);
stmt->result.buf[ofs].val =
(char *)emalloc(stmt->result.buf[ofs].buflen);
- bind[ofs].buffer_type =
MYSQL_TYPE_LONGLONG;
+ bind[ofs].buffer_type =
col_type;
bind[ofs].buffer = stmt-
>result.buf[ofs].val;
bind[ofs].is_null = &stmt-
>result.is_null[ofs];
bind[ofs].buffer_length =
stmt->result.buf[ofs].buflen;
@@ -713,6 +716,11 @@
}
else {
ZVAL_LONG(stmt->result.vars[i], llval);
}
+#ifdef FIELD_TYPE_BIT
+ } else if
(stmt->stmt->bind[i].buffer_type == MYSQL_TYPE_BIT) {
+
llval = *(my_ulonglong *)stmt->result.buf[i].val;
+
ZVAL_BOOL(stmt->result.vars[i], llval == 0 ? 0 : 1);
+#endif
} else {
ZVAL_STRINGL(stmt->result.vars[i], stmt->result.buf[i].val,
stmt->result.buf[i].buflen, 1);
}
Reproduce code:
---
query( "CREATE TABLE test( test_col BIT NOT NULL )" );
$DATABASE->query( "INSERT INTO test VALUES ( 1, 0, 1, 0 )" );
$statement = $DATABASE->prepare( "SELECT test_col FROM test" );
$statement->execute();
$statement->bind_result( $bits );
while ( $statement->fetch() === TRUE )
debug_zval_dump( $bits );
$statement->close();
?>
Expected result:
bool(true) refcount(1)
bool(false) refcount(1)
bool(true) refcount(1)
bool(false) refcount(1)
Actual result:
--
Warning: mysqli_stmt::bind_result(): Server returned unknown
type 16. Probably your client library is incompatible with the
server version you use! in - on line 8
NULL refcount(1)
NULL refcount(1)
NULL refcount(1)
NULL refcount(1)
--
Edit this bug report at http://bugs.php.net/?id=37671&edit=1
#37671 [NEW]: MySQLi extension fails to recognize BIT colums
From: squasar at eternalviper dot net
Operating system: *
PHP version: 5.1.4
PHP Bug Type: MySQLi related
Bug description: MySQLi extension fails to recognize BIT colums
Description:
When attempting to use MySQLi prepared statements with BIT
columns, an "unrecognized column type" error is thrown. Here
is a working patch. I do not know if this is an ideal
implementation:
A working patch:
Index: ext/mysqli/mysqli_api.c
===
RCS file: /repository/php-src/ext/mysqli/mysqli_api.c,v
retrieving revision 1.118.2.22
diff -u -r1.118.2.22 mysqli_api.c
--- ext/mysqli/mysqli_api.c 5 Apr 2006 12:17:08 -
1.118.2.22
+++ ext/mysqli/mysqli_api.c 2 Jun 2006 04:59:44 -
@@ -303,10 +303,13 @@
break;
case MYSQL_TYPE_LONGLONG:
+#ifdef FIELD_TYPE_BIT
+ case MYSQL_TYPE_BIT:
+#endif
stmt->result.buf[ofs].type =
IS_STRING;
stmt->result.buf[ofs].buflen
= sizeof(my_ulonglong);
stmt->result.buf[ofs].val =
(char *)emalloc(stmt->result.buf[ofs].buflen);
- bind[ofs].buffer_type =
MYSQL_TYPE_LONGLONG;
+ bind[ofs].buffer_type =
col_type;
bind[ofs].buffer = stmt-
>result.buf[ofs].val;
bind[ofs].is_null = &stmt-
>result.is_null[ofs];
bind[ofs].buffer_length =
stmt->result.buf[ofs].buflen;
@@ -713,6 +716,11 @@
}
else {
ZVAL_LONG(stmt->result.vars[i], llval);
}
+#ifdef FIELD_TYPE_BIT
+ } else if
(stmt->stmt->bind[i].buffer_type == MYSQL_TYPE_BIT) {
+
llval = *(my_ulonglong *)stmt->result.buf[i].val;
+
ZVAL_BOOL(stmt->result.vars[i], llval == 0 ? 0 : 1);
+#endif
} else {
ZVAL_STRINGL(stmt->result.vars[i], stmt->result.buf[i].val,
stmt->result.buf[i].buflen, 1);
}
Reproduce code:
---
query( "CREATE TABLE test( test_col BIT NOT NULL )" );
$DATABASE->query( "INSERT INTO test VALUES ( 1, 0, 1, 0 )" );
$statement = $DATABASE->prepare( "SELECT test_col FROM test" );
$statement->execute();
$statement->bind_result( $bits );
while ( $statement->fetch() === TRUE )
debug_zval_dump( $bits );
$statement->close();
?>
Expected result:
bool(true) refcount(1)
bool(false) refcount(1)
bool(true) refcount(1)
bool(false) refcount(1)
Actual result:
--
Warning: mysqli_stmt::bind_result(): Server returned unknown
type 16. Probably your client library is incompatible with the
server version you use! in - on line 8
NULL refcount(1)
NULL refcount(1)
NULL refcount(1)
NULL refcount(1)
--
Edit bug report at http://bugs.php.net/?id=37671&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37671&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37671&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37671&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37671&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37671&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37671&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37671&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37671&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37671&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37671&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37671&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37671&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37671&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37671&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37671&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37671&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37671&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37671&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37671&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37671&r=mysqlcfg
#35805 [NEW]: no way to tell the libxslt/libexslt versions
From: squasar at eternalviper dot net Operating system: * PHP version: 5CVS-2005-12-26 (CVS) PHP Bug Type: XSLT related Bug description: no way to tell the libxslt/libexslt versions Description: There are no LIBXSLT_VERSION, LIBXSLT_DOTTED_VERSION, LIBEXSLT_VERSION, or LIBEXSLT_DOTTED_VERSION constants as there are for libxml. Thus there is no means for client code to determine what version of libxslt it's running against short of parsing phpinfo(). -- Edit bug report at http://bugs.php.net/?id=35805&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35805&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35805&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35805&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35805&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35805&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35805&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35805&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35805&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35805&r=support Expected behavior:http://bugs.php.net/fix.php?id=35805&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35805&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35805&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35805&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35805&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35805&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35805&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35805&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35805&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35805&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35805&r=mysqlcfg
#35759 [Csd->Opn]: mysqli_stmt_bind_result() makes huge allocation when column empty
ID: 35759
User updated by: squasar at eternalviper dot net
Reported By: squasar at eternalviper dot net
-Status: Closed
+Status: Open
Bug Type: MySQLi related
Operating System: *
-PHP Version: 5.1.1
+PHP Version: 5.1.2-CVS
Assigned To: andrey
New Comment:
I apologize for misunderstanding; this is fixed in 5.1.2-
CVS, but I'm used to there being a "This bug has been fixed
in CVS." message for that. Regardless, the test case in CVS
(ext/mysqli/tests/bug35759.phpt) is non-functional for the
issue; it does not check that memory limits are enabled or
ensure than a memory limit is set if so, and thus does not
necessarily test the problem (The default memory limit if
it's been compiled in is of course 8M, but this can't and
shouldn't be relied upon). Here's the unified diff of my
correction:
Index: ext/mysqli/tests/bug35759.phpt
===
RCS file: /repository/php-src/ext/mysqli/tests/Attic/
bug35759.phpt,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 bug35759.phpt
--- ext/mysqli/tests/bug35759.phpt 22 Dec 2005 18:11:39
- 1.1.2.1
+++ ext/mysqli/tests/bug35759.phpt 25 Dec 2005 01:51:31
-
@@ -1,7 +1,10 @@
--TEST--
bug #35759 : mysqli_stmt_bind_result() makes huge
allocation when column empty
--SKIPIF--
-
+
+--INI--
+memory_limit=1M
--FILE--
stmt->fields[ofs].max_length == 0) {
This will be true if the column is empty as well as in the
case where the user has not called store_result(). The result
is the code using the value of length instead of max_length,
which is 16M for a mediumblob.
Reproduce code:
---
Assume there exists a table:
CREATE TABLE a_table ( some_blob MEDIUMBLOB NOT NULL );
execute();
$s->store_result();
print_r( $s->result_metadata()->fetch_fields() );
$s->bind_result( $data );
$s->fetch();
print_r( $data );
?>
Expected result:
Array
(
[0] => stdClass Object
(
[name] => some_blob
[orgname] => some_blob
[table] => a_table
[orgtable] => a_table
[def] =>
[max_length] => 0
[length] => 0
[charsetnr] => 63
[flags] => 144
[type] => 252
[decimals] => 0
)
)
Actual result:
--
Array
(
[0] => stdClass Object
(
[name] => some_blob
[orgname] => some_blob
[table] => a_table
[orgtable] => a_table
[def] =>
[max_length] => 0
[length] => 16777215
[charsetnr] => 63
[flags] => 144
[type] => 252
[decimals] => 0
)
)
Fatal error: Allowed memory size of 8388608 bytes exhausted
(tried to allocate 16777216 bytes) in test.php on line 8
--
Edit this bug report at http://bugs.php.net/?id=35759&edit=1
#35759 [Csd->Opn]: mysqli_stmt_bind_result() makes huge allocation when column empty
ID: 35759
User updated by: squasar at eternalviper dot net
Reported By: squasar at eternalviper dot net
-Status: Closed
+Status: Open
Bug Type: MySQLi related
Operating System: *
PHP Version: 5.1.1
Assigned To: andrey
New Comment:
I don't understand how this is a documentation bug. I can
verify that MySQLi is making gigantic (16M) allocations in the
case of a column with an empty value. This happens EVEN WITH
store_result() being called first!
Previous Comments:
[2005-12-22 19:14:50] [EMAIL PROTECTED]
Should be fixed by now.
Thanks for reporting!
[2005-12-21 09:16:48] [EMAIL PROTECTED]
This sounds more like documentation issue than a real bug, but I let
Georg decide.
[2005-12-21 07:41:55] squasar at eternalviper dot net
Description:
If a MEDIUMBLOB column has an empty value (length of zero),
mysqli_stmt_bind_result() attempts to allocate a buffer of 16M
for it. The offending code is in mysqli_api.c, line 332:
if (stmt->stmt->fields[ofs].max_length == 0) {
This will be true if the column is empty as well as in the
case where the user has not called store_result(). The result
is the code using the value of length instead of max_length,
which is 16M for a mediumblob.
Reproduce code:
---
Assume there exists a table:
CREATE TABLE a_table ( some_blob MEDIUMBLOB NOT NULL );
execute();
$s->store_result();
print_r( $s->result_metadata()->fetch_fields() );
$s->bind_result( $data );
$s->fetch();
print_r( $data );
?>
Expected result:
Array
(
[0] => stdClass Object
(
[name] => some_blob
[orgname] => some_blob
[table] => a_table
[orgtable] => a_table
[def] =>
[max_length] => 0
[length] => 0
[charsetnr] => 63
[flags] => 144
[type] => 252
[decimals] => 0
)
)
Actual result:
--
Array
(
[0] => stdClass Object
(
[name] => some_blob
[orgname] => some_blob
[table] => a_table
[orgtable] => a_table
[def] =>
[max_length] => 0
[length] => 16777215
[charsetnr] => 63
[flags] => 144
[type] => 252
[decimals] => 0
)
)
Fatal error: Allowed memory size of 8388608 bytes exhausted
(tried to allocate 16777216 bytes) in test.php on line 8
--
Edit this bug report at http://bugs.php.net/?id=35759&edit=1
#35759 [NEW]: mysqli_stmt_bind_result() makes huge allocation when column empty
From: squasar at eternalviper dot net
Operating system: *
PHP version: 5.1.1
PHP Bug Type: MySQLi related
Bug description: mysqli_stmt_bind_result() makes huge allocation when column
empty
Description:
If a MEDIUMBLOB column has an empty value (length of zero),
mysqli_stmt_bind_result() attempts to allocate a buffer of 16M
for it. The offending code is in mysqli_api.c, line 332:
if (stmt->stmt->fields[ofs].max_length == 0) {
This will be true if the column is empty as well as in the
case where the user has not called store_result(). The result
is the code using the value of length instead of max_length,
which is 16M for a mediumblob.
Reproduce code:
---
Assume there exists a table:
CREATE TABLE a_table ( some_blob MEDIUMBLOB NOT NULL );
execute();
$s->store_result();
print_r( $s->result_metadata()->fetch_fields() );
$s->bind_result( $data );
$s->fetch();
print_r( $data );
?>
Expected result:
Array
(
[0] => stdClass Object
(
[name] => some_blob
[orgname] => some_blob
[table] => a_table
[orgtable] => a_table
[def] =>
[max_length] => 0
[length] => 0
[charsetnr] => 63
[flags] => 144
[type] => 252
[decimals] => 0
)
)
Actual result:
--
Array
(
[0] => stdClass Object
(
[name] => some_blob
[orgname] => some_blob
[table] => a_table
[orgtable] => a_table
[def] =>
[max_length] => 0
[length] => 16777215
[charsetnr] => 63
[flags] => 144
[type] => 252
[decimals] => 0
)
)
Fatal error: Allowed memory size of 8388608 bytes exhausted
(tried to allocate 16777216 bytes) in test.php on line 8
--
Edit bug report at http://bugs.php.net/?id=35759&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35759&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35759&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35759&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35759&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35759&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35759&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35759&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35759&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35759&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35759&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35759&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35759&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35759&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35759&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35759&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35759&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35759&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35759&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35759&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35759&r=mysqlcfg
#34955 [Fbk->Opn]: PEAR install fails
ID: 34955 User updated by: squasar at eternalviper dot net Reported By: squasar at eternalviper dot net -Status: Feedback +Status: Open Bug Type: Compile Failure -Operating System: Mac OS X 10.4.2/Darwin 8.2.0 +Operating System: MacOS X 10.4.3,i686-pc-linux-gnu -PHP Version: 5.1.0RC3 +PHP Version: 5.1.0RC4 Assigned To: cellog New Comment: I found the issue. Adding --enable-zend-multibyte to ./ configure fails both the PEAR install and Zend/tests/ halt02.phpt. Removing it makes both work correctly. I've run the test several times using a number of different configurations on both OS X 10.4.3 and i686-pc-linux-gnu; it always succeeds with Zend multibyte off and always fails with it on, both the halt02.phpt test and the PEAR install, on both systems. Although "succeeds" is a relative term. The PEAR install runs, but spits this out at me (5.1.0RC4, latest .phar): [PEAR] Archive_Tar- installed: 1.3.1 [PEAR] Console_Getopt - installed: 1.2 pear/PEAR can optionally use package "pear/XML_RPC" (version >= 1.4.0) Warning: PEAR_Installer_Role::factory(PEAR/Installer/Role/ Php.php): failed to open stream: No such file or directory in phar://install-pear-nozlib.phar/PEAR/Installer/Role.php on line 80 Fatal error: PEAR_Installer_Role::factory(): Failed opening required 'PEAR/Installer/Role/Php.php' (include_path='.:/ Users/gwynne/Desktop/Web/php/lib/php') in phar://install- pear-nozlib.phar/PEAR/Installer/Role.php on line 80 make[1]: *** [install-pear-installer] Error 255 make: *** [install-pear] Error 2 Previous Comments: [2005-11-05 17:37:32] [EMAIL PROTECTED] I have reports of many users successfully running this on Mac OS X, so I am inclined to think it is a problem with your setup. Please try with the latest install-pear-nozlib.phar, just in case this makes any difference. [2005-11-03 22:41:11] [EMAIL PROTECTED] Greg, perhaps we should remove PEAR totally from PHP and keep it separate. This thing has always slowed the releases of PHP and it should really end by now.. -------- [2005-10-27 13:30:26] squasar at eternalviper dot net No; PEAR does not install. As far as I can tell, install-pear- nozlib.phar never runs at all; php parses it and spits out 800K worth of ? characters. [2005-10-27 05:29:23] [EMAIL PROTECTED] I can't reproduce this on gentoo linux. Does PEAR actually install? [2005-10-22 11:50:54] [EMAIL PROTECTED] Greg, check it out please. 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/34955 -- Edit this bug report at http://bugs.php.net/?id=34955&edit=1
#34955 [Fbk->Opn]: PEAR install fails
ID: 34955 User updated by: squasar at eternalviper dot net Reported By: squasar at eternalviper dot net -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.4.2/Darwin 8.2.0 PHP Version: 5.1.0RC3 Assigned To: cellog New Comment: No; PEAR does not install. As far as I can tell, install-pear- nozlib.phar never runs at all; php parses it and spits out 800K worth of ? characters. Previous Comments: [2005-10-27 05:29:23] [EMAIL PROTECTED] I can't reproduce this on gentoo linux. Does PEAR actually install? [2005-10-22 11:50:54] [EMAIL PROTECTED] Greg, check it out please. [2005-10-22 05:58:17] squasar at eternalviper dot net Description: The "Installing PEAR environment" phase of the "make install" command results in several pages of garbage output and no installed PEAR. The error occurs when make attempts to run the install-pear-nozlib.phar script. Reproduce code: --- $ ./buildconf --force $ ./configure --prefix=/usr --with-apxs --enable-cli --disable-short-tags --with-zlib --with-bz2 --enable-ftp --with-iconv --enable-mbstring --with-mysql=/usr --enable-sockets --enable-debug --enable-simplexml --with-xsl=/usr --with-curl=/usr --with-curlwrappers --enable-bcmath --with-gmp=/usr/local --with-gd --with-freetype-dir=/usr/X11R6 --enable-gd-native-ttf --with-imap=/usr/local/imap --with-imap-ssl=/usr --with-xmlrpc --with-xml-dir=/usr --with-expat-dir=/usr --with-iconv-dir=/usr --with-mysqli=/usr/bin/mysql_config --with-pdo-mysql=/usr --with-embedded-mysqli --enable-maintainer-zts --enable-zend-multibyte --enable-memory-limit --with-svn=/usr $ make -j 3 $ sudo make install Expected result: Installing PHP SAPI module: apache [activating module `php5' in /etc/httpd/httpd.conf] cp libs/libphp5.so /usr/libexec/httpd/libphp5.so chmod 755 /usr/libexec/httpd/libphp5.so cp /etc/httpd/httpd.conf /etc/httpd/httpd.conf.bak cp /etc/httpd/httpd.conf.new /etc/httpd/httpd.conf rm /etc/httpd/httpd.conf.new Installing PHP CLI binary:/usr/bin/ Installing PHP CLI man page: /usr/man/man1/ Installing build environment: /usr/lib/php/build/ Installing header files: /usr/include/php/ Installing helper programs: /usr/bin/ program: phpize program: php-config Installing man pages: /usr/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/lib/php/ Installing PDO headers: /usr/include/php/ext/pdo/ Actual result: -- Installing PHP SAPI module: apache [activating module `php5' in /etc/httpd/httpd.conf] cp libs/libphp5.so /usr/libexec/httpd/libphp5.so chmod 755 /usr/libexec/httpd/libphp5.so cp /etc/httpd/httpd.conf /etc/httpd/httpd.conf.bak cp /etc/httpd/httpd.conf.new /etc/httpd/httpd.conf rm /etc/httpd/httpd.conf.new Installing PHP CLI binary:/usr/bin/ Installing PHP CLI man page: /usr/man/man1/ Installing build environment: /usr/lib/php/build/ Installing header files: /usr/include/php/ Installing helper programs: /usr/bin/ program: phpize program: php-config Installing man pages: /usr/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/lib/php/ ???/* this continues for exactly 821228 characters total */???Installing PDO headers: /usr/include/php/ext/pdo/ -- Edit this bug report at http://bugs.php.net/?id=34955&edit=1
#34955 [NEW]: PEAR install fails
From: squasar at eternalviper dot net Operating system: Mac OS X 10.4.2/Darwin 8.2.0 PHP version: 5.1.0RC3 PHP Bug Type: Compile Failure Bug description: PEAR install fails Description: The "Installing PEAR environment" phase of the "make install" command results in several pages of garbage output and no installed PEAR. The error occurs when make attempts to run the install-pear-nozlib.phar script. Reproduce code: --- $ ./buildconf --force $ ./configure --prefix=/usr --with-apxs --enable-cli --disable-short-tags --with-zlib --with-bz2 --enable-ftp --with-iconv --enable-mbstring --with-mysql=/usr --enable-sockets --enable-debug --enable-simplexml --with-xsl=/usr --with-curl=/usr --with-curlwrappers --enable-bcmath --with-gmp=/usr/local --with-gd --with-freetype-dir=/usr/X11R6 --enable-gd-native-ttf --with-imap=/usr/local/imap --with-imap-ssl=/usr --with-xmlrpc --with-xml-dir=/usr --with-expat-dir=/usr --with-iconv-dir=/usr --with-mysqli=/usr/bin/mysql_config --with-pdo-mysql=/usr --with-embedded-mysqli --enable-maintainer-zts --enable-zend-multibyte --enable-memory-limit --with-svn=/usr $ make -j 3 $ sudo make install Expected result: Installing PHP SAPI module: apache [activating module `php5' in /etc/httpd/httpd.conf] cp libs/libphp5.so /usr/libexec/httpd/libphp5.so chmod 755 /usr/libexec/httpd/libphp5.so cp /etc/httpd/httpd.conf /etc/httpd/httpd.conf.bak cp /etc/httpd/httpd.conf.new /etc/httpd/httpd.conf rm /etc/httpd/httpd.conf.new Installing PHP CLI binary:/usr/bin/ Installing PHP CLI man page: /usr/man/man1/ Installing build environment: /usr/lib/php/build/ Installing header files: /usr/include/php/ Installing helper programs: /usr/bin/ program: phpize program: php-config Installing man pages: /usr/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/lib/php/ Installing PDO headers: /usr/include/php/ext/pdo/ Actual result: -- Installing PHP SAPI module: apache [activating module `php5' in /etc/httpd/httpd.conf] cp libs/libphp5.so /usr/libexec/httpd/libphp5.so chmod 755 /usr/libexec/httpd/libphp5.so cp /etc/httpd/httpd.conf /etc/httpd/httpd.conf.bak cp /etc/httpd/httpd.conf.new /etc/httpd/httpd.conf rm /etc/httpd/httpd.conf.new Installing PHP CLI binary:/usr/bin/ Installing PHP CLI man page: /usr/man/man1/ Installing build environment: /usr/lib/php/build/ Installing header files: /usr/include/php/ Installing helper programs: /usr/bin/ program: phpize program: php-config Installing man pages: /usr/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/lib/php/ ???/* this continues for exactly 821228 characters total */???Installing PDO headers: /usr/include/php/ext/pdo/ -- Edit bug report at http://bugs.php.net/?id=34955&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34955&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34955&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34955&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34955&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34955&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34955&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34955&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34955&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34955&r=support Expected behavior: http://bugs.php.net/fix.php?id=34955&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34955&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34955&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34955&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34955&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34955&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34955&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34955&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34955&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34955&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34955&r=mysqlcfg
#34818 [NEW]: new mysqli_stmt() crashes if first parameter is not a valid mysqli_link
From: squasar at eternalviper dot net
Operating system: *
PHP version: 5.1.0RC1
PHP Bug Type: MySQLi related
Bug description: new mysqli_stmt() crashes if first parameter is not a valid
mysqli_link
Description:
Calling __construct() on mysqli_stmt with an unset variable
as the mysqli_link crashes PHP in mysqli_stmt_construct.
Note that this is actually 5.1.0RC2 (CVS tag
php_5_1_0RC2_PRE). This may affect other MySQLi functions
(?). A possible fix, minus a more informative error message
is here, but my instinct says there may be more going on
behind this than the check in MYSQLI_FETCH_RESOURCE() since
passing a literal NULL or similar instead of an undefined
variable gives an error message instead of crashing.
Index: ext/mysqli/php_mysqli.h
===
RCS file: /repository/php-src/ext/mysqli/php_mysqli.h,v
retrieving revision 1.54
diff -u -r1.54 php_mysqli.h
--- ext/mysqli/php_mysqli.h 3 Aug 2005 14:07:31 -
1.54
+++ ext/mysqli/php_mysqli.h 10 Oct 2005 19:17:35 -
@@ -202,7 +202,12 @@
#define MYSQLI_FETCH_RESOURCE(__ptr, __type, __id, __name)
\
{ \
MYSQLI_RESOURCE *my_res; \
- mysqli_object *intern = (mysqli_object *)
zend_object_store_get_object(*(__id) TSRMLS_CC);\
+ mysqli_object *intern = NULL; \
+ if (Z_TYPE_PP(__id) != IS_OBJECT) {\
+ php_error(E_WARNING, "Object parameter
invalid"); \
+ RETURN_NULL(); \
+ } \
+ intern = (mysqli_object *)
zend_object_store_get_object(*(__id) TSRMLS_CC);\
if (!(my_res = (MYSQLI_RESOURCE *)intern->ptr)) {\
php_error(E_WARNING, "Couldn't fetch %s",
intern->zo.ce->name);\
RETURN_NULL();\
Reproduce code:
---
Expected result:
Warning: Object parameter invalid in - on line 1
Actual result:
--
Bus error
Thread 0 Crashed:
0 php 0x000c1bb8 zif_mysqli_stmt_construct + 252
(mysqli.c:675)
1 php 0x0020ab88 zend_do_fcall_common_helper_SPEC + 1560
(zend_vm_execute.h:184)
2 php 0x0020a4c4 execute + 520 (zend_vm_execute.h:87)
3 php 0x001e0630 zend_execute_scripts + 444 (zend.c:
1079)
4 php 0x00195334 php_execute_script + 780 (main.c:1679)
5 php 0x002921ac main + 3684 (php_cli.c:1040)
6 php 0x2b58 _start + 344 (crt.c:272)
7 php 0x29fc start + 60
--
Edit bug report at http://bugs.php.net/?id=34818&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34818&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34818&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34818&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34818&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34818&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34818&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34818&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34818&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34818&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34818&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34818&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34818&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34818&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34818&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34818&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34818&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34818&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34818&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34818&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34818&r=mysqlcfg
#34785 [Opn]: Can not properly subclass mysqli_stmt
ID: 34785
User updated by: squasar at eternalviper dot net
Reported By: squasar at eternalviper dot net
Status: Open
Bug Type: MySQLi related
Operating System: MacOS X 10.4.2/Darwin 8.2.0
PHP Version: 5.1.0RC1
New Comment:
Here's the udiff for the fix:
Index: ext/mysqli/mysqli_fe.c
===
RCS file: /repository/php-src/ext/mysqli/mysqli_fe.c,v
retrieving revision 1.49
diff -u -r1.49 mysqli_fe.c
--- ext/mysqli/mysqli_fe.c 3 Aug 2005 14:07:30 -
1.49
+++ ext/mysqli/mysqli_fe.c 7 Oct 2005 23:12:05 -
@@ -283,6 +283,7 @@
PHP_FALIAS(reset,mysqli_stmt_reset,NULL)
PHP_FALIAS(prepare,mysqli_stmt_prepare, NULL)
PHP_FALIAS
(store_result,mysqli_stmt_store_result,NULL)
+ PHP_FALIAS(mysqli_stmt,mysqli_stmt_construct,NULL)
{NULL, NULL, NULL}
};
/* }}} */
Previous Comments:
[2005-10-08 01:11:32] squasar at eternalviper dot net
Description:
If mysqli_stmt is subclassed (only makes sense in PHP 5.1.0 or
above), calling parent::__construct() results in "Fatal error:
Can not call constructor".
Fix:
Index: ext/mysqli/mysqli_fe.c
==
=
RCS file: /repository/php-src/ext/mysqli/mysqli_fe.c,v
retrieving revision 1.49
diff -r1.49 mysqli_fe.c
285a286
> PHP_FALIAS(mysqli_stmt,mysqli_stmt_construct,NULL)
Reproduce code:
---
Expected result:
object(my_stmt)#2 (0) {
}
Actual result:
--
Fatal error: Can not call constructor in - on line 4
--
Edit this bug report at http://bugs.php.net/?id=34785&edit=1
#34785 [NEW]: Can not properly subclass mysqli_stmt
From: squasar at eternalviper dot net
Operating system: MacOS X 10.4.2/Darwin 8.2.0
PHP version: 5.1.0RC1
PHP Bug Type: MySQLi related
Bug description: Can not properly subclass mysqli_stmt
Description:
If mysqli_stmt is subclassed (only makes sense in PHP 5.1.0 or
above), calling parent::__construct() results in "Fatal error:
Can not call constructor".
Fix:
Index: ext/mysqli/mysqli_fe.c
==
=
RCS file: /repository/php-src/ext/mysqli/mysqli_fe.c,v
retrieving revision 1.49
diff -r1.49 mysqli_fe.c
285a286
> PHP_FALIAS(mysqli_stmt,mysqli_stmt_construct,NULL)
Reproduce code:
---
Expected result:
object(my_stmt)#2 (0) {
}
Actual result:
--
Fatal error: Can not call constructor in - on line 4
--
Edit bug report at http://bugs.php.net/?id=34785&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34785&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34785&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34785&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34785&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34785&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34785&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34785&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34785&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34785&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34785&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34785&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34785&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34785&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34785&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34785&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34785&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34785&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34785&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34785&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34785&r=mysqlcfg
#34666 [NEW]: print and echo do not apply filters on STDOUT
From: squasar at eternalviper dot net Operating system: Mac OS X 10.4.2/Darwin 8.2.0 PHP version: 5.1.0RC1 PHP Bug Type: CGI related Bug description: print and echo do not apply filters on STDOUT Description: When using the CLI SAPI, installing filters on STDOUT with stream_filter_prepend()/stream_filter_append() does not apply those filters when print or echo are used. Suggested fix: have sapi_cli_single_write() in sapi/cli/php_cli.c use php_stream_write() instead of write()/fwrite() (possibly based on a ./configure option?) Reproduce code: --- Expected result: nopq nopq Actual result: -- nopq abcd -- Edit bug report at http://bugs.php.net/?id=34666&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34666&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34666&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34666&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34666&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34666&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34666&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34666&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34666&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34666&r=support Expected behavior: http://bugs.php.net/fix.php?id=34666&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34666&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34666&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34666&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34666&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34666&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34666&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34666&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34666&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34666&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34666&r=mysqlcfg
#33523 [NEW]: Memory leak in xmlrpc_encode_request() when encoding output option specified
From: squasar at eternalviper dot net Operating system: Mac OS X 10.4.1/Darwin 8.1.0 PHP version: 5.1.0b2 PHP Bug Type: XMLRPC-EPI related Bug description: Memory leak in xmlrpc_encode_request() when encoding output option specified Description: Calling xmlrpc_encode_request() with 'encoding' specified in output_options causes a memory leak in xmlrpc-epi-php.c on line 381, regardless of the encoding specified. It looks as if a call to estrdup() does not have a matching efree(). './configure' '--prefix=/usr' '--with-apxs' '--enable-cli' '-- disable-short-tags' '--with-zlib' '--with-bz2' '--enable-ftp' '--with-iconv' '--enable-mbstring' '--with-mysql=/usr' '-- enable-sockets' '--enable-debug' '--enable-simplexml' '--with- xsl=/usr' '--with-curl=/usr' '--with-curlwrappers' '--enable- bcmath' '--with-gmp=/usr/local' '--with-gd' '--with-freetype- dir=/usr/X11R6' '--enable-gd-native-ttf' '--with-imap=/usr/ local/imap' '--with-imap-ssl=/usr' '--with-xmlrpc' '--with- xml-dir=/usr' '--with-expat-dir=/usr' '--with-iconv-dir=/usr' Reproduce code: --- 'utf-8' ) ); ?> Expected result: No output at all. Actual result: -- Zend's memory debugger shows: /Users/gwynne/src/php-src/ext/xmlrpc/xmlrpc-epi-php.c(381) : Freeing 0x01BBB368 (6 bytes), script=- === Total 1 memory leaks detected === -- Edit bug report at http://bugs.php.net/?id=33523&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33523&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33523&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33523&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33523&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33523&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33523&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33523&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33523&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33523&r=support Expected behavior: http://bugs.php.net/fix.php?id=33523&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33523&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33523&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33523&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33523&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33523&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33523&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33523&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33523&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33523&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33523&r=mysqlcfg
