#48057 [Opn]: Only the date fields of the first row are fetched, others are empty

2009-07-02 Thread info at programmiernutte dot net 
 ID:   48057
 User updated by:  info at programmiernutte dot net
 Reported By:  info at programmiernutte dot net
 Status:   Open
 Bug Type: PDO related
 Operating System: *
-PHP Version:  5.3.0RC1
+PHP Version:  5.3.0
 New Comment:

I dug out my rusty C skills and looked into this myself. It came down 
to the following patch which works for me although I don't quite see 
why this minor change would cause different behaviour. Maybe someone 
would enlighten me.

This is my patch against PHP 5.3.0:

--- php-5.3.0/ext/pdo_firebird/firebird_statement.c 2009-02-09 
13:07:23.0 +0100
+++ php-5.3.0patched/ext/pdo_firebird/firebird_statement.c  2009-
07-03 01:41:24.0 +0200
@@ -363,7 +363,9 @@ static int firebird_stmt_get_col(pdo_stm
fmt = S->H-
>timestamp_format ? S->H->timestamp_format : PDO_FB_DEF_TIMESTAMP_FMT;
}
/* convert the timestamp into 
a string */
-   *ptr = FETCH_BUF(S-
>fetch_buf[colno], char, *len = 80, NULL);
+
+   *len = 80;
+   *ptr = FETCH_BUF(S-
>fetch_buf[colno], char, *len, NULL);
*len = strftime(*ptr, *len, 
fmt, &t);
break;
case SQL_BLOB:


Previous Comments:
----

[2009-05-01 08:29:03] info at programmiernutte dot net

Worse, the only row that would be complete is nulled because of an 
older bug:
array(4) {
  ["ID"]=>
  NULL
  [0]=>
  NULL
  ["BAR"]=>
  NULL
  [1]=>
  NULL
}
array(4) {
  ["ID"]=>
  string(1) "2"
  [0]=>
  string(1) "2"
  ["BAR"]=>
  string(0) ""
  [1]=>
  string(0) ""
}
array(4) {
  ["ID"]=>
  string(1) "3"
  [0]=>
  string(1) "3"
  ["BAR"]=>
  string(0) ""
  [1]=>
  string(0) ""
}

----------------

[2009-04-27 17:05:30] j...@php.net

Does this happen with PHP 5.2.9 ?



[2009-04-23 07:26:14] info at programmiernutte dot net

Description:

PDO::fetch() only returns date fields on the first call. 
subsequent calls return empty strings instead of dates. 

Configure Command =>  './configure'  '--
prefix=/usr/local/php' '--with-apxs2' '--without-pdo-sqlite' 
'--without-mysql'

php.ini-settings don't seem to matter, I only have these:
date.timezone = "Europe/Berlin"
include_path = "/Library/WebServer/php-includes/"
allow_call_time_pass_reference = Off
expose_php = Off
magic_quotes_gpc = Off
register_argc_argv = Off
output_buffering = On
plus settings for xdebug, apc and memcache, I already tried 
disabling them, no difference.

PDO_FIREBIRD is loaded as an 
extension:extension=pdo_firebird.so






Reproduce code:
---
isql:
SQL> create database 'test.fdb';
SQL> CREATE TABLE FOO (ID INTEGER, BAR DATE);
SQL> INSERT INTO FOO (ID, BAR) VALUES ('1', '11.04.2009');
SQL> INSERT INTO FOO (ID, BAR) VALUES ('2', '12.04.2009');
SQL> INSERT INTO FOO (ID, BAR) VALUES ('3', '13.04.2009');

php:
 true,
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_OBJ
)
);


$oStmt = $oPDO->query('select id, bar from foo');


foreach($oStmt as $oRow)
{
var_dump($oRow);
}
?>



Expected result:

