#47143 [Opn]: Throwing an exception in a destructor causes a fatal error
ID: 47143
User updated by: felixcca at yahoo dot ca
Reported By: felixcca at yahoo dot ca
Status: Open
Bug Type: Scripting Engine problem
Operating System: Irrelevant
PHP Version: 5.2.8
New Comment:
Sorry, made a mistake on the original error message. It's Exception
thrown without a stack frame, as stated below, and not Exception
thrown without a stack trace.
Previous Comments:
[2009-01-18 05:16:31] felixcca at yahoo dot ca
Description:
Basically a duplicate of #31304, but it seems I can't reopen the ticket
myself since I'm not a dev nor the original poster.
When an exception is thrown in a destructor, the exception is lost, and
a pointless Fatal Error is issued:
Fatal Error: Exception thrown without a stack trace
debug_backtrace() will still get you a stack trace from a destructor
without issuing any error, let alone causing the loss of debugging
data.
Also, only wrapping the exception in a try-catch inside the destructor
works, and allows you to just print the exception and exit as if
exceptions really worked in destructors.
Why spit out the Fatal Error?
Reproduce code:
---
?php
class ExceptionThrower
{
public function __destruct()
{
throw new Exception;
}
}
$obj = new ExceptionThrower;
?
Expected result:
Fatal error: Uncaught exception 'Exception' in snippet.php:6
Stack trace:
#0 [internal function]: ExceptionThrower-__destruct()
#1 {main}
thrown in snippet.php on line 6
Actual result:
--
Fatal error: Exception thrown without a stack frame in Unknown on line
0
--
Edit this bug report at http://bugs.php.net/?id=47143edit=1
#38926 [Opn]: --zend-multibyte doesn't work for a few seconds on startup
ID: 38926
User updated by: lapo at lapo dot it
Reported By: lapo at lapo dot it
Status: Open
Bug Type:mbstring related
PHP Version: 5.2.8
New Comment:
I've noticed --zend-multibyte always works if the module mbstring is
NOT included, fails if it's there.
Can the module interfere with the loading of .php?
Previous Comments:
[2009-01-16 10:25:32] lapo at lapo dot it
Re-opening as something clearly changed in the behavior in 5.2.6-5.2.8
changes (something erratically working became something that doesn't
work at all).
I will take a look at the diff myself in the weekend.
[2009-01-16 10:22:13] lapo at lapo dot it
Ah, something changed with 5.2.8 indeed: it now is always broken,
doesn't fix after a bit like it did before.
A bit more clarity about the test script, an hex dump:
% hd checkUTF8.php
ef bb bf 3c 3f 3d 20 28 27 c3 a0 27 20 3d 3d 20 |?= ('à'
== |
0010 22 5c 78 43 33 5c 78 41 30 22 29 20 3f 20 22 4f
|\xC3\xA0) ? O|
0020 4b 5c 6e 22 20 3a 20 22 42 72 6f 6b 65 6e 5c 6e |K\n :
Broken\n|
0030 22 20 3f 3e | ?|
[2008-06-21 08:45:35] lapo at lapo dot it
Using PHP 5.2.6 the situation is changed slightly: it seems that now
the page is broken on the first access only:
% php checkUTF8.php
Broken
(restart webserver)
% while true; do elinks -dump 'http://localhost/checkUTF8.php'; done
Broken
OK
OK
OK
OK
^C
[2007-05-31 01:00:00] 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.
[2007-05-23 22:54:05] sni...@php.net
Try the latest snapshot, and if it fails (propably) then run it through
valgrind (using CLI) and see if there are any errors, etc. Also, what
was the configure line you used to make 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/38926
--
Edit this bug report at http://bugs.php.net/?id=38926edit=1
#47113 [Bgs]: Corrupt DBF When Using DATE
ID: 47113
User updated by: Shock dot art at gmail dot com
Reported By: Shock dot art at gmail dot com
Status: Bogus
Bug Type: dBase related
Operating System: FreeBSD 6.3-STABLE
PHP Version: 5.2.8
New Comment:
Don't fixed!
Previous Comments:
[2009-01-17 22:37:26] fel...@php.net
Duplicated of Bug #46282, which was hopefully fixed today.
Thanks.
[2009-01-15 10:46:39] Shock dot art at gmail dot com
Creating a dBase file with a DATE-field type, will corrupt the
database.
[2009-01-15 10:43:36] Shock dot art at gmail dot com
Description:
Creating or opening a dBase file with a DATE-field type, will create a
database with lenght = 0 for date field type.
Reproduce code:
---
Reproduce code:
---
?php
// database definition
$def = array(
array(date, D),
array(name, C, 50),
array(email,C, 128),
array(ismember, L)
);
// creation
if (!dbase_create('test.dbf', $def)) {
echo Error, can't create the database\n;
}
// open in read-write mode
$db = dbase_open('test.dbf', 2);
if ($db) {
for ($i = 0; $i 5; $i++) {
dbase_add_record($db, array(
date('Ymd'),
'Name #'. $i,
'Email #'. $i,
'T'));
}
dbase_close($db);
}
?
Expected result:
A simple database with 5 lines, where DATE, Name Email are entered
correctly.
Actual result:
--
The code above will create file called test.dbf, which is corrupted
when opening it with any normal DBF-viewer (CDBF, DBF Manager, ...).
If
the DATE-field is replaced with a CHAR-field, all works fine.
Date-format is taken from the PHP.NET website and confirmed by the
dBase-format.
--
Edit this bug report at http://bugs.php.net/?id=47113edit=1
#38926 [Opn-Csd]: --zend-multibyte doesn't work for a few seconds on startup
ID: 38926
User updated by: lapo at lapo dot it
Reported By: lapo at lapo dot it
-Status: Open
+Status: Closed
Bug Type:mbstring related
PHP Version: 5.2.8
New Comment:
I correct myself, in fact 5.2.8 *fixed the bug*, not the opposite.
In php.ini needs to be mbstring.language = uni as changing the
internal in the script is too late (the script has already been
loaded) and anything else is too narrow to contain the correctly
decoded chars.
Previous Comments:
[2009-01-18 09:28:18] lapo at lapo dot it
I've noticed --zend-multibyte always works if the module mbstring is
NOT included, fails if it's there.
Can the module interfere with the loading of .php?
[2009-01-16 10:25:32] lapo at lapo dot it
Re-opening as something clearly changed in the behavior in 5.2.6-5.2.8
changes (something erratically working became something that doesn't
work at all).
I will take a look at the diff myself in the weekend.
[2009-01-16 10:22:13] lapo at lapo dot it
Ah, something changed with 5.2.8 indeed: it now is always broken,
doesn't fix after a bit like it did before.
A bit more clarity about the test script, an hex dump:
% hd checkUTF8.php
ef bb bf 3c 3f 3d 20 28 27 c3 a0 27 20 3d 3d 20 |?= ('à'
== |
0010 22 5c 78 43 33 5c 78 41 30 22 29 20 3f 20 22 4f
|\xC3\xA0) ? O|
0020 4b 5c 6e 22 20 3a 20 22 42 72 6f 6b 65 6e 5c 6e |K\n :
Broken\n|
0030 22 20 3f 3e | ?|
[2008-06-21 08:45:35] lapo at lapo dot it
Using PHP 5.2.6 the situation is changed slightly: it seems that now
the page is broken on the first access only:
% php checkUTF8.php
Broken
(restart webserver)
% while true; do elinks -dump 'http://localhost/checkUTF8.php'; done
Broken
OK
OK
OK
OK
^C
[2007-05-31 01:00:00] 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/38926
--
Edit this bug report at http://bugs.php.net/?id=38926edit=1
#47113 [Bgs]: Corrupt DBF When Using DATE
ID: 47113
User updated by: Shock dot art at gmail dot com
Reported By: Shock dot art at gmail dot com
Status: Bogus
Bug Type: dBase related
Operating System: FreeBSD 6.3-STABLE
PHP Version: 5.2.8
New Comment:
Be attentive!!!
To fix this bug maybe must do replace some lines in module dbf_head.c
For function put_dbf_field()
In put_dbf_field Was:
196 switch (dbf-db_type) {
197 case 'N':
198 dbfield.dbf_flen[0] = dbf-db_flen;
199 dbfield.dbf_flen[1] = dbf-db_fdc;
200 break;
201 case 'D':
202 dbf-db_flen = 8;
203 break;
204 case 'L':
205 dbf-db_flen = 1;
206 break;
207 default:
208 put_short(dbfield.dbf_flen, dbf-db_flen);
maybe correct Is:
196 switch (dbf-db_type) {
197 case 'N':
198 dbfield.dbf_flen[0] = dbf-db_flen;
199 dbfield.dbf_flen[1] = dbf-db_fdc;
200 break;
201 case 'D':
202(delete) dbf-db_flen = 8;
202(add)dbfield.dbf_flen[0] = 8;
(add)dbfield.dbf_flen[1] = ??? dbf-db_fdc;?
203 break;
204 case 'L':
205(delete) dbf-db_flen = 1;
205(add)dbfield.dbf_flen[0] = 1;
(add)dbfield.dbf_flen[1] = ??? dbf-db_fdc;?
206 break;
207 default:
208 put_short(dbfield.dbf_flen, dbf-db_flen);
dbfield.dbf_flen and dbf-db_flen - is not the same!!! :)
compare with function get_dbf_field:
153 dbf-db_type = dbfield.dbf_type;
154 switch (dbf-db_type) {
155 case 'N':
156 case 'F':
157 dbf-db_flen = dbfield.dbf_flen[0];
158 dbf-db_fdc = dbfield.dbf_flen[1];
159 break;
160case 'D':
161 dbf-db_flen = 8;
162 break;
163 case 'L':
164 dbf-db_flen = 1;
165 break;
166 default:
167 dbf-db_flen = get_short(dbfield.dbf_flen);
168 break;
169 }
I hopefully this is solve the problem and someone with an CVS account
can use this info to
get the change into the repository.
And i hope that someone with an CVS don't be a lazy for check my
code. :)
Previous Comments:
[2009-01-18 10:29:06] Shock dot art at gmail dot com
Don't fixed!
[2009-01-17 22:37:26] fel...@php.net
Duplicated of Bug #46282, which was hopefully fixed today.
Thanks.
[2009-01-15 10:46:39] Shock dot art at gmail dot com
Creating a dBase file with a DATE-field type, will corrupt the
database.
[2009-01-15 10:43:36] Shock dot art at gmail dot com
Description:
Creating or opening a dBase file with a DATE-field type, will create a
database with lenght = 0 for date field type.
Reproduce code:
---
Reproduce code:
---
?php
// database definition
$def = array(
array(date, D),
array(name, C, 50),
array(email,C, 128),
array(ismember, L)
);
// creation
if (!dbase_create('test.dbf', $def)) {
echo Error, can't create the database\n;
}
// open in read-write mode
$db = dbase_open('test.dbf', 2);
if ($db) {
for ($i = 0; $i 5; $i++) {
dbase_add_record($db, array(
date('Ymd'),
'Name #'. $i,
'Email #'. $i,
'T'));
}
dbase_close($db);
}
?
Expected result:
A simple database with 5 lines, where DATE, Name Email are entered
correctly.
Actual result:
--
The code above will create file called test.dbf, which is corrupted
when opening it with any normal DBF-viewer (CDBF, DBF Manager, ...).
If
the DATE-field is replaced with a CHAR-field, all works fine.
Date-format is taken from the PHP.NET website and confirmed by the
dBase-format.
--
Edit this bug report at http://bugs.php.net/?id=47113edit=1
#47113 [Bgs]: Corrupt DBF When Using DATE
ID: 47113
Updated by: fel...@php.net
Reported By: Shock dot art at gmail dot com
Status: Bogus
Bug Type: dBase related
Operating System: FreeBSD 6.3-STABLE
PHP Version: 5.2.8
New Comment:
dbfield.dbf_flen and dbf-db_flen - is not the same!!! :)
Sure, that was the problem. And 'D' an 'L' can use perfectly the
put_short(). They doesnt requires setting the value manually as 'N'.
What problem are you seeing? Thanks.
Previous Comments:
[2009-01-18 10:45:09] Shock dot art at gmail dot com
Be attentive!!!
To fix this bug maybe must do replace some lines in module dbf_head.c
For function put_dbf_field()
In put_dbf_field Was:
196 switch (dbf-db_type) {
197 case 'N':
198 dbfield.dbf_flen[0] = dbf-db_flen;
199 dbfield.dbf_flen[1] = dbf-db_fdc;
200 break;
201 case 'D':
202 dbf-db_flen = 8;
203 break;
204 case 'L':
205 dbf-db_flen = 1;
206 break;
207 default:
208 put_short(dbfield.dbf_flen, dbf-db_flen);
maybe correct Is:
196 switch (dbf-db_type) {
197 case 'N':
198 dbfield.dbf_flen[0] = dbf-db_flen;
199 dbfield.dbf_flen[1] = dbf-db_fdc;
200 break;
201 case 'D':
202(delete) dbf-db_flen = 8;
202(add)dbfield.dbf_flen[0] = 8;
(add)dbfield.dbf_flen[1] = ??? dbf-db_fdc;?
203 break;
204 case 'L':
205(delete) dbf-db_flen = 1;
205(add)dbfield.dbf_flen[0] = 1;
(add)dbfield.dbf_flen[1] = ??? dbf-db_fdc;?
206 break;
207 default:
208 put_short(dbfield.dbf_flen, dbf-db_flen);
dbfield.dbf_flen and dbf-db_flen - is not the same!!! :)
compare with function get_dbf_field:
153 dbf-db_type = dbfield.dbf_type;
154 switch (dbf-db_type) {
155 case 'N':
156 case 'F':
157 dbf-db_flen = dbfield.dbf_flen[0];
158 dbf-db_fdc = dbfield.dbf_flen[1];
159 break;
160case 'D':
161 dbf-db_flen = 8;
162 break;
163 case 'L':
164 dbf-db_flen = 1;
165 break;
166 default:
167 dbf-db_flen = get_short(dbfield.dbf_flen);
168 break;
169 }
I hopefully this is solve the problem and someone with an CVS account
can use this info to
get the change into the repository.
And i hope that someone with an CVS don't be a lazy for check my
code. :)
[2009-01-18 10:29:06] Shock dot art at gmail dot com
Don't fixed!
[2009-01-17 22:37:26] fel...@php.net
Duplicated of Bug #46282, which was hopefully fixed today.
Thanks.
[2009-01-15 10:46:39] Shock dot art at gmail dot com
Creating a dBase file with a DATE-field type, will corrupt the
database.
[2009-01-15 10:43:36] Shock dot art at gmail dot com
Description:
Creating or opening a dBase file with a DATE-field type, will create a
database with lenght = 0 for date field type.
Reproduce code:
---
Reproduce code:
---
?php
// database definition
$def = array(
array(date, D),
array(name, C, 50),
array(email,C, 128),
array(ismember, L)
);
// creation
if (!dbase_create('test.dbf', $def)) {
echo Error, can't create the database\n;
}
// open in read-write mode
$db = dbase_open('test.dbf', 2);
if ($db) {
for ($i = 0; $i 5; $i++) {
dbase_add_record($db, array(
date('Ymd'),
'Name #'. $i,
'Email #'. $i,
'T'));
}
dbase_close($db);
}
?
Expected result:
A simple database with 5 lines, where DATE, Name Email are entered
correctly.
Actual result:
--
The code above will create file called test.dbf, which is corrupted
when opening it with any normal DBF-viewer (CDBF, DBF Manager, ...).
If
the DATE-field is replaced with a CHAR-field, all works fine.
Date-format is taken from the PHP.NET website and confirmed by the
dBase-format.
--
Edit this bug report at http://bugs.php.net/?id=47113edit=1
#47130 [Fbk-Bgs]: JSON problems
ID: 47130
Updated by: scott...@php.net
Reported By: svacinap at compsys dot cz
-Status: Feedback
+Status: Bogus
Bug Type: JSON related
Operating System: Linux Slackware 12.1
PHP Version: 5.2.8
New Comment:
Any strings passed to json_encode should be valid utf-8, the manual
and error message make this clear.
Previous Comments:
[2009-01-18 02:49:17] svacinap at compsys dot cz
Hi, thanks for interest :-) I am not a php programmer, so I don't know
howto help any better, sorry. In the apache error log you can see this:
/var/www/mail/modules/email/json.php on line 1310
so line 1310 is the last line of the json.php code, it's end like this:
}
}
}catch(Exception $e)
{
$response['feedback']=$e-getMessage();
$response['success']=false;
}
if(defined('IMAP_CONNECTED'))
{
$imap-close();
}
echo json_encode($response);
--
line 1310 is this: echo json_encode($response);
I don't really know If this is help to you. Please let my know, I will
contact programmer of this code.
Thanks
[2009-01-17 18:26:05] johan...@php.net
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 ?php and ends 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.
[2009-01-16 15:56:16] svacinap at compsys dot cz
Description:
Please read this:
http://www.group-office.com/forum/viewtopic.php?f=1t=4255start=0
php log:
[Fri Jan 16 10:26:34 2009] [error] [client 78.102.78.55] PHP Warning:
json_encode() [a href='function.json-encode'function.json-encode/a]:
Invalid UTF-8 sequence in argument in
/var/www/mail/modules/email/json.php on line 1310
--
Edit this bug report at http://bugs.php.net/?id=47130edit=1
#47048 [Com]: Segfault with new pg_meta_data
ID: 47048
Comment by: webs dot support at gmail dot com
Reported By: ml-php dot net at bettercom dot de
Status: Feedback
Bug Type: PostgreSQL related
Operating System: FreeBSD 7.0-RELEASE
PHP Version: 5.2.8
New Comment:
Felipe, check your code for the operating system FreeBSD 7.0 and you
catch a bug.
Previous Comments:
[2009-01-17 22:56:08] fel...@php.net
It works fine for me, see:
teste=# SELECT table_schema, table_name FROM information_schema.tables
WHERE table_schema = 'public';
table_schema | table_name
--+
public | id
var_dump(pg_meta_data($x, 'id'));
array(1) {
[id]=
array(6) {
[num]=
int(1)
[type]=
string(4) int4
[len]=
int(4)
[not null]=
bool(false)
[has default]=
bool(false)
[array dims]=
int(0)
}
}
[2009-01-17 21:59:53] igulyaev at gmail dot com
part of pgsql.c
src = estrdup(table_name);
tmp_name = php_strtok_r(src, ., tmp_name2);
if (!*tmp_name2) {
/* Default schema */
tmp_name2 = tmp_name;
tmp_name = public;
}
in condition tmp_name2 is NULL if table_name without scheme name
[2009-01-17 21:06:11] webs dot support at gmail dot com
(gdb) where
#0 0x000804d338e1 in php_pgsql_meta_data () from
/usr/local/lib/php/20060613-debug/pgsql.so
#1 0x000804d344e9 in zif_pg_meta_data () from
/usr/local/lib/php/20060613-debug/pgsql.so
#2 0x005c7e29 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffcf50) at zend_vm_execute.h:200
#3 0x005cea3f in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fffcf50) at zend_vm_execute.h:1729
#4 0x005c7864 in execute (op_array=0x929588) at
zend_vm_execute.h:92
#5 0x0059b830 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/ports/lang/php5/work/php-5.2.8/Zend/zend.c:1134
#6 0x0053aecb in php_execute_script
(primary_file=0x7fffe890) at
/usr/ports/lang/php5/work/php-5.2.8/main/main.c:2023
#7 0x00629957 in main (argc=2, argv=0x7fffea10) at
/usr/ports/lang/php5/work/php-5.2.8/sapi/cli/php_cli.c:1133
[2009-01-16 11:30:59] j...@php.net
Compile PHP using --enable-debug option and provide a new, useful
backtrace.
[2009-01-14 06:33:39] ml-php dot net at bettercom dot de
postgres-8.3.5 is the version I'm using here (server libs)
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/47048
--
Edit this bug report at http://bugs.php.net/?id=47048edit=1
#47125 [Opn-Bgs]: MCRYPT_RIJNDAEL_256, 192 do not use blocksizes of 128 bit as specified in AES
ID: 47125
Updated by: der...@php.net
Reported By: j dot andersch at foofox dot de
-Status: Open
+Status: Bogus
Bug Type: mcrypt related
Operating System: *
PHP Version: 5.2.8
New Comment:
THis is not a bug in PHP, but in libmcrypt like you already mentioned
yourself:
MCRYPT_RIJNDAEL_192 uses int nb=6 and the MCRYPT_RIJNDAEL_256 uses
int nb=8 insted of int nb = 4 in
libmcrypt-2.5.8/modules/algorithms/rijndael-256.c and
rijndael-192.c
Previous Comments:
[2009-01-16 10:56:13] j dot andersch at foofox dot de
Description:
According to the AES-specifications [1] the AES-Rijndael encrypts
always blocks of 128 bits of binary data with a key of 128, 196 or 256
bit, and therefore the output should always be 128 bit.
However only the MCRYPT_RIJNDAEL_128 algorithm conforms with [1],
because the blocksizes to be encrypted of the other implementations
expand to 192 and 256 bit instead of using 128 bit.
MCRYPT_RIJNDAEL_192 uses int nb=6 and the MCRYPT_RIJNDAEL_256 uses int
nb=8 insted of int nb = 4 in
libmcrypt-2.5.8/modules/algorithms/rijndael-256.c and rijndael-192.c
[1] Federal Information Processing Standards Publication 197, November
26, 2001, Announcing the ADVANCED ENCRYPTION STANDARD (AES)
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
Reproduce code:
---
?php
# test if AES complies with [1]
$key = 'E8E9EAEBEDEEEFF0F2F3F4F5F7F8F9FA';
$plaintext = '014BAF2278A69D331D5180103643E99A';
# expected cipher: 6743C3D1519AB4F2CD9A78AB09A511BD
# convert input
$key = pack('H*', $key);
$plaintext = pack('H*', $plaintext);
# encrypt
$td = mcrypt_module_open(MCRYPT_RIJNDAEL_128, '', MCRYPT_MODE_ECB,
'');
$iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_RAND);
mcrypt_generic_init($td, $key, $iv);
$encrypted_data = mcrypt_generic($td, $plaintext);
mcrypt_generic_deinit($td);
mcrypt_module_close($td);
# display encryption value: should be 6743c3d1519ab4f2cd9a78ab09a511bd
echo bin2hex($encrypted_data);
?
Expected result:
modifying the script for the MCRYPT_RIJNDAEL_192 and
MCRYPT_RIJNDAEL_256 bit encryption should give:
Key (192): 04050607090A0B0C0E0F10111314151618191A1B1D1E1F20
Plaintext:76777475F1F2F3F4F8F9E6E07172
Ciphertext: 5d1ef20dced6bcbc12131ac7c54788aa
Key (256):
08090A0B0D0E0F10121314151718191A1C1D1E1F21222324262728292B2C2D2E
Plaintext:069A007FC76A459F98BAF917FEDF9521
Ciphertext:080e9517eb1677719acf728086040ae3
Actual result:
--
192: d08b9555cdcef5cfa6c421654e5efc686408f0e120c1ec38
256: 01e0d5ddff688d8377101cd6fb60b4474a66a0d3a22e72a75dbe24daa9aa4dfe
--
Edit this bug report at http://bugs.php.net/?id=47125edit=1
#47128 [Opn-Bgs]: NLS_DATE_FORMAT
ID: 47128
Updated by: j...@php.net
Reported By: iteam dot soft at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: Red Hat 8.0
PHP Version: 5.2.8
New Comment:
And you immediately assume your bad configuration is a bug in
PHP..pff..
Previous Comments:
[2009-01-16 14:55:23] iteam dot soft at gmail dot com
Description:
For about a week ago I had installed on my box Apache 2.2.10 with PHP
5.2.7. Beside this the php was compiled with FirebirdSql and Oracle
Instant Client.
On apache start I put a env variabile
export NLS_DATE_FORMAT=DD.MM.
On my application start point from PHP I also double ensure the
NLS_DATE_FORMAT it's set so I put also
putenv('NLS_DATE_FORMAT=DD.MM.');
Everything was ok and my application display the date format from
oracle as I set it. All good.
Last week ... I made upgrade to Apache 2.2.11 and PHP 5.28.
After upgrade nothing change to my application or configuration only
this applications (apacheand and php) as I mentioned above.
From this point the date format that I was getting from Oracle was
NOT what I set.
The returned date format was in Oracle standard DD-M-RR.
So I try everything .. recheck ... reset env variables .. put extra
configuration for php ... but no result. The same bad date.
I know I could use the alter session as a work-arround ... but this
envolves running the alter session eache time user wants information
from the database. The application it's huge and with a lot of users
and it's running on the intranet system.
So I preffer the PUTENV method.
So all was ok until the upgrade from apache 2.2.10 to 2.2.11 and php
5.2.7 to 5.2.8
Reproduce code:
---
I try all this ... at once and one by one ... no result.
$_ENV[NLS_DATE_FORMAT] = 'DD.MM.';
putenv('NLS_DATE_FORMAT=DD.MM.');
apache_setenv('NLS_DATE_FORMAT=DD.MM.');
Expected result:
The Oracle date format to be:
22.01.2009
Actual result:
--
22-JAN-09
--
Edit this bug report at http://bugs.php.net/?id=47128edit=1
#47048 [Fbk-Csd]: Segfault with new pg_meta_data
ID: 47048
Updated by: fel...@php.net
Reported By: ml-php dot net at bettercom dot de
-Status: Feedback
+Status: Closed
Bug Type: PostgreSQL related
Operating System: FreeBSD 7.0-RELEASE
PHP Version: 5.2.8
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Thanks gentlemen.
Previous Comments:
[2009-01-18 20:23:29] webs dot support at gmail dot com
Felipe, check your code for the operating system FreeBSD 7.0 and you
catch a bug.
[2009-01-17 22:56:08] fel...@php.net
It works fine for me, see:
teste=# SELECT table_schema, table_name FROM information_schema.tables
WHERE table_schema = 'public';
table_schema | table_name
--+
public | id
var_dump(pg_meta_data($x, 'id'));
array(1) {
[id]=
array(6) {
[num]=
int(1)
[type]=
string(4) int4
[len]=
int(4)
[not null]=
bool(false)
[has default]=
bool(false)
[array dims]=
int(0)
}
}
[2009-01-17 21:59:53] igulyaev at gmail dot com
part of pgsql.c
src = estrdup(table_name);
tmp_name = php_strtok_r(src, ., tmp_name2);
if (!*tmp_name2) {
/* Default schema */
tmp_name2 = tmp_name;
tmp_name = public;
}
in condition tmp_name2 is NULL if table_name without scheme name
[2009-01-17 21:06:11] webs dot support at gmail dot com
(gdb) where
#0 0x000804d338e1 in php_pgsql_meta_data () from
/usr/local/lib/php/20060613-debug/pgsql.so
#1 0x000804d344e9 in zif_pg_meta_data () from
/usr/local/lib/php/20060613-debug/pgsql.so
#2 0x005c7e29 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffcf50) at zend_vm_execute.h:200
#3 0x005cea3f in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fffcf50) at zend_vm_execute.h:1729
#4 0x005c7864 in execute (op_array=0x929588) at
zend_vm_execute.h:92
#5 0x0059b830 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/ports/lang/php5/work/php-5.2.8/Zend/zend.c:1134
#6 0x0053aecb in php_execute_script
(primary_file=0x7fffe890) at
/usr/ports/lang/php5/work/php-5.2.8/main/main.c:2023
#7 0x00629957 in main (argc=2, argv=0x7fffea10) at
/usr/ports/lang/php5/work/php-5.2.8/sapi/cli/php_cli.c:1133
[2009-01-16 11:30:59] j...@php.net
Compile PHP using --enable-debug option and provide a new, useful
backtrace.
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/47048
--
Edit this bug report at http://bugs.php.net/?id=47048edit=1
#47089 [Asn-Fbk]: Shebang is printed under Windows
ID: 47089 Updated by: paj...@php.net Reported By: vr...@php.net -Status: Assigned +Status: Feedback Bug Type: CGI related Operating System: win32 only PHP Version: 5.3.0alpha4-dev Assigned To: pajoye New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works with all 5.3.0 snaps, VC9VC6 TS and NTS: C:\Users\..\php53snapphp \php-sdk\php53\vc9\x86\PHP_5_3\shebang.php 5.3.0alpha4-dev Can you try again using a recent snapshot please? Previous Comments: [2009-01-14 20:04:56] paj...@php.net I have to check (assigned to me +) [2009-01-14 19:31:44] il...@php.net Pierre, Is there a problem with mmap() on windows where it ignores the start offset? [2009-01-14 09:19:47] vr...@php.net php.exe in Windows distribution is CLI. ?php echo PHP_SAPI; ? prints cli. [2009-01-13 18:18:12] il...@php.net What SAPI are you using? [2009-01-13 12:44:46] vr...@php.net Description: The shebang line (e.g. #!/usr/bin/php) is printed in PHP 5.3.0alpha4-dev by php.exe while it was not printed in earlier versions (e.g. PHP 5.2.8). This is a backwards incompatible change which brings platform difference. Reproduce code: --- #!/usr/bin/php ?php echo PHP_VERSION; ? Expected result: 5.3.0alpha4-dev Actual result: -- #!/usr/bin/php 5.3.0alpha4-dev -- Edit this bug report at http://bugs.php.net/?id=47089edit=1
#47128 [Bgs]: NLS_DATE_FORMAT
ID: 47128
User updated by: iteam dot soft at gmail dot com
Reported By: iteam dot soft at gmail dot com
Status: Bogus
Bug Type: *General Issues
Operating System: Red Hat 8.0
PHP Version: 5.2.8
New Comment:
The configuration of apache and php it's ok.
Everything works the same except this date issue.
I also ... installed again the php 5.2.7 with apache 2.2.11 and the
date work just fine now ... with the bad configuration. The
configuration files I keep ... and just replace the initials one.
If ... it's something wrong with my configuration ... which I don't
see how it's possible for my server ... can you give me a hint.
Previous Comments:
[2009-01-18 23:12:07] j...@php.net
And you immediately assume your bad configuration is a bug in
PHP..pff..
[2009-01-16 14:55:23] iteam dot soft at gmail dot com
Description:
For about a week ago I had installed on my box Apache 2.2.10 with PHP
5.2.7. Beside this the php was compiled with FirebirdSql and Oracle
Instant Client.
On apache start I put a env variabile
export NLS_DATE_FORMAT=DD.MM.
On my application start point from PHP I also double ensure the
NLS_DATE_FORMAT it's set so I put also
putenv('NLS_DATE_FORMAT=DD.MM.');
Everything was ok and my application display the date format from
oracle as I set it. All good.
Last week ... I made upgrade to Apache 2.2.11 and PHP 5.28.
After upgrade nothing change to my application or configuration only
this applications (apacheand and php) as I mentioned above.
From this point the date format that I was getting from Oracle was
NOT what I set.
The returned date format was in Oracle standard DD-M-RR.
So I try everything .. recheck ... reset env variables .. put extra
configuration for php ... but no result. The same bad date.
I know I could use the alter session as a work-arround ... but this
envolves running the alter session eache time user wants information
from the database. The application it's huge and with a lot of users
and it's running on the intranet system.
So I preffer the PUTENV method.
So all was ok until the upgrade from apache 2.2.10 to 2.2.11 and php
5.2.7 to 5.2.8
Reproduce code:
---
I try all this ... at once and one by one ... no result.
$_ENV[NLS_DATE_FORMAT] = 'DD.MM.';
putenv('NLS_DATE_FORMAT=DD.MM.');
apache_setenv('NLS_DATE_FORMAT=DD.MM.');
Expected result:
The Oracle date format to be:
22.01.2009
Actual result:
--
22-JAN-09
--
Edit this bug report at http://bugs.php.net/?id=47128edit=1
