from:"barry dot verdon at complinet dot com"

#37559 [Fbk->Csd]: Pesistent flag & assigning PDO instances to and array more than once

2007-07-23 Thread barry dot verdon at complinet dot com

 ID:   37559
 User updated by:  barry dot verdon at complinet dot com
 Reported By:  barry dot verdon at complinet dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: PDO related
 Operating System: Win XP SP2 & Debian 2.6.10
 PHP Version:  5.1.4
 Assigned To:  wez
 New Comment:

I have checked this with the Windows snapshot and it works as expected.
I have not tested on a linux snapshot but am assuming this will work
too. Well done, thanks very much.


Previous Comments:


[2007-07-23 12:12:36] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi





[2006-05-23 10:32:07] barry dot verdon at complinet dot com

Description:

When assigning instances of PDO objects within the scope of a function
to an array with global scope or scope outside that function it causes a
seg fault when accessing a member of the PDO object on the second run of
the function.

It can also be within a class with the array being a member of the
class and the function being the method of the class.

It only happens when the persistent flag is set to true.

On the second run of the function when the PDO instance is assigned to
the array the symbol table seems to get corrupted, no seg fault occurs
but object id's start getting recycled with new instances. Only when the
member is accessed again after this corruption does a seg fault occur.

Tested it on :
5.1.4 - CLI and Apache 2.0.54 - Windows XP SP2
5.2.0dev200605221830 - CLI - Windows XP SP2
5.0.5 - CLI - Debian 2.6.10 (Unstable)

Reproduce code:
---
true);
$instance = new PDO($dsn, $username, $password, $driverOptions);
$instance->test = 'test';
$instances['test'] = $instance; // This is the line that causes the
damage on the 2nd run
var_dump($instance);
$instance->test = 'test'; // This is the line that seg faults on
2nd run
print_r('Test');
}
run(); run();
?>

Expected result:

To see the var_dump of $instance with the member test with a value of
'test' in it and the print of 'Test' TWICE.

Actual result:
--
On second function call, var_dump of $instance no longer has the test
member in it and 'Test' does not get printed out a second time.

Starting program: /usr/local/bin/php test.php
Test

Program received signal SIGSEGV, Segmentation fault.
0x082065cd in zend_hash_quick_find (ht=0x0, arKey=0x84d469c "test",
nKeyLength=5, h=275477765, pData=0xbfffcd74) at
/share/php-5.0.5/Zend/zend_hash.c:879
879 p = ht->arBuckets[nIndex];

(gdb) backtrace
#0  0x082065cd in zend_hash_quick_find (ht=0x0, arKey=0x84d469c "test",
nKeyLength=5, h=275477765, pData=0xbfffcd74) at
/share/php-5.0.5/Zend/zend_hash.c:879
#1  0x0821313d in zend_std_write_property (object=0x84d3e04,
member=0x84d3a04, value=0x84d3d2c) at
/share/php-5.0.5/Zend/zend_object_handlers.c:362
#2  0x0822b5eb in zend_assign_to_object (result=0x84d39d8,
object_ptr=0x84d4250, op2=, value_op=0x84d3a38,
Ts=0xbfffce40, opcode=136)
at /share/php-5.0.5/Zend/zend_execute.c:437
#3  0x0822b9a9 in zend_assign_obj_handler (execute_data=0xbfffd154,
opline=0x84d39d4, op_array=0x84d3ba0) at
/share/php-5.0.5/Zend/zend_execute.c:2239
#4  0x0821dd22 in execute (op_array=0x84d3ba0) at
/share/php-5.0.5/Zend/zend_execute.c:1437
#5  0x0821fe45 in zend_do_fcall_common_helper (execute_data=0xbfffd304,
opline=0x84d1dac, op_array=0x84cd9cc) at
/share/php-5.0.5/Zend/zend_execute.c:2789
#6  0x0822e317 in zend_do_fcall_handler (execute_data=0xbfffd304,
opline=0x84d1dac, op_array=0x84cd9cc) at
/share/php-5.0.5/Zend/zend_execute.c:2894
#7  0x0821dd22 in execute (op_array=0x84cd9cc) at
/share/php-5.0.5/Zend/zend_execute.c:1437
#8  0x08200253 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /share/php-5.0.5/Zend/zend.c:1064
#9  0x081cb1db in php_execute_script (primary_file=0xb6a0) at
/share/php-5.0.5/main/main.c:1643
#10 0x08235efa in main (argc=2, argv=0xb774) at
/share/php-5.0.5/sapi/cli/php_cli.c:946