object(stdClass)#3 (2) {
  ["ID"]=>
  string(1) "1"
  ["BAR"]=>
  string(10) "2009-04-11"
}
object(stdClass)#4 (2) {
  ["ID"]=>
  string(1) "2"
  ["BAR"]=>
  string(10) "2009-04-12"
}
object(stdClass)#3 (2) {
  ["ID"]=>
  string(1) "3"
  ["BAR"]=>
  string(10) "2009-04-13"
}






Actual result:
--
object(stdClass)#3 (2) {
  ["ID"]=>
  string(1) "1"
  ["BAR"]=>
  string(10) "2009-04-11"
}
object(stdClass)#4 (2) {
  ["ID"]=>
  string(1) "2"
  ["BAR"]=>
  string(0) ""
}
object(stdClass)#3 (2) {
  ["ID"]=>
  string(1) "3"
  ["BAR"]=>
  string(0) ""
}










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

#48276 [Opn]: date('Y') returns 0000

2009-05-27 Thread info at programmiernutte dot net 
 ID:   48276
 User updated by:  info at programmiernutte dot net
 Reported By:  info at programmiernutte dot net
 Status:   Open
 Bug Type: Date/time related
 Operating System: Mac OS X 10.4 PPC
 PHP Version:  5.3.0RC2
 New Comment:

I just verified the issue unter Linux PPC, Debian Lenny PPC to be 
specific.


Previous Comments:


[2009-05-27 23:07:35] info at programmiernutte dot net

PPC or Intel? I tested this on 10.4 and 10.5 on PPC with the same 
results.



[2009-05-27 22:00:56] j at teamonetickets dot com

I cannot reproduce this on OS X 10.5.7 with PHP 5.3.0RC2.

$oDateTime = new DateTime();
print_r($oDateTime);

Result:
DateTime Object
(
[date] => 2009-05-27 14:57:33
[timezone_type] => 3
[timezone] => America/Phoenix
)

echo date('y');
Result:
09

echo date('Y');
Result:
2009



[2009-05-25 05:37:39] der...@php.net

I still can't reproduce this, and I still don't have access to this
platform.

--------

[2009-05-24 19:22:55] info at programmiernutte dot net

DateTime is also affected:

$oDateTime = new DateTime();

print_r($oDateTime);

Result:
DateTime Object
(
[date] => -05-24 21:27:10
[timezone_type] => 3
[timezone] => Europe/Berlin
)



[2009-05-22 01:00:02] 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".



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/48276

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

#48276 [Fbk->Opn]: date('Y') returns 0000

2009-05-27 Thread info at programmiernutte dot net 
 ID:   48276
 User updated by:  info at programmiernutte dot net
 Reported By:  info at programmiernutte dot net
-Status:   Feedback
+Status:   Open
 Bug Type: Date/time related
 Operating System: Mac OS X 10.4 PPC
 PHP Version:  5.3.0RC2
 New Comment:

PPC or Intel? I tested this on 10.4 and 10.5 on PPC with the same 
results.


Previous Comments:


[2009-05-27 22:00:56] j at teamonetickets dot com

I cannot reproduce this on OS X 10.5.7 with PHP 5.3.0RC2.

$oDateTime = new DateTime();
print_r($oDateTime);

Result:
DateTime Object
(
[date] => 2009-05-27 14:57:33
[timezone_type] => 3
[timezone] => America/Phoenix
)

echo date('y');
Result:
09

echo date('Y');
Result:
2009



[2009-05-25 05:37:39] der...@php.net

I still can't reproduce this, and I still don't have access to this
platform.

--------

[2009-05-24 19:22:55] info at programmiernutte dot net

DateTime is also affected:

$oDateTime = new DateTime();

print_r($oDateTime);

Result:
DateTime Object
(
[date] => -05-24 21:27:10
[timezone_type] => 3
[timezone] => Europe/Berlin
)



[2009-05-22 01:00:02] 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".



[2009-05-14 09:05:52] der...@php.net

