Bug #24522 [Com]: MSSQL: "Changed database context to" error when running query
Edit report at https://bugs.php.net/bug.php?id=24522&edit=1
ID: 24522
Comment by: rayphilip3 at gmail dot com
Reported by:cdcr440 at hotmail dot com
Summary:MSSQL: "Changed database context to" error when
running query
Status: Bogus
Type: Bug
Package:MSSQL related
Operating System: WinNT
PHP Version:4.3.1
Block user comment: N
Private report: N
New Comment:
Hi Cjrogala,
Could you tell how you had solved this issue? My application also has this
strange problem
Thanks
Ray
Previous Comments:
[2011-07-10 18:42:00] cjrogala at gmail dot com
I am an idiot. Please disregard my post.
[2011-07-10 18:34:22] cjrogala at gmail dot com
You may want to reopen this issue. I am inserting data into MS SQL Server
2008r2 and using PHP 5.2; and the same error occurs. The positive is that the
error did not prevent the data from being inserted into the database, but it
did display the same error message. I did not attempt to change the timeout
since this is a much later version. I also noticed this issue in a few
different location on the web. I am logging into the database as the sa and
like I said, the data is making into the database; but the error still appears
when validating the result of the query. Unlike the previous post, I will not
provide a credentials, but I know it's not a connection error since the data is
getting into the database. Here is my code:
$tsql = "USE littleliam
INSERT INTO [littleliam].[dbo].[tbl_blogPosts]
([postText]
,[created]
,[createdBy]
,[approved])
VALUES ('" .$postText ."', GETDATE(), " .$author .", " .$approvalStatus
.")";
//Used to validate the query by running it in SQL Server Management studios
echo $tsql;
//Prepare and execute the statement.
mssql_select_db('littleliam');
$insertReview = mssql_query($tsql, $msServerLink);
if (!$res) {
print("SQL statement failed with error:\n");
print(" ".mssql_get_last_message()."\n");
} else {
print("One data row inserted.\n");
}
mssql_close($msServerLink);
My connection script is:
$msServerLink = mssql_connect($db_server, $db_user, $db_pass);
The only thing I could think of is selecting the database in the connect
function. Can a database be selected in the mssql_connect function?
[2003-07-13 10:48:25] sni...@php.net
Temporarily closing. :)
[2003-07-10 04:03:09] cdcr440 at hotmail dot com
Thank you very much for that. Unfortunately, I can't check that this fixes the
problem because it's gone today and I didn't manage to find a query that fails.
As I said it's unpredictable and appears/disappears regularly. I've increased
the timeout and I'll see if the problem comes back again.
Sorry to have wasted your time, I think you can temporarily close this bug
report.
[2003-07-09 17:19:58] f...@php.net
This sounds like a timeout porblem.
You can use two php.ini settings to control the timeouts.
mssql.connect_timeout = 5
mssql.timeout = 60
These are default values in seconds. try to increase the second timeout value.
(I'll make sure thes values makes it into the distributed versions of php.ini).
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
https://bugs.php.net/bug.php?id=24522
--
Edit this bug report at https://bugs.php.net/bug.php?id=24522&edit=1
Bug #55653 [Csd]: PS crash with libmysql when binding same variable as param and out
Edit report at https://bugs.php.net/bug.php?id=55653&edit=1
ID: 55653
Updated by: larue...@php.net
Reported by:u...@php.net
Summary:PS crash with libmysql when binding same variable as
param and out
Status: Closed
Type: Bug
Package:MySQLi related
PHP Version:5.4SVN-2011-09-09 (SVN)
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
this also cause a segfault in
ext/mysqli/tests/mysqli_stmt_execute_stored_proc.php
Previous Comments:
[2011-09-10 03:52:04] larue...@php.net
This bug has been fixed in SVN.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
[2011-09-10 03:51:02] larue...@php.net
Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revision&revision=316474
Log: Fixed Bug #55653(PS crash with libmysql when binding same variable as
param and out)
Actually this caused by attempt to efree a INTERNED string
[2011-09-09 12:12:45] u...@php.net
Test added
[2011-09-09 12:11:54] u...@php.net
Automatic comment from SVN on behalf of uw
Revision: http://svn.php.net/viewvc/?view=revision&revision=316455
Log: Bug #55653
[2011-09-09 12:00:27] u...@php.net
Description:
This will crash, if using mysqli with libmysql.
sapi/cli/php -r '$link = new mysqli("192.168.2.27", "root", "", "test"); $stmt
= $link->stmt_init(); $in = "a"; $stmt->prepare("SELECT ?");
$stmt->bind_param("s", $in); $stmt->execute(); $stmt->bind_result($in);
$stmt->fetch(); var_dump($in);'
/home/nixnutz/php-src/branches/PHP_5_4/ext/mysqli/mysqli_api.c(890) : Block
0x071e5870 status:
Invalid pointer: ((size=0x005976c6) != (next.prev=0x))
==12847== Conditional jump or move depends on uninitialised value(s)
==12847==at 0x81C242: zend_mm_check_ptr (zend_alloc.c:1388)
==12847==by 0x81C230: zend_mm_check_ptr (zend_alloc.c:1385)
==12847==by 0x81DDA6: _zend_mm_free_int (zend_alloc.c:2064)
==12847==by 0x81F350: _efree (zend_alloc.c:2436)
==12847==by 0x5F412E: mysqli_stmt_fetch_libmysql (mysqli_api.c:890)
Box 1:
mysqli
MysqlI Support => enabled
Client API library version => 5.6.2-m5
Active Persistent Links => 0
Inactive Persistent Links => 0
Active Links => 0
Client API header version => 5.6.2-m5
MYSQLI_SOCKET => /tmp/mysql.sock
Box 2:
mysqli
MysqlI Support => enabled
Client API library version => 5.1.45
Active Persistent Links => 0
Inactive Persistent Links => 0
Active Links => 0
Client API header version => 5.1.45
MYSQLI_SOCKET => /tmp/mysql.sock
Test script:
---
sapi/cli/php -r '$link = new mysqli("192.168.2.27", "root", "", "test"); $stmt
= $link->stmt_init(); $in = "a"; $stmt->prepare("SELECT ?");
$stmt->bind_param("s", $in); $stmt->execute(); $stmt->bind_result($in);
$stmt->fetch(); var_dump($in);'
--
Edit this bug report at https://bugs.php.net/bug.php?id=55653&edit=1
Bug #55661 [Opn]: mysqli/tests/bug54674.phpt failed when link against libmysql
Edit report at https://bugs.php.net/bug.php?id=55661&edit=1 ID: 55661 Updated by: larue...@php.net Reported by:larue...@php.net Summary:mysqli/tests/bug54674.phpt failed when link against libmysql Status: Open Type: Bug Package:MySQLi related Operating System: Linux PHP Version:trunk-SVN-2011-09-10 (SVN) Block user comment: N Private report: N New Comment: ext/mysqli/tests/mysqli_last_insert_id.phpt also failed, with diff: 002+ [007] API id should have been reset to 0 because previous query was SELECT, got API 1, SQL 1 003+ [010] API id should have been reset to 0 because previous query was SELECT, got API 1, SQL 1 008+ [027] API id should have been reset to 0 because previous query failed, got API 4, SQL 4 Previous Comments: [2011-09-10 04:07:23] larue...@php.net Description: mysqli/tests/bug54674.phpt failed when linked against libmysql Test script: --- none Expected result: PASS Actual result: -- FAIELD diff: 001+ bool(false) 001- bool(true) -- Edit this bug report at https://bugs.php.net/bug.php?id=55661&edit=1
[PHP-BUG] Bug #55662 [NEW]: test script cause seg fault
From: laruence
Operating system: Linux 64bit
PHP version: 5.4SVN-2011-09-10 (SVN)
Package: MySQLi related
Bug Type: Bug
Bug description:test script cause seg fault
Description:
ext/mysqli/tests/mysqli_explain_metadata.phpt cause a segment fault(linked
against libmysql)
backtrace:
#0 0x00302af6ff20 in strlen () from /lib64/tls/libc.so.6
#1 0x007dbeb5 in add_property_string_ex (arg=0x2a99479160,
key=0xb68dec
"catalog", key_len=8,
str=0x20200a3e6e6f6974 ,
duplicate=1)
at /home/huixc/opensource/php-src/trunk/Zend/zend_API.c:1561
#2 0x005f9a35 in php_add_field_properties (value=0x2a99479160,
field=0x1000410)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1060
#3 0x005f9d80 in zif_mysqli_fetch_fields (ht=1,
return_value=0x2a994bcf68, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1118
#4 0x0080e1b6 in zend_do_fcall_common_helper_SPEC
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:642
#5 0x0081491a in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:2215
#6 0x0080ceba in execute (op_array=0xff40d0) at
/home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:410
#7 0x007d559c in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/huixc/opensource/php-src/trunk/Zend/zend.c:1262
#8 0x0075698b in php_execute_script (primary_file=0x7fb230) at
/home/huixc/opensource/php-src/trunk/main/main.c:2388
#9 0x008f53f9 in do_cli (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:983
#10 0x008f629a in main (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:1356
f2,
(gdb) p *field
$2 = {name = 0x10007d0 "possible_keys", org_name = 0x10007e0 "", table =
0x10007c0 "", org_table = 0x10007c8 "", db = 0x10007b8 "",
catalog = 0x20200a3e6e6f6974 ,
def =
0x0, length = 4096, max_length = 0,
name_length = 537542259, org_name_length = 1818311712, table_length =
1047748969, org_table_length = 762278761, db_length = 959789112,
catalog_length = 792474157, def_length = 1634298977, flags = 0, decimals
= 31,
charsetnr = 8, type = MYSQL_TYPE_VAR_STRING,
extension = 0x61696c612f3c3130}
Test script:
---
ext/mysqli/tests/mysqli_explain_metadata.phpt
Expected result:
passed
Actual result:
--
seg fault
--
Edit bug report at https://bugs.php.net/bug.php?id=55662&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55662&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55662&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55662&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55662&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55662&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55662&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55662&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55662&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55662&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55662&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55662&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55662&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55662&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55662&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55662&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55662&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55662&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55662&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55662&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55662&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55662&r=mysqlcfg
[PHP-BUG] Bug #55661 [NEW]: mysqli/tests/bug54674.phpt failed when link against libmysql
From: laruence Operating system: Linux PHP version: trunk-SVN-2011-09-10 (SVN) Package: MySQLi related Bug Type: Bug Bug description:mysqli/tests/bug54674.phpt failed when link against libmysql Description: mysqli/tests/bug54674.phpt failed when linked against libmysql Test script: --- none Expected result: PASS Actual result: -- FAIELD diff: 001+ bool(false) 001- bool(true) -- Edit bug report at https://bugs.php.net/bug.php?id=55661&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55661&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55661&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55661&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55661&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55661&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55661&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55661&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55661&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55661&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55661&r=support Expected behavior: https://bugs.php.net/fix.php?id=55661&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55661&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55661&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55661&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55661&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55661&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55661&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55661&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55661&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55661&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55661&r=mysqlcfg
Bug #55660 [Opn->Fbk]: SplFixedArray::fromArray causing segmentation fault 11
Edit report at https://bugs.php.net/bug.php?id=55660&edit=1
ID: 55660
Updated by: larue...@php.net
Reported by:rewilliams at crystaltech dot com
Summary:SplFixedArray::fromArray causing segmentation fault
11
-Status: Open
+Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Mac OS X 10.7.1
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
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 for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
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.
I can not reproduce it with a test csv file(1005 line, 13 cloumns) with 5.3
trunk
Previous Comments:
[2011-09-09 21:32:23] rewilliams at crystaltech dot com
Hmm, I don't see how to upload reproduction scripts. The script is below; I'll
leave the data
file to the tester. I created a simple CSV file that had 10,005 lines of 13
columns each, where
the value of every column is the alphabet. It included one trailing blank line
and used CRLF line
endings.
Here's the script:
setFlags(SplFileObject::SKIP_EMPTY |
SplFileObject::DROP_NEW_LINE |
SplFileObject::READ_CSV);
$return = array();
foreach ($fileObj as $oneLine) {
$return[] = new stdClass();
} //foreach
switch ($whichOption) {
case 1:
$return = array_slice($return, 0, );
$result = SplFixedArray::fromArray($return);
//we get here
return $result;
break;
case 2:
$return = array_slice($return, 0, 1);
$result = SplFixedArray::fromArray($return);
//we won't get here - get "Segmentation fault:
11"
return $result;
break;
} //switch
} //ImportData
} //NmsObj
//$dataSet1 = NmsObj::ImportData(1);
$dataSet1 = NmsObj::ImportData(2);
echo "Done!\n";
?>
[2011-09-09 21:26:12] rewilliams at crystaltech dot com
Description:
I created a script that uses SplFileObject to iterate over a CSV file. As it
goes, it creates a new object with each line's data and adds the object to an
array. Running it with 10k or more lines crashes with a "Segmentation fault:
11"
error message, while anything up to 9,999 lines works well. Adjusting PHP's
memory limit had no effect.
I've attached a partial reduction to this bug. It seems like I really need the
elements of the SplFileObject and the class for each line, as skipping either
one of those (even when the resulting array is much larger than 10k items)
causes the failure to disappear. I'm not sure exactly what the trigger is,
however. My reduction includes a sample CSV file of just over 10k lines, and
though it still uses SplFileObject and a per-line object, the class for the
latter is just an stdClass, and the data from the file is essentially ignored.
The script has two lines near the bottom that are method calls to ImportData().
Comment out one or the other to see the script run successfully or to see it
fail. Option 1 works; option 2 fails.
Note that I tested this under 5.3.6, not the 5.3.8 that's indicated on the bug.
I do not have access to the latter.
Expected result:
I'd expect the script to run to completion in all cases, assuming there is
sufficient memory.
Actual result:
--
The script fails in the case of >= 1 items in the array being converted.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55660&edit=1
Bug #55653 [Opn->Csd]: PS crash with libmysql when binding same variable as param and out
Edit report at https://bugs.php.net/bug.php?id=55653&edit=1
ID: 55653
Updated by: larue...@php.net
Reported by:u...@php.net
Summary:PS crash with libmysql when binding same variable as
param and out
-Status: Open
+Status: Closed
Type: Bug
Package:MySQLi related
PHP Version:5.4SVN-2011-09-09 (SVN)
-Assigned To:
+Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-09-10 03:51:02] larue...@php.net
Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revision&revision=316474
Log: Fixed Bug #55653(PS crash with libmysql when binding same variable as
param and out)
Actually this caused by attempt to efree a INTERNED string
[2011-09-09 12:12:45] u...@php.net
Test added
[2011-09-09 12:11:54] u...@php.net
Automatic comment from SVN on behalf of uw
Revision: http://svn.php.net/viewvc/?view=revision&revision=316455
Log: Bug #55653
[2011-09-09 12:00:27] u...@php.net
Description:
This will crash, if using mysqli with libmysql.
sapi/cli/php -r '$link = new mysqli("192.168.2.27", "root", "", "test"); $stmt
= $link->stmt_init(); $in = "a"; $stmt->prepare("SELECT ?");
$stmt->bind_param("s", $in); $stmt->execute(); $stmt->bind_result($in);
$stmt->fetch(); var_dump($in);'
/home/nixnutz/php-src/branches/PHP_5_4/ext/mysqli/mysqli_api.c(890) : Block
0x071e5870 status:
Invalid pointer: ((size=0x005976c6) != (next.prev=0x))
==12847== Conditional jump or move depends on uninitialised value(s)
==12847==at 0x81C242: zend_mm_check_ptr (zend_alloc.c:1388)
==12847==by 0x81C230: zend_mm_check_ptr (zend_alloc.c:1385)
==12847==by 0x81DDA6: _zend_mm_free_int (zend_alloc.c:2064)
==12847==by 0x81F350: _efree (zend_alloc.c:2436)
==12847==by 0x5F412E: mysqli_stmt_fetch_libmysql (mysqli_api.c:890)
Box 1:
mysqli
MysqlI Support => enabled
Client API library version => 5.6.2-m5
Active Persistent Links => 0
Inactive Persistent Links => 0
Active Links => 0
Client API header version => 5.6.2-m5
MYSQLI_SOCKET => /tmp/mysql.sock
Box 2:
mysqli
MysqlI Support => enabled
Client API library version => 5.1.45
Active Persistent Links => 0
Inactive Persistent Links => 0
Active Links => 0
Client API header version => 5.1.45
MYSQLI_SOCKET => /tmp/mysql.sock
Test script:
---
sapi/cli/php -r '$link = new mysqli("192.168.2.27", "root", "", "test"); $stmt
= $link->stmt_init(); $in = "a"; $stmt->prepare("SELECT ?");
$stmt->bind_param("s", $in); $stmt->execute(); $stmt->bind_result($in);
$stmt->fetch(); var_dump($in);'
--
Edit this bug report at https://bugs.php.net/bug.php?id=55653&edit=1
Bug #55660 [Opn]: SplFixedArray::fromArray causing segmentation fault 11
Edit report at https://bugs.php.net/bug.php?id=55660&edit=1
ID: 55660
User updated by:rewilliams at crystaltech dot com
Reported by:rewilliams at crystaltech dot com
Summary:SplFixedArray::fromArray causing segmentation fault
11
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Mac OS X 10.7.1
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Hmm, I don't see how to upload reproduction scripts. The script is below; I'll
leave the data
file to the tester. I created a simple CSV file that had 10,005 lines of 13
columns each, where
the value of every column is the alphabet. It included one trailing blank line
and used CRLF line
endings.
Here's the script:
setFlags(SplFileObject::SKIP_EMPTY |
SplFileObject::DROP_NEW_LINE |
SplFileObject::READ_CSV);
$return = array();
foreach ($fileObj as $oneLine) {
$return[] = new stdClass();
} //foreach
switch ($whichOption) {
case 1:
$return = array_slice($return, 0, );
$result = SplFixedArray::fromArray($return);
//we get here
return $result;
break;
case 2:
$return = array_slice($return, 0, 1);
$result = SplFixedArray::fromArray($return);
//we won't get here - get "Segmentation fault:
11"
return $result;
break;
} //switch
} //ImportData
} //NmsObj
//$dataSet1 = NmsObj::ImportData(1);
$dataSet1 = NmsObj::ImportData(2);
echo "Done!\n";
?>
Previous Comments:
[2011-09-09 21:26:12] rewilliams at crystaltech dot com
Description:
I created a script that uses SplFileObject to iterate over a CSV file. As it
goes, it creates a new object with each line's data and adds the object to an
array. Running it with 10k or more lines crashes with a "Segmentation fault:
11"
error message, while anything up to 9,999 lines works well. Adjusting PHP's
memory limit had no effect.
I've attached a partial reduction to this bug. It seems like I really need the
elements of the SplFileObject and the class for each line, as skipping either
one of those (even when the resulting array is much larger than 10k items)
causes the failure to disappear. I'm not sure exactly what the trigger is,
however. My reduction includes a sample CSV file of just over 10k lines, and
though it still uses SplFileObject and a per-line object, the class for the
latter is just an stdClass, and the data from the file is essentially ignored.
The script has two lines near the bottom that are method calls to ImportData().
Comment out one or the other to see the script run successfully or to see it
fail. Option 1 works; option 2 fails.
Note that I tested this under 5.3.6, not the 5.3.8 that's indicated on the bug.
I do not have access to the latter.
Expected result:
I'd expect the script to run to completion in all cases, assuming there is
sufficient memory.
Actual result:
--
The script fails in the case of >= 1 items in the array being converted.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55660&edit=1
[PHP-BUG] Bug #55660 [NEW]: SplFixedArray::fromArray causing segmentation fault 11
From: Operating system: Mac OS X 10.7.1 PHP version: 5.3.8 Package: Reproducible crash Bug Type: Bug Bug description:SplFixedArray::fromArray causing segmentation fault 11 Description: I created a script that uses SplFileObject to iterate over a CSV file. As it goes, it creates a new object with each line's data and adds the object to an array. Running it with 10k or more lines crashes with a "Segmentation fault: 11" error message, while anything up to 9,999 lines works well. Adjusting PHP's memory limit had no effect. I've attached a partial reduction to this bug. It seems like I really need the elements of the SplFileObject and the class for each line, as skipping either one of those (even when the resulting array is much larger than 10k items) causes the failure to disappear. I'm not sure exactly what the trigger is, however. My reduction includes a sample CSV file of just over 10k lines, and though it still uses SplFileObject and a per-line object, the class for the latter is just an stdClass, and the data from the file is essentially ignored. The script has two lines near the bottom that are method calls to ImportData(). Comment out one or the other to see the script run successfully or to see it fail. Option 1 works; option 2 fails. Note that I tested this under 5.3.6, not the 5.3.8 that's indicated on the bug. I do not have access to the latter. Expected result: I'd expect the script to run to completion in all cases, assuming there is sufficient memory. Actual result: -- The script fails in the case of >= 1 items in the array being converted. -- Edit bug report at https://bugs.php.net/bug.php?id=55660&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55660&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55660&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55660&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55660&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55660&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55660&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55660&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55660&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55660&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55660&r=support Expected behavior: https://bugs.php.net/fix.php?id=55660&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55660&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55660&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55660&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55660&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55660&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55660&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55660&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55660&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55660&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55660&r=mysqlcfg
[PHP-BUG] Req #55659 [NEW]: Correcting phpt test files for current configurations
From: Operating system: Linux ( should be OS agnostic ) PHP version: 5.3.8 Package: InterBase related Bug Type: Feature/Change Request Bug description:Correcting phpt test files for current configurations Description: Test 003 result default field names have changed over time. Not sure how far bake the change goes database version wise. Test 006 is demonstrating how rounding of integers works rather than flagging an real error. 7.5 should always round up to 8, so that should be expected in the result set. Test script: --- Patch is for the test script ... -- Edit bug report at https://bugs.php.net/bug.php?id=55659&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55659&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55659&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55659&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55659&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55659&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55659&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55659&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55659&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55659&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55659&r=support Expected behavior: https://bugs.php.net/fix.php?id=55659&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55659&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55659&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55659&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55659&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55659&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55659&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55659&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55659&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55659&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55659&r=mysqlcfg
Bug #55657 [Opn->Bgs]: Adding a day to the timestamp does not change the value of date('d',$ts)
Edit report at https://bugs.php.net/bug.php?id=55657&edit=1
ID: 55657
Updated by: dtajchre...@php.net
Reported by:steve7642 at gmail dot com
Summary:Adding a day to the timestamp does not change the
value of date('d',$ts)
-Status: Open
+Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Linux linuxvps1.ciniva.com 2.6.1
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
You've discovered daylight saving time! This code helps you understand what
happens slightly better: http://codepad.org/kBgS1g6W
[1] http://en.wikipedia.org/wiki/Daylight_saving_time
Previous Comments:
[2011-09-09 18:26:17] steve7642 at gmail dot com
Description:
Adding 7 days to the timestamp for 2011-11-05 increased the date by 6 days
only. run sample code.
Test script:
---
/*
It appears that the day function of the time stamp is falling behind .
*/
$ts = mktime(0,0,0,10,29,2011) + 7*86400 ;
$mday1 = date('d',$ts); //OK
$ts = mktime(0,0,0,10,29,2011) + 14*86400 ;
$mday2 = date('d',$ts); //1 day behind
$ts = mktime(0,0,0,10,29,2011) + 21*86400 ;
$mday3 = date('d',$ts); // 1 day behind
echo $mday1. ' ' . $mday2.' '. $mday3 ;
--
Edit this bug report at https://bugs.php.net/bug.php?id=55657&edit=1
[PHP-BUG] Bug #55657 [NEW]: Adding a day to the timestamp does not change the value of date('d',$ts)
From:
Operating system: Linux linuxvps1.ciniva.com 2.6.1
PHP version: Irrelevant
Package: Date/time related
Bug Type: Bug
Bug description:Adding a day to the timestamp does not change the value of
date('d',$ts)
Description:
Adding 7 days to the timestamp for 2011-11-05 increased the date by 6 days
only. run sample code.
Test script:
---
/*
It appears that the day function of the time stamp is falling behind .
*/
$ts = mktime(0,0,0,10,29,2011) + 7*86400 ;
$mday1 = date('d',$ts); //OK
$ts = mktime(0,0,0,10,29,2011) + 14*86400 ;
$mday2 = date('d',$ts); //1 day behind
$ts = mktime(0,0,0,10,29,2011) + 21*86400 ;
$mday3 = date('d',$ts); // 1 day behind
echo $mday1. ' ' . $mday2.' '. $mday3 ;
--
Edit bug report at https://bugs.php.net/bug.php?id=55657&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55657&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55657&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55657&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55657&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55657&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55657&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55657&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55657&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55657&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55657&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55657&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55657&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55657&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55657&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55657&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55657&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55657&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55657&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55657&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55657&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55657&r=mysqlcfg
Bug #55655 [Opn]: Use ctlib 15.5 64bits failed
Edit report at https://bugs.php.net/bug.php?id=55655&edit=1
ID: 55655
User updated by:michel dot payan at gmail dot com
Reported by:michel dot payan at gmail dot com
Summary:Use ctlib 15.5 64bits failed
Status: Open
Type: Bug
Package:Sybase-ct (ctlib) related
Operating System: Linux ReadHat 5.3 x86_64
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
I see that we can modify the file ext/sybase_ct/config.m4, but i can't know the
procedure to take this modification into account.
Is anyone can help me ? (phpize ...).
Previous Comments:
[2011-09-09 14:13:26] michel dot payan at gmail dot com
Description:
Y want to use PHP 5.2.17 with lib DB 1.7.14 for Oracle (11.2) and Sybase (15.5)
in a 64 bits environnement.
All work for Oracle.
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
Linux linnt27.tlt 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64
x86_64 x86_64 GNU/Linux
Sybase CTISQL Utility/15.5/P-EBF17747 ESD #4/DRV.15.5.1/Linux Intel/Linux
2.6.9-55.ELsmp x86_64/BUILD1550-006/OPT/Sun Apr 18 01:03:56 2010
For Sybase i haved the knowed problem to take 64bits libraries ...
So i have manually modified the Makefile to put the good libraries, compilation
and installation work (make and make install), but have errors when i want to
execute sybase query !
Used config command:
cd $HOME/php-5.2.17
./configure --prefix=/home/oracle/php5.2.17
--with-apxs2=/home/oracle/apache/bin/apxs \
--disable-short-tags --with-zlib --enable-calendar --enable-ftp --with-gd
--with-freetype-dir \
--with-iconv --with-gettext --with-jpeg-dir=/usr/lib --with-png-dir
--enable-mbstring --enable-pcntl \
--enable-soap --enable-zip --with-pear --enable-bcmath --without-sqlite
--without-pdo-sqlite \
--enable-sigchild --with-libdir=lib64 --enable-gd-native-ttf --enable-xmlwriter
--without-readline --with-gd --with-xpm-dir --enable-exif \
--with-oci8=$ORACLE_HOME --with-pdo-oci=$ORACLE_HOME \
--with-sybase-ct=$SYBASE/$SYBASE_OCS
Manually modify Makefile to put:
CFLAGS = $(CFLAGS_CLEAN) -DSYB_LP64
EXTRA_LIBS = -lcrypt -lz -lsybcs64 -lsybct64 -lsybcomn64 -lsybintl64 -lsybtcl64
...
So, when i test connexion with the test.php script i have this error:
Fail to connect:
Erreur: DB Error: no database selected
DB Error: no database selected
So, if i change my dsn to "sybase://indsyb_maj:psswd@DBSYBIND", the connection
work but i have this error:
Fatal error: Call to undefined method DB_Error::numRows() in
/home/oracle/SQWareWeb/v2.0/test.php on line 41
So, if i comment the line that call $res->numRows(), i have:
DB Error: unknown error
What the good solution to compile PHP with Sybase 64bits ? I have to stand in
PHP 5.2 ...
Test script:
---
";
$dsn = "sybase://indsyb_maj:psswd@DBSYBIND/syb_inddba";
$options = array('debug' => 2, 'portability' => DB_PORTABILITY_ALL);
$db = DB::connect($dsn,$options);
if (DB::isError($db))
{
echo "dsn=$dsn\n";
echo "Fail to connect:\n";
echo "Erreur: ".$db->getMessage()."\n";
die ($db->getMessage());
}
$query = "select distinct DataServer from tedt_Repository where Status!='OFF'
order by 1";
$res = $db->query($query);
echo "Numrows: ".$res->numRows()."\n";
if (DB::isError($res))
{
die ($res->getMessage());
}
while ($record = $res->fetchRow(DB_FETCHMODE_ASSOC))
{
echo nl2br(print_r($record,true))."\n";
}
$res->free();
$db->disconnect();
?>
--
Edit this bug report at https://bugs.php.net/bug.php?id=55655&edit=1
[PHP-BUG] Bug #55655 [NEW]: Use ctlib 15.5 64bits failed
From:
Operating system: Linux ReadHat 5.3 x86_64
PHP version: 5.3.8
Package: Sybase-ct (ctlib) related
Bug Type: Bug
Bug description:Use ctlib 15.5 64bits failed
Description:
Y want to use PHP 5.2.17 with lib DB 1.7.14 for Oracle (11.2) and Sybase
(15.5) in a 64 bits environnement.
All work for Oracle.
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
Linux linnt27.tlt 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64
x86_64 x86_64 GNU/Linux
Sybase CTISQL Utility/15.5/P-EBF17747 ESD #4/DRV.15.5.1/Linux Intel/Linux
2.6.9-55.ELsmp x86_64/BUILD1550-006/OPT/Sun Apr 18 01:03:56 2010
For Sybase i haved the knowed problem to take 64bits libraries ...
So i have manually modified the Makefile to put the good libraries,
compilation and installation work (make and make install), but have errors
when i want to execute sybase query !
Used config command:
cd $HOME/php-5.2.17
./configure --prefix=/home/oracle/php5.2.17
--with-apxs2=/home/oracle/apache/bin/apxs \
--disable-short-tags --with-zlib --enable-calendar --enable-ftp --with-gd
--with-freetype-dir \
--with-iconv --with-gettext --with-jpeg-dir=/usr/lib --with-png-dir
--enable-mbstring --enable-pcntl \
--enable-soap --enable-zip --with-pear --enable-bcmath --without-sqlite
--without-pdo-sqlite \
--enable-sigchild --with-libdir=lib64 --enable-gd-native-ttf
--enable-xmlwriter --without-readline --with-gd --with-xpm-dir
--enable-exif \
--with-oci8=$ORACLE_HOME --with-pdo-oci=$ORACLE_HOME \
--with-sybase-ct=$SYBASE/$SYBASE_OCS
Manually modify Makefile to put:
CFLAGS = $(CFLAGS_CLEAN) -DSYB_LP64
EXTRA_LIBS = -lcrypt -lz -lsybcs64 -lsybct64 -lsybcomn64 -lsybintl64
-lsybtcl64 ...
So, when i test connexion with the test.php script i have this error:
Fail to connect:
Erreur: DB Error: no database selected
DB Error: no database selected
So, if i change my dsn to "sybase://indsyb_maj:psswd@DBSYBIND", the
connection work but i have this error:
Fatal error: Call to undefined method DB_Error::numRows() in
/home/oracle/SQWareWeb/v2.0/test.php on line 41
So, if i comment the line that call $res->numRows(), i have:
DB Error: unknown error
What the good solution to compile PHP with Sybase 64bits ? I have to stand
in PHP 5.2 ...
Test script:
---
";
$dsn = "sybase://indsyb_maj:psswd@DBSYBIND/syb_inddba";
$options = array('debug' => 2, 'portability' => DB_PORTABILITY_ALL);
$db = DB::connect($dsn,$options);
if (DB::isError($db))
{
echo "dsn=$dsn\n";
echo "Fail to connect:\n";
echo "Erreur: ".$db->getMessage()."\n";
die ($db->getMessage());
}
$query = "select distinct DataServer from tedt_Repository where
Status!='OFF' order by 1";
$res = $db->query($query);
echo "Numrows: ".$res->numRows()."\n";
if (DB::isError($res))
{
die ($res->getMessage());
}
while ($record = $res->fetchRow(DB_FETCHMODE_ASSOC))
{
echo nl2br(print_r($record,true))."\n";
}
$res->free();
$db->disconnect();
?>
--
Edit bug report at https://bugs.php.net/bug.php?id=55655&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55655&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55655&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55655&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55655&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55655&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55655&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55655&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55655&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55655&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55655&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55655&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55655&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55655&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55655&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55655&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55655&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55655&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55655&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55655&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55655&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55655&r=mysqlcfg
[PHP-BUG] Req #55654 [NEW]: ereg() behavior for preg_match
From: Operating system: Windows 7 PHP version: 5.3SVN-2011-09-09 (snap) Package: Regexps related Bug Type: Feature/Change Request Bug description:ereg() behavior for preg_match Description: Consideration. I choosen "September Snapshot", because I could not find mine in the list. My installation report to "PHP 5.3.3. Build Date: Jul 21 2010 20:25:38". Alright. I would like to ask, if is there any possibility to add, maybe through another non-Perl compatible modifier, the behavior we had with ereg(). The behavior I'm talking about refers to match as much as possible instead of stop at very first valid match. This is useful sometimes. In my case, specially to validate input data against a RFC specification. Look at this snippet: https://ideone.com/sC6mA I tried to make it as much specific as I could. The intention was to validate float point numbers, between zero and 1, with none and up to three decimals, denying invalid floats, such as 0.00 (same as zero) or 1.0 (same as 1). But, the "lazy" behavior of preg_match() is accepting the code above, where 0.3444 should be denied, because of its 4 decimals. But since 0.344 is valid in the last length verification (one and up to three), the function accepts the input data, and the last digit is simply ignored, because preg_match() already caracterized 0.344 as valid. I hope you understand Expected result: An empty array Actual result: -- A match -- Edit bug report at https://bugs.php.net/bug.php?id=55654&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55654&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55654&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55654&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55654&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55654&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55654&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55654&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55654&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55654&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55654&r=support Expected behavior: https://bugs.php.net/fix.php?id=55654&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55654&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55654&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55654&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55654&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55654&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55654&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55654&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55654&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55654&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55654&r=mysqlcfg
Bug #55653 [Opn]: PS crash with libmysql when binding same variable as param and out
Edit report at https://bugs.php.net/bug.php?id=55653&edit=1
ID: 55653
Updated by: u...@php.net
Reported by:u...@php.net
Summary:PS crash with libmysql when binding same variable as
param and out
Status: Open
Type: Bug
Package:MySQLi related
PHP Version:5.4SVN-2011-09-09 (SVN)
Block user comment: N
Private report: N
New Comment:
Test added
Previous Comments:
[2011-09-09 12:11:54] u...@php.net
Automatic comment from SVN on behalf of uw
Revision: http://svn.php.net/viewvc/?view=revision&revision=316455
Log: Bug #55653
[2011-09-09 12:00:27] u...@php.net
Description:
This will crash, if using mysqli with libmysql.
sapi/cli/php -r '$link = new mysqli("192.168.2.27", "root", "", "test"); $stmt
= $link->stmt_init(); $in = "a"; $stmt->prepare("SELECT ?");
$stmt->bind_param("s", $in); $stmt->execute(); $stmt->bind_result($in);
$stmt->fetch(); var_dump($in);'
/home/nixnutz/php-src/branches/PHP_5_4/ext/mysqli/mysqli_api.c(890) : Block
0x071e5870 status:
Invalid pointer: ((size=0x005976c6) != (next.prev=0x))
==12847== Conditional jump or move depends on uninitialised value(s)
==12847==at 0x81C242: zend_mm_check_ptr (zend_alloc.c:1388)
==12847==by 0x81C230: zend_mm_check_ptr (zend_alloc.c:1385)
==12847==by 0x81DDA6: _zend_mm_free_int (zend_alloc.c:2064)
==12847==by 0x81F350: _efree (zend_alloc.c:2436)
==12847==by 0x5F412E: mysqli_stmt_fetch_libmysql (mysqli_api.c:890)
Box 1:
mysqli
MysqlI Support => enabled
Client API library version => 5.6.2-m5
Active Persistent Links => 0
Inactive Persistent Links => 0
Active Links => 0
Client API header version => 5.6.2-m5
MYSQLI_SOCKET => /tmp/mysql.sock
Box 2:
mysqli
MysqlI Support => enabled
Client API library version => 5.1.45
Active Persistent Links => 0
Inactive Persistent Links => 0
Active Links => 0
Client API header version => 5.1.45
MYSQLI_SOCKET => /tmp/mysql.sock
Test script:
---
sapi/cli/php -r '$link = new mysqli("192.168.2.27", "root", "", "test"); $stmt
= $link->stmt_init(); $in = "a"; $stmt->prepare("SELECT ?");
$stmt->bind_param("s", $in); $stmt->execute(); $stmt->bind_result($in);
$stmt->fetch(); var_dump($in);'
--
Edit this bug report at https://bugs.php.net/bug.php?id=55653&edit=1
[PHP-BUG] Bug #55653 [NEW]: PS crash with libmysql when binding same variable as param and out
From:
Operating system:
PHP version: 5.4SVN-2011-09-09 (SVN)
Package: MySQLi related
Bug Type: Bug
Bug description:PS crash with libmysql when binding same variable as param and
out
Description:
This will crash, if using mysqli with libmysql.
sapi/cli/php -r '$link = new mysqli("192.168.2.27", "root", "", "test");
$stmt = $link->stmt_init(); $in = "a"; $stmt->prepare("SELECT ?");
$stmt->bind_param("s", $in); $stmt->execute(); $stmt->bind_result($in);
$stmt->fetch(); var_dump($in);'
/home/nixnutz/php-src/branches/PHP_5_4/ext/mysqli/mysqli_api.c(890) : Block
0x071e5870 status:
Invalid pointer: ((size=0x005976c6) != (next.prev=0x))
==12847== Conditional jump or move depends on uninitialised value(s)
==12847==at 0x81C242: zend_mm_check_ptr (zend_alloc.c:1388)
==12847==by 0x81C230: zend_mm_check_ptr (zend_alloc.c:1385)
==12847==by 0x81DDA6: _zend_mm_free_int (zend_alloc.c:2064)
==12847==by 0x81F350: _efree (zend_alloc.c:2436)
==12847==by 0x5F412E: mysqli_stmt_fetch_libmysql (mysqli_api.c:890)
Box 1:
mysqli
MysqlI Support => enabled
Client API library version => 5.6.2-m5
Active Persistent Links => 0
Inactive Persistent Links => 0
Active Links => 0
Client API header version => 5.6.2-m5
MYSQLI_SOCKET => /tmp/mysql.sock
Box 2:
mysqli
MysqlI Support => enabled
Client API library version => 5.1.45
Active Persistent Links => 0
Inactive Persistent Links => 0
Active Links => 0
Client API header version => 5.1.45
MYSQLI_SOCKET => /tmp/mysql.sock
Test script:
---
sapi/cli/php -r '$link = new mysqli("192.168.2.27", "root", "", "test");
$stmt = $link->stmt_init(); $in = "a"; $stmt->prepare("SELECT ?");
$stmt->bind_param("s", $in); $stmt->execute(); $stmt->bind_result($in);
$stmt->fetch(); var_dump($in);'
--
Edit bug report at https://bugs.php.net/bug.php?id=55653&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55653&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55653&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55653&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55653&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55653&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55653&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55653&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55653&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55653&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55653&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55653&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55653&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55653&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55653&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55653&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55653&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55653&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55653&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55653&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55653&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55653&r=mysqlcfg
Bug #54798 [Csd->Asn]: Segfault when CURLOPT_STDERR file pointer is closed before calling curl_exec
Edit report at https://bugs.php.net/bug.php?id=54798&edit=1
ID: 54798
User updated by:sh...@php.net
Reported by:sh...@php.net
Summary:Segfault when CURLOPT_STDERR file pointer is closed
before calling curl_exec
-Status: Closed
+Status: Assigned
Type: Bug
Package:cURL related
Operating System: Ubuntu Linux 11.04 x86
PHP Version:trunk-SVN-2011-05-17 (SVN)
Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
The fix was wrong, reopening bug, see discussion over here:
http://news.php.net/php.cvs/66389 and here http://news.php.net/php.cvs/66399
Previous Comments:
[2011-09-08 14:37:37] bj...@php.net
This bug has been fixed in SVN.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
[2011-09-08 14:37:05] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=316417
Log: Fixed bug#54798Segfault when CURLOPT_STDERR file pointer is closed
before calling curl_exec
[2011-05-17 16:25:32] sh...@php.net
Description:
Related to http://bugs.php.net/bug.php?id=48203
Curl crashes when CURLOPT_STDERR file pointer is closed before calling
curl_exec(), i.e.
$fp = fopen(dirname(__FILE__) . '/bug48203.tmp', 'w');
$ch = curl_init();
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_STDERR, $fp);
curl_setopt($ch, CURLOPT_URL, getenv("PHP_CURL_HTTP_REMOTE_SERVER"));
fclose($fp); // <-- premature close of $fp caused a crash!
curl_exec($ch); // segfault
Error is reproduced on latest svn php5.3, php5.4 and trunk
Fix is also attached here.
Test script:
---
Full test script is available here:
http://svn.php.net/viewvc/php/php-src/trunk/ext/curl/tests/bug48203.phpt?view=markup
Expected result:
No segfault, see test script
Actual result:
--
Segfault
--
Edit this bug report at https://bugs.php.net/bug.php?id=54798&edit=1
Req #40799 [Com]: change string conversion behaviour for objects not implementing __toString()
Edit report at https://bugs.php.net/bug.php?id=40799&edit=1 ID: 40799 Comment by: oliver dot graetz at gmx dot de Reported by:oliver dot graetz at gmx dot de Summary:change string conversion behaviour for objects not implementing __toString() Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: any PHP Version:5.2.1 Block user comment: N Private report: N New Comment: First of all: Fixing the DateTime class is a good start but this is really just one of many problems. Four and a half years have passed and with the current PHP the problem still persists: Put any object not implementing __toString() into code where it is converted to string (for example using "implode()") and you get a catchable fatal error. PHP is a language ultimately designed to produce strings in 99.999% of all calls to any PHP script. Introducing language changes that make this harder is not a good idea. There are many situations when code runs through a list or hierarchy of variables. The current situation forces the programmer to check whether a cast to string for any variables is safe: $printable = (!is_object($var) or method_exists($var, '__toString')); This is really a joke on its own: For arrays and even resources there is a fallback (e.g. "Resource id #17"), only for objects someone decided that it would be a good idea to instead produce catchable fatal errors under certain circumstances. For me there currently remain some questions: 1. Why is there still no output for engine internal classes like DateTime where there is good reason to actually provide a default output? 2. Why is there no "is_printable($var)" function if PHP changed to a language where not all variables can be printed? The above code should not be needed to answer such a basic question. Thinking about a "Printable" interface would also be a good idea if the current situation with triggering errors remains. 3. Why is there a fallback "Array" for arrays but not "Object" or something else for objects not providing the __toString method? 4. Why does this have to be a catchable fatal error that forces the programmer to provide an error handler that purposely ignores it to continue script execution? Wouldn't an E_WARNING have sufficed? Previous Comments: [2010-02-16 22:24:56] none at mialinator dot com just fix datetime! [2007-03-14 03:51:50] oliver dot graetz at gmx dot de Description: Yes, I read the upgrade guide and the other bug reports regarding this topic so this is not a bug report but a plea for reconsideration. I really like that finally __toString() works in every situation but the inability to output object instances without __toString() defined is just too annoying. PHP preaches the KISS principle and on this issue the language is breaking its own rules. First of all, there are engine internal classes where the programmer is unable to provide a __toString method. Subclassing all of these classes upon usage just "to be on the safe side" is nonsense. If object output can't be changed to provide a fallback if __toString() is missing then at least all engine internal classes should implement their own default output. Secondly, for safety many programmers might be tempted to make all classes extend a common superclass just "to be on the safe side". This is braindead for the sake of any OOP concept but I already see some guys on the horizon ready to do it. And at last: There are so many convenient functions that just break if their input contains "problem objects". It just makes no sense that PHP forces me to implement an "object safe" version of implode()! I just had to do that and the loss of performance makes me shudder. Rasmus once said that PHP should only be a frontend for "PHP templates" that make use of as much precompiled code as possible. So why are these "templates" forced to implement ever more stuff in the userland? Suggestions: - at least implement default output for all engine internal classes - change __toString() to have a fallback, even "[__toString() missing]" improves on the current situation -- if this isn't POSSIBLE: PLEASE clearly state why at prominent places in the documentation. -- if this isn't WANTED: make it configurable or better, add a magic function, for example __tostring_fallback(), which should return a string. If it doesn't exist or doesn't return a string: go ahead raising the recoverable error! Abusing an error handler to do this is NOT a solution. Reproduce code: --- https://bugs.php.net/bug.php?id=40799&edit=1
[PHP-BUG] Req #55651 [NEW]: Option to force PHP to ignore the PASV address returned
From: Operating system: All PHP version: 5.3.8 Package: FTP related Bug Type: Feature/Change Request Bug description:Option to force PHP to ignore the PASV address returned Description: In response to the PASV command, FTP servers sometimes return their IP address (10.X for example) and PHP honors this IP address, stores it in ftp->pasvaddr and uses that for future connections. This is problematic because PHP won't be able to communicate with a server behind a NAT device using passive FTP. The attached patch adds the USEPASVADDRESS option (a boolean) which can be set and read via the ftp_set_option() and ftp_get_option() functions. USEPASVADDRESS is set to TRUE by default to preserve existing functionality. When USEPASVADDRESS is set to FALSE, the ftp extension will ignore the IP address returned by the PASV command and instead use the IP address passed to ftp_connect() (or ftp_ssl_connect()) In the future we may expand the values to include AUTO which would ignore any RFC 1918 IP addresses returned by the PASV command. The only thing to note is that the call to ftp_set_option() must be made before ftp_pasv() is called. -- Edit bug report at https://bugs.php.net/bug.php?id=55651&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55651&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55651&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55651&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55651&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55651&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55651&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55651&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55651&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55651&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55651&r=support Expected behavior: https://bugs.php.net/fix.php?id=55651&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55651&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55651&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55651&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55651&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55651&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55651&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55651&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55651&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55651&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55651&r=mysqlcfg
Bug #54158 [Ana->Csd]: MYSQLND + PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE
Edit report at https://bugs.php.net/bug.php?id=54158&edit=1
ID: 54158
Updated by: and...@php.net
Reported by:tamas at ideaweb dot hu
Summary:MYSQLND + PDO MySQL requires #define
MYSQL_OPT_LOCAL_INFILE
-Status: Analyzed
+Status: Closed
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.3.5
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-09-02 13:53:30] and...@php.net
Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revision&revision=316039
Log: Fix for Bug #54158 MYSQLND + PDO MySQL requires #define
MYSQL_OPT_LOCAL_INFILE
and a bunch of other small preprocessor fixes
[2011-04-03 03:57:48] anthon dot pang at gmail dot com
Sorry, you're right. My "workaround" is actually because MySQL is compiled
with --enable-local-infile.
[2011-04-03 01:08:09] anthon dot pang at gmail dot com
As a workaround, I use PDO::ATTR_EMULATE_PREPARES. With 5.2.17 and 5.3.6 (using
mysqlndb), both LOAD DATA INFILE and LOAD DATA LOCAL INFILE work on my Ubuntu
10.04 box, using PDO_MYSQL and MYSQLI extensions.
[2011-03-04 10:21:43] and...@php.net
to be fixed after 5.3.6 is released
[2011-03-04 01:18:56] tamas at ideaweb dot hu
Description:
Hi,
On php 5.3.x PDO LOAD DATA LOCAL INFILE support seems broken. Running the code
below issues a warning:
Warning: PDOStatement::execute(): LOAD DATA LOCAL INFILE forbidden in
/home/tamas/percona/load3.php on line 17
This is coming from mysqlnd when CLIENT_LOCAL_FILES option is disabled. Looking
at the trace file, PDO doesn't call mysql_options (set_client_option) to enable
local infile support. I tracked down this is caused by the following ifdef in
ext/pdo_mysql/mysql_driver.c:
#ifdef MYSQL_OPT_LOCAL_INFILE
if (mysql_options(H->server, MYSQL_OPT_LOCAL_INFILE, (const char
*)&local_infile)) {
pdo_mysql_error(dbh);
goto cleanup;
}
#endif
MYSQL_OPT_LOCAL_INFILE is undefined hence the whole block which would enable
local infile support is disabled. When the ifdef/endif line is commented out
everything works. I also tested with mysqli, that is unaffected and works as
expected.
And a related bug to this one: http://bugs.php.net/46964
Configure Command => './configure' '--prefix=/home/tamas/percona/php53dbg'
'--disable-all' '--with-pdo-mysql=mysqlnd' '--enable-debug' '--enable-pdo'
'--with-mysqli=mysqlnd' '--with-mysql=mysqlnd'
Thanks,
Tamas
Test script:
---
define('MYSQL_ALL_DSN','mysql:host=10.8.0.1;dbname=c');
define('MYSQL_ALL_USER','a');
define('MYSQL_ALL_PASS','b');
$sql = 'LOAD DATA LOCAL INFILE \'/home/tamas/percona/testLoad.data\' INTO
TABLE mail_message '.
'FIELDS TERMINATED BY \',\' OPTIONALLY ENCLOSED BY \'"\' LINES TERMINATED
BY \'\n\' '.
'(priority, user_id, `to`, template_id, data, custom_text_hash, spam)';
$con = new PDO(MYSQL_ALL_DSN, MYSQL_ALL_USER, MYSQL_ALL_PASS,
array(
PDO::MYSQL_ATTR_LOCAL_INFILE => 1,
));
$stmt = $con->prepare($sql);
$stmt->execute();
--
Edit this bug report at https://bugs.php.net/bug.php?id=54158&edit=1
Bug #55650 [Opn->Csd]: !empty returns false positive if subkey not set, but not if _GET is set manually
Edit report at https://bugs.php.net/bug.php?id=55650&edit=1
ID: 55650
User updated by:chris dot wisefool at gmail dot com
Reported by:chris dot wisefool at gmail dot com
Summary:!empty returns false positive if subkey not set, but
not if _GET is set manually
-Status: Open
+Status: Closed
Type: Bug
Package:Built-in web server
Operating System: Windows 6.1 build 7600 i586
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
After slightly changing my code example to:
'1');
var_dump($_GET);
if (!empty($_GET['search']['filter']))
echo 'SEARCH FILTER PARAM WAS NOT PROVIDED!';
The results do seem consistent with the behavior as explained in #27677 (I see
that the behavior didn't occur when set manually because I was setting 'search'
to 1 NOT '1' and the subscripting behavior only occurred with strings.
So it seems the behavior is correct per PHP's documentation, just not my
assumptions based on that documentation. It means to test for a subkey you have
to use the longer !empty($_GET['search']) && array_key_exists('filter',
$_GET['search']) && is_array($_GET['search']['filter']), but hey, that's life :)
So I'm closing the bug.
Previous Comments:
[2011-09-09 06:42:33] chris dot wisefool at gmail dot com
Reworded bug summary to be more descriptive and succinct
[2011-09-09 06:39:54] chris dot wisefool at gmail dot com
Either the form munged part of my data (unlikely) or I pasted it in wrong. The
line after
if (!empty($_GET['search']['filter'])) echo 'SEARCH FILTER PARAM WAS PROVIDED!';
should be
$_GET = array('search'=>1);
if (!empty($_GET['search']['filter']))
echo 'SEARCH FILTER PARAM WAS NOT PROVIDED!';
I'd edit it, but it seems you can't: you can only add comments...
[2011-09-09 06:29:54] chris dot wisefool at gmail dot com
Description:
Running on PHP Version 5.3.5, EasyPHP Server Apache.
The test code on my system shows "SEARCH FILTER PARAM WAS PROVIDED" if
?search=1
is passed for the query string but curiously not if ?search[a]=1 is provided.
Based on some other bug reports (#27677) I thought maybe the behavior was
correct,
but if so then it seems a bug that when _GET is manually set to the same value
instead of set by PHP parsing the query string, that it gives different
results.
So it seems a bug either way. :)
Test script:
---
http://somesite/?search=1
if (!empty($_GET['search']['filter'])) echo 'SEARCH FILTER PARAM WAS PROVIDED!';
# The REALLY odd thing is if I do this it does give the expected results:
$_GET
if (!empty($_GET['search']['filter']))
echo 'SEARCH FILTER PARAM WAS NOT PROVIDED!';
1);
var_dump($_GET);
if (!empty($_GET['search']['filter']))
echo 'SEARCH FILTER PARAM WAS NOT PROVIDED!';
Expected result:
SEARCH FILTER PARAM WAS PROVIDED if ?search[filter]=1 provided
No "SEARCH FILTER PARAM WAS PROVIDED" if ?search=1
Actual result:
--
SEARCH FILTER PARAM WAS PROVIDED if ?search=1 or ?search[filter]=1 provided
--
Edit this bug report at https://bugs.php.net/bug.php?id=55650&edit=1