#4  0x0821dd22 in execute (op_array=0x84d3ba0) at
/share/php-5.0.5/Zend/zend_execute.c:1437
1437if (EX(opline)->handler(&execute_data,
EX(opline), op_array TSRMLS_CC)) {





-- 
Edit this bug report at http://bugs.php.net/?id=37559&edit=1

#36286 [Com]: Variable holding query results has to be unset

2006-09-07 Thread barry dot verdon at complinet dot com

 ID:   36286
 Comment by:   barry dot verdon at complinet dot com
 Reported By:  memoimyself at yahoo dot com dot br
 Status:   No Feedback
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.1.2
 New Comment:

I have experienced the same thing on 5.1.3 on Debian. Here is the test
case I used

$db = new PDO(DSN, USERNAME, PASSWORD);

$stmt = $db->query('SELECT 1+1 AS answer');
$answer = $stmt->fetch(PDO::FETCH_ASSOC); // All fine here

$stmt = $db->query('SELECT 1+2 AS result');
$result = $stmt->fetch(PDO::FETCH_ASSOC); // Result is false


It does the same thing with a foreach loop. But if you named the
variables $stmt1 and $stmt2 is would work fine. It even caused a
problem when I had a class wrapping, not extending, PDOStatement,
slightly different error, on the __call magic method instead, but with
different variable names all worked fine.


Previous Comments:


[2006-02-12 01:00:03] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2006-02-04 18:47:21] [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-02-04 14:39:58] memoimyself at yahoo dot com dot br

Description:

When running more than one query in a row with PDO, if the result set
is assigned to a variable with the same name (e.g. $result) each time,
only the first assignment works properly: from the second time on, the
variable will contain an empty result set.

I have tested my code in two different setups: Linux (A2 Web Hosting
server running PHP 5.1.2) and Windows XP (my test server, also running
PHP 5.1.2). This problem ONLY occurs in the first setup (Linux).

It does not matter which "fetch style" is used.

I have worked around this problem by unsetting the result variable each
time as soon as all data has been fetched from it.

Reproduce code:
---
$dbh = new PDO(BD_DSN, BD_USERNAME, BD_PWD);

if ($result = $dbh->query('SELECT * FROM table_1'))
{
$all_rows_1 = $result->fetchAll(PDO::FETCH_OBJ);
}

if ($result = $dbh->query('SELECT * FROM table_2'))
{
$all_rows_2 = $result->fetchAll(PDO::FETCH_OBJ);
}

Expected result:

If both tables actually contain data, $all_rows_1 and $all_rows_2
should both contain all the data from each table.

Actual result:
--
When code similar to the example is run on my Windows XP test server,
everything works as expected.

When, however, the same code is run on the Linux production server,
$all_rows_2 will contain an empty array rather than an array with
objects representing each row from the table.

If I add unset($result) after each $result->fetchAll(PDO::FETCH_OBJ),
then everything works well on the Linux server as well.

Curiously, I have had no problems assigning other types of object the
variables with the same name in a sequence or loop (e.g. when creating
XML elements in a loop and assigning them to a variable with the same
name each time).





-- 
Edit this bug report at http://bugs.php.net/?id=36286&edit=1

#37559 [NEW]: Pesistent flag & assigning PDO instances to and array more than once

2006-05-23 Thread barry dot verdon at complinet dot com

From: barry dot verdon at complinet dot com
Operating system: Win XP SP2 & Debian 2.6.10
PHP version:  5.1.4
PHP Bug Type: PDO related
Bug description:  Pesistent flag & assigning PDO instances to and array more 
than once

Description:

When assigning instances of PDO objects within the scope of a function to
an array with global scope or scope outside that function it causes a seg
fault when accessing a member of the PDO object on the second run of the
function.

It can also be within a class with the array being a member of the class
and the function being the method of the class.

It only happens when the persistent flag is set to true.

On the second run of the function when the PDO instance is assigned to the
array the symbol table seems to get corrupted, no seg fault occurs but
object id's start getting recycled with new instances. Only when the
member is accessed again after this corruption does a seg fault occur.

Tested it on :
5.1.4 - CLI and Apache 2.0.54 - Windows XP SP2
5.2.0dev200605221830 - CLI - Windows XP SP2
5.0.5 - CLI - Debian 2.6.10 (Unstable)

Reproduce code:
---
true);
$instance = new PDO($dsn, $username, $password, $driverOptions);
$instance->test = 'test';
$instances['test'] = $instance; // This is the line that causes the
damage on the 2nd run
var_dump($instance);
$instance->test = 'test'; // This is the line that seg faults on 2nd
run
print_r('Test');
}
run(); run();
?>

Expected result:

To see the var_dump of $instance with the member test with a value of
'test' in it and the print of 'Test' TWICE.