Could you provide access? I don't have the possibility to test and
debug on this specific platform myself.



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/48276

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

#48276 [NoF->Opn]: date('Y') returns 0000

2009-05-24 Thread info at programmiernutte dot net 
 ID:   48276
 User updated by:  info at programmiernutte dot net
 Reported By:  info at programmiernutte dot net
-Status:   No Feedback
+Status:   Open
 Bug Type: Date/time related
 Operating System: Mac OS X 10.4 PPC
 PHP Version:  5.3.0RC2
 New Comment:

DateTime is also affected:

$oDateTime = new DateTime();

print_r($oDateTime);

Result:
DateTime Object
(
[date] => -05-24 21:27:10
[timezone_type] => 3
[timezone] => Europe/Berlin
)


Previous Comments:


[2009-05-22 01:00:02] 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".



[2009-05-14 09:05:52] der...@php.net

Could you provide access? I don't have the possibility to test and
debug on this specific platform myself.



[2009-05-14 08:48:22] info at programmiernutte dot net

Me neither, I have 5.3.0RC2 flawlessly working on Linux, 
The issue occurs on my development system on Mac OS X 10.4 PPC only
with 
5.3.0RC2. RC1 works correct. Strange, I know.



[2009-05-14 08:40:31] der...@php.net

Bleh, wrong link. Anyway, I can not reproduce this on Linux.



[2009-05-14 08:39:43] der...@php.net

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.




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/48276

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

#48276 [Fbk->Opn]: date('Y') returns 0000

2009-05-14 Thread info at programmiernutte dot net 
 ID:   48276
 User updated by:  info at programmiernutte dot net
 Reported By:  info at programmiernutte dot net
-Status:   Feedback
+Status:   Open
 Bug Type: Date/time related
-Operating System: Max OS X 10.4 PPC
+Operating System: Mac OS X 10.4 PPC
 PHP Version:  5.3.0RC2
 New Comment:

Me neither, I have 5.3.0RC2 flawlessly working on Linux, 
The issue occurs on my development system on Mac OS X 10.4 PPC only
with 
5.3.0RC2. RC1 works correct. Strange, I know.


Previous Comments:


[2009-05-14 08:40:31] der...@php.net

Bleh, wrong link. Anyway, I can not reproduce this on Linux.



[2009-05-14 08:39:43] der...@php.net

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.




[2009-05-14 08:17:22] info at programmiernutte dot net

Description:

After upgrading to 5.3.0 RC2, date('Y') always returns . No php.ini
setting (date.timezone) seems to have any influence.

date('y') works as expected and returns 09.

This Problem did not occur with 5.3.0RC1.

Reproduce code:
---
marvin:~/src/php-5.3.0RC2 thomas$ ./sapi/cli/php 



Expected result:

marvin:~/src/php-5.3.0RC2 thomas$ ./sapi/cli/php 

2009

Actual result:
--
marvin:~/src/php-5.3.0RC2 thomas$ ./sapi/cli/php 







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

#48276 [NEW]: date('Y') returns 0000

2009-05-14 Thread info at programmiernutte dot net 
From: info at programmiernutte dot net
Operating system: Max OS X 10.4 PPC
PHP version:  5.3.0RC2
PHP Bug Type: Date/time related
Bug description:  date('Y') returns 

Description:

After upgrading to 5.3.0 RC2, date('Y') always returns . No php.ini
setting (date.timezone) seems to have any influence.

date('y') works as expected and returns 09.

This Problem did not occur with 5.3.0RC1.

Reproduce code:
---
marvin:~/src/php-5.3.0RC2 thomas$ ./sapi/cli/php 



Expected result:

marvin:~/src/php-5.3.0RC2 thomas$ ./sapi/cli/php 

2009

Actual result:
--
marvin:~/src/php-5.3.0RC2 thomas$ ./sapi/cli/php 



