Bug #51930 [Com]: die() returns exit code 0
Edit report at http://bugs.php.net/bug.php?id=51930&edit=1
ID: 51930
Comment by: smlerman at gmail dot com
Reported by: ml at vulnscan dot org
Summary: die() returns exit code 0
Status: Wont fix
Type: Bug
Package: Unknown/Other Function
Operating System: Linux
PHP Version: 5.3.2
New Comment:
Would it make sense to add an overload that takes two parameters? i.e.
die([string message, [int status = 0]])
Previous Comments:
[2010-05-28 07:49:50] ahar...@php.net
I agree that it doesn't seem terribly logical, but it's been the case
for a good ten years or so at this point, so I can't really see the exit
code changing now.
[2010-05-27 14:15:05] ml at vulnscan dot org
Description:
die() returns exit status 0 (success), which is IMHO illogical.
This mostly matters when using PHP-CLI, for example where you have the
usual:
@mysql_connect(..) or die('sql blahblah');
...in that case a success error code is returned.
I had this in an authentication callback script which returns 0 on user
success and any other value on user failure.
In this case it returned 'success' in case of a SQL server error.
The only workaround I can see is first printing the error message, and
then doing an explicit die/exit with a numerical value. This does not
exactly improve code readability/niceness. And, like I said, I simply
didn't expect die() to return a success exit code.
Test script:
---
Expected result:
I expect a non-zero exit code, instead of 0 (success).
Actual result:
--
Exit status of 0 (success)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51930&edit=1
#47363 [Com]: for($i=4;$i<((func_num_args() + sizeof($array)));$i++) does not work.
ID: 47363
Comment by: smlerman at gmail dot com
Reported By: devilx at devilx dot net
Status: Open
Bug Type: Arrays related
Operating System: Linux, Mac OS X
PHP Version: 5.2.9RC1
New Comment:
Try checking the value of sizeof($wuergs) inside the loop. Hint: it
changes every time.
Previous Comments:
[2009-02-12 04:15:07] devilx at devilx dot net
Description:
The Calculation of sizeof + func_num_args within a for does not work /
ends in an endless-for.
Reproduce code:
---
f("this","is","a","test");
function f()
{
$wuergs = array (
0 => "1234",
1 => "B",
2 => "C",
3 => "D"
);
$args=func_get_args();
for($i=4;$i<((func_num_args() + sizeof($wuergs)));$i++)
{
$wuergs[$i]=$args[$i-4];
}
return l_backend($wuergs);
}
Expected result:
Moving the content of $args four arrays highr.
Actual result:
--
Endless loop.
--
Edit this bug report at http://bugs.php.net/?id=47363&edit=1
#47202 [NEW]: FTP fopen wrapper and # in file names
From: smlerman at gmail dot com
Operating system: Any
PHP version: 5.2.8
PHP Bug Type: FTP related
Bug description: FTP fopen wrapper and # in file names
Description:
It seems that the FTP fopen wrapper truncates file names when it
encounters a pound sign (#). The FTP server's log shows a request for
"file".
I have tried replacing the # with %23 (the result of urlencode), but the
server sees that as a request for "file%231.txt".
Reproduce code:
---
// Use fopen wrapper
$data = file_get_contents("ftp://username:passw...@ftp.example.com/file
#1.txt");
var_dump(strlen($data));
// Use ftp_* functions
$conn = ftp_connect('ftp.example.com');
ftp_login($conn, 'username', 'password');
ftp_get($conn, 'C:\\test.txt', 'file#1.txt', FTP_BINARY);
var_dump(filesize('C:\\test.txt'));
Expected result:
int(7)
int(7)
Actual result:
--
Warning: file_get_contents(ftp://@ftp.example.com/file#1.txt) [function.file-get-contents]: failed
to open stream: FTP server reports 550 /file : The system cannot find the
path specified. in...
int(0)
int(7)
--
Edit bug report at http://bugs.php.net/?id=47202&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47202&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47202&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47202&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47202&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47202&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47202&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47202&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47202&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47202&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47202&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47202&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47202&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47202&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47202&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47202&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47202&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47202&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47202&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47202&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47202&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47202&r=mysqlcfg
#45358 [Com]: var_dump(strtotime('1214431948'));
ID: 45358
Comment by: smlerman at gmail dot com
Reported By: viorel dot irimia at gmail dot com
Status: Open
Bug Type: Date/time related
Operating System: Debian GNU/Linux 4.0
PHP Version: 5.2.6
New Comment:
'1214431948' is being understood as
'HHiiss'
var_dump(date('Y-m-d H:i:s', strtotime('1214431947'))); will show you
what's happening.
Previous Comments:
[2008-06-25 19:50:44] viorel dot irimia at gmail dot com
Description:
It seems that var_dump(strtotime('1214431948')); is returning
int(-678980717) instead timestamp / false / -1
I belive is an overflow somewhere...
Version:
PHP Version 5.2.0-8+etch11
Build Date May 10 2008 10:31:53
Linux 2.6.18-6-686, debian 4.0
Reproduce code:
---
var_dump(strtotime('1214431948'));
var_dump(strtotime('1214431946'));
Expected result:
false | -1
false | -1
Actual result:
--
int(-678980717)
int(-742139117)
--
Edit this bug report at http://bugs.php.net/?id=45358&edit=1
#45319 [Com]: Array's don't convert as per documentation
ID: 45319
Comment by: smlerman at gmail dot com
Reported By: peillert at xs4all dot nl
Status: Open
Bug Type: Variables related
Operating System: Linux
PHP Version: 5.2.6
New Comment:
I'm not sure, but this may be related to a bug I filed a while ago:
http://bugs.php.net/bug.php?id=40692
Previous Comments:
[2008-06-20 01:59:22] peillert at xs4all dot nl
Description:
Array's don't convert as the documentation says and emit's an E_WARNING
upon conversion.
the documentation says that when converting an scalar value to an array
the result will be an array with 1 element, the original scalar value.
however the scalar value is never converted and an E_WARNING is emitted
instead. see code below.
a quote from the documentation:
"For any of the types: integer, float, string, boolean and resource,
converting a value to an array results in an array with a single element
with index zero and the value of the scalar which was converted. In
other words, (array)$scalarValue is exactly the same as
array($scalarValue)."
more interesting is that also the '(array)$scalarValue' does not work
but if the scalar evaluates to NULL such as false or an empty string it
does work. as in the test code i including below only test 2 works as
expected. test 1 emits an E_WARNING and test 3 fails silently.
now either the documentation is out-of-date but i cannot imagine that
this is the intended behaviour. especially test 3 is troublesome as an
explicit cast of any kind should not fail silently.
Reproduce code:
---
Expected result:
//test 1.
bool(true);
array(1) {
[0] =>
bool(true);
[1] =>
string(26) "A new element to the array";
}
//for test 2.
bool(false);
array(1) {
[0] =>
string(26) "A new element to the array";
}
//for test3.
(bool)true;
array(1) {
[0] =>
bool(true);
}
Actual result:
--
Test 1.
bool(true)
Warning: Cannot use a scalar value as an array in array_bug.php on line
6
bool(true)
Test 2.
bool(false)
array(1) {
[0]=>
string(26) "A new element to the array"
}
Test 3.
bool(true)
bool(true)
--
Edit this bug report at http://bugs.php.net/?id=45319&edit=1
#42694 [Com]: decbin() is not returning the correct value
ID: 42694
Comment by: smlerman at gmail dot com
Reported By: carrotcake1029 at gmail dot com
Status: Open
Bug Type: Math related
Operating System: Windows Vista Home Premium
PHP Version: 5.2.4
New Comment:
It's most likely because the number you're using is greater than the
maximum for a 32-bit signed integer, resulting in an integer overflow.
Try it with a smaller number and see what happens.
Previous Comments:
[2007-09-18 07:08:32] carrotcake1029 at gmail dot com
Description:
I wrote my own little function that can take numbers and make turn them
into numbers of other bases. When I ran a few tries with binary, I
began to notice that PHP's decbin() was not matching up with mine.
Easily proven, mine was correct.
Reproduce code:
---
echo dec2base(4728937489, 2) . "\n";
echo decbin(4728937489);
function dec2base($int, $base)
{
while ($int >= 1)
{
$ret .= $int % $base;
$int = $int / $base;
}
return strrev($ret);
}
Expected result:
10001100111011101110111010001
10001100111011101110111010001
Actual result:
--
10001100111011101110111010001
1100111011101110111010001
--
Edit this bug report at http://bugs.php.net/?id=42694&edit=1
#42152 [Com]: Operator Precedence: postincrement before '['
ID: 42152
Comment by: smlerman at gmail dot com
Reported By: php at tfwasmus dot enschedenet dot nl
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Windows Xp x64
PHP Version: 5CVS-2007-07-30 (snap)
New Comment:
Last I knew, using a variable that you post-increment (and maybe
pre-increment, can't remember for sure) elsewhere in the same statement
results in undefined behavior.
Previous Comments:
[2007-07-31 11:33:46] [EMAIL PROTECTED]
Either I missed something but = has lower precedence than [ ?
[2007-07-30 23:26:44] php at tfwasmus dot enschedenet dot nl
Description:
According to the operator precedence
(http://www.php.net/manual/en/language.operators.php#language.operators.precedence),
a (post)increment should be evalued after the '['.
It seems that isn't true in assigning to an array in PHP5 anymore,
while it was in PHP4. Latest snapshots of both checked (30-07-2007).
This could also be a documentation problem.
Reproduce code:
---
Expected result:
array(1) {
[1]=>
int(1)
}
int(2)
Actual result:
--
array(1) {
[2]=>
int(1)
}
int(2)
--
Edit this bug report at http://bugs.php.net/?id=42152&edit=1
#41401 [Com]: Order of Operations error on divide by negative
ID: 41401 Comment by: smlerman at gmail dot com Reported By: drlippman at yahoo dot com Status: Open Bug Type: Math related Operating System: Windows, Linux PHP Version: 4.4.7 New Comment: Looks like a problem with the parsing of unary negation. Previous Comments: [2007-05-16 18:24:03] [EMAIL PROTECTED] This IS a bug. http://de.php.net/operators lists unary - having higher precedence than the arithmetic operators, and that is the way it should be. So, this statement should evaluate to 1/(-2)*5 and that is -2.5 and not -0.1. [2007-05-16 12:50:59] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. [2007-05-15 15:44:07] drlippman at yahoo dot com Description: Left-to-right order of operations does not appear to be honored when dividing by a negative Reproduce code: --- 1/-2*5 Expected result: -2.5 Actual result: -- -.1 -- Edit this bug report at http://bugs.php.net/?id=41401&edit=1
#40968 [Com]: Multiple intances of a singleton class when stored in session
ID: 40968
Comment by: smlerman at gmail dot com
Reported By: oriol dot gual at gmail dot com
Status: Open
Bug Type: Session related
Operating System: Windows XP SP2
PHP Version: 5.2.1
New Comment:
The only thing that can guarantee only one instance of your class
existing is that Singleton::$instance is the only place you store an
instance and getInstance() is the only way to retrieve an instance. Once
you create a second place that an instance can be stored, such as
storing an instance somewhere else (in the session data) and destroying
the instance in the static property (which happens when the script
ends), you create a second way to retrieve an entirely different
instance. In general, there's no 100% guaranteed way to ensure that only
one instance of a given class can ever exist.
Previous Comments:
[2007-04-01 01:42:08] b dot fore at mail dot com
That's a gross abuse of ext/session dude.
[2007-03-31 16:54:52] oriol dot gual at gmail dot com
Description:
When storing an object of a singleton class in the session, you can
have more than one instance of that class in other subsequent
executions.
Reproduce code:
---
class Singleton {
private static $instance;
private function __construct() {}
final public static function getInstance()
{
if (!isset(Singleton::$instance))
{
Singleton::$instance = &new Singleton;
}
return Singleton::$instance;
}
}
session_start();
if(!isset($_SESSION['singleton'])) $_SESSION['singleton'] =
Singleton::getInstance();
$test = Singleton::getInstance();
$anotherTest = Singleton::getInstance();
var_dump(Singleton::getInstance() === $test);
var_dump(Singleton::getInstance() === $anotherTest);
var_dump($test === $anotherTest);
var_dump(Singleton::getInstance() === $_SESSION['singleton']);
var_dump($test === $_SESSION['singleton']);
var_dump($anotherTest === $_SESSION['singleton']);
session_write_close();
Expected result:
Session not started (first execution)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
Subsequent executions
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
Actual result:
--
Session not started (first execution it's OK)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
Subsequent executions (fails, multiple instances)
bool(true)
bool(true)
bool(true)
bool(false)
bool(false)
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=40968&edit=1
#40961 [Com]: problem with preg_replace and preg_match functions
ID: 40961
Comment by: smlerman at gmail dot com
Reported By: jfgingras at cegep-ste-foy dot qc dot ca
Status: Open
Bug Type: *Regular Expressions
Operating System: FreeBSD 6.1-RELEASE
PHP Version: 5.2.1
New Comment:
$body = "b2c3d4e5f6a7b8c9e0f1a2b3c4d5e6f7";
$body = preg_replace('/(^[a-f0-9]{32}$)/', '?', $body );
var_dump($body);
string(1) "?"
That's what I get in 5.1.6 on Linux and 5.2.1 on Windows.
Previous Comments:
[2007-03-30 17:30:43] jfgingras at cegep-ste-foy dot qc dot ca
Description:
I can't use full PCRE in preg_replace and preg_match functions.
If I do:
$body = "b2c3d4e5f6a7b8c9e0f1a2b3c4d5e6f7";
$body = preg_replace('/(^[a-f0-9]{32}$)/', '?', $body );
preg_replace() return en empty string instead of "?" or the original
string if the regex doesn't match as the documentation says.
But, if I use this:
$body = "b2c3d4e5f6a7b8c9e0f1a2b3c4d5e6f7";
$body = preg_replace('^[a-f0-9]{32}$', '?', $body );
It works!!
I got the same problem with preg_match, it always return false.
--
Edit this bug report at http://bugs.php.net/?id=40961&edit=1
#40692 [Opn]: Trying to use boolean as array doesn't give an error
ID: 40692
User updated by: smlerman at gmail dot com
Reported By: smlerman at gmail dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Any
PHP Version: 5.2.1
New Comment:
Here's another test case that shows that something isn't quite right
with implicit conversions.
Results:
int(8191)
NULL
NULL
string(1) "1"
int(12345)
So $a isn't being converted to a string or array if you do $a[0]. It
also isn't converted to a string if you do $a{0}, and I have no idea
what else it could reasonably convert to. I never rely on these
implicit conversions, so I have no real personal interest in whether
the behavior stays the same as it is now or if the conversions are
fixed, but some kind of error message, even a notice for an undefined
index for something like $a['foo'], would help with debugging this kind
of programmer mistake.
Previous Comments:
----
[2007-03-05 00:22:42] smlerman at gmail dot com
Actually, as my code shows, you do not get false, you get NULL, so it's
obviously not doing a normal conversion to an array. I'm not disputing
the value of the expression, since it makes perfect sense to me that
the value of a non-existent variable should be NULL. In all other
cases, though, it also gives a notice, which is what would be nice to
have.
[2007-03-05 00:10:28] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
(string)false == ""
"" does not have offset 0 and therefor you get a warning message.
(array)false == array(0 => false);
and when you access element 0 of this array you get false in return.
----------------
[2007-03-03 16:57:17] smlerman at gmail dot com
Yeah, in 6 years of programming PHP, I never noticed that it isn't a
strictly typed language. Trying to use an undefined offset of an array
gives an error message. Trying to use a non-existant character index of
a string gives an error message. So what is the boolean being converted
to such that using an incorrect offset isn't an error?
[2007-03-03 15:58:22] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
PHP is not type strict.
----------------
[2007-03-02 16:20:40] smlerman at gmail dot com
Description:
If you try to use a boolean as an array (which most likely means an
error occurred somewhere), the value is correctly returned as NULL, but
no error message is reported. Obviously not a major problem, but it
would make debugging a little easier.
Reproduce code:
---
Expected result:
int(8191)
[Something like] Notice: Cannot use boolean as array in C:\Documents
and Settings\...\boolean_array.php on line 5
NULL
Notice: Uninitialized string offset: 0 in C:\Documents and
Settings\...\boolean_array.php on line 8
string(0) ""
Actual result:
--
int(8191)
NULL
Notice: Uninitialized string offset: 0 in C:\Documents and
Settings\Scott\My Documents\Test Files\boolean_array.php on line 8
string(0) ""
--
Edit this bug report at http://bugs.php.net/?id=40692&edit=1
#40692 [Bgs->Opn]: Trying to use boolean as array doesn't give an error
ID: 40692 User updated by: smlerman at gmail dot com Reported By: smlerman at gmail dot com -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: Any PHP Version: 5.2.1 New Comment: Actually, as my code shows, you do not get false, you get NULL, so it's obviously not doing a normal conversion to an array. I'm not disputing the value of the expression, since it makes perfect sense to me that the value of a non-existent variable should be NULL. In all other cases, though, it also gives a notice, which is what would be nice to have. Previous Comments: [2007-03-05 00:10:28] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php (string)false == "" "" does not have offset 0 and therefor you get a warning message. (array)false == array(0 => false); and when you access element 0 of this array you get false in return. ---- [2007-03-03 16:57:17] smlerman at gmail dot com Yeah, in 6 years of programming PHP, I never noticed that it isn't a strictly typed language. Trying to use an undefined offset of an array gives an error message. Trying to use a non-existant character index of a string gives an error message. So what is the boolean being converted to such that using an incorrect offset isn't an error? [2007-03-03 15:58:22] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php PHP is not type strict. -------- [2007-03-02 16:20:40] smlerman at gmail dot com Description: If you try to use a boolean as an array (which most likely means an error occurred somewhere), the value is correctly returned as NULL, but no error message is reported. Obviously not a major problem, but it would make debugging a little easier. Reproduce code: --- Expected result: int(8191) [Something like] Notice: Cannot use boolean as array in C:\Documents and Settings\...\boolean_array.php on line 5 NULL Notice: Uninitialized string offset: 0 in C:\Documents and Settings\...\boolean_array.php on line 8 string(0) "" Actual result: -- int(8191) NULL Notice: Uninitialized string offset: 0 in C:\Documents and Settings\Scott\My Documents\Test Files\boolean_array.php on line 8 string(0) "" -- Edit this bug report at http://bugs.php.net/?id=40692&edit=1
#40692 [Bgs->Opn]: Trying to use boolean as array doesn't give an error
ID: 40692 User updated by: smlerman at gmail dot com Reported By: smlerman at gmail dot com -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: Any PHP Version: 5.2.1 New Comment: Yeah, in 6 years of programming PHP, I never noticed that it isn't a strictly typed language. Trying to use an undefined offset of an array gives an error message. Trying to use a non-existant character index of a string gives an error message. So what is the boolean being converted to such that using an incorrect offset isn't an error? Previous Comments: [2007-03-03 15:58:22] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php PHP is not type strict. [2007-03-02 16:20:40] smlerman at gmail dot com Description: If you try to use a boolean as an array (which most likely means an error occurred somewhere), the value is correctly returned as NULL, but no error message is reported. Obviously not a major problem, but it would make debugging a little easier. Reproduce code: --- Expected result: int(8191) [Something like] Notice: Cannot use boolean as array in C:\Documents and Settings\...\boolean_array.php on line 5 NULL Notice: Uninitialized string offset: 0 in C:\Documents and Settings\...\boolean_array.php on line 8 string(0) "" Actual result: -- int(8191) NULL Notice: Uninitialized string offset: 0 in C:\Documents and Settings\Scott\My Documents\Test Files\boolean_array.php on line 8 string(0) "" -- Edit this bug report at http://bugs.php.net/?id=40692&edit=1
#40692 [NEW]: Trying to use boolean as array doesn't give an error
From: smlerman at gmail dot com Operating system: Any PHP version: 5.2.1 PHP Bug Type: Scripting Engine problem Bug description: Trying to use boolean as array doesn't give an error Description: If you try to use a boolean as an array (which most likely means an error occurred somewhere), the value is correctly returned as NULL, but no error message is reported. Obviously not a major problem, but it would make debugging a little easier. Reproduce code: --- Expected result: int(8191) [Something like] Notice: Cannot use boolean as array in C:\Documents and Settings\...\boolean_array.php on line 5 NULL Notice: Uninitialized string offset: 0 in C:\Documents and Settings\...\boolean_array.php on line 8 string(0) "" Actual result: -- int(8191) NULL Notice: Uninitialized string offset: 0 in C:\Documents and Settings\Scott\My Documents\Test Files\boolean_array.php on line 8 string(0) "" -- Edit bug report at http://bugs.php.net/?id=40692&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40692&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40692&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40692&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40692&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40692&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40692&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40692&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40692&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40692&r=support Expected behavior:http://bugs.php.net/fix.php?id=40692&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40692&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40692&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40692&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40692&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40692&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40692&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40692&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40692&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40692&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40692&r=mysqlcfg
#39450 [Com]: getenv() fills $_POST-Array
ID: 39450
Comment by: smlerman at gmail dot com
Reported By: patrik dot mayer at i12 dot de
Status: Open
Bug Type: Unknown/Other Function
Operating System: SuSE 10, 2.6.13-15.12-smp
PHP Version: 5.2.0
New Comment:
Confirmed on Windows XP Professional.
register_globals = Off
register_long_arrays = Off
variables_order = GPCS
Changing variables_order to EGPCS does seem to fix the problem.
Previous Comments:
[2006-12-21 17:06:27] fugacityguy-developer at yahoo dot com
I am getting a similar behavior where calling getenv() is populating
the $_FILES global:
\n";
$h = getenv('DOCUMENT_ROOT');
var_dump($_FILES);
?>
yields:
array(0) { } array(0) { }
array(1) { ["DOCUMENT_ROOT"]=> string(26) "/usr/csite/WebServer/html/"
}
This is PHP 5.2.0 on Redhat Enterprise Linux 4.
[2006-12-15 22:14:29] balue at gmail dot com
I'm experiencing the same issue as well using:
Apache 1.3.37
PHP 5.2
FreeBSD 4.11 (most current patches)
This did not happen in 5.1.6. And Yes, changing the variable_order to
EGPCS fixed it as well.
[2006-11-27 14:52:26] patrik dot mayer at i12 dot de
Hi,
sorry for not getting back soon.
I've emailed our phpinfo() to tony2001 (at) php (dot) net.
Hopefully you can see anything where the behavior could come from.
At the moment we are fine by setting variables_order from GPCS to
EGPCS.
Big thnx from germany.
[2006-11-20 13:26:37] [EMAIL PROTECTED]
Well, we still have not idea how to reproduce this.
Please show your phpinfo().
[2006-11-20 13:21:54] patrik dot mayer at i12 dot de
Nope, there are non loaded.
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/39450
--
Edit this bug report at http://bugs.php.net/?id=39450&edit=1
#39923 [Bgs]: Undefined constants IMG_PNG, IMG_JPG, IMG_GIF
ID: 39923 User updated by: smlerman at gmail dot com Reported By: smlerman at gmail dot com Status: Bogus Bug Type: GD related Operating System: Windows PHP Version: 5.2.0 New Comment: Yeah, that's what made me think they had maybe been deprecated. Also, the IMAGETYPE_ constants seemed to work fine, and I assumed that those were also defined in GD. Previous Comments: [2006-12-21 14:57:12] [EMAIL PROTECTED] This is impossible. These constants are defined in GD extension and if they are not, then the extension is missing. [2006-12-21 14:55:04] smlerman at gmail dot com Weird, I can't reproduce it now. The original error message was "[21-Dec-2006 09:13:50] PHP Notice: Use of undefined constant IMG_PNG - assumed 'IMG_PNG' in...", but all of the images that should be on the page showed up fine. Might have been a glitch with the 5.2.0 upgrade process. I'll reopen if I manage to reproduce. ---- [2006-12-21 14:42:36] smlerman at gmail dot com Nope, GD is enabled and working fine. GD Support enabled GD Version bundled (2.0.28 compatible) FreeType Supportenabled FreeType Linkagewith freetype FreeType Version2.1.9 T1Lib Support enabled GIF Read Supportenabled GIF Create Support enabled JPG Support enabled PNG Support enabled WBMP Supportenabled XBM Support enabled (Sorry about the summary. Browser must have auto-filled it without my noticing) [2006-12-21 14:35:32] [EMAIL PROTECTED] IMG_* constants are defined in GD which is obviously not enabled in your installation. ---- [2006-12-21 14:33:21] smlerman at gmail dot com Description: The constants IMG_PNG, IMG_JPG, and IMG_GIF are reported as undefined. IMAGETYPE_PNG, IMAGETYPE_JPEG, and IMAGETYPE_GIF all work fine. If the IMG_ constants were removed intentionally in favor of the IMAGETYPE_ constants, this is just a documentation issue. Reproduce code: --- Expected result: 3 2 1 3 2 1 Actual result: -- Notice: Use of undefined constant IMG_PNG - assumed 'IMG_PNG' in test.php on line 3 IMG_PNG Notice: Use of undefined constant IMG_JPG - assumed 'IMG_JPG' in test.php on line 4 IMG_JPG Notice: Use of undefined constant IMG_GIF - assumed 'IMG_GIF' in test.php on line 5 IMG_GIF 3 2 1 -- Edit this bug report at http://bugs.php.net/?id=39923&edit=1
#39923 [Opn->Bgs]: Undefined constants IMG_PNG, IMG_JPG, IMG_GIF
ID: 39923 User updated by: smlerman at gmail dot com Reported By: smlerman at gmail dot com -Status: Open +Status: Bogus Bug Type: GD related Operating System: Windows PHP Version: 5.2.0 New Comment: Weird, I can't reproduce it now. The original error message was "[21-Dec-2006 09:13:50] PHP Notice: Use of undefined constant IMG_PNG - assumed 'IMG_PNG' in...", but all of the images that should be on the page showed up fine. Might have been a glitch with the 5.2.0 upgrade process. I'll reopen if I manage to reproduce. Previous Comments: ---- [2006-12-21 14:42:36] smlerman at gmail dot com Nope, GD is enabled and working fine. GD Support enabled GD Version bundled (2.0.28 compatible) FreeType Supportenabled FreeType Linkagewith freetype FreeType Version2.1.9 T1Lib Support enabled GIF Read Supportenabled GIF Create Support enabled JPG Support enabled PNG Support enabled WBMP Supportenabled XBM Support enabled (Sorry about the summary. Browser must have auto-filled it without my noticing) [2006-12-21 14:35:32] [EMAIL PROTECTED] IMG_* constants are defined in GD which is obviously not enabled in your installation. ---- [2006-12-21 14:33:21] smlerman at gmail dot com Description: The constants IMG_PNG, IMG_JPG, and IMG_GIF are reported as undefined. IMAGETYPE_PNG, IMAGETYPE_JPEG, and IMAGETYPE_GIF all work fine. If the IMG_ constants were removed intentionally in favor of the IMAGETYPE_ constants, this is just a documentation issue. Reproduce code: --- Expected result: 3 2 1 3 2 1 Actual result: -- Notice: Use of undefined constant IMG_PNG - assumed 'IMG_PNG' in test.php on line 3 IMG_PNG Notice: Use of undefined constant IMG_JPG - assumed 'IMG_JPG' in test.php on line 4 IMG_JPG Notice: Use of undefined constant IMG_GIF - assumed 'IMG_GIF' in test.php on line 5 IMG_GIF 3 2 1 -- Edit this bug report at http://bugs.php.net/?id=39923&edit=1
#39923 [Bgs->Opn]: Undefined constants IMG_PNG, IMG_JPG, IMG_GIF
ID: 39923 User updated by: smlerman at gmail dot com -Summary: Somewhat misleading notice message with type conversions Reported By: smlerman at gmail dot com -Status: Bogus +Status: Open Bug Type: GD related Operating System: Windows PHP Version: 5.2.0 New Comment: Nope, GD is enabled and working fine. GD Support enabled GD Version bundled (2.0.28 compatible) FreeType Supportenabled FreeType Linkagewith freetype FreeType Version2.1.9 T1Lib Support enabled GIF Read Supportenabled GIF Create Support enabled JPG Support enabled PNG Support enabled WBMP Supportenabled XBM Support enabled (Sorry about the summary. Browser must have auto-filled it without my noticing) Previous Comments: [2006-12-21 14:35:32] [EMAIL PROTECTED] IMG_* constants are defined in GD which is obviously not enabled in your installation. [2006-12-21 14:33:21] smlerman at gmail dot com Description: The constants IMG_PNG, IMG_JPG, and IMG_GIF are reported as undefined. IMAGETYPE_PNG, IMAGETYPE_JPEG, and IMAGETYPE_GIF all work fine. If the IMG_ constants were removed intentionally in favor of the IMAGETYPE_ constants, this is just a documentation issue. Reproduce code: --- Expected result: 3 2 1 3 2 1 Actual result: -- Notice: Use of undefined constant IMG_PNG - assumed 'IMG_PNG' in test.php on line 3 IMG_PNG Notice: Use of undefined constant IMG_JPG - assumed 'IMG_JPG' in test.php on line 4 IMG_JPG Notice: Use of undefined constant IMG_GIF - assumed 'IMG_GIF' in test.php on line 5 IMG_GIF 3 2 1 -- Edit this bug report at http://bugs.php.net/?id=39923&edit=1
#39923 [NEW]: Somewhat misleading notice message with type conversions
From: smlerman at gmail dot com Operating system: Windows PHP version: 5.2.0 PHP Bug Type: GD related Bug description: Somewhat misleading notice message with type conversions Description: The constants IMG_PNG, IMG_JPG, and IMG_GIF are reported as undefined. IMAGETYPE_PNG, IMAGETYPE_JPEG, and IMAGETYPE_GIF all work fine. If the IMG_ constants were removed intentionally in favor of the IMAGETYPE_ constants, this is just a documentation issue. Reproduce code: --- Expected result: 3 2 1 3 2 1 Actual result: -- Notice: Use of undefined constant IMG_PNG - assumed 'IMG_PNG' in test.php on line 3 IMG_PNG Notice: Use of undefined constant IMG_JPG - assumed 'IMG_JPG' in test.php on line 4 IMG_JPG Notice: Use of undefined constant IMG_GIF - assumed 'IMG_GIF' in test.php on line 5 IMG_GIF 3 2 1 -- Edit bug report at http://bugs.php.net/?id=39923&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39923&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39923&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39923&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39923&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39923&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39923&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39923&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39923&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39923&r=support Expected behavior:http://bugs.php.net/fix.php?id=39923&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39923&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39923&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39923&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39923&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39923&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39923&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39923&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39923&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39923&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39923&r=mysqlcfg
#39922 [Com]: array_search returns incorrect position after array_push or array_unshift
ID: 39922
Comment by: smlerman at gmail dot com
Reported By: willem at fkkc dot nl
Status: Open
Bug Type: Scripting Engine problem
Operating System: Debian
PHP Version: 5.2.0
New Comment:
Fix your error_reporting and/or display_errors settings.
Warning: Wrong parameter count for array_search() in ... on line 4
http://www.php.net/manual/en/function.array-search.php
Previous Comments:
[2006-12-21 11:40:41] willem at fkkc dot nl
Description:
array_search returns incorrect position-value when an array is modified
with array_push or array_unshift
Reproduce code:
---
$array = array('a1','b2','c3');
array_unshift($array,'d4');
$pos = array_search('d4');
if($pos === FALSE){
print implode(',',$array);
}else{
print 'Position = '.$pos;
}
Expected result:
Position = 0
Actual result:
--
d4,a1,b2,c3
--
Edit this bug report at http://bugs.php.net/?id=39922&edit=1
#39834 [Com]: PHP not recognizing php.ini changes
ID: 39834 Comment by: smlerman at gmail dot com Reported By: nicole at antfarminteractive dot com Status: Open Bug Type: Unknown/Other Function Operating System: Windows 2000 PHP Version: 5.2.0 New Comment: The configuration path shown in phpinfo() is where PHP looks for php.ini. PHP does not use the PATH environment variable to find php.ini. I know there's an Apache configuration directive PHPIniDir to change the path, but I don't know if there's an equivalent for IIS. The list of places that PHP looks for php.ini can be found in the manual: http://www.php.net/manual/en/configuration.php#configuration.file Previous Comments: [2006-12-14 19:24:57] nicole at antfarminteractive dot com Description: I have a Windows 2000 web server that is using IIS, as well as a SMTP virtual server. I have updated the "sendmail_from" option within the php.ini file, and the server has been restarted numerous times. PHP is installed within the "C:\php" directory. For some reason, the phpinfo() file shows the PHP configuration path as "C:\winnt", despite the fact that I have added the ";c:\php" directory within the server's environment variables (the one for PATH). Also, the "sendmail_from" area shows "no value", although the php.ini file does not reflect this. I have searched everywhere and cannot resolve this. Why is PHP failing to recognize the PHP.ini file? Reproduce code: --- [mail function] ; For Win32 only. SMTP = localhost smtp_port = 25 ; For Win32 only. sendmail_from = [client [EMAIL PROTECTED] domain].com -- Edit this bug report at http://bugs.php.net/?id=39834&edit=1
#39823 [Com]: DOMDocument::load() trims off end of include path
ID: 39823 Comment by: smlerman at gmail dot com Reported By: esayre at olemiss dot edu Status: Feedback Bug Type: DOM XML related Operating System: Red Hat Enterprise Linux 3 PHP Version: 5.2.0 New Comment: Unless it has changed in 5.2, DOMDocument->load() doesn't use include_path. You have to give it an absolute path or a path relative to the current working directory. Previous Comments: [2006-12-14 05:42:12] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2006-12-13 22:59:01] esayre at olemiss dot edu Description: While trying to load an XML document into a PHP script that runs through the CLI I ran into the following error. PHP Warning: DOMDocument::load(): I/O warning : failed to load external entity "/var/www/GrahamCracker/FARIntegration/ ORSPRequestTemplate.xml" in /var/www/code/GrahamCracker/ FARIntegration/SynchronizeDatabases.php on line 126 PHP Fatal error: Call to a member function appendChild() on a non-object in /var/www/code/GrahamCracker/FARIntegration/ SynchronizeDatabases.php on line 132 The include path was set properly as "/var/www/code" but the DOMDocument::load() method tried to use "/var/www" which is not listed in the include path. Actual result: -- PHP Warning: DOMDocument::load(): I/O warning : failed to load external entity "/var/www/GrahamCracker/FARIntegration/ ORSPRequestTemplate.xml" in /var/www/code/GrahamCracker/ FARIntegration/SynchronizeDatabases.php on line 126 PHP Fatal error: Call to a member function appendChild() on a non-object in /var/www/code/GrahamCracker/FARIntegration/ SynchronizeDatabases.php on line 132 -- Edit this bug report at http://bugs.php.net/?id=39823&edit=1
#38907 [NEW]: Somewhat misleading notice message with type conversions
From: smlerman at gmail dot com Operating system: Windows (presumably others) PHP version: 5.1.6 PHP Bug Type: Variables related Bug description: Somewhat misleading notice message with type conversions Description: If you try to compare an object to a string, the error message says that the object could not be converted to an int. It makes it a little more difficult to debug code when you're looking for a comparison involving an integer instead of a string. Nothing really major, but a would-be-nice kind of fix. Reproduce code: --- Expected result: Notice: Object of class Foo could not be converted to string in int_convert.php on line 7 Actual result: -- Notice: Object of class Foo could not be converted to int in int_convert.php on line 7 -- Edit bug report at http://bugs.php.net/?id=38907&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38907&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38907&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38907&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38907&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38907&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38907&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38907&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38907&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38907&r=support Expected behavior:http://bugs.php.net/fix.php?id=38907&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38907&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38907&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38907&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38907&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38907&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38907&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38907&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38907&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38907&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38907&r=mysqlcfg
#37813 [Com]: Max_execution_time ignored
ID: 37813 Comment by: smlerman at gmail dot com Reported By: stefan dot glaesser at gmail dot com Status: Open Bug Type: CGI related Operating System: Debian Sarge PHP Version: 5.1.4 New Comment: May be related to http://bugs.php.net/bug.php?id=37408 Previous Comments: [2006-06-15 10:19:07] stefan dot glaesser at gmail dot com Description: using: PHP 5.1.4-0.1 (cli) (built: Jun 13 2006 21:46:20) Running a larger PHP-Script on commandline stops after max_execution_time of 60 seconds. The configuration value in /etc/php5/cli/php.ini is completly ignored. Reproduce code: --- #!/usr/bin/php5 -q -- Edit this bug report at http://bugs.php.net/?id=37813&edit=1
#37361 [Com]: prepare statement alter the datatype of a parameter
ID: 37361
Comment by: smlerman at gmail dot com
Reported By: axel dot azerty at laposte dot net
Status: Open
Bug Type: PDO related
Operating System: Fedora Core 5 - Linux 2.6.16
PHP Version: 5.1.4
New Comment:
bindParam and bindValue treat the parameter as a string by default,
which means the value has special characters escaped and the entire
value quoted. Your code produces COALESCE(MAX('id_board'),0), which is
probably not what you want. You'll most likely need to place the field
name directly in the query instead of trying to bind it as if it were
normal data.
Previous Comments:
[2006-05-08 07:01:03] axel dot azerty at laposte dot net
Description:
The prepared statement in PDO seems to lost or to have its type
altered.
When typing a 'SELECT COALESCE(MAX(field),0) FROM table' under
postgresql shell, no problem.
When using this query as is in PHP (with PDO), no problem.
When trying SELECT COALESCE(MAX(?),0) FROM table as a prepared
statement, the execution fails.
Replacing "MAX(?),0" by "MAX(?),'0'" solves the problem, but the
returned value is a string, and not an integer.
Reproduce code:
---
$stmt = $dbh->prepare("SELECT COALESCE(MAX(?),0) FROM board");
$stmt->bindParam(1,$fld);
$fld = "id_board";
if(!$stmt->execute()) print_r($stmt->errorInfo());
Expected result:
The expected result is "0" , in the case or the table is empty or the
number of lines in the table.
Actual result:
--
The statement->errorInfo() returns :
Array
(
[0] => 42804
[1] => 7
[2] => ERREUR: Les COALESCE types text et integer ne peuvent pas
correspondre
)
In english : "the COALESCE types text and interger can't match".
--
Edit this bug report at http://bugs.php.net/?id=37361&edit=1
#37285 [Com]: PDOConnection->exec fails silently
ID: 37285
Comment by: smlerman at gmail dot com
Reported By: vldi at yahoo dot com
Status: Assigned
Bug Type: PDO related
Operating System: Suse 10
PHP Version: 5CVS-2006-05-02 (snap)
Assigned To: wez
New Comment:
Well, I found the problem with my code.
$stmt->bindValue(':something', $some_array, PDO::PARAM_INT);
Obviously, trying to bind an array as an integer doesn't work too well.
Some type of error message/exception would be nice to see though.
Previous Comments:
[2006-05-04 14:59:14] smlerman at gmail dot com
5.1.2 using MySQL.
This also appears to be a problem with prepared queries.
$stmt->execute() returns false, but no exception is raised. Both
$db->errorInfo() and $stmt->errorInfo() show no error (code '0').
The database log shows the query being prepared, but doesn't show the
execution attempt.
$res = $stmt->execute();
echo ""; var_dump($res, $stmt->errorInfo(), $db->errorInfo());
echo "";
bool(false)
array(1) {
[0]=>
string(5) "0"
}
array(1) {
[0]=>
string(5) "0"
}
[2006-05-02 21:05:00] vldi at yahoo dot com
Description:
PDO does not raise the exception when SQL fails.
Config is: './configure' '--prefix=/usr/local/php5' '--with-openssl'
'--with-kerberos' '--with-zlib' '--with-bz2' '--enable-calendar'
'--with-curl' '--with-curlwrappers' '--enable-exif' '--enable-ftp'
'--with-gettext' '--with-ldap' '--with-ldap-sasl'
'--with-mssql=/usr/local/freetds' '--with-mysql' '--with-mysql-sock'
'--with-mysqli' '--with-unixODBC=/usr' '--with-pdo-mysql'
'--with-pdo-odbc=unixODBC,/usr' '--enable-sockets' '--enable-sysvmsg'
'--enable-sysvsem' '--enable-sysvshm' '--with-xsl' '--with-pear'
'--disable-cgi' '--with-apxs2=/usr/local/apache2/bin/apxs'
'--with-config-file-path=/etc/php.ini' '--enable-debug'
Reproduce code:
---
No DBH";
die();
};
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$dbh->exec("
create procedure pdotest
@param_in int = null,
@param_out int output
as
set @param_out = @param_in
go
");
} catch ( PDOException $e ) {
print "Failed: ".$e->getMessage()."";
die();
}
?>
Succedeed
Expected result:
Expect to either see the new procedure created, or exception raised.
Actual result:
--
The page displays "Succeesed", yet no procedure created in the
database.
--
Edit this bug report at http://bugs.php.net/?id=37285&edit=1
#37285 [Com]: PDOConnection->exec fails silently
ID: 37285
Comment by: smlerman at gmail dot com
Reported By: vldi at yahoo dot com
Status: Assigned
Bug Type: PDO related
Operating System: Suse 10
PHP Version: 5CVS-2006-05-02 (snap)
Assigned To: wez
New Comment:
5.1.2 using MySQL.
This also appears to be a problem with prepared queries.
$stmt->execute() returns false, but no exception is raised. Both
$db->errorInfo() and $stmt->errorInfo() show no error (code '0').
The database log shows the query being prepared, but doesn't show the
execution attempt.
$res = $stmt->execute();
echo ""; var_dump($res, $stmt->errorInfo(), $db->errorInfo());
echo "";
bool(false)
array(1) {
[0]=>
string(5) "0"
}
array(1) {
[0]=>
string(5) "0"
}
Previous Comments:
[2006-05-02 21:05:00] vldi at yahoo dot com
Description:
PDO does not raise the exception when SQL fails.
Config is: './configure' '--prefix=/usr/local/php5' '--with-openssl'
'--with-kerberos' '--with-zlib' '--with-bz2' '--enable-calendar'
'--with-curl' '--with-curlwrappers' '--enable-exif' '--enable-ftp'
'--with-gettext' '--with-ldap' '--with-ldap-sasl'
'--with-mssql=/usr/local/freetds' '--with-mysql' '--with-mysql-sock'
'--with-mysqli' '--with-unixODBC=/usr' '--with-pdo-mysql'
'--with-pdo-odbc=unixODBC,/usr' '--enable-sockets' '--enable-sysvmsg'
'--enable-sysvsem' '--enable-sysvshm' '--with-xsl' '--with-pear'
'--disable-cgi' '--with-apxs2=/usr/local/apache2/bin/apxs'
'--with-config-file-path=/etc/php.ini' '--enable-debug'
Reproduce code:
---
No DBH";
die();
};
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$dbh->exec("
create procedure pdotest
@param_in int = null,
@param_out int output
as
set @param_out = @param_in
go
");
} catch ( PDOException $e ) {
print "Failed: ".$e->getMessage()."";
die();
}
?>
Succedeed
Expected result:
Expect to either see the new procedure created, or exception raised.
Actual result:
--
The page displays "Succeesed", yet no procedure created in the
database.
--
Edit this bug report at http://bugs.php.net/?id=37285&edit=1
#37174 [Com]: bindvalue doing segfault (pdo_pgsql)
ID: 37174
Comment by: smlerman at gmail dot com
Reported By: xcenti at gmail dot com
Status: Feedback
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.2
New Comment:
Not sure if it's directly related, but I noticed the duplicate names
for the parameters and remembered having a similar problem. See http://bugs.php.net/bug.php?id=35604";>Bug #35604
Previous Comments:
[2006-04-23 20:00:22] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-04-23 19:46:48] xcenti at gmail dot com
Description:
segfault under Linux in PHP 5.1.2 and 5.1.3RC4-dev (under Windows with
PHP 5.1.2 no problem)
Reproduce code:
---
prepare('SELECT :name, :name');
$stmt->bindValue(':name', 'foo');
$stmt->execute();
?>
Expected result:
all, but not crash
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1424372816 (LWP 10842)]
0xb7b189b0 in mallopt () from /lib/tls/libc.so.6
(gdb) bt
#0 0xb7b189b0 in mallopt () from /lib/tls/libc.so.6
#1 0xb7b17c43 in malloc () from /lib/tls/libc.so.6
#2 0xb74501c6 in initPQExpBuffer () from /usr/lib/libpq.so.4
#3 0xb744ec89 in pqGetErrorNotice3 () from /usr/lib/libpq.so.4
#4 0xb744e3f0 in pqParseInput3 () from /usr/lib/libpq.so.4
#5 0xb74472d9 in PQconsumeInput () from /usr/lib/libpq.so.4
#6 0xb7447461 in PQgetResult () from /usr/lib/libpq.so.4
#7 0xb74477bb in PQexecPrepared () from /usr/lib/libpq.so.4
#8 0xb7680e4f in pgsql_stmt_execute (stmt=0x840f768,
tsrm_ls=0x82a9218) at
/root/php5.1-200604230030/ext/pdo_pgsql/pgsql_statement.c:136
#9 0xb7678c70 in zif_PDOStatement_execute (ht=1,
return_value=0x840fac0, return_value_ptr=0x0, this_ptr=0x1,
return_value_used=1, tsrm_ls=0x82a9218)
at /root/php5.1-200604230030/ext/pdo/pdo_stmt.c:451
#10 0xb78437e8 in zend_do_fcall_common_helper_SPEC
(execute_data=0xab197ab0, tsrm_ls=0x82a9218) at zend_vm_execute.h:200
#11 0xb7842cec in execute (op_array=0x8342158, tsrm_ls=0x82a9218) at
zend_vm_execute.h:92
#12 0xb784345f in zend_do_fcall_common_helper_SPEC
(execute_data=0xab19a080, tsrm_ls=0x82a9218) at zend_vm_execute.h:234
#13 0xb7842cec in execute (op_array=0x833d948, tsrm_ls=0x82a9218) at
zend_vm_execute.h:92
#14 0xb784345f in zend_do_fcall_common_helper_SPEC
(execute_data=0xab19a4e0, tsrm_ls=0x82a9218) at zend_vm_execute.h:234
#15 0xb7842cec in execute (op_array=0x8329fa0, tsrm_ls=0x82a9218) at
zend_vm_execute.h:92
#16 0xb78239ec in zend_execute_scripts (type=8, tsrm_ls=0x82a9218,
retval=0x0, file_count=3) at
/root/php5.1-200604230030/Zend/zend.c:1109
#17 0xb77d9329 in php_execute_script (primary_file=0xab19c870,
tsrm_ls=0x82a9218) at /root/php5.1-200604230030/main/main.c:1732
#18 0xb78a61ee in php_handler (r=0x82be060) at
/root/php5.1-200604230030/sapi/apache2handler/sapi_apache2.c:586
#19 0x0807a155 in ap_run_handler ()
#20 0x0807a760 in ap_invoke_handler ()
#21 0x08069d5a in ap_process_request ()
#22 0x0806521d in _start ()
#23 0x082be060 in ?? ()
#24 0x0004 in ?? ()
#25 0x082be060 in ?? ()
#26 0x080854cc in ap_run_pre_connection ()
#27 0x08085385 in ap_run_process_connection ()
#28 0x080766d1 in ap_graceful_stop_signalled ()
#29 0x08076e9a in ap_graceful_stop_signalled ()
#30 0xb7c3cf36 in apr_threadattr_stacksize_set () from
/usr/lib/libapr-0.so.0
#31 0xb7bdfb63 in start_thread () from /lib/tls/libpthread.so.0
#32 0xb7b7e18a in clone () from /lib/tls/libc.so.6
--
Edit this bug report at http://bugs.php.net/?id=37174&edit=1
#37144 [Com]: PHP crashes trying to assign into property of dide object
ID: 37144 Comment by: smlerman at gmail dot com Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.1.2 Assigned To: dmitry New Comment: I don't get a segfault on Windows 5.1.1, Linux 5.1.1 (compiled on Ubuntu), or Linux 5.1.2 (compiled on Fedora). As a side note, should that even be valid syntax? Shouldn't the left side of assignment only allow variables (other than the special language construct list())? Isn't foo()->bar[1] an expression, not a variable? Previous Comments: [2006-04-20 08:30:53] [EMAIL PROTECTED] Description: PHP removes a temorary object then tryes to assign into its property. As a result we have SIGSEGV. Reproduce code: --- bar = array(1); return $x; } foo()->bar[1] = "123"; echo "ok\n"; ?> Expected result: ok Actual result: -- crash and/or memory leaks -- Edit this bug report at http://bugs.php.net/?id=37144&edit=1
#35604 [Fbk->Opn]: PDO crash
ID: 35604 User updated by: smlerman at gmail dot com Reported By: smlerman at gmail dot com -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Linux PHP Version: 5CVS-2005-12-09 (snap) Assigned To: wez New Comment: Still get a segmentation fault with the 2005-12-22-1330 snapshot. Previous Comments: [2005-12-22 14:50:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-12-12 14:40:52] smlerman at gmail dot com # awk --version GNU Awk 3.1.3 Copyright (C) 1989, 1991-2003 Free Software Foundation. [2005-12-12 14:26:47] [EMAIL PROTECTED] ==19435== Invalid write of size 4 ==19435==at 0x80B5654: pgsql_stmt_param_hook (pgsql_statement.c:278) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== Address 0x1BD907B8 is 0 bytes after a block of size 8 alloc'd ==19435==at 0x1B901B95: calloc (vg_replace_malloc.c:279) ==19435==by 0x80B52AD: pgsql_stmt_param_hook (pgsql_statement.c:222) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== ==19435== Invalid write of size 4 ==19435==at 0x80B5672: pgsql_stmt_param_hook (pgsql_statement.c:279) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== Address 0x1BD907F0 is 0 bytes after a block of size 8 alloc'd ==19435==at 0x1B901B95: calloc (vg_replace_malloc.c:279) ==19435==by 0x80B52CF: pgsql_stmt_param_hook (pgsql_statement.c:225) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== ==19435== Invalid write of size 4 ==19435==at 0x80B5687: pgsql_stmt_param_hook (pgsql_statement.c:280) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== Address 0x1BD90828 is 0 bytes after a block of size 8 alloc'd ==19435==at 0x1B901B95: calloc (vg_replace_malloc.c:279) ==19435==by 0x80B52F1: pgsql_stmt_param_hook (pgsql_statement.c:228) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==
#35604 [Asn]: PDO crash
ID: 35604 User updated by: smlerman at gmail dot com Reported By: smlerman at gmail dot com Status: Assigned Bug Type: PDO related Operating System: Linux PHP Version: 5CVS-2005-12-09 (snap) Assigned To: wez New Comment: # awk --version GNU Awk 3.1.3 Copyright (C) 1989, 1991-2003 Free Software Foundation. Previous Comments: [2005-12-12 14:26:47] [EMAIL PROTECTED] ==19435== Invalid write of size 4 ==19435==at 0x80B5654: pgsql_stmt_param_hook (pgsql_statement.c:278) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== Address 0x1BD907B8 is 0 bytes after a block of size 8 alloc'd ==19435==at 0x1B901B95: calloc (vg_replace_malloc.c:279) ==19435==by 0x80B52AD: pgsql_stmt_param_hook (pgsql_statement.c:222) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== ==19435== Invalid write of size 4 ==19435==at 0x80B5672: pgsql_stmt_param_hook (pgsql_statement.c:279) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== Address 0x1BD907F0 is 0 bytes after a block of size 8 alloc'd ==19435==at 0x1B901B95: calloc (vg_replace_malloc.c:279) ==19435==by 0x80B52CF: pgsql_stmt_param_hook (pgsql_statement.c:225) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== ==19435== Invalid write of size 4 ==19435==at 0x80B5687: pgsql_stmt_param_hook (pgsql_statement.c:280) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== Address 0x1BD90828 is 0 bytes after a block of size 8 alloc'd ==19435==at 0x1B901B95: calloc (vg_replace_malloc.c:279) ==19435==by 0x80B52F1: pgsql_stmt_param_hook (pgsql_statement.c:228) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== ==19435== Invalid write of size 4 ==19435==at 0x80B56E0: pgsql_stmt_param_hook (pgsql_statement.c:287) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_v
#35604 [Fbk->Opn]: PDO crash
ID: 35604 User updated by: smlerman at gmail dot com Reported By: smlerman at gmail dot com -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Linux PHP Version: 5CVS-2005-12-09 (snap) New Comment: ./configure --prefix=/usr/local/php5 --with-pgsql=/usr/local/pgsql/ --with-mysql=/usr/local/mysql/ --with-pdo --with-pdo-pgsql --with-pdo-mysql --with-gd --with-jpeg-dir=/usr/local/lib --with-zlib-dir=/usr/local/zlib --with-png-dir=/usr/local/libpng --with-apxs2=/usr/local/apache/bin/apxs --enable-debug Previous Comments: [2005-12-12 10:30:15] [EMAIL PROTECTED] What was the configure line you used? [2005-12-09 22:56:35] smlerman at gmail dot com Here's the backtrace. (gdb) bt #0 0x00556716 in free () from /lib/tls/libc.so.6 #1 0x082184cd in shutdown_memory_manager (silent=0, full_shutdown=0) at /root/php/php5.1-200512091530/Zend/zend_alloc.c:512 #2 0x081f903f in php_request_shutdown (dummy=0x0) at /root/php/php5.1-200512091530/main/main.c:1303 #3 0x08280e1f in main (argc=2, argv=0xbfe192e4) at /root/php/php5.1-200512091530/sapi/cli/php_cli.c:1142 (gdb) [2005-12-09 18:03:45] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php 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. [2005-12-09 17:53:52] smlerman at gmail dot com Tried the same code on my Linux box at home (Fedora Core 2, first test server I believe is Fedora 4), and it just gives a segmentation fault instead. Tried the php5.1-200512091530 snapshot, and I get the same results. [2005-12-08 19:16:57] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip 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/35604 -- Edit this bug report at http://bugs.php.net/?id=35604&edit=1
#35604 [Fbk->Opn]: PDO crash
ID: 35604
User updated by: smlerman at gmail dot com
Reported By: smlerman at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.1
New Comment:
Here's the backtrace.
(gdb) bt
#0 0x00556716 in free () from /lib/tls/libc.so.6
#1 0x082184cd in shutdown_memory_manager (silent=0, full_shutdown=0)
at /root/php/php5.1-200512091530/Zend/zend_alloc.c:512
#2 0x081f903f in php_request_shutdown (dummy=0x0) at
/root/php/php5.1-200512091530/main/main.c:1303
#3 0x08280e1f in main (argc=2, argv=0xbfe192e4) at
/root/php/php5.1-200512091530/sapi/cli/php_cli.c:1142
(gdb)
Previous Comments:
[2005-12-09 18:03:45] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php 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.
[2005-12-09 17:53:52] smlerman at gmail dot com
Tried the same code on my Linux box at home (Fedora Core 2, first test
server I believe is Fedora 4), and it just gives a segmentation fault
instead. Tried the php5.1-200512091530 snapshot, and I get the same
results.
[2005-12-08 19:16:57] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2005-12-08 19:08:57] smlerman at gmail dot com
Description:
PHP crashes on the following code. Changing the second named marker
from :foo1 to :foo2 fixes the crash, which made me think it had to do
with duplicate names. However, removing the where clause (leaving both
name markers :foo1) also eliminates the crash, though the statement
gets an error code of "HY093" (no full message).
Reproduce code:
---
prepare("UPDATE test SET foo1 = :foo1, foo2 = :foo1 WHERE
foo1 = :id");
$stmt->bindParam(':foo1', $foo1);
$stmt->bindParam(':foo2', $foo2);
$stmt->bindParam(':id', $id);
$foo1 = "foo";
$foo2 = "foo";
$id = "foo";
var_dump($stmt->errorInfo());
$stmt->execute();
?>
Expected result:
An error message of some kind if duplicate names aren't allowed, but
certainly not a memory dump.
Actual result:
--
*** glibc detected *** php: free(): invalid next size (fast):
0x09980018 ***
Followed by a backtrace and memory dump
--
Edit this bug report at http://bugs.php.net/?id=35604&edit=1
#35604 [Fbk->Opn]: PDO crash
ID: 35604
User updated by: smlerman at gmail dot com
Reported By: smlerman at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.1
New Comment:
Tried the same code on my Linux box at home (Fedora Core 2, first test
server I believe is Fedora 4), and it just gives a segmentation fault
instead. Tried the php5.1-200512091530 snapshot, and I get the same
results.
Previous Comments:
[2005-12-08 19:16:57] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2005-12-08 19:08:57] smlerman at gmail dot com
Description:
PHP crashes on the following code. Changing the second named marker
from :foo1 to :foo2 fixes the crash, which made me think it had to do
with duplicate names. However, removing the where clause (leaving both
name markers :foo1) also eliminates the crash, though the statement
gets an error code of "HY093" (no full message).
Reproduce code:
---
prepare("UPDATE test SET foo1 = :foo1, foo2 = :foo1 WHERE
foo1 = :id");
$stmt->bindParam(':foo1', $foo1);
$stmt->bindParam(':foo2', $foo2);
$stmt->bindParam(':id', $id);
$foo1 = "foo";
$foo2 = "foo";
$id = "foo";
var_dump($stmt->errorInfo());
$stmt->execute();
?>
Expected result:
An error message of some kind if duplicate names aren't allowed, but
certainly not a memory dump.
Actual result:
--
*** glibc detected *** php: free(): invalid next size (fast):
0x09980018 ***
Followed by a backtrace and memory dump
--
Edit this bug report at http://bugs.php.net/?id=35604&edit=1
#35604 [NEW]: PDO crash
From: smlerman at gmail dot com
Operating system: Linux
PHP version: 5.1.1
PHP Bug Type: PDO related
Bug description: PDO crash
Description:
PHP crashes on the following code. Changing the second named marker from
:foo1 to :foo2 fixes the crash, which made me think it had to do with
duplicate names. However, removing the where clause (leaving both name
markers :foo1) also eliminates the crash, though the statement gets an
error code of "HY093" (no full message).
Reproduce code:
---
prepare("UPDATE test SET foo1 = :foo1, foo2 = :foo1 WHERE
foo1 = :id");
$stmt->bindParam(':foo1', $foo1);
$stmt->bindParam(':foo2', $foo2);
$stmt->bindParam(':id', $id);
$foo1 = "foo";
$foo2 = "foo";
$id = "foo";
var_dump($stmt->errorInfo());
$stmt->execute();
?>
Expected result:
An error message of some kind if duplicate names aren't allowed, but
certainly not a memory dump.
Actual result:
--
*** glibc detected *** php: free(): invalid next size (fast): 0x09980018
***
Followed by a backtrace and memory dump
--
Edit bug report at http://bugs.php.net/?id=35604&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35604&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35604&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35604&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35604&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35604&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35604&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35604&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35604&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35604&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35604&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35604&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35604&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35604&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35604&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35604&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35604&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35604&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35604&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35604&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35604&r=mysqlcfg
#35345 [Com]: SQLite won't load (specified module not found)
ID: 35345 Comment by: smlerman at gmail dot com Reported By: csaba at alum dot mit dot edu Status: Feedback Bug Type: PDO related Operating System: Win XP Pro PHP Version: 5CVS-2005-11-23 (snap) Assigned To: wez New Comment: I had the same problem. I had extension=php_pdo.dll (plus the drivers for MySQL, Postgres, and SQLite) after the extensions list in php.ini-dist. Moving those lines up above, so that they're before extension=php_sqlite.dll, fixed the problem. Definitely something that needs to be added to the installation docs for SQLite. It also might be a good idea to add the PDO extensions to php.ini-dist. Since the PDO extensions would be before the SQLite extension in alphabetical order anyway, most people would never notice the dependency. Previous Comments: [2005-11-23 10:54:25] [EMAIL PROTECTED] For reasons discussed on the mailing list recently (see the threads on PHP 5.1 upgrade notes), ext/sqlite depends on the PDO extension, because it provides a sqlite2 PDO driver. You need to ensure that the PDO extension is loaded before the sqlite extension. [2005-11-23 10:10:08] csaba at alum dot mit dot edu Description: I downloaded a new snapshot (.zip) of PHP (version 5.1.0 RC7), stopped Apache 2 and overwrote the prior extracted files (about 10), all sitting in c:\winapps\php.net. In addition, I also extracted php_sqlite.dll to the same directory (since my sqlite code which had been relying on PHP 5.1 of Aug 31 no longer functioned). Next I went into c:\windows\php.ini and added the line extension=php_sqlite.dll (the only other extension I have loading is php_shmop.dll). * Note, at the least there seems to be a documentation bug because php.net/sqlite says to add php_extension=php_sqlite.dll * Now when I go to restart apache 2, I get the following confirm alert/msgbox twice: Warning PHP Startup: Unable to load dynamic library './php_sqlite.dll' - The specified module could not be found. This is an exceptionally unhelpful message as a normal person would suspect that there is a problem locating php_sqlite.dll as that is the only thing specified. At any rate, the loading is successful if I also add extension=php_pdo.dll to php.ini and plunk php_pdo.dll into the main directory. Without setting extension nor file for php_pdo_sqlite.dll Thanks, Csaba Gabor from Vienna Expected result: 1. I expect that all I need to run my older code is php_sqlite.dll I do not expect to need php_pdo.dll which I do not currently utilitze in my code. php_pdo.dll should be relying on php_sqlite.dll, if anything, and not the other way around. 2. I expect the docs in http://php.net/sqlite (and perhaps also http://php.net/pdo-sqlite) to mention when I should use only php_sqlite.dll (and set extension), when I need to include php_pdo.dll (and whether I should use php_sqlite.dll with it or php_pdo_sqlite.dll or both). Actual result: -- 1. php_sqlite.dll seems to require php_pdo.dll to function. This seems counterintuitive, at best. 2. A user (me) is sure to wonder how the two ...sqlite.dll come into play. This is in addition/commensurate with being confused about how to swap drivers between v2 and 3 and when one would want to do so. In other words, there seem to be possibilities of with/without pdo, v2 or v3 drivers, and two distinct sqlite dll's. -- Edit this bug report at http://bugs.php.net/?id=35345&edit=1