Actual result:
--
On second function call, var_dump of $instance no longer has the test
member in it and 'Test' does not get printed out a second time.

Starting program: /usr/local/bin/php test.php
Test

Program received signal SIGSEGV, Segmentation fault.
0x082065cd in zend_hash_quick_find (ht=0x0, arKey=0x84d469c "test",
nKeyLength=5, h=275477765, pData=0xbfffcd74) at
/share/php-5.0.5/Zend/zend_hash.c:879
879 p = ht->arBuckets[nIndex];

(gdb) backtrace
#0  0x082065cd in zend_hash_quick_find (ht=0x0, arKey=0x84d469c "test",
nKeyLength=5, h=275477765, pData=0xbfffcd74) at
/share/php-5.0.5/Zend/zend_hash.c:879
#1  0x0821313d in zend_std_write_property (object=0x84d3e04,
member=0x84d3a04, value=0x84d3d2c) at
/share/php-5.0.5/Zend/zend_object_handlers.c:362
#2  0x0822b5eb in zend_assign_to_object (result=0x84d39d8,
object_ptr=0x84d4250, op2=, value_op=0x84d3a38,
Ts=0xbfffce40, opcode=136)
at /share/php-5.0.5/Zend/zend_execute.c:437
#3  0x0822b9a9 in zend_assign_obj_handler (execute_data=0xbfffd154,
opline=0x84d39d4, op_array=0x84d3ba0) at
/share/php-5.0.5/Zend/zend_execute.c:2239
#4  0x0821dd22 in execute (op_array=0x84d3ba0) at
/share/php-5.0.5/Zend/zend_execute.c:1437
#5  0x0821fe45 in zend_do_fcall_common_helper (execute_data=0xbfffd304,
opline=0x84d1dac, op_array=0x84cd9cc) at
/share/php-5.0.5/Zend/zend_execute.c:2789
#6  0x0822e317 in zend_do_fcall_handler (execute_data=0xbfffd304,
opline=0x84d1dac, op_array=0x84cd9cc) at
/share/php-5.0.5/Zend/zend_execute.c:2894
#7  0x0821dd22 in execute (op_array=0x84cd9cc) at
/share/php-5.0.5/Zend/zend_execute.c:1437
#8  0x08200253 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /share/php-5.0.5/Zend/zend.c:1064
#9  0x081cb1db in php_execute_script (primary_file=0xb6a0) at
/share/php-5.0.5/main/main.c:1643
#10 0x08235efa in main (argc=2, argv=0xb774) at
/share/php-5.0.5/sapi/cli/php_cli.c:946

#4  0x0821dd22 in execute (op_array=0x84d3ba0) at
/share/php-5.0.5/Zend/zend_execute.c:1437
1437if (EX(opline)->handler(&execute_data, EX(opline),
op_array TSRMLS_CC)) {

-- 
Edit bug report at http://bugs.php.net/?id=37559&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=37559&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=37559&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=37559&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37559&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=37559&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=37559&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37559&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37559&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=37559&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37559&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=37559&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=37559&r=submittedtwice
register_globals: http://

#34237 [NEW]: A protected method should cause a fatal error if called publicly.

2005-08-24 Thread barry dot verdon at complinet dot com

From: barry dot verdon at complinet dot com
Operating system: Redhat el3
PHP version:  5.0.4
PHP Bug Type: Class/Object related
Bug description:  A protected method should cause a fatal error if called 
publicly.

Description:

A protected function is accessible publicly if a child class has a public
function that instantiates the child object and calls the protected
function. This public function can then be called publicly. I would have
expected a fatal error to be produced from the protected function call.

Is this intended behaviour? Or should I declare the function as public in
the case of this not being the desired functionality and may change at a
later point?

Reproduce code:
---
protectedFunction();
}
}

$childClass = new childClass();
$childClass->publicFunction();
?>

Expected result:

Fatal Error on line 11, $childClass->protectedFunction().

Actual result:
--
This is a protected function.

-- 
Edit bug report at http://bugs.php.net/?id=34237&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=34237&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=34237&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=34237&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34237&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34237&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=34237&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=34237&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=34237&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34237&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=34237&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=34237&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=34237&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34237&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=34237&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34237&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=34237&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34237&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=34237&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=34237&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=34237&r=mysqlcfg

#37559 [Fbk->Csd]: Pesistent flag & assigning PDO instances to and array more than once

#36286 [Com]: Variable holding query results has to be unset

#37559 [NEW]: Pesistent flag & assigning PDO instances to and array more than once

#34237 [NEW]: A protected method should cause a fatal error if called publicly.

4 matches

Site Navigation

Mail list logo

Footer information