-- 
Edit bug report at http://bugs.php.net/?id=48276&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48276&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48276&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48276&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48276&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48276&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48276&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48276&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48276&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48276&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48276&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48276&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48276&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48276&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48276&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48276&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48276&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48276&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48276&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48276&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48276&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48276&r=mysqlcfg

#48057 [Fbk->Opn]: Only the date fields of the first row are fetched, others are empty

2009-05-01 Thread info at programmiernutte dot net 
 ID:   48057
 User updated by:  info at programmiernutte dot net
 Reported By:  info at programmiernutte dot net
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: *
 PHP Version:  5.3.0RC1
 New Comment:

Worse, the only row that would be complete is nulled because of an 
older bug:
array(4) {
  ["ID"]=>
  NULL
  [0]=>
  NULL
  ["BAR"]=>
  NULL
  [1]=>
  NULL
}
array(4) {
  ["ID"]=>
  string(1) "2"
  [0]=>
  string(1) "2"
  ["BAR"]=>
  string(0) ""
  [1]=>
  string(0) ""
}
array(4) {
  ["ID"]=>
  string(1) "3"
  [0]=>
  string(1) "3"
  ["BAR"]=>
  string(0) ""
  [1]=>
  string(0) ""
}


Previous Comments:
----

[2009-04-27 17:05:30] j...@php.net

Does this happen with PHP 5.2.9 ?



[2009-04-23 07:26:14] info at programmiernutte dot net

Description:

PDO::fetch() only returns date fields on the first call. 
subsequent calls return empty strings instead of dates. 

Configure Command =>  './configure'  '--
prefix=/usr/local/php' '--with-apxs2' '--without-pdo-sqlite' 
'--without-mysql'

php.ini-settings don't seem to matter, I only have these:
date.timezone = "Europe/Berlin"
include_path = "/Library/WebServer/php-includes/"
allow_call_time_pass_reference = Off
expose_php = Off
magic_quotes_gpc = Off
register_argc_argv = Off
output_buffering = On
plus settings for xdebug, apc and memcache, I already tried 
disabling them, no difference.

PDO_FIREBIRD is loaded as an 
extension:extension=pdo_firebird.so






Reproduce code:
---
isql:
SQL> create database 'test.fdb';
SQL> CREATE TABLE FOO (ID INTEGER, BAR DATE);
SQL> INSERT INTO FOO (ID, BAR) VALUES ('1', '11.04.2009');
SQL> INSERT INTO FOO (ID, BAR) VALUES ('2', '12.04.2009');
SQL> INSERT INTO FOO (ID, BAR) VALUES ('3', '13.04.2009');

php:
 true,
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_OBJ
)
);


$oStmt = $oPDO->query('select id, bar from foo');


foreach($oStmt as $oRow)
{
var_dump($oRow);
}
?>



Expected result:

object(stdClass)#3 (2) {
  ["ID"]=>
  string(1) "1"
  ["BAR"]=>
  string(10) "2009-04-11"
}
object(stdClass)#4 (2) {
  ["ID"]=>
  string(1) "2"
  ["BAR"]=>
  string(10) "2009-04-12"
}
object(stdClass)#3 (2) {
  ["ID"]=>
  string(1) "3"
  ["BAR"]=>
  string(10) "2009-04-13"
}






Actual result:
--
object(stdClass)#3 (2) {
  ["ID"]=>
  string(1) "1"
  ["BAR"]=>
  string(10) "2009-04-11"
}
object(stdClass)#4 (2) {
  ["ID"]=>
  string(1) "2"
  ["BAR"]=>
  string(0) ""
}
object(stdClass)#3 (2) {
  ["ID"]=>
  string(1) "3"
  ["BAR"]=>
  string(0) ""
}










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

#47829 [Fbk->Opn]: Segmentation fault on startup with PDO Firebird compiled in

2009-05-01 Thread info at programmiernutte dot net 
 ID:   47829
 User updated by:  info at programmiernutte dot net
 Reported By:  info at programmiernutte dot net
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Debian Etch x86_64
 PHP Version:  5.3.0RC1
 New Comment:

Same thing:

localhost:~/php5.2-200905010630/sapi/cli# ./php 
Segmentation fault

gdb trace:
(gdb) run
Starting program: /root/php5.2-200905010630/sapi/cli/php 
warning: no loadable sections found in added symbol-file system-
supplied DSO at 0x779fe000
[Thread debugging using libthread_db enabled]
[New Thread 47269144047376 (LWP 16865)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47269144047376 (LWP 16865)]
0x0062c1aa in _zend_hash_add_or_update (ht=0xa8f740, 
arKey=0x8bbb92 "firebird", nKeyLength=8, pData=0x77995060, 
nDataSize=8, pDest=0x0, flag=2) at /root/php5.2-
200905010630/Zend/zend_hash.c:218
218 p = ht->arBuckets[nIndex];
(gdb) where
#0  0x0062c1aa in _zend_hash_add_or_update (ht=0xa8f740, 
arKey=0x8bbb92 "firebird", nKeyLength=8, 
pData=0x77995060, nDataSize=8, pDest=0x0, flag=2) at 
/root/php5.2-200905010630/Zend/zend_hash.c:218
#1  0x0052718f in php_pdo_register_driver (driver=0xa661c0) at

/root/php5.2-200905010630/ext/pdo/pdo.c:184
#2  0x005311c0 in zm_startup_pdo_firebird (type=, module_number=9157530)
at /root/php5.2-200905010630/ext/pdo_firebird/pdo_firebird.c:58
#3  0x006257c3 in zend_startup_module_ex (module=0xae52d0) at 
/root/php5.2-200905010630/Zend/zend_API.c:1472
#4  0x0062a995 in zend_hash_apply (ht=0xa93bc0, 
apply_func=0x6256c0 )
at /root/php5.2-200905010630/Zend/zend_hash.c:673
#5  0x00623fea in zend_startup_modules () at /root/php5.2-
200905010630/Zend/zend_API.c:1519
#6  0x005deebd in php_module_startup (sf=, additional_modules=0x0, num_additional_modules=0)
at /root/php5.2-200905010630/main/main.c:1843
#7  0x006a171d in php_cli_startup (sapi_module=0x0) at 
/root/php5.2-200905010630/sapi/cli/php_cli.c:386
#8  0x006a1e11 in main (argc=1, argv=0x77995688) at 
/root/php5.2-200905010630/sapi/cli/php_cli.c:745


Previous Comments:


[2009-04-30 10:48:27] j...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2009-03-29 21:51:51] info at programmiernutte dot net

I did some more experimenting, and I figured that the Crash does not
occur when PDO Firebird is compiled as a shared module and loaded as
extension. PDO Extension seems to work.



[2009-03-29 16:11:42] info at programmiernutte dot net

Description:

I am getting Segmentation fault on startup, no matter if SAPI apache 2
or CLI. Same Version of PHP and same Firebird Version (2.1.1.) are
running flawlessly on my G4 Mac on Mac OS X 10.4.11, so maybe this is
64bit-related? 
I used gdb to track this down to PDO Firebird Initialisation Startup:

(gdb) run
Starting program: /usr/src/php-5.3.0RC1/sapi/cli/php 
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread 47013927445712 (LWP 16824)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47013927445712 (LWP 16824)]
zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
3210if (ce->type & ZEND_INTERNAL_CLASS) {
(gdb) where
#0  zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
#1  0x005190c2 in zm_startup_pdo_firebird (type=, module_number=)
at /usr/src/php-5.3.0RC1/ext/pdo_firebird/pdo_firebird.c:58
#2  0x0061cfbe in zend_startup_module_ex (module=0xcafb10) at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1593
#3  0x00625f05 in zend_hash_apply (ht=0xc62e80,
apply_func=0x61cec0 )
at /usr/src/php-5.3.0RC1/Zend/zend_hash.c:673
#4  0x0061d89a in zend_startup_modules () at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1642
#5  0x005c827f in php_module_startup (sf=,
additional_modules=0x0, num_additional_modules=0)
at /usr/src/php-5.3.0RC1/main/main.c:1952
#6  0x006a0e5d in php_cli_startup (sapi_module=0x0) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:370
#7  0x006a155f in main (argc=1, argv=0x7fff63c23928) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:742






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

#48057 [NEW]: Only the date fields of the first row are fetched, others are empty

2009-04-23 Thread info at programmiernutte dot net 
From: info at programmiernutte dot net
Operating system: no matter
PHP version:  5.3.0RC1
PHP Bug Type: PDO related
Bug description:  Only the date fields of the first row are fetched, others are 
empty

Description:

PDO::fetch() only returns date fields on the first call. 
subsequent calls return empty strings instead of dates. 

Configure Command =>  './configure'  '--
prefix=/usr/local/php' '--with-apxs2' '--without-pdo-sqlite' 
'--without-mysql'

php.ini-settings don't seem to matter, I only have these:
date.timezone = "Europe/Berlin"
include_path = "/Library/WebServer/php-includes/"
allow_call_time_pass_reference = Off
expose_php = Off
magic_quotes_gpc = Off
register_argc_argv = Off
output_buffering = On
plus settings for xdebug, apc and memcache, I already tried 
disabling them, no difference.

PDO_FIREBIRD is loaded as an 
extension:extension=pdo_firebird.so






Reproduce code:
---
isql:
SQL> create database 'test.fdb';
SQL> CREATE TABLE FOO (ID INTEGER, BAR DATE);
SQL> INSERT INTO FOO (ID, BAR) VALUES ('1', '11.04.2009');
SQL> INSERT INTO FOO (ID, BAR) VALUES ('2', '12.04.2009');
SQL> INSERT INTO FOO (ID, BAR) VALUES ('3', '13.04.2009');

php:
 true,
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_OBJ
)
);


$oStmt = $oPDO->query('select id, bar from foo');


foreach($oStmt as $oRow)
{
var_dump($oRow);
}
?>



Expected result:

object(stdClass)#3 (2) {
  ["ID"]=>
  string(1) "1"
  ["BAR"]=>
  string(10) "2009-04-11"
}
object(stdClass)#4 (2) {
  ["ID"]=>
  string(1) "2"
  ["BAR"]=>
  string(10) "2009-04-12"
}
object(stdClass)#3 (2) {
  ["ID"]=>
  string(1) "3"
  ["BAR"]=>
  string(10) "2009-04-13"
}






Actual result:
--
object(stdClass)#3 (2) {
  ["ID"]=>
  string(1) "1"
  ["BAR"]=>
  string(10) "2009-04-11"
}
object(stdClass)#4 (2) {
  ["ID"]=>
  string(1) "2"
  ["BAR"]=>
  string(0) ""
}
object(stdClass)#3 (2) {
  ["ID"]=>
  string(1) "3"
  ["BAR"]=>
  string(0) ""
}






-- 
Edit bug report at http://bugs.php.net/?id=48057&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48057&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48057&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48057&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48057&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48057&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48057&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48057&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48057&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48057&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48057&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48057&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48057&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48057&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48057&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48057&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48057&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48057&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48057&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48057&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48057&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48057&r=mysqlcfg

#47829 [Opn]: Segmentation fault on startup with PDO Firebird compiled in

2009-03-29 Thread info at programmiernutte dot net 
 ID:   47829
 User updated by:  info at programmiernutte dot net
 Reported By:  info at programmiernutte dot net
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Debian Etch x86_64
 PHP Version:  5.3.0RC1
 New Comment:

I did some more experimenting, and I figured that the Crash does not
occur when PDO Firebird is compiled as a shared module and loaded as
extension. PDO Extension seems to work.


Previous Comments:


[2009-03-29 16:11:42] info at programmiernutte dot net

Description:

I am getting Segmentation fault on startup, no matter if SAPI apache 2
or CLI. Same Version of PHP and same Firebird Version (2.1.1.) are
running flawlessly on my G4 Mac on Mac OS X 10.4.11, so maybe this is
64bit-related? 
I used gdb to track this down to PDO Firebird Initialisation Startup:

(gdb) run
Starting program: /usr/src/php-5.3.0RC1/sapi/cli/php 
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread 47013927445712 (LWP 16824)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47013927445712 (LWP 16824)]
zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
3210if (ce->type & ZEND_INTERNAL_CLASS) {
(gdb) where
#0  zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
#1  0x005190c2 in zm_startup_pdo_firebird (type=, module_number=)
at /usr/src/php-5.3.0RC1/ext/pdo_firebird/pdo_firebird.c:58
#2  0x0061cfbe in zend_startup_module_ex (module=0xcafb10) at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1593
#3  0x00625f05 in zend_hash_apply (ht=0xc62e80,
apply_func=0x61cec0 )
at /usr/src/php-5.3.0RC1/Zend/zend_hash.c:673
#4  0x0061d89a in zend_startup_modules () at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1642
#5  0x005c827f in php_module_startup (sf=,
additional_modules=0x0, num_additional_modules=0)
at /usr/src/php-5.3.0RC1/main/main.c:1952
#6  0x006a0e5d in php_cli_startup (sapi_module=0x0) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:370
#7  0x006a155f in main (argc=1, argv=0x7fff63c23928) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:742






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

#47829 [NEW]: Segmentation fault on startup with PDO Firebird compiled in

2009-03-29 Thread info at programmiernutte dot net 
From: info at programmiernutte dot net
Operating system: Debian Etch x86_64
PHP version:  5.3.0RC1
PHP Bug Type: Reproducible crash
Bug description:  Segmentation fault on startup with PDO Firebird compiled in

Description:

I am getting Segmentation fault on startup, no matter if SAPI apache 2 or
CLI. Same Version of PHP and same Firebird Version (2.1.1.) are running
flawlessly on my G4 Mac on Mac OS X 10.4.11, so maybe this is
64bit-related? 
I used gdb to track this down to PDO Firebird Initialisation Startup:

(gdb) run
Starting program: /usr/src/php-5.3.0RC1/sapi/cli/php 
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread 47013927445712 (LWP 16824)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47013927445712 (LWP 16824)]
zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
3210if (ce->type & ZEND_INTERNAL_CLASS) {
(gdb) where
#0  zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
#1  0x005190c2 in zm_startup_pdo_firebird (type=, module_number=)
at /usr/src/php-5.3.0RC1/ext/pdo_firebird/pdo_firebird.c:58
#2  0x0061cfbe in zend_startup_module_ex (module=0xcafb10) at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1593
#3  0x00625f05 in zend_hash_apply (ht=0xc62e80,
apply_func=0x61cec0 )
at /usr/src/php-5.3.0RC1/Zend/zend_hash.c:673
#4  0x0061d89a in zend_startup_modules () at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1642
#5  0x005c827f in php_module_startup (sf=,
additional_modules=0x0, num_additional_modules=0)
at /usr/src/php-5.3.0RC1/main/main.c:1952
#6  0x006a0e5d in php_cli_startup (sapi_module=0x0) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:370
#7  0x006a155f in main (argc=1, argv=0x7fff63c23928) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:742


-- 
Edit bug report at http://bugs.php.net/?id=47829&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47829&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47829&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47829&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47829&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47829&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47829&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47829&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47829&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47829&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47829&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47829&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47829&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47829&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47829&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47829&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47829&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47829&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47829&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47829&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47829&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47829&r=mysqlcfg