date:20061002

 ID:   38874
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dabbaking at gmail dot com
-Status:   Assigned
+Status:   Feedback
 Bug Type: MySQLi related
 Operating System: Win32
 PHP Version:  5.2.0RC5
 Assigned To:  georg
 New Comment:

Please set display_startup_errors to On and run `php -m` (first make
sure the CLI binary uses the same php.ini with php_mysqli.dll
enabled).
Paste here all the error messages you get.


Previous Comments:


[2006-09-22 21:45:08] dabbaking at gmail dot com

I have RC5-dev running. Still a problem.



[2006-09-19 19:58:41] dabbaking at gmail dot com

I'm not getting any errors. The normal mysql extension loads. I have
libmysql.dll in my path before mysql.



[2006-09-19 15:02:52] [EMAIL PROTECTED]

Do you get any error messages? Does mysql extension load? Do you have
libmysql.dll from the php distribution in your PATH *before* mysql
database directory.



[2006-09-18 21:54:04] dabbaking at gmail dot com

I just want to note that the other extensions on the list loaded fine.
Including the normal mysql extension. I have MySQL 5.0 running.



[2006-09-18 21:51:37] dabbaking at gmail dot com

Description:

The mysqli extension won't load.

Reproduce code:
---
extension=php_mysqli.dll

Expected result:

Suppose to load the extension

Actual result:
--
The extension did not load.





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

#38882 [Opn->Fbk]: ldap_connect causes Segmentation fault

 ID:   38882
 Updated by:   [EMAIL PROTECTED]
 Reported By:  d dot wynne at ljmu dot ac dot uk
-Status:   Open
+Status:   Feedback
 Bug Type: LDAP related
 Operating System: SuSE 10.1 x86_64
 PHP Version:  4.4.4
 New Comment:

See also bug #38819 and the solution inside.
Let us know if it works for you.


Previous Comments:


[2006-09-29 15:04:24] d dot wynne at ljmu dot ac dot uk

OK, Built & installed. Presumably now there's some new options or
statements to the /usr/bin/php CLI script with the ldap_connect
statement.



[2006-09-29 14:45:19] [EMAIL PROTECTED]

`make clean` is required.



[2006-09-29 14:44:04] d dot wynne at ljmu dot ac dot uk

.
 Zend/zend_sprintf.lo Zend/zend_ini.lo Zend/zend_qsort.lo
Zend/zend_multibyte.lo
 Zend/zend_strtod.lo Zend/zend_execute.lo sapi/cli/php_cli.lo
sapi/cli/getopt.lo
 main/internal_functions_cli.lo -lcrypt -lcrypt -lsybdb -lldap -llber
-lresolv -
lm -ldl -lnsl -lssl -lcrypto -ldl -ldl -lm -lnsl -lirc -lclntsh -lcrypt
-lcrypt 
 -o sapi/cli/php
ext/standard/info.lo: In function `php_info_print_table_header':
/home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:756:
undefined refere
nce to `ts_resource_ex'
ext/standard/info.lo: In function `php_info_print_table_row':
/home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:800:
undefined refere
nce to `ts_resource_ex'
ext/standard/info.lo: In function `php_print_gpcse_array':
/home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:119:
undefined refere
nce to `executor_globals_id'
ext/standard/info.lo: In function `php_info_write_wrapper':
/home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:67:
undefined referen
ce to `ts_resource_ex'
ext/standard/info.lo: In function `php_print_info':
/home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:624:
undefined refere
nce to `executor_globals_id'
/home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:554:
undefined refere
nce to `sapi_globals_id'



[2006-09-29 14:06:23] [EMAIL PROTECTED]

>a) The PHP build fails if I do
>--enable-experimental-zts

Please elaborate.



[2006-09-29 14:00:00] d dot wynne at ljmu dot ac dot uk

Now I'm stuck:

a) The PHP build fails if I do
--enable-experimental-zts

b) SuSE 10.1 only ships with apache2 binary RPM's. I downloaded apache
1.3 source and compiled / installed  & ran, but httpd just dies, no
errors in the loge either. In any case a downgrade to apache 1.3 isn't
an option as I have other apache 2.x only modules that I besides PHP.

c) No updates on the SuSE update server for either apache2 or
openldap.

Problem appears to point to OpenLDAP, so all I can think of next is to
compile / install the latest build. Maybe this is an anomaly with 64
bit machines, which is why it's reporing is not more widespread.



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

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

#38996 [Opn->Csd]: PDO persistant connection breaks on mysql restart

 ID:   38996
 Updated by:   [EMAIL PROTECTED]
 Reported By:  fifthnormal at hotmail dot com
-Status:   Open
+Status:   Closed
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.1.6
 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.




Previous Comments:


[2006-09-29 19:13:28] fifthnormal at hotmail dot com

Description:

Hello,

I am using PDO as a database layer to connect to MySQL. I add the
attribute to use a persistant connection. This works as expected

If the MySQL server is restarted, then PHP responds with this error
message:

SQLSTATE[HY000]: General error: 2006 MySQL server has gone away

>From this point on the connection won't work. This error message will
only go away after httpd has been restarted.

Thanks,

Daniel Burge

Reproduce code:
---
 true));
?>



Expected result:

I would expect that PDO would reestablish the connection if it drops. 

Actual result:
--
PDO returns the error message:

SQLSTATE[HY000]: General error: 2006 MySQL server has gone away






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

#39019 [Opn->Bgs]: Header And Location Problem

 ID:   39019
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bojan dot saksida at volja dot net
-Status:   Open
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: Windows XP
 PHP Version:  6CVS-2006-10-02 (snap)
 New Comment:

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.




Previous Comments:


[2006-10-02 21:10:21] bojan dot saksida at volja dot net

I also tried using PHP5 whitch was included in instalation in NuSphere
PhpED, I got the same result



[2006-10-02 21:08:55] bojan dot saksida at volja dot net

Description:

i have file index.php

insede is:

//to doo
if statment
{
header("Location: register.php");
}
//to doo
if statment2
{
header("Location: login.php");
}

end of file index.php

i can easly redirect to login.php but i can't to register.php. if i
disable login.php header, then i can go to register.php. if i put:
header("Location: register.php");
die("");

in this case both Location headers works fine.







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

#39019 [Opn]: Header And Location Problem

2006-10-02 Thread bojan dot saksida at volja dot net

 ID:   39019
 User updated by:  bojan dot saksida at volja dot net
 Reported By:  bojan dot saksida at volja dot net
 Status:   Open
 Bug Type: *General Issues
 Operating System: Windows XP
 PHP Version:  6CVS-2006-10-02 (snap)
 New Comment:

I also tried using PHP5 whitch was included in instalation in NuSphere
PhpED, I got the same result


Previous Comments:


[2006-10-02 21:08:55] bojan dot saksida at volja dot net

Description:

i have file index.php

insede is:

//to doo
if statment
{
header("Location: register.php");
}
//to doo
if statment2
{
header("Location: login.php");
}

end of file index.php

i can easly redirect to login.php but i can't to register.php. if i
disable login.php header, then i can go to register.php. if i put:
header("Location: register.php");
die("");

in this case both Location headers works fine.







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

#39019 [NEW]: Header And Location Problem

2006-10-02 Thread bojan dot saksida at volja dot net

From: bojan dot saksida at volja dot net
Operating system: Windows XP
PHP version:  6CVS-2006-10-02 (snap)
PHP Bug Type: *General Issues
Bug description:  Header And Location Problem

Description:

i have file index.php

insede is:

//to doo
if statment
{
header("Location: register.php");
}
//to doo
if statment2
{
header("Location: login.php");
}

end of file index.php

i can easly redirect to login.php but i can't to register.php. if i
disable login.php header, then i can go to register.php. if i put:
header("Location: register.php");
die("");

in this case both Location headers works fine.



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

#39004 [Opn->Csd]: Configure Command './configure' 'dummy' 'grep' 'ggrep' !?

 ID:   39004
 Updated by:   [EMAIL PROTECTED]
 Reported By:  phpbugs at thequod dot de
-Status:   Open
+Status:   Closed
 Bug Type: *Compile Issues
 Operating System: Ubuntu Linux
 PHP Version:  5CVS-2006-09-30 (CVS)
 Assigned To:  iliaa
 New Comment:

Ok, that's now fixed too.


Previous Comments:


[2006-10-02 20:28:59] phpbugs at thequod dot de

I've noticed it in php.cvs, but this as before the patch.

config.nice looks ok:
"""
#! /bin/sh
#
# Created by configure

'./configure' \
'--enable-calendar' \
'--enable-exif' \
...
"""

But in phpinfo it does not:
Configure Command 
=>  '--enable-calendar' '--enable-exif' ...
(missing the "./configure" command itself)



[2006-10-02 19:53:48] [EMAIL PROTECTED]

Please try the next snapshot, I've applied one more fix.



[2006-10-02 19:33:25] phpbugs at thequod dot de

Not quite. There are now single quotes again, but the 
leading "./configure" is missing.

If this is the desired behaviour (different to 5.1 at 
least), then ok.



[2006-10-02 15:35:03] [EMAIL PROTECTED]

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.





[2006-10-01 22:48:07] phpbugs at thequod dot de

Also the initial "./configure" command is missing in the 
output after applying the patch.



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

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

#39004 [Fbk->Opn]: Configure Command './configure' 'dummy' 'grep' 'ggrep' !?

2006-10-02 Thread phpbugs at thequod dot de

 ID:   39004
 User updated by:  phpbugs at thequod dot de
 Reported By:  phpbugs at thequod dot de
-Status:   Feedback
+Status:   Open
 Bug Type: *Compile Issues
 Operating System: Ubuntu Linux
 PHP Version:  5CVS-2006-09-30 (CVS)
 Assigned To:  iliaa
 New Comment:

I've noticed it in php.cvs, but this as before the patch.

config.nice looks ok:
"""
#! /bin/sh
#
# Created by configure

'./configure' \
'--enable-calendar' \
'--enable-exif' \
...
"""

But in phpinfo it does not:
Configure Command 
=>  '--enable-calendar' '--enable-exif' ...
(missing the "./configure" command itself)


Previous Comments:


[2006-10-02 19:53:48] [EMAIL PROTECTED]

Please try the next snapshot, I've applied one more fix.



[2006-10-02 19:33:25] phpbugs at thequod dot de

Not quite. There are now single quotes again, but the 
leading "./configure" is missing.

If this is the desired behaviour (different to 5.1 at 
least), then ok.



[2006-10-02 15:35:03] [EMAIL PROTECTED]

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.





[2006-10-01 22:48:07] phpbugs at thequod dot de

Also the initial "./configure" command is missing in the 
output after applying the patch.



[2006-10-01 22:44:07] phpbugs at thequod dot de

Better. But now all arguments are encapsulated in two 
single quotes, while they were given in one single quote 
before, e.g.:
Configure Command 
=>  ''--enable-calendar'' ''--enable-exif'' ...



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

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

#39004 [Opn->Fbk]: Configure Command './configure' 'dummy' 'grep' 'ggrep' !?

 ID:   39004
 Updated by:   [EMAIL PROTECTED]
 Reported By:  phpbugs at thequod dot de
-Status:   Open
+Status:   Feedback
-Bug Type: *General Issues
+Bug Type: *Compile Issues
 Operating System: Ubuntu Linux
 PHP Version:  5CVS-2006-09-30 (CVS)
 Assigned To:  iliaa
 New Comment:

Please try the next snapshot, I've applied one more fix.


Previous Comments:


[2006-10-02 19:33:25] phpbugs at thequod dot de

Not quite. There are now single quotes again, but the 
leading "./configure" is missing.

If this is the desired behaviour (different to 5.1 at 
least), then ok.



[2006-10-02 15:35:03] [EMAIL PROTECTED]

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.





[2006-10-01 22:48:07] phpbugs at thequod dot de

Also the initial "./configure" command is missing in the 
output after applying the patch.



[2006-10-01 22:44:07] phpbugs at thequod dot de

Better. But now all arguments are encapsulated in two 
single quotes, while they were given in one single quote 
before, e.g.:
Configure Command 
=>  ''--enable-calendar'' ''--enable-exif'' ...



[2006-10-01 21:51:37] [EMAIL PROTECTED]

Try this patch and let me know if that fixes the problem
http://bb.prohost.org/patch/bug39004.txt



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

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

#39004 [Csd->Opn]: Configure Command './configure' 'dummy' 'grep' 'ggrep' !?

2006-10-02 Thread phpbugs at thequod dot de

 ID:   39004
 User updated by:  phpbugs at thequod dot de
 Reported By:  phpbugs at thequod dot de
-Status:   Closed
+Status:   Open
 Bug Type: *General Issues
 Operating System: Ubuntu Linux
 PHP Version:  5CVS-2006-09-30 (CVS)
 Assigned To:  iliaa
 New Comment:

Not quite. There are now single quotes again, but the 
leading "./configure" is missing.

If this is the desired behaviour (different to 5.1 at 
least), then ok.


Previous Comments:


[2006-10-02 15:35:03] [EMAIL PROTECTED]

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.





[2006-10-01 22:48:07] phpbugs at thequod dot de

Also the initial "./configure" command is missing in the 
output after applying the patch.



[2006-10-01 22:44:07] phpbugs at thequod dot de

Better. But now all arguments are encapsulated in two 
single quotes, while they were given in one single quote 
before, e.g.:
Configure Command 
=>  ''--enable-calendar'' ''--enable-exif'' ...



[2006-10-01 21:51:37] [EMAIL PROTECTED]

Try this patch and let me know if that fixes the problem
http://bb.prohost.org/patch/bug39004.txt



[2006-10-01 20:46:35] phpbugs at thequod dot de

2.60-1 (Debian/Ubuntu)



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

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

#39018 [NEW]: Error control operator '@' fails to suppress "Uninitialized string offset"

2006-10-02 Thread mpb dot mail at gmail dot com

From: mpb dot mail at gmail dot com
Operating system: Gentoo Linux
PHP version:  5.1.6
PHP Bug Type: Scripting Engine problem
Bug description:  Error control operator '@' fails to suppress "Uninitialized 
string offset"

Description:

The error control operator '@' fails to suppress (some) "Uninitialized
string offset" notices.

See example for details.

The problem also occurs on with PHP 4.4.x.


Reproduce code:
---



Expected result:

Done!


Actual result:
--
Notice: Uninitialized string offset:  4 in /home/build/test.php on line 7

Notice: Uninitialized string offset:  4 in /home/build/test.php on line 8

Notice: Uninitialized string offset:  4 in /home/build/test.php on line 9

Notice: Uninitialized string offset:  4 in /home/build/test.php on line
10

Notice: Uninitialized string offset:  4 in /home/build/test.php on line
11
Done!


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

#39012 [Opn->Bgs]: Incorrect gmdate('U') and date_default_timezone_set()

 ID:   39012
 Updated by:   [EMAIL PROTECTED]
 Reported By:  djmaze at planet dot nl
-Status:   Open
+Status:   Bogus
 Bug Type: Date/time related
 Operating System: Windows
 PHP Version:  5.1.6
 New Comment:

time() also returns a unix timestamp. A unix timestamp is always in UTC
so it is pointless to do -date('Z') there is that would shift the time
two hours into the past.
time() and gmdate('U') show the same time, and that is correct.

But feel free to make your own functions which implement the wrong
logic.


Previous Comments:


[2006-10-02 18:05:57] djmaze at planet dot nl

You are contradicting.
Quote: Unix timestamps are always in GMT (=UTC) so there is no problem
here.

My server is set to CET which is currently GMT+2
time()-date('Z') = 1159724908 = UTC
gmdate('U') = 1159732108 = GMT+2

As you can see gmdate('U') is NOT UTC

I found so many more issues with the current date and time functions
that i'm planning to write my own php_utc extension with utcdate() and
utctime() functions with an explanation why.



[2006-10-02 09:41:45] [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

Unix timestamps are always in GMT (=UTC) so there is no problem here.



[2006-10-01 19:57:09] djmaze at planet dot nl

Description:

gmdate('U') shows the incorrect unix epoch.

http://php.net/gmdate: 'Format a GMT/UTC date/time'
http://php.net/date: 'U = Seconds since the Unix Epoch (January 1 1970
00:00:00 GMT)'

After calling date_default_timezone_set() everything is messed up, or
is that the whole purpose but someone forgot to document it?


Reproduce code:
---
 time(),
'date(\'U\')' => date('U'),
'date(\'Z\')'  => date('Z'),
'gmtime' => (time()-date('Z')),
'gmdate(\'U\')' => gmdate('U'),
'gmdate(\'Z\')' => gmdate('Z'),
'date_default_timezone' => date_default_timezone_get(),
);
}
$def = get_unixts();
date_default_timezone_set('UTC');
$set = get_unixts();

echo 'typenormalafter set
UTC';
foreach ($def as $t => $v)
{
echo "$t$v{$set[$t]}";
}
echo '';
?>

Expected result:

typenormal  after set UTC
time()  1159732108  1159724908
date('U')   1159732108  1159724908
date('Z')   72000
gmtime  1159724908  1159724908
gmdate('U') 1159724908  1159724908
gmdate('Z') 0   0


Actual result:
--
typenormal  after set UTC
time()  1159732108  1159732108
date('U')   1159732108  1159732108
date('Z')   72000
gmtime  1159724908  1159732108
gmdate('U') 1159732108  1159732108
gmdate('Z') 0   0






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

#39012 [Bgs->Opn]: Incorrect gmdate('U') and date_default_timezone_set()

2006-10-02 Thread djmaze at planet dot nl

 ID:   39012
 User updated by:  djmaze at planet dot nl
 Reported By:  djmaze at planet dot nl
-Status:   Bogus
+Status:   Open
 Bug Type: Date/time related
 Operating System: Windows
 PHP Version:  5.1.6
 New Comment:

You are contradicting.
Quote: Unix timestamps are always in GMT (=UTC) so there is no problem
here.

My server is set to CET which is currently GMT+2
time()-date('Z') = 1159724908 = UTC
gmdate('U') = 1159732108 = GMT+2

As you can see gmdate('U') is NOT UTC

I found so many more issues with the current date and time functions
that i'm planning to write my own php_utc extension with utcdate() and
utctime() functions with an explanation why.


Previous Comments:


[2006-10-02 09:41:45] [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

Unix timestamps are always in GMT (=UTC) so there is no problem here.



[2006-10-01 19:57:09] djmaze at planet dot nl

Description:

gmdate('U') shows the incorrect unix epoch.

http://php.net/gmdate: 'Format a GMT/UTC date/time'
http://php.net/date: 'U = Seconds since the Unix Epoch (January 1 1970
00:00:00 GMT)'

After calling date_default_timezone_set() everything is messed up, or
is that the whole purpose but someone forgot to document it?


Reproduce code:
---
 time(),
'date(\'U\')' => date('U'),
'date(\'Z\')'  => date('Z'),
'gmtime' => (time()-date('Z')),
'gmdate(\'U\')' => gmdate('U'),
'gmdate(\'Z\')' => gmdate('Z'),
'date_default_timezone' => date_default_timezone_get(),
);
}
$def = get_unixts();
date_default_timezone_set('UTC');
$set = get_unixts();

echo 'typenormalafter set
UTC';
foreach ($def as $t => $v)
{
echo "$t$v{$set[$t]}";
}
echo '';
?>

Expected result:

typenormal  after set UTC
time()  1159732108  1159724908
date('U')   1159732108  1159724908
date('Z')   72000
gmtime  1159724908  1159724908
gmdate('U') 1159724908  1159724908
gmdate('Z') 0   0


Actual result:
--
typenormal  after set UTC
time()  1159732108  1159732108
date('U')   1159732108  1159732108
date('Z')   72000
gmtime  1159724908  1159732108
gmdate('U') 1159732108  1159732108
gmdate('Z') 0   0






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

#39002 [Fbk]: apache 2.2.3 don't start : R_PPC_REL24 relocation error

 ID:   39002
 Updated by:   [EMAIL PROTECTED]
 Reported By:  benoitc at archlinuxppc dot org
 Status:   Feedback
 Bug Type: Apache2 related
 Operating System: Arch Linux PPC
 PHP Version:  5.1.6
 New Comment:

I'd check --with-imap* first, cclient is known to have problems on
different systems as to my experience.


Previous Comments:


[2006-10-02 17:48:47] [EMAIL PROTECTED]

Yes, you guessed correctly :) Good luck.



[2006-10-02 17:14:03] benoitc at archlinuxppc dot org

it works. So I now I guess it's time to test each switch ?



[2006-10-02 09:04:49] [EMAIL PROTECTED]

Remove all those ./configure options and try with only these:
./configure --with-apxs2 --disable-all




[2006-09-30 09:32:33] benoitc at archlinuxppc dot org

Description:

Apache 2.2.3 don't start with last version of php 5.1.6. I have this
error :





Reproduce code:
---
Php configure line :

 ./configure --with-apxs2 --prefix=/usr --sysconfdir=/etc \
--with-layout=PHP \
--with-ttf --enable-mailparse --with-config-file-scan-dir=/etc \
--enable-bcmath=shared --enable-calendar=shared --enable-ftp=shared
\
--enable-gd-native-ttf --enable-magic-quotes --enable-posix=shared
\
--enable-session --enable-shared --enable-shmop=shared
--enable-pdo=shared \
--enable-sqlite-utf8 --enable-sockets=shared --enable-xml\
--enable-sysvsem=shared --enable-sysvshm=shared
--enable-sysvmsg=shared \
--enable-track-vars --enable-trans-sid --enable-safe-mode \
--with-imap --with-imap-ssl --with-ncurses --with-readline \
--with-bz2=shared --with-curl --with-mime-magic \
--with-freetype-dir=/usr --with-gd=shared --enable-exif
--with-jpeg-dir=/usr \
--enable-dba --without-db2 --without-db3 --with-inifile
--with-flatfile \
--with-gdbm --with-ldap=shared --with-openssl --with-gettext \
--with-unixODBC=shared,/usr --with-pdo-odbc=shared,unixODBC,/usr \
--with-mysqli=shared,/usr/bin/mysql_config
--with-mysql-sock=/tmp/mysql.sock \
--with-pdo-mysql=shared,/usr --with-mysql=shared,/usr \
--with-pgsql=shared --with-pgsql-sock=/tmp/pgsql.sock
--with-pdo-pgsql=shared,/usr \
--with-sqlite=shared --with-pdo-sqlite=shared,/usr \
--with-pear=/usr/share/pear --with-dom --with-dom-xslt --with-xsl
\
--with-png-dir=/usr --with-regex=php --with-zlib
--enable-soap=shared \
--enable-mbstring=all --enable-mbregex --with-snmp=shared,/usr 




Actual result:
--
httpd: Syntax error on line 114 of /etc/httpd/conf/httpd.conf: Cannot
load /etc/httpd/modules/libphp5.so into server:
/etc/httpd/modules/libphp5.so: R_PPC_REL24 relocation at 0x0d81ae40 for
symbol `free' out of range





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

#39002 [Opn->Fbk]: apache 2.2.3 don't start : R_PPC_REL24 relocation error

 ID:   39002
 Updated by:   [EMAIL PROTECTED]
 Reported By:  benoitc at archlinuxppc dot org
-Status:   Open
+Status:   Feedback
 Bug Type: Apache2 related
 Operating System: Arch Linux PPC
 PHP Version:  5.1.6
 New Comment:

Yes, you guessed correctly :) Good luck.


Previous Comments:


[2006-10-02 17:14:03] benoitc at archlinuxppc dot org

it works. So I now I guess it's time to test each switch ?



[2006-10-02 09:04:49] [EMAIL PROTECTED]

Remove all those ./configure options and try with only these:
./configure --with-apxs2 --disable-all




[2006-09-30 09:32:33] benoitc at archlinuxppc dot org

Description:

Apache 2.2.3 don't start with last version of php 5.1.6. I have this
error :





Reproduce code:
---
Php configure line :

 ./configure --with-apxs2 --prefix=/usr --sysconfdir=/etc \
--with-layout=PHP \
--with-ttf --enable-mailparse --with-config-file-scan-dir=/etc \
--enable-bcmath=shared --enable-calendar=shared --enable-ftp=shared
\
--enable-gd-native-ttf --enable-magic-quotes --enable-posix=shared
\
--enable-session --enable-shared --enable-shmop=shared
--enable-pdo=shared \
--enable-sqlite-utf8 --enable-sockets=shared --enable-xml\
--enable-sysvsem=shared --enable-sysvshm=shared
--enable-sysvmsg=shared \
--enable-track-vars --enable-trans-sid --enable-safe-mode \
--with-imap --with-imap-ssl --with-ncurses --with-readline \
--with-bz2=shared --with-curl --with-mime-magic \
--with-freetype-dir=/usr --with-gd=shared --enable-exif
--with-jpeg-dir=/usr \
--enable-dba --without-db2 --without-db3 --with-inifile
--with-flatfile \
--with-gdbm --with-ldap=shared --with-openssl --with-gettext \
--with-unixODBC=shared,/usr --with-pdo-odbc=shared,unixODBC,/usr \
--with-mysqli=shared,/usr/bin/mysql_config
--with-mysql-sock=/tmp/mysql.sock \
--with-pdo-mysql=shared,/usr --with-mysql=shared,/usr \
--with-pgsql=shared --with-pgsql-sock=/tmp/pgsql.sock
--with-pdo-pgsql=shared,/usr \
--with-sqlite=shared --with-pdo-sqlite=shared,/usr \
--with-pear=/usr/share/pear --with-dom --with-dom-xslt --with-xsl
\
--with-png-dir=/usr --with-regex=php --with-zlib
--enable-soap=shared \
--enable-mbstring=all --enable-mbregex --with-snmp=shared,/usr 




Actual result:
--
httpd: Syntax error on line 114 of /etc/httpd/conf/httpd.conf: Cannot
load /etc/httpd/modules/libphp5.so into server:
/etc/httpd/modules/libphp5.so: R_PPC_REL24 relocation at 0x0d81ae40 for
symbol `free' out of range





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

#39002 [Fbk->Opn]: apache 2.2.3 don't start : R_PPC_REL24 relocation error

2006-10-02 Thread benoitc at archlinuxppc dot org

 ID:   39002
 User updated by:  benoitc at archlinuxppc dot org
 Reported By:  benoitc at archlinuxppc dot org
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: Arch Linux PPC
 PHP Version:  5.1.6
 New Comment:

it works. So I now I guess it's time to test each switch ?


Previous Comments:


[2006-10-02 09:04:49] [EMAIL PROTECTED]

Remove all those ./configure options and try with only these:
./configure --with-apxs2 --disable-all




[2006-09-30 09:32:33] benoitc at archlinuxppc dot org

Description:

Apache 2.2.3 don't start with last version of php 5.1.6. I have this
error :





Reproduce code:
---
Php configure line :

 ./configure --with-apxs2 --prefix=/usr --sysconfdir=/etc \
--with-layout=PHP \
--with-ttf --enable-mailparse --with-config-file-scan-dir=/etc \
--enable-bcmath=shared --enable-calendar=shared --enable-ftp=shared
\
--enable-gd-native-ttf --enable-magic-quotes --enable-posix=shared
\
--enable-session --enable-shared --enable-shmop=shared
--enable-pdo=shared \
--enable-sqlite-utf8 --enable-sockets=shared --enable-xml\
--enable-sysvsem=shared --enable-sysvshm=shared
--enable-sysvmsg=shared \
--enable-track-vars --enable-trans-sid --enable-safe-mode \
--with-imap --with-imap-ssl --with-ncurses --with-readline \
--with-bz2=shared --with-curl --with-mime-magic \
--with-freetype-dir=/usr --with-gd=shared --enable-exif
--with-jpeg-dir=/usr \
--enable-dba --without-db2 --without-db3 --with-inifile
--with-flatfile \
--with-gdbm --with-ldap=shared --with-openssl --with-gettext \
--with-unixODBC=shared,/usr --with-pdo-odbc=shared,unixODBC,/usr \
--with-mysqli=shared,/usr/bin/mysql_config
--with-mysql-sock=/tmp/mysql.sock \
--with-pdo-mysql=shared,/usr --with-mysql=shared,/usr \
--with-pgsql=shared --with-pgsql-sock=/tmp/pgsql.sock
--with-pdo-pgsql=shared,/usr \
--with-sqlite=shared --with-pdo-sqlite=shared,/usr \
--with-pear=/usr/share/pear --with-dom --with-dom-xslt --with-xsl
\
--with-png-dir=/usr --with-regex=php --with-zlib
--enable-soap=shared \
--enable-mbstring=all --enable-mbregex --with-snmp=shared,/usr 




Actual result:
--
httpd: Syntax error on line 114 of /etc/httpd/conf/httpd.conf: Cannot
load /etc/httpd/modules/libphp5.so into server:
/etc/httpd/modules/libphp5.so: R_PPC_REL24 relocation at 0x0d81ae40 for
symbol `free' out of range





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

#39017 [Opn->Asn]: foreach(($obj = new myClass) as $v); echo $obj; segfaults

 ID:   39017
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Assigned
 Bug Type: Scripting Engine problem
 Operating System: Irrelevant
 PHP Version:  5.1.6
 Assigned To:  dmitry


Previous Comments:


[2006-10-02 16:26:56] [EMAIL PROTECTED]

Description:

The foreach construct destroys the object, leaving the variable in a
strange state.

class A {} foreach(($a = new A) as $v);
var_dump($a); // UNKNOWN:0
echo $a; // segfaults

This was spotted by Zuu on [EMAIL PROTECTED]







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

#39017 [NEW]: foreach(($obj = new myClass) as $v); echo $obj; segfaults

2006-10-02 Thread [EMAIL PROTECTED]

From: [EMAIL PROTECTED]
Operating system: Irrelevant
PHP version:  5.1.6
PHP Bug Type: Scripting Engine problem
Bug description:  foreach(($obj = new myClass) as $v); echo $obj; segfaults

Description:

The foreach construct destroys the object, leaving the variable in a
strange state.

class A {} foreach(($a = new A) as $v);
var_dump($a); // UNKNOWN:0
echo $a; // segfaults

This was spotted by Zuu on [EMAIL PROTECTED]



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

#39016 [Opn->Asn]: Segfault in preg_replace_impl

 ID:   39016
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jan at horde dot org
-Status:   Open
+Status:   Assigned
 Bug Type: PCRE related
 Operating System: Linux
 PHP Version:  5.2.0RC4
-Assigned To:  
+Assigned To:  andrei
 New Comment:

Andrei, please take a look at this.
Looks like yet another stack overflow in PCRE..


Previous Comments:


[2006-10-02 15:51:41] jan at horde dot org

(gdb) p subject
$1 = (zval **) 0xb6f019e0
(gdb) p **subject
Cannot access memory at address 0x1
(gdb) p string_key
$2 = 0x10 
(gdb) p num_key
$3 = 1



[2006-10-02 15:48:34] [EMAIL PROTECTED]

What do you get in GDB with
p subject
p **subject
p string_key
p num_key
?



[2006-10-02 15:41:08] jan at horde dot org

I didn't try a snapshot since this happens with PHP 4, so I guess it's
an older issue that simply hasn't been triggered yet.

Here's the valgrind log:

==32185==  Address 0xBE32 is on thread 1's stack
==32185==
==32185== Invalid read of size 4
==32185==at 0x449FCA7: preg_replace_impl (php_pcre.c:1307)
==32185==by 0x4767B6B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==  Address 0x1 is not stack'd, malloc'd or (recently) free'd
==32185==
==32185== Process terminating with default action of signal 11
(SIGSEGV)
==32185==  Access not within mapped region at address 0x1
==32185==at 0x449FCA7: preg_replace_impl (php_pcre.c:1307)
==32185==by 0x4767B6B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)



[2006-10-02 15:36:50] jan at horde dot org

I should add the lines of code that caused this, right? :)


$regexp = <

#39016 [Fbk->Opn]: Segfault in preg_replace_impl

 ID:   39016
 User updated by:  jan at horde dot org
 Reported By:  jan at horde dot org
-Status:   Feedback
+Status:   Open
 Bug Type: PCRE related
 Operating System: Linux
 PHP Version:  5.2.0RC4
 New Comment:

(gdb) p subject
$1 = (zval **) 0xb6f019e0
(gdb) p **subject
Cannot access memory at address 0x1
(gdb) p string_key
$2 = 0x10 
(gdb) p num_key
$3 = 1


Previous Comments:


[2006-10-02 15:48:34] [EMAIL PROTECTED]

What do you get in GDB with
p subject
p **subject
p string_key
p num_key
?



[2006-10-02 15:41:08] jan at horde dot org

I didn't try a snapshot since this happens with PHP 4, so I guess it's
an older issue that simply hasn't been triggered yet.

Here's the valgrind log:

==32185==  Address 0xBE32 is on thread 1's stack
==32185==
==32185== Invalid read of size 4
==32185==at 0x449FCA7: preg_replace_impl (php_pcre.c:1307)
==32185==by 0x4767B6B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==  Address 0x1 is not stack'd, malloc'd or (recently) free'd
==32185==
==32185== Process terminating with default action of signal 11
(SIGSEGV)
==32185==  Access not within mapped region at address 0x1
==32185==at 0x449FCA7: preg_replace_impl (php_pcre.c:1307)
==32185==by 0x4767B6B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)



[2006-10-02 15:36:50] jan at horde dot org

I should add the lines of code that caused this, right? :)


$regexp = <

#39016 [Opn->Fbk]: Segfault in preg_replace_impl

 ID:   39016
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jan at horde dot org
-Status:   Open
+Status:   Feedback
-Bug Type: Reproducible crash
+Bug Type: PCRE related
 Operating System: Linux
 PHP Version:  5.2.0RC4
 New Comment:

What do you get in GDB with
p subject
p **subject
p string_key
p num_key
?


Previous Comments:


[2006-10-02 15:41:08] jan at horde dot org

I didn't try a snapshot since this happens with PHP 4, so I guess it's
an older issue that simply hasn't been triggered yet.

Here's the valgrind log:

==32185==  Address 0xBE32 is on thread 1's stack
==32185==
==32185== Invalid read of size 4
==32185==at 0x449FCA7: preg_replace_impl (php_pcre.c:1307)
==32185==by 0x4767B6B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==  Address 0x1 is not stack'd, malloc'd or (recently) free'd
==32185==
==32185== Process terminating with default action of signal 11
(SIGSEGV)
==32185==  Access not within mapped region at address 0x1
==32185==at 0x449FCA7: preg_replace_impl (php_pcre.c:1307)
==32185==by 0x4767B6B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)



[2006-10-02 15:36:50] jan at horde dot org

I should add the lines of code that caused this, right? :)


$regexp = <

#39016 [Opn]: Segfault in preg_replace_impl

 ID:   39016
 User updated by:  jan at horde dot org
 Reported By:  jan at horde dot org
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  5.2.0RC4
 New Comment:

I didn't try a snapshot since this happens with PHP 4, so I guess it's
an older issue that simply hasn't been triggered yet.

Here's the valgrind log:

==32185==  Address 0xBE32 is on thread 1's stack
==32185==
==32185== Invalid read of size 4
==32185==at 0x449FCA7: preg_replace_impl (php_pcre.c:1307)
==32185==by 0x4767B6B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==  Address 0x1 is not stack'd, malloc'd or (recently) free'd
==32185==
==32185== Process terminating with default action of signal 11
(SIGSEGV)
==32185==  Access not within mapped region at address 0x1
==32185==at 0x449FCA7: preg_replace_impl (php_pcre.c:1307)
==32185==by 0x4767B6B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)


Previous Comments:


[2006-10-02 15:36:50] jan at horde dot org

I should add the lines of code that caused this, right? :)


$regexp = <

#39016 [Fbk->Opn]: Segfault in preg_replace_impl

 ID:   39016
 User updated by:  jan at horde dot org
 Reported By:  jan at horde dot org
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  5.2.0RC4
 New Comment:

I should add the lines of code that caused this, right? :)


$regexp = <

#39004 [Asn->Csd]: Configure Command './configure' 'dummy' 'grep' 'ggrep' !?

2006-10-02 Thread iliaa

 ID:   39004
 Updated by:   [EMAIL PROTECTED]
 Reported By:  phpbugs at thequod dot de
-Status:   Assigned
+Status:   Closed
 Bug Type: *General Issues
 Operating System: Ubuntu Linux
 PHP Version:  5CVS-2006-09-30 (CVS)
 Assigned To:  iliaa
 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.




Previous Comments:


[2006-10-01 22:48:07] phpbugs at thequod dot de

Also the initial "./configure" command is missing in the 
output after applying the patch.



[2006-10-01 22:44:07] phpbugs at thequod dot de

Better. But now all arguments are encapsulated in two 
single quotes, while they were given in one single quote 
before, e.g.:
Configure Command 
=>  ''--enable-calendar'' ''--enable-exif'' ...



[2006-10-01 21:51:37] [EMAIL PROTECTED]

Try this patch and let me know if that fixes the problem
http://bb.prohost.org/patch/bug39004.txt



[2006-10-01 20:46:35] phpbugs at thequod dot de

2.60-1 (Debian/Ubuntu)



[2006-10-01 20:37:35] [EMAIL PROTECTED]

What version of autoconf are you using?



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

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

#39016 [Opn->Fbk]: Segfault in preg_replace_impl

 ID:   39016
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jan at horde dot org
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  5.2.0RC4
 New Comment:

Did you try fresh snapshots?
Do you see anything interesting with valgrind?


Previous Comments:


[2006-10-02 15:30:19] jan at horde dot org

Description:

Using preg_replace to parse and process email address in certain email
message headers causes reproducable segfaults. Unfortunately these
don't happen in a stripped down preg_replace call, but only in the
context of a larger application. I was able to get a backtrace though
that might be helpful:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210352992 (LWP 32029)]
0xb75f8ca7 in preg_replace_impl (ht=,
return_value=0xb6560604, return_value_ptr=,
this_ptr=0x0, return_value_used=1, is_callable_replace=0 '\0')
at /home/jan/software/php-5.2.0RC4/ext/pcre/php_pcre.c:1307
1307   
switch(zend_hash_get_current_key(Z_ARRVAL_PP(subject), &string_key,
&num_key, 0))

(gdb) bt
#0  0xb75f8ca7 in preg_replace_impl (ht=,
return_value=0xb6560604, return_value_ptr=,
this_ptr=0x0, return_value_used=1, is_callable_replace=0 '\0')
at /home/jan/software/php-5.2.0RC4/ext/pcre/php_pcre.c:1307
#1  0xb78c0b6c in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfaf8090)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:200
#2  0xb78b3fbd in execute (op_array=0xb651143c)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#3  0xb78c05eb in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfaf8560)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:234
#4  0xb78b3fbd in execute (op_array=0xb659a668)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#5  0xb78c05eb in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfaf8860)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:234
#6  0xb78b3fbd in execute (op_array=0xb659b664)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#7  0xb78c05eb in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfaf8e40)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:234
#8  0xb78b3fbd in execute (op_array=0xb65d7868)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#9  0xb78c05eb in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfaf8fa0)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:234
#10 0xb78b3fbd in execute (op_array=0xb65d7798)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#11 0xb78c05eb in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfaf9850)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:234
#12 0xb78b3fbd in execute (op_array=0xb66171b8)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#13 0xb78c05eb in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfaf9ab0)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:234
#14 0xb78b3fbd in execute (op_array=0xb65d7934)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#15 0xb78c05eb in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfb00890)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:234
#16 0xb78b3fbd in execute (op_array=0xb6eb227c)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#17 0xb7898bb7 in zend_execute_scripts (type=8, retval=,
file_count=3) at /home/jan/software/php-5.2.0RC4/Zend/zend.c:1096
#18 0xb785b112 in php_execute_script (primary_file=0xbfb02bbc)
at /home/jan/software/php-5.2.0RC4/main/main.c:1759
#19 0xb790f73f in apache_php_module_main (r=0x80d4434,
display_source_mode=0)
at /home/jan/software/php-5.2.0RC4/sapi/apache/sapi_apache.c:53
#20 0xb79106d8 in send_php (r=0x80d4434, display_source_mode=0,
filename=0x0)
at /home/jan/software/php-5.2.0RC4/sapi/apache/mod_php5.c:665
#21 0xb7910926 in send_parsed_php (r=0x80d4434)
at /home/jan/software/php-5.2.0RC4/sapi/apache/mod_php5.c:680
#22 0x0806bd77 in ap_invoke_handler ()
#23 0x080823d9 in process_request_internal ()
#24 0x08082436 in ap_process_request ()
#25 0x08078b16 in child_main ()
#26 0x08078d4d in make_child ()
#27 0x08078ebd in startup_children ()
#28 0x0807958a in standalone_main ()
#29 0x08079e50 in main ()

The segfault happens in PHP 4 too.






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

#39016 [NEW]: Segfault in preg_replace_impl

From: jan at horde dot org
Operating system: Linux
PHP version:  5.2.0RC4
PHP Bug Type: Reproducible crash
Bug description:  Segfault in preg_replace_impl

Description:

Using preg_replace to parse and process email address in certain email
message headers causes reproducable segfaults. Unfortunately these don't
happen in a stripped down preg_replace call, but only in the context of a
larger application. I was able to get a backtrace though that might be
helpful:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210352992 (LWP 32029)]
0xb75f8ca7 in preg_replace_impl (ht=,
return_value=0xb6560604, return_value_ptr=,
this_ptr=0x0, return_value_used=1, is_callable_replace=0 '\0')
at /home/jan/software/php-5.2.0RC4/ext/pcre/php_pcre.c:1307
1307   
switch(zend_hash_get_current_key(Z_ARRVAL_PP(subject), &string_key,
&num_key, 0))

(gdb) bt
#0  0xb75f8ca7 in preg_replace_impl (ht=,
return_value=0xb6560604, return_value_ptr=,
this_ptr=0x0, return_value_used=1, is_callable_replace=0 '\0')
at /home/jan/software/php-5.2.0RC4/ext/pcre/php_pcre.c:1307
#1  0xb78c0b6c in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfaf8090)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:200
#2  0xb78b3fbd in execute (op_array=0xb651143c)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#3  0xb78c05eb in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfaf8560)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:234
#4  0xb78b3fbd in execute (op_array=0xb659a668)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#5  0xb78c05eb in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfaf8860)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:234
#6  0xb78b3fbd in execute (op_array=0xb659b664)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#7  0xb78c05eb in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfaf8e40)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:234
#8  0xb78b3fbd in execute (op_array=0xb65d7868)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#9  0xb78c05eb in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfaf8fa0)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:234
#10 0xb78b3fbd in execute (op_array=0xb65d7798)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#11 0xb78c05eb in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfaf9850)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:234
#12 0xb78b3fbd in execute (op_array=0xb66171b8)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#13 0xb78c05eb in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfaf9ab0)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:234
#14 0xb78b3fbd in execute (op_array=0xb65d7934)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#15 0xb78c05eb in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfb00890)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:234
#16 0xb78b3fbd in execute (op_array=0xb6eb227c)
at /home/jan/software/php-5.2.0RC4/Zend/zend_vm_execute.h:92
#17 0xb7898bb7 in zend_execute_scripts (type=8, retval=,
file_count=3) at /home/jan/software/php-5.2.0RC4/Zend/zend.c:1096
#18 0xb785b112 in php_execute_script (primary_file=0xbfb02bbc)
at /home/jan/software/php-5.2.0RC4/main/main.c:1759
#19 0xb790f73f in apache_php_module_main (r=0x80d4434,
display_source_mode=0)
at /home/jan/software/php-5.2.0RC4/sapi/apache/sapi_apache.c:53
#20 0xb79106d8 in send_php (r=0x80d4434, display_source_mode=0,
filename=0x0)
at /home/jan/software/php-5.2.0RC4/sapi/apache/mod_php5.c:665
#21 0xb7910926 in send_parsed_php (r=0x80d4434)
at /home/jan/software/php-5.2.0RC4/sapi/apache/mod_php5.c:680
#22 0x0806bd77 in ap_invoke_handler ()
#23 0x080823d9 in process_request_internal ()
#24 0x08082436 in ap_process_request ()
#25 0x08078b16 in child_main ()
#26 0x08078d4d in make_child ()
#27 0x08078ebd in startup_children ()
#28 0x0807958a in standalone_main ()
#29 0x08079e50 in main ()

The segfault happens in PHP 4 too.


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

#38997 [Opn->Bgs]: Cannot configure PHP for cross-compilation with Apache 2.2.3

 ID:   38997
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lstefani at fortresstech dot com
-Status:   Open
+Status:   Bogus
 Bug Type: *Configuration Issues
 Operating System: Linux 2.6.12
 PHP Version:  5.1.6
 New Comment:

If you want apxs utility to be enhanced - please report it as a feature
request to Apache developers.
There is nothing PHP can do about it.


Previous Comments:


[2006-10-02 14:29:37] lstefani at fortresstech dot com

Hi Tony,

I noticed that you marked the Status as Bogus.  If PHP isn't meant to
be cross-compiled, I have not found any online documentation supporting
that.  In fact, the --host= and --target= options within PHP 5.1.6's
configure script suggest that cross-compilation *is* supported.

Assuming I'm correct that cross-compilation is a feature of PHP, I
believe this bug should remain open.  Perhaps the Apache folks can
address this by making apxs truly platform independent, instead of
relying on binaries that may not necessarily be executable on the build
system (I've logged a bug against Apache 2.2.3 on same).

Alternatively, perhaps the PHP configure script can be enhanced to
support manual overrides of whatever is needed through the apxs -q
command to support cross-compilation?

Thanks,
Larry



[2006-09-29 21:24:17] lstefani at fortresstech dot com

Hi Tony,

Thanks for the quick response.  OK, so apxs and (indirectly) httpd must
be executable.  Am I correct in assuming that if I were to temporarily
install a native (X86) httpd to make PHP configure happy, I'd be in
trouble because the native compilation flags are (obviously) different
for the cross-compiled build?

Do you recommend that I attack this problem by removing the apxs
dependency and pass in all of the compilation flags, paths, etc. that
PHP needs to build the Apache module?

I'm highly motivated to make cross-compilation work because the
alternative is to install all of the source trees, toolchains, etc. on
the target platform and build natively.  That's just not practical for
my development environment.

Thanks,
Larry Stefani



[2006-09-29 20:29:02] [EMAIL PROTECTED]

PHP _does_ need to execute apxs to get correct compilation flags, paths
etc. required to compile Apache module. There is nothing we can do about
it.



[2006-09-29 19:18:28] lstefani at fortresstech dot com

Description:

After successfully cross-compiling Apache 2.2.3 on Linux x86 machine
for MIPS target, PHP fails to configure properly with --with-apxs2=
flag.  The reason for the failure is that PHP configure executes apxs
utility, which executes httpd, but that binary was cross-compiled, so
it fails to execute.

Reproduce code:
---
env ac_cv_func_fopencookie=no ac_cv_func_getaddrinfo=yes
ac_cv_func_utime_null=yes ac_cv_func_waitpid=yes ac_cv_pread=yes
ac_cv_pwrite=yes ac_cv_sizeof_long=4
ac_cv_php_xml2_config_path=/usr/apache/bin/xml2-config
PKG_CONFIG_PATH=/usr/apache/lib/pkgconfig
ac_cv_prog_CC=/buildtools/gcc-3.3.2-glibc-2.3.2/mips-linux/bin/mips-linux-gcc
./configure --host=mips-linux --target=mips-linux --without-iconv
--without-mysql --without-pear --enable-sigchild --enable-bcmath
--with-apxs2=/usr/apache/bin/apxs --with-libxml-dir=/usr/apache
--prefix=/usr/apache


Expected result:

Successful configuration of PHP for subsequent make operation.  When
configuring for cross-compilation, PHP configure should not be
dependent on natively executing binaries that were built for other
targets.  What information does PHP configure require of apxs and
httpd?  Is there an alternative way to retrieve it?

Actual result:
--
Configuring SAPI modules
checking for AOLserver support... no
checking for Apache 1.x module support via DSO through APXS... no
checking for Apache 1.x module support... no
checking for mod_charset compatibility option... no
checking for Apache 2.0 filter-module support via DSO through APXS...
no
checking for Apache 2.0 handler-module support via DSO through APXS...

Sorry, I cannot run apxs.  Possible reasons follow:

1. Perl is not installed
2. apxs was not found. Try to pass the path using
--with-apxs2=/path/to/apxs
3. Apache was not built using --enable-so (the apxs usage page is
displayed)

The output of /usr/apache/bin/apxs follows:
sh: /usr/apache/bin/httpd: cannot execute binary file
apxs:Error: Sorry, no shared object support for Apache.
apxs:Error: available under your platform. Make sure.
apxs:Error: the Apache module mod_so is compiled into.
apxs:Error: your server binary `/usr/apache/bin/httpd'..
configure: error: Aborting






-- 
Edit this bug report at

#39015 [Opn->Bgs]: dbase_open don't works

 ID:   39015
 Updated by:   [EMAIL PROTECTED]
 Reported By:  renato at metrosp dot com dot br
-Status:   Open
+Status:   Bogus
 Bug Type: dBase related
 Operating System: FreeBSD 4-STABLE
 PHP Version:  5.1.6
 New Comment:

The "T" (timestamp?) fields are not support by ext/dbase.
The list of supported field types can be found in the docs:
http://php.net/dbase 


Previous Comments:


[2006-10-02 14:32:07] renato at metrosp dot com dot br

Follow the link to the file:

http://extranet.metrosp.com.br/200.dbf



[2006-10-02 14:28:28] [EMAIL PROTECTED]

This meand the dbf file is not readable or has a broken header.
Please upload this file (or another one, which demonstrates it)
somewhere and leave the link here.



[2006-10-02 14:28:05] [EMAIL PROTECTED]

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.




[2006-10-02 14:20:25] renato at metrosp dot com dot br

Description:

dbase_open() function don't works.

Reproduce code:
---
$dbo = dbase_open("/var/www/html/dbf/200.dbf",0);

Expected result:

No errors and the database opened. This bug don't occur in 5.1.2.

Actual result:
--
Warning: dbase_open() [function.dbase-open]: unable to open database
/var/www/html/dbf/200.dbf in /var/www/html/dbfopen.php on line 3





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

#39015 [Fbk->Opn]: dbase_open don't works

2006-10-02 Thread renato at metrosp dot com dot br

 ID:   39015
 User updated by:  renato at metrosp dot com dot br
 Reported By:  renato at metrosp dot com dot br
-Status:   Feedback
+Status:   Open
 Bug Type: dBase related
 Operating System: FreeBSD 4-STABLE
 PHP Version:  5.1.6
 New Comment:

Follow the link to the file:

http://extranet.metrosp.com.br/200.dbf


Previous Comments:


[2006-10-02 14:28:28] [EMAIL PROTECTED]

This meand the dbf file is not readable or has a broken header.
Please upload this file (or another one, which demonstrates it)
somewhere and leave the link here.



[2006-10-02 14:28:05] [EMAIL PROTECTED]

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.




[2006-10-02 14:20:25] renato at metrosp dot com dot br

Description:

dbase_open() function don't works.

Reproduce code:
---
$dbo = dbase_open("/var/www/html/dbf/200.dbf",0);

Expected result:

No errors and the database opened. This bug don't occur in 5.1.2.

Actual result:
--
Warning: dbase_open() [function.dbase-open]: unable to open database
/var/www/html/dbf/200.dbf in /var/www/html/dbfopen.php on line 3





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

#38997 [Bgs->Opn]: Cannot configure PHP for cross-compilation with Apache 2.2.3

2006-10-02 Thread lstefani at fortresstech dot com

 ID:   38997
 User updated by:  lstefani at fortresstech dot com
 Reported By:  lstefani at fortresstech dot com
-Status:   Bogus
+Status:   Open
 Bug Type: *Configuration Issues
 Operating System: Linux 2.6.12
 PHP Version:  5.1.6
 New Comment:

Hi Tony,

I noticed that you marked the Status as Bogus.  If PHP isn't meant to
be cross-compiled, I have not found any online documentation supporting
that.  In fact, the --host= and --target= options within PHP 5.1.6's
configure script suggest that cross-compilation *is* supported.

Assuming I'm correct that cross-compilation is a feature of PHP, I
believe this bug should remain open.  Perhaps the Apache folks can
address this by making apxs truly platform independent, instead of
relying on binaries that may not necessarily be executable on the build
system (I've logged a bug against Apache 2.2.3 on same).

Alternatively, perhaps the PHP configure script can be enhanced to
support manual overrides of whatever is needed through the apxs -q
command to support cross-compilation?

Thanks,
Larry


Previous Comments:


[2006-09-29 21:24:17] lstefani at fortresstech dot com

Hi Tony,

Thanks for the quick response.  OK, so apxs and (indirectly) httpd must
be executable.  Am I correct in assuming that if I were to temporarily
install a native (X86) httpd to make PHP configure happy, I'd be in
trouble because the native compilation flags are (obviously) different
for the cross-compiled build?

Do you recommend that I attack this problem by removing the apxs
dependency and pass in all of the compilation flags, paths, etc. that
PHP needs to build the Apache module?

I'm highly motivated to make cross-compilation work because the
alternative is to install all of the source trees, toolchains, etc. on
the target platform and build natively.  That's just not practical for
my development environment.

Thanks,
Larry Stefani



[2006-09-29 20:29:02] [EMAIL PROTECTED]

PHP _does_ need to execute apxs to get correct compilation flags, paths
etc. required to compile Apache module. There is nothing we can do about
it.



[2006-09-29 19:18:28] lstefani at fortresstech dot com

Description:

After successfully cross-compiling Apache 2.2.3 on Linux x86 machine
for MIPS target, PHP fails to configure properly with --with-apxs2=
flag.  The reason for the failure is that PHP configure executes apxs
utility, which executes httpd, but that binary was cross-compiled, so
it fails to execute.

Reproduce code:
---
env ac_cv_func_fopencookie=no ac_cv_func_getaddrinfo=yes
ac_cv_func_utime_null=yes ac_cv_func_waitpid=yes ac_cv_pread=yes
ac_cv_pwrite=yes ac_cv_sizeof_long=4
ac_cv_php_xml2_config_path=/usr/apache/bin/xml2-config
PKG_CONFIG_PATH=/usr/apache/lib/pkgconfig
ac_cv_prog_CC=/buildtools/gcc-3.3.2-glibc-2.3.2/mips-linux/bin/mips-linux-gcc
./configure --host=mips-linux --target=mips-linux --without-iconv
--without-mysql --without-pear --enable-sigchild --enable-bcmath
--with-apxs2=/usr/apache/bin/apxs --with-libxml-dir=/usr/apache
--prefix=/usr/apache


Expected result:

Successful configuration of PHP for subsequent make operation.  When
configuring for cross-compilation, PHP configure should not be
dependent on natively executing binaries that were built for other
targets.  What information does PHP configure require of apxs and
httpd?  Is there an alternative way to retrieve it?

Actual result:
--
Configuring SAPI modules
checking for AOLserver support... no
checking for Apache 1.x module support via DSO through APXS... no
checking for Apache 1.x module support... no
checking for mod_charset compatibility option... no
checking for Apache 2.0 filter-module support via DSO through APXS...
no
checking for Apache 2.0 handler-module support via DSO through APXS...

Sorry, I cannot run apxs.  Possible reasons follow:

1. Perl is not installed
2. apxs was not found. Try to pass the path using
--with-apxs2=/path/to/apxs
3. Apache was not built using --enable-so (the apxs usage page is
displayed)

The output of /usr/apache/bin/apxs follows:
sh: /usr/apache/bin/httpd: cannot execute binary file
apxs:Error: Sorry, no shared object support for Apache.
apxs:Error: available under your platform. Make sure.
apxs:Error: the Apache module mod_so is compiled into.
apxs:Error: your server binary `/usr/apache/bin/httpd'..
configure: error: Aborting






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

#39015 [Fbk]: dbase_open don't works

 ID:   39015
 Updated by:   [EMAIL PROTECTED]
 Reported By:  renato at metrosp dot com dot br
 Status:   Feedback
 Bug Type: dBase related
 Operating System: FreeBSD 4-STABLE
 PHP Version:  5.1.6
 New Comment:

This meand the dbf file is not readable or has a broken header.
Please upload this file (or another one, which demonstrates it)
somewhere and leave the link here.


Previous Comments:


[2006-10-02 14:28:05] [EMAIL PROTECTED]

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.




[2006-10-02 14:20:25] renato at metrosp dot com dot br

Description:

dbase_open() function don't works.

Reproduce code:
---
$dbo = dbase_open("/var/www/html/dbf/200.dbf",0);

Expected result:

No errors and the database opened. This bug don't occur in 5.1.2.

Actual result:
--
Warning: dbase_open() [function.dbase-open]: unable to open database
/var/www/html/dbf/200.dbf in /var/www/html/dbfopen.php on line 3





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

#39015 [Opn->Fbk]: dbase_open don't works

 ID:   39015
 Updated by:   [EMAIL PROTECTED]
 Reported By:  renato at metrosp dot com dot br
-Status:   Open
+Status:   Feedback
 Bug Type: dBase related
 Operating System: FreeBSD 4-STABLE
 PHP Version:  5.1.6
 New Comment:

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.



Previous Comments:


[2006-10-02 14:20:25] renato at metrosp dot com dot br

Description:

dbase_open() function don't works.

Reproduce code:
---
$dbo = dbase_open("/var/www/html/dbf/200.dbf",0);

Expected result:

No errors and the database opened. This bug don't occur in 5.1.2.

Actual result:
--
Warning: dbase_open() [function.dbase-open]: unable to open database
/var/www/html/dbf/200.dbf in /var/www/html/dbfopen.php on line 3





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

#39015 [NEW]: dbase_open don't works

2006-10-02 Thread renato at metrosp dot com dot br

From: renato at metrosp dot com dot br
Operating system: FreeBSD 4-STABLE
PHP version:  5.1.6
PHP Bug Type: dBase related
Bug description:  dbase_open don't works

Description:

dbase_open() function don't works.

Reproduce code:
---
$dbo = dbase_open("/var/www/html/dbf/200.dbf",0);

Expected result:

No errors and the database opened. This bug don't occur in 5.1.2.

Actual result:
--
Warning: dbase_open() [function.dbase-open]: unable to open database
/var/www/html/dbf/200.dbf in /var/www/html/dbfopen.php on line 3

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

#39013 [Opn->Fbk]: apache shutdown automatically

 ID:   39013
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jerry_zbs at 163 dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Apache related
 Operating System: windows2003
 PHP Version:  5.1.6


Previous Comments:


[2006-10-02 14:00:02] jerry_zbs at 163 dot com

thank you..!!
i will try it..



[2006-10-02 09:28:44] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2006-10-02 08:24:11] jerry_zbs at 163 dot com

Description:

i setuped an apache2.0(or higher version) server with php5.14(or higher
version) in modularization not in cgi mode,prophase,the server run in
the normal state,but after having more and more vistor,the server
shutdown automatically...then i refer the log of system,there is one
line "Application Error: Apache.exeCversion 2.0.49.0CError module:
unknownCversion 0.0.0.0CError Address 0x018c1c70B"...

if i run php in cgi mode,the problem disappear..

this is the one problem

and..i try to visit the "htm" page,not "php" page ,and fresh it
endlessly,the "htm" page has no problem,the server run find,but fresh
the "php" page is not!when i freshed the "php" page a few times, the
server shutdown automatically again...

i think,it may be the php core's problem..

the lower version php hasn't this problem,because i used the php5.0RC2
for a long time before..

i've try different versions of apache,but the same problem still
appear!

if anyone has this problem,and u fixed it,contact me,please!thanks a
lots!






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

#39013 [Fbk->Opn]: apache shutdown automatically

2006-10-02 Thread jerry_zbs at 163 dot com

 ID:   39013
 User updated by:  jerry_zbs at 163 dot com
 Reported By:  jerry_zbs at 163 dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Apache related
 Operating System: windows2003
 PHP Version:  5.1.6
 New Comment:

thank you..!!
i will try it..


Previous Comments:


[2006-10-02 09:28:44] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2006-10-02 08:24:11] jerry_zbs at 163 dot com

Description:

i setuped an apache2.0(or higher version) server with php5.14(or higher
version) in modularization not in cgi mode,prophase,the server run in
the normal state,but after having more and more vistor,the server
shutdown automatically...then i refer the log of system,there is one
line "Application Error: Apache.exeCversion 2.0.49.0CError module:
unknownCversion 0.0.0.0CError Address 0x018c1c70B"...

if i run php in cgi mode,the problem disappear..

this is the one problem

and..i try to visit the "htm" page,not "php" page ,and fresh it
endlessly,the "htm" page has no problem,the server run find,but fresh
the "php" page is not!when i freshed the "php" page a few times, the
server shutdown automatically again...

i think,it may be the php core's problem..

the lower version php hasn't this problem,because i used the php5.0RC2
for a long time before..

i've try different versions of apache,but the same problem still
appear!

if anyone has this problem,and u fixed it,contact me,please!thanks a
lots!






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

#39001 [Opn->Csd]: ReflectionProperty returns incorrect declaring class for protected properties

 ID:   39001
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kzantow at gmail dot com
-Status:   Open
+Status:   Closed
 Bug Type: Class/Object related
 Operating System: Windows XP SP2
 PHP Version:  5.1.6
 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.




Previous Comments:


[2006-09-30 05:20:34] kzantow at gmail dot com

Description:

ReflectionProperty returns incorrect declaring class for protected
properties.

Reproduce code:
---
class Parent {
public $publicVar;
protected $protectedVar;
}

class Child extends Parent {
}

$r = new ReflectionClass('Child');
print $r->getProperty('publicVar')->getDeclaringClass()->getName();
print $r->getProperty('protectedVar')->getDeclaringClass()->getName();


Expected result:

ParentClass
ParentClass


Actual result:
--
ParentClass
ChildClass





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

#38819 [Csd->Fbk]: segfault in ldap_get_entries()

ID: 38819
Updated by: [EMAIL PROTECTED]
Reported By: madcoder at gmail dot com
-Status: Closed
+Status: Feedback
Bug Type: LDAP related
Operating System: 2.6.17-gentoo linux amd64
PHP Version: 5.1.6
New Comment:

>works *without* any segfaults.
Ok, great. Please don't close the report until the issue is resolved in
PHP.
Could you please also ask OpenLDAP developers if this flag would affect
anything else? I.e. if it didn't segfault before, could this flag add
any problems?
If no, I'll add it to the config.m4, so it'll be defined in all
builds.

>But wouldn't it be beneficial to take the OpenLDAP
>developers' advice, and rewrite this so-called
>"deprecated" use of OpenLDAP?
Sure it would be. And we would gladly accept their help.
But the current situation is that ext/ldap maintainer is not active for
a long time and nobody really interested in ldap. If you can help us
with that - you're welcome.

Also, it would be good if OpenLDAP developers keep the backward
compatibility, since we cannot rely on users using the most
latest-and-greatest OpenLDAP version and rewrite ext/ldap each time
they change the API.

Previous Comments:

[2006-10-02 11:32:34] madcoder at gmail dot com

Sorry, it appears I added that in the wrong place. I added it to the
Makefile for ext/ldap, and it compiled, and works *without* any
segfaults.

I don't want to sound rude, so please don't take this the wrong way,
... But wouldn't it be beneficial to take the OpenLDAP developers'
advice, and rewrite this so-called "deprecated" use of OpenLDAP? It
appears to only occur on certain machines, perhaps even only on certain
amd64 machines, but it is still rather annoying if no one is sure what
causes it, and it takes 2 weeks (or longer, in my case, since I've been
having this problem long before I posted to any trackers) to get an
answer from someone.

Thanks again for your help, and patience while working through this
problem.

[2006-10-02 11:20:50] madcoder at gmail dot com

In ext/ldap/config.m4, I changed the following to add the flag you
mentioned:

> CPPFLAGS="$CPPFLAGS -I$LDAP_INCDIR -DLDAP_DEPRECATED=1"

Then reconfigured and rebuilt php. I'm not sure if I did that
properly, but from what information I found about the flag, that is
appropriate.

And I *do* still get the segfault. Should I try a distclean as well?
Or should I recompile OpenLDAP first (with or without that flag)?

[2006-10-02 09:20:13] [EMAIL PROTECTED]

So does it work for you if you add that magical -DLDAP_DEPRECATED=1 ?

[2006-10-01 08:16:08] madcoder at gmail dot com

For reference, I'm cross-posting a bug report I've opened with OpenLDAP
(ITS# 4690) in case they can provide any further information:
http://www.openldap.org/its/index.cgi/Incoming?id=4690;expression=ldap_get_values;statetype=-1

[2006-09-30 03:37:13] madcoder at gmail dot com

Any other ideas? This problem is kind of a blocker for me right now...
I still don't understand why it works fine inside valgrind, but it
segfaults on its own and inside gdb. I know it's segfaulting because
of the message "Cannot access memory at address 0x55a0bfe0", so the for
loop checking vals[i] obviously fails. But what steps can I take to
debug this further?

It could be a problem in openldap, since the line in php's ldap.c just
before it calls the openldap function 'ldap_count_values' is
ldap_get_values(), which is what is returning the memory address of
0x55a0bfe0. But if it were in fact a problem with openldap, would the
cli ldapsearch fail as well?

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

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

#38819 [Opn->Csd]: segfault in ldap_get_entries()

2006-10-02 Thread madcoder at gmail dot com

ID: 38819
User updated by: madcoder at gmail dot com
Reported By: madcoder at gmail dot com
-Status: Open
+Status: Closed
Bug Type: LDAP related
Operating System: 2.6.17-gentoo linux amd64
PHP Version: 5.1.6
New Comment:

Sorry, it appears I added that in the wrong place. I added it to the
Makefile for ext/ldap, and it compiled, and works *without* any
segfaults.

Thanks again for your help, and patience while working through this
problem.

Previous Comments:

[2006-10-02 11:20:50] madcoder at gmail dot com

In ext/ldap/config.m4, I changed the following to add the flag you
mentioned:

> CPPFLAGS="$CPPFLAGS -I$LDAP_INCDIR -DLDAP_DEPRECATED=1"

Then reconfigured and rebuilt php. I'm not sure if I did that
properly, but from what information I found about the flag, that is
appropriate.

And I *do* still get the segfault. Should I try a distclean as well?
Or should I recompile OpenLDAP first (with or without that flag)?

[2006-10-02 09:20:13] [EMAIL PROTECTED]

So does it work for you if you add that magical -DLDAP_DEPRECATED=1 ?

[2006-10-01 08:16:08] madcoder at gmail dot com

[2006-09-30 03:37:13] madcoder at gmail dot com

[2006-09-26 11:08:50] madcoder at gmail dot com

I've tried, but the program doesn't segfault, so it exits normally.
I'm not very experienced with gdb, so I'm not sure how to give it a
breakpoint of ldap_count_values (I tried 'break ldap_count_values' and
'break ldap_count_values()', and it doesn't break).

It does still return the information as expected.

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

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

#38819 [Fbk->Opn]: segfault in ldap_get_entries()

2006-10-02 Thread madcoder at gmail dot com

 ID:   38819
 User updated by:  madcoder at gmail dot com
 Reported By:  madcoder at gmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: LDAP related
 Operating System: 2.6.17-gentoo linux amd64
 PHP Version:  5.1.6
 New Comment:

In ext/ldap/config.m4, I changed the following to add the flag you
mentioned:

>  CPPFLAGS="$CPPFLAGS -I$LDAP_INCDIR -DLDAP_DEPRECATED=1"

Then reconfigured and rebuilt php.  I'm not sure if I did that
properly, but from what information I found about the flag, that is
appropriate.

And I *do* still get the segfault.  Should I try a distclean as well?
Or should I recompile OpenLDAP first (with or without that flag)?


Previous Comments:


[2006-10-02 09:20:13] [EMAIL PROTECTED]

So does it work for you if you add that magical -DLDAP_DEPRECATED=1 ?



[2006-10-01 08:16:08] madcoder at gmail dot com

For reference, I'm cross-posting a bug report I've opened with OpenLDAP
(ITS# 4690) in case they can provide any further information:
http://www.openldap.org/its/index.cgi/Incoming?id=4690;expression=ldap_get_values;statetype=-1



[2006-09-30 03:37:13] madcoder at gmail dot com

Any other ideas?  This problem is kind of a blocker for me right now...
 I still don't understand why it works fine inside valgrind, but it
segfaults on its own and inside gdb.  I know it's segfaulting because
of the message "Cannot access memory at address 0x55a0bfe0", so the for
loop checking vals[i] obviously fails.  But what steps can I take to
debug this further?

It could be a problem in openldap, since the line in php's ldap.c just
before it calls the openldap function 'ldap_count_values' is
ldap_get_values(), which is what is returning the memory address of
0x55a0bfe0.  But if it were in fact a problem with openldap, would the
cli ldapsearch fail as well?



[2006-09-26 11:08:50] madcoder at gmail dot com

I've tried, but the program doesn't segfault, so it exits normally. 
I'm not very experienced with gdb, so I'm not sure how to give it a
breakpoint of ldap_count_values (I tried 'break ldap_count_values' and
'break ldap_count_values()', and it doesn't break).

It does still return the information as expected.



[2006-09-26 10:57:53] [EMAIL PROTECTED]

Is it possible to perform the same actions using ldapsearch utility in
console?



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

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

#39003 [Opn->Csd]: __autoload unnecessarily called for type hinting

 ID:   39003
 Updated by:   [EMAIL PROTECTED]
 Reported By:  christoph at ziegenberg dot de
-Status:   Open
+Status:   Closed
-Bug Type: Documentation problem
+Bug Type: Scripting Engine problem
 Operating System: WinXP SP2
 PHP Version:  5.1.6
 New Comment:

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




Previous Comments:


[2006-10-02 10:42:37] [EMAIL PROTECTED]

It's just a doc problem Tony... he's doing an instance of with an
unknown class. That gives an error message before the instance of runs
and can show it's error message.



[2006-10-02 09:39:28] [EMAIL PROTECTED]

Not a bug here, this is expected so marking as doc problem.



[2006-10-01 06:51:19] christoph at ziegenberg dot de

My version of the manual says this (from the example code):

// Fatal Error: Argument 1 must be an instance of OtherClass
$foo = new stdClass;
$myclass->test($foo);

So I should get the error "Fatal error: Argument 1 passed to test()
must be an instance of OtherClassName, called in [...]", but I get the
error "Fatal error: Class 'OtherClassName' not found in [...]".

Of course these are both fatal errors, but the one hand I expect
another behaviour for the autoloader function as described and on the
other hand the "correct" error message would help to debug the code,
because the current error only refers to the __autoloader() function
(so you have to use debug_backtrace()/debug_print_backtrace()).



[2006-10-01 06:07:57] judas dot iscariote at gmail dot com

if this is the expected behaviuor ( at least, not the behaviuor I
expect ;) ) it is not mentioned in the manual, so either the manual or
the engine needs to be corrected ;-)



[2006-09-30 10:05:56] christoph at ziegenberg dot de

Description:

if i check if a variable is an instance of specific class with
"instanceof" and the class i check for has not been loaded,
__autoloader() is not called (as expected).

if i do the "same" check by type hinting, the __autoloader() function
is called, which normally leads to including the required class file
and so unnecessarily consumes memory and time.

Reproduce code:
---
";
}
test($obj);
?>

Expected result:

no instance of OtherClassName

Actual result:
--
no instance of OtherClassName
try to load class OtherClassName
Fatal error: Class 'OtherClassName' not found in [...] on line 7





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

#39011 [Opn->Bgs]: foreach($_GET as $key => &$value) causes later bugs passing $_GET as a paramete

2006-10-02 Thread php_bug dot email at email dot digiways dot com

 ID:   39011
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php_bug dot email at email dot digiways dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Arrays related
 Operating System: Windows XP
 PHP Version:  5.1.6
 New Comment:

>Are you talking about arrays in general, or about my example?

I'm talking about your example, of course.

>If you are talking about my example, then please explain >why the
element in the array becomes a reference if we add >a reference to it?

Because they both now point to the same value. This is how references
work.
See what the docs say:
http://www.php.net/manual/en/language.references.whatdo.php


Previous Comments:


[2006-10-02 10:09:14] php_bug dot email at email dot digiways dot com

> And since all the elements in the array are references

Are you talking about arrays in general, or about my example?

If you are talking about arrays in general, this is simply wrong, a
simple example can demostrate that.

If you are talking about my example, then please explain why the
element in the array becomes a reference if we add a reference to it?

I.e.
   $a = array('foo' => 'bar');
here $a contains the value 'bar' and not the reference to it.
   $tmp = &$a['foo'];
Are you saying that now $a has changed and now it contains a reference
to 'bar' and does not contain it as a value any more? Where is this
documented?



[2006-10-02 08:46:52] [EMAIL PROTECTED]

>Documentation describes that parameters are passed to >functions by
value by default. 
They are passed by value, including all the references in the array.
And since all the elements in the array are references, you're able to
modify them in the function.
See var_dump($myarray);



[2006-10-01 22:42:59] php_bug dot email at email dot digiways dot com

Documentation describes that parameters are passed to functions by
value by default. And since the behaviour you are talking about is not
documented anywhere, it is definitely a bug.

So, I suggest you read PHP documentation starting with
http://www.php.net/manual/en/functions.arguments.php
which clearly states:
===
By default, function arguments are passed by value (so that if you
change the value of the argument within the function, it does not get
changed outside of the function). If you wish to allow a function to
modify its arguments, you must pass them by reference.
===

and then explain it again why the problem described above is not a bug
although it does not do what PHP documentation states it does.



[2006-10-01 22:34:35] judas dot iscariote at gmail dot com

again, THIS IS NOT A BUG ¡!

but yes,this behaviuor should be described in the documentation I
think.

I still think this kind of code should raise an E_WARNING or something
( the idea was proposed a while ago, but refused)



[2006-10-01 22:12:20] plyrvt at mail dot ru

This bug can be described shortly:
"Existance of a reference to the element of an array prevents this
element to be passed by value as long as any reference point to it"



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

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

#39011 [Bgs->Opn]: foreach($_GET as $key => &$value) causes later bugs passing $_GET as a paramete

 ID:   39011
 User updated by:  php_bug dot email at email dot digiways dot com
 Reported By:  php_bug dot email at email dot digiways dot com
-Status:   Bogus
+Status:   Open
 Bug Type: Arrays related
 Operating System: Windows XP
 PHP Version:  5.1.6
 New Comment:

> And since all the elements in the array are references

Are you talking about arrays in general, or about my example?

If you are talking about arrays in general, this is simply wrong, a
simple example can demostrate that.

If you are talking about my example, then please explain why the
element in the array becomes a reference if we add a reference to it?

I.e.
   $a = array('foo' => 'bar');
here $a contains the value 'bar' and not the reference to it.
   $tmp = &$a['foo'];
Are you saying that now $a has changed and now it contains a reference
to 'bar' and does not contain it as a value any more? Where is this
documented?


Previous Comments:


[2006-10-02 08:46:52] [EMAIL PROTECTED]

>Documentation describes that parameters are passed to >functions by
value by default. 
They are passed by value, including all the references in the array.
And since all the elements in the array are references, you're able to
modify them in the function.
See var_dump($myarray);



[2006-10-01 22:42:59] php_bug dot email at email dot digiways dot com

Documentation describes that parameters are passed to functions by
value by default. And since the behaviour you are talking about is not
documented anywhere, it is definitely a bug.

So, I suggest you read PHP documentation starting with
http://www.php.net/manual/en/functions.arguments.php
which clearly states:
===
By default, function arguments are passed by value (so that if you
change the value of the argument within the function, it does not get
changed outside of the function). If you wish to allow a function to
modify its arguments, you must pass them by reference.
===

and then explain it again why the problem described above is not a bug
although it does not do what PHP documentation states it does.



[2006-10-01 22:34:35] judas dot iscariote at gmail dot com

again, THIS IS NOT A BUG ¡!

but yes,this behaviuor should be described in the documentation I
think.

I still think this kind of code should raise an E_WARNING or something
( the idea was proposed a while ago, but refused)



[2006-10-01 22:12:20] plyrvt at mail dot ru

This bug can be described shortly:
"Existance of a reference to the element of an array prevents this
element to be passed by value as long as any reference point to it"



[2006-10-01 22:02:06] php_bug dot email at email dot digiways dot com

Actually this is not just about foreach, this is the generic problem
with references.
Apparently if you have a reference to an array element, then when you
pass that array to a function and modify that element in the function,
then the external array is modified as well, and not just the copy
passed to the function.

A small example which shows the problem:
$myarray = array( 'mykey' => 'foo' );
function doit($tmp) { $tmp['mykey'] = 'bar'; }
$value = &$myarray['mykey'];
echo $myarray['mykey']."\n";
doit($myarray);
echo $myarray['mykey']."\n";

Once again - can anyone point to the documentation page which explains
this behaviour ?



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

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

#39003 [Opn->Asn]: __autoload unnecessarily called for type hinting

 ID:   39003
 Updated by:   [EMAIL PROTECTED]
 Reported By:  christoph at ziegenberg dot de
-Status:   Open
+Status:   Assigned
-Bug Type: Documentation problem
+Bug Type: Scripting Engine problem
 Operating System: WinXP SP2
 PHP Version:  5.1.6
-Assigned To:  
+Assigned To:  dmitry


Previous Comments:


[2006-10-02 09:39:28] [EMAIL PROTECTED]

Not a bug here, this is expected so marking as doc problem.



[2006-10-01 06:51:19] christoph at ziegenberg dot de

My version of the manual says this (from the example code):

// Fatal Error: Argument 1 must be an instance of OtherClass
$foo = new stdClass;
$myclass->test($foo);

So I should get the error "Fatal error: Argument 1 passed to test()
must be an instance of OtherClassName, called in [...]", but I get the
error "Fatal error: Class 'OtherClassName' not found in [...]".

Of course these are both fatal errors, but the one hand I expect
another behaviour for the autoloader function as described and on the
other hand the "correct" error message would help to debug the code,
because the current error only refers to the __autoloader() function
(so you have to use debug_backtrace()/debug_print_backtrace()).



[2006-10-01 06:07:57] judas dot iscariote at gmail dot com

if this is the expected behaviuor ( at least, not the behaviuor I
expect ;) ) it is not mentioned in the manual, so either the manual or
the engine needs to be corrected ;-)



[2006-09-30 10:05:56] christoph at ziegenberg dot de

Description:

if i check if a variable is an instance of specific class with
"instanceof" and the class i check for has not been loaded,
__autoloader() is not called (as expected).

if i do the "same" check by type hinting, the __autoloader() function
is called, which normally leads to including the required class file
and so unnecessarily consumes memory and time.

Reproduce code:
---
";
}
test($obj);
?>

Expected result:

no instance of OtherClassName

Actual result:
--
no instance of OtherClassName
try to load class OtherClassName
Fatal error: Class 'OtherClassName' not found in [...] on line 7





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

#39014 [Opn->Bgs]: php.ini data.timezone invalid

2006-10-02 Thread deepseath at gmail dot com

 ID:   39014
 User updated by:  deepseath at gmail dot com
 Reported By:  deepseath at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: IIS related
 Operating System: Win2000
 PHP Version:  5.1.6
 New Comment:

Occasionally resolved, but I do not know why, hehe


Previous Comments:


[2006-10-02 09:42:32] deepseath at gmail dot com

Description:

Win2000 installed in the php.ini data.timezone appears invalid. I set
up for the PRC, but the visit phpinfo () is still timezone=UTC show, I
set up the php.ini is correct and has kept the webserver. I was the IIS
webserver 

Reproduce code:
---
[Date]
; Defines the default timezone used by the date functions
date.timezone = PRC






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

#39014 [NEW]: php.ini data.timezone invalid

2006-10-02 Thread deepseath at gmail dot com

From: deepseath at gmail dot com
Operating system: Win2000
PHP version:  5.1.6
PHP Bug Type: IIS related
Bug description:  php.ini data.timezone invalid

Description:

Win2000 installed in the php.ini data.timezone appears invalid. I set up
for the PRC, but the visit phpinfo () is still timezone=UTC show, I set up
the php.ini is correct and has kept the webserver. I was the IIS webserver 

Reproduce code:
---
[Date]
; Defines the default timezone used by the date functions
date.timezone = PRC


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

#39012 [Opn->Bgs]: Incorrect gmdate('U') and date_default_timezone_set()

 ID:   39012
 Updated by:   [EMAIL PROTECTED]
 Reported By:  djmaze at planet dot nl
-Status:   Open
+Status:   Bogus
 Bug Type: Date/time related
 Operating System: Windows
 PHP Version:  5.1.6
 New Comment:

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

Unix timestamps are always in GMT (=UTC) so there is no problem here.


Previous Comments:


[2006-10-01 19:57:09] djmaze at planet dot nl

Description:

gmdate('U') shows the incorrect unix epoch.

http://php.net/gmdate: 'Format a GMT/UTC date/time'
http://php.net/date: 'U = Seconds since the Unix Epoch (January 1 1970
00:00:00 GMT)'

After calling date_default_timezone_set() everything is messed up, or
is that the whole purpose but someone forgot to document it?


Reproduce code:
---
 time(),
'date(\'U\')' => date('U'),
'date(\'Z\')'  => date('Z'),
'gmtime' => (time()-date('Z')),
'gmdate(\'U\')' => gmdate('U'),
'gmdate(\'Z\')' => gmdate('Z'),
'date_default_timezone' => date_default_timezone_get(),
);
}
$def = get_unixts();
date_default_timezone_set('UTC');
$set = get_unixts();

echo 'typenormalafter set
UTC';
foreach ($def as $t => $v)
{
echo "$t$v{$set[$t]}";
}
echo '';
?>

Expected result:

typenormal  after set UTC
time()  1159732108  1159724908
date('U')   1159732108  1159724908
date('Z')   72000
gmtime  1159724908  1159724908
gmdate('U') 1159724908  1159724908
gmdate('Z') 0   0


Actual result:
--
typenormal  after set UTC
time()  1159732108  1159732108
date('U')   1159732108  1159732108
date('Z')   72000
gmtime  1159724908  1159732108
gmdate('U') 1159732108  1159732108
gmdate('Z') 0   0






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

#39006 [Opn->Fbk]: PHP crashes at shutdown if browscap is on

 ID:   39006
 Updated by:   [EMAIL PROTECTED]
 Reported By:  alt2k4 at yandex dot ru
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: windows (xp sp2)
 PHP Version:  5.2.0RC4
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.




Previous Comments:


[2006-10-01 22:38:14] phpbugs at thequod dot de

Have you tried reproducing it with a php.ini file where 
just browscap is defined?



[2006-10-01 09:05:30] alt2k4 at yandex dot ru

Description:

PHP crashes at shutdown if browscap file is specified(even if
get_browser() not used). (tested on CGI)

Reproduce code:
---
ANYTHING, browscap enabled

Expected result:

normal shutdown.

Actual result:
--
php crash.
(I am REALLY sorry if this is not php problem, but mine installation)





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

#39013 [Opn->Fbk]: apache shutdown automatically

 ID:   39013
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jerry_zbs at 163 dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Apache related
 Operating System: windows2003
 PHP Version:  5.1.6
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2006-10-02 08:24:11] jerry_zbs at 163 dot com

Description:

i setuped an apache2.0(or higher version) server with php5.14(or higher
version) in modularization not in cgi mode,prophase,the server run in
the normal state,but after having more and more vistor,the server
shutdown automatically...then i refer the log of system,there is one
line "Application Error: Apache.exeCversion 2.0.49.0CError module:
unknownCversion 0.0.0.0CError Address 0x018c1c70B"...

if i run php in cgi mode,the problem disappear..

this is the one problem

and..i try to visit the "htm" page,not "php" page ,and fresh it
endlessly,the "htm" page has no problem,the server run find,but fresh
the "php" page is not!when i freshed the "php" page a few times, the
server shutdown automatically again...

i think,it may be the php core's problem..

the lower version php hasn't this problem,because i used the php5.0RC2
for a long time before..

i've try different versions of apache,but the same problem still
appear!

if anyone has this problem,and u fixed it,contact me,please!thanks a
lots!






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

#38819 [Opn->Fbk]: segfault in ldap_get_entries()

 ID:   38819
 Updated by:   [EMAIL PROTECTED]
 Reported By:  madcoder at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: LDAP related
 Operating System: 2.6.17-gentoo linux amd64
 PHP Version:  5.1.6
 New Comment:

So does it work for you if you add that magical -DLDAP_DEPRECATED=1 ?


Previous Comments:


[2006-10-01 08:16:08] madcoder at gmail dot com

For reference, I'm cross-posting a bug report I've opened with OpenLDAP
(ITS# 4690) in case they can provide any further information:
http://www.openldap.org/its/index.cgi/Incoming?id=4690;expression=ldap_get_values;statetype=-1



[2006-09-30 03:37:13] madcoder at gmail dot com

Any other ideas?  This problem is kind of a blocker for me right now...
 I still don't understand why it works fine inside valgrind, but it
segfaults on its own and inside gdb.  I know it's segfaulting because
of the message "Cannot access memory at address 0x55a0bfe0", so the for
loop checking vals[i] obviously fails.  But what steps can I take to
debug this further?

It could be a problem in openldap, since the line in php's ldap.c just
before it calls the openldap function 'ldap_count_values' is
ldap_get_values(), which is what is returning the memory address of
0x55a0bfe0.  But if it were in fact a problem with openldap, would the
cli ldapsearch fail as well?



[2006-09-26 11:08:50] madcoder at gmail dot com

I've tried, but the program doesn't segfault, so it exits normally. 
I'm not very experienced with gdb, so I'm not sure how to give it a
breakpoint of ldap_count_values (I tried 'break ldap_count_values' and
'break ldap_count_values()', and it doesn't break).

It does still return the information as expected.



[2006-09-26 10:57:53] [EMAIL PROTECTED]

Is it possible to perform the same actions using ldapsearch utility in
console?



[2006-09-26 10:43:23] madcoder at gmail dot com

Program received signal SIGSEGV, Segmentation fault.
0x2af2b2e5f0ab in ldap_count_values (vals=0x55a07f90) at
getvalues.c:153
153 for ( i = 0; vals[i] != NULL; i++ )
(gdb) p vals
$1 = (char **) 0x55a07f90
(gdb) p 0
$2 = 0
(gdb) p vals[0]
Cannot access memory at address 0x55a07f90

The memory address is the same.  Can't access memory?  It seems like
its a problem in php's ldap_get_entries still (or further up the stack)
because ldap_count_entries(), which calls the same function, works fine
and returns '1'.



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

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

#37103 [Opn->Csd]: libmbfl headers not installed

 ID:   37103
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Fedora at FamilleCollet dot com
-Status:   Open
+Status:   Closed
 Bug Type: mbstring related
 Operating System: Linux (Fedora)
 PHP Version:  5.1.6
 Assigned To:  hirokawa
 New Comment:

5.2 is the next 5.x release.


Previous Comments:


[2006-10-01 14:57:54] Fedora at FamilleCollet dot com

Seems ok for the headers with php5.2-200610011230.

What about php 5.1 branch ?



[2006-10-01 08:35:26] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2006-09-26 22:23:00] [EMAIL PROTECTED]

Assigned to the maintainer.



[2006-09-19 16:26:40] Fedora at FamilleCollet dot com

For php-5.2.0

I don't understand permissions on ext/mbstring/libmbfl/mbfl/mbfl_defs.h
(rwxr-xr-x) while other headers are rw-r--r--

I think the '*' in the config.m4 file is the problem.
So i change my previous patch to simply remove it and the packaging is
complete with all the headers (and mailparse pecl extension build
fine).

--- ext/mbstring/config.m4.orig 2006-09-18 17:46:08.0 +0200
+++ ext/mbstring/config.m4  2006-09-18 17:47:08.0 +0200
@@ -302,7 +302,7 @@
   dnl libmbfl is required
   PHP_MBSTRING_SETUP_LIBMBFL
   PHP_MBSTRING_EXTENSION
-  PHP_INSTALL_HEADERS([ext/mbstring], [libmbfl/config.h
libmbfl/mbfl/eaw_table.h libmbfl/mbfl/mbfilter.h
libmbfl/mbfl/mbfilter_8bit.h libmbfl/mbfl/mbfilter_pass.h
libmbfl/mbfl/mbfilter_wchar.h libmbfl/mbfl/mbfl_allocators.h
libmbfl/mbfl/mbfl_consts.h libmbfl/mbfl/mbfl_convert.h
libmbfl/mbfl/mbfl_defs.h* libmbfl/mbfl/mbfl_encoding.h
libmbfl/mbfl/mbfl_filter_output.h libmbfl/mbfl/mbfl_ident.h
libmbfl/mbfl/mbfl_language.h libmbfl/mbfl/mbfl_memory_device.h
libmbfl/mbfl/mbfl_string.h ])
+  PHP_INSTALL_HEADERS([ext/mbstring], [libmbfl/config.h
libmbfl/mbfl/eaw_table.h libmbfl/mbfl/mbfilter.h
libmbfl/mbfl/mbfilter_8bit.h libmbfl/mbfl/mbfilter_pass.h
libmbfl/mbfl/mbfilter_wchar.h libmbfl/mbfl/mbfl_allocators.h
libmbfl/mbfl/mbfl_consts.h libmbfl/mbfl/mbfl_convert.h
libmbfl/mbfl/mbfl_defs.h  libmbfl/mbfl/mbfl_encoding.h
libmbfl/mbfl/mbfl_filter_output.h libmbfl/mbfl/mbfl_ident.h
libmbfl/mbfl/mbfl_language.h libmbfl/mbfl/mbfl_memory_device.h
libmbfl/mbfl/mbfl_string.h ])
 fi

 # vim600: sts=2 sw=2 et



[2006-09-18 15:55:09] Fedora at FamilleCollet dot com

Still present in php-5.1.6 (only half corrected)

Patch :
--- ext/mbstring/config.m4.orig 2006-07-24 18:07:44.0 +0200
+++ ext/mbstring/config.m4  2006-07-24 18:08:03.0 +0200
@@ -293,7 +293,7 @@
   dnl libmbfl is required
   PHP_MBSTRING_SETUP_LIBMBFL
   PHP_MBSTRING_EXTENSION
-  PHP_INSTALL_HEADERS([ext/mbstring], [libmbfl/ libmbfl/mbfl])
+  PHP_INSTALL_HEADERS([ext/mbstring], [libmbfl/ libmbfl/mbfl/])
 fi
 
 # vim600: sts=2 sw=2 et


Even present in php-5.2.0RC5-dev (missing only one file : mbfl_defs.h)

Patch :
--- ext/mbstring/config.m4.orig 2006-09-18 17:46:08.0 +0200
+++ ext/mbstring/config.m4  2006-09-18 17:47:08.0 +0200
@@ -302,7 +302,7 @@
   dnl libmbfl is required
   PHP_MBSTRING_SETUP_LIBMBFL
   PHP_MBSTRING_EXTENSION
-  PHP_INSTALL_HEADERS([ext/mbstring], [libmbfl/config.h
libmbfl/mbfl/eaw_table.h libmbfl/mbfl/mbfilter.h
libmbfl/mbfl/mbfilter_8bit.h libmbfl/mbfl/mbfilter_pass.h
libmbfl/mbfl/mbfilter_wchar.h libmbfl/mbfl/mbfl_allocators.h
libmbfl/mbfl/mbfl_consts.h libmbfl/mbfl/mbfl_convert.h
libmbfl/mbfl/mbfl_defs.h* libmbfl/mbfl/mbfl_encoding.h
libmbfl/mbfl/mbfl_filter_output.h libmbfl/mbfl/mbfl_ident.h
libmbfl/mbfl/mbfl_language.h libmbfl/mbfl/mbfl_memory_device.h
libmbfl/mbfl/mbfl_string.h ])
+  PHP_INSTALL_HEADERS([ext/mbstring], [libmbfl/ libmbfl/mbfl/])
 fi
 
 # vim600: sts=2 sw=2 et



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

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

#39005 [Opn->Fbk]: Apache/PHP crashes

 ID:   39005
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at edwardk dot info
-Status:   Open
+Status:   Feedback
 Bug Type: Apache related
 Operating System: Windows 2003
 PHP Version:  4CVS-2006-09-30 (snap)
 New Comment:

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.




Previous Comments:


[2006-09-30 19:50:07] php at edwardk dot info

Description:

Opteron 246, Windows 2003 Std SP1
Apache 1.3.37
PHP 4.4.4

Also tried php4-win32-STABLE-200609301230, also crashing.

Apache crashes every 3-10 seconds upon first starting the Apache
service.
drwatson seems to indicate it's a PHP fault, log is included.

Requests made while apache is up seem to work fine.
Apache's parent process survives and auto-restarts the child process.

Reproduce code:
---
Server runs too many scripts to tell specifically.

Expected result:

Apache/PHP shouldn't crash

Actual result:
--
Microsoft (R) DrWtsn32
Copyright (C) 1985-2002 Microsoft Corp. All rights reserved.



Application exception occurred:
App: C:\Program Files\Apache Group\Apache\Apache.exe
(pid=2020)
When: 9/30/2006 @ 14:33:08.797
Exception number: c005 (access violation)

*> System Information <*
Computer Name: LT2
User Name: SYSTEM
Terminal Session Id: 0
Number of Processors: 2
Processor Type: x86 Family 15 Model 37 Stepping 1
Windows Version: 5.2
Current Build: 3790
Service Pack: 1
Current Type: Multiprocessor Free
Registered Organization: Windows-2003
Registered Owner: Windows-2003

*> Task List <*
   0 System Process
   4 System
 716 smss.exe
 788 csrss.exe
 868 winlogon.exe
 924 services.exe
 936 lsass.exe
1096 svchost.exe
1200 svchost.exe
1256 svchost.exe
1280 svchost.exe
1332 svchost.exe
1548 spoolsv.exe
1576 msdtc.exe
1772 svchost.exe
1912 G6FTPSERVER.EXE
2384 mysqld-max.exe
2404 mysqld-max.exe
2420 mysqld-max.exe
3644 PDAgent.exe
3860 svchost.exe
3876 PDEngine.exe
4088 alg.exe
2452 csrss.exe
3620 winlogon.exe
2208 csrss.exe
 884 winlogon.exe
5724 rdpclip.exe
5940 rdpclip.exe
6076 Explorer.EXE
2284 ctfmon.exe
 380 Explorer.EXE
2132 TSVNCache.exe
5588 wmiprvse.exe
3688 ADSM.exe
 476 jusched.exe
4324 G6FTPTray.exe
4684 mailserver.exe
4592 pg2.exe
4484 daemon.exe
4692 ADSM.exe
5128 ApacheMonitor.exe
4596 PowerMenu.exe
1500 flashfxp.exe
4240 TaskInfo.exe
4496 mmc.exe
3312 Explorer.EXE
5716 logon.scr
5264 Share.exe
5028 mirc.exe
4572 Apache.exe
3360 Apache.exe
2900 Apache.exe
3044 TextPad.exe
3676 wmiprvse.exe
3040 regedit.exe
2020 Apache.exe
4360 cmd.exe
3072 cmd.exe
5280 cmd.exe
4340 cmd.exe
4140 rotatelogs.exe
1624 cmd.exe
4224 cmd.exe
2948 rotatelogs.exe
3172 cmd.exe
3132 rotatelogs.exe
2968 cmd.exe
5468 rotatelogs.exe
3432 cmd.exe
 320 cmd.exe
4764 rotatelogs.exe
5344 cmd.exe
4680 cmd.exe
3444 cmd.exe
3120 cmd.exe
1440 rotatelogs.exe
5380 cmd.exe
 660 rotatelogs.exe
2260 cmd.exe
5200 cmd.exe
1748 rotatelogs.exe
 472 rotatelogs.exe
5984 rotatelogs.exe
4836 rotatelogs.exe
2176 rotatelogs.exe
4416 rotatelogs.exe
3700 rotatelogs.exe
5216 rotatelogs.exe
5304 rotatelogs.exe
2648 rotatelogs.exe
3652 drwtsn32.exe
2596 Error 0x8007012B

*> Module List <*
0040 - 00405000: C:\Program Files\Apache
Group\Apache\Apache.exe
00a0 - 00a17000: C:\WINDOWS\system32\odbcint.dll
00a6 - 00bd7000:
C:\php\extensions\php_mbstring.dll
00be - 00c1: C:\php\extensions\php_curl.dll
00c1 - 00c41000: C:\WINDOWS\system32\SSLEAY32.dll
00c5 - 00d58000: C:\WINDOWS\system32\LIBEAY32.dll
00de - 00ded000: C:\php\extensions\php_exif.dll
00df - 00ec5000: C:\php\extensions\php_gd2.dll
1000 - 10161000: C:\php\php4ts.dll
1c0f - 1c0f5000: C:\Program Files\Apache
Group\Apache\Win9xConHook.dll
4bf7 - 4bfad000: C:\WINDOWS\system32\ODBC32.dll
5f27 - 5f2c9000: C:\WINDOWS\system32\hnetcfg.dll
6000 - 60007000: c:\php\sapi\php4apache.dll
62d8 - 62d89000: C:\WINDOWS\system32\LPK.DLL
6950 - 69517000: C:\WINDOWS\system32\faultrep.dll
6fe4 - 6fe45000: c:\program files\apache
group\apache\modules\mod_status.so
6fe6 - 6fe6b000: c:\program file

#38998 [Opn->Asn]: wrong default values in constructor

 ID:   38998
 Updated by:   [EMAIL PROTECTED]
 Reported By:  camka at email dot ee
-Status:   Open
+Status:   Assigned
 Bug Type: MySQLi related
 Operating System: win 2000
 PHP Version:  5.1.6
-Assigned To:  
+Assigned To:  georg
 New Comment:

Assigned to the maintainer.


Previous Comments:


[2006-10-02 09:04:02] camka at email dot ee

This does not describe, why the first case does not give an error at
all, even if the host is not reachable or does not exist:

$m = mysqli(); // with no parameters



[2006-10-02 08:54:51] [EMAIL PROTECTED]

NULL values passed as parameter to mysqli::__construct() have a special
meaning, which are described in the docs.



[2006-09-29 22:42:06] camka at email dot ee

Description:

If passing NULL parameters in mysqli::__construct, as they are by
default, the values are not actually taken from php.ini (or apache
conf) file.

Tested with both 5.1.6 and 5.2 latest snapshot.

Reproduce code:
---
virtual host conf:
php_admin_value "mysqli.default_host" zorro
php_admin_value "mysqli.default_user" rootf
php_admin_value "mysqli.default_pw" ff



Expected result:

Access denied for user 'rootf'@'zorro' (using password: YES) 
Access denied for user 'rootf'@'zorro' (using password: YES)
Access denied for user 'rootf'@'zorro' (using password: YES)
Access denied for user 'rootf'@'zorro' (using password: YES)

Actual result:
--
[empty]
Access denied for user 'rootf'@'localhost' (using password: YES) 
Access denied for user 'ODBC'@'localhost' (using password: YES) 
Access denied for user 'ODBC'@'localhost' (using password: NO) 





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

#39002 [Opn->Fbk]: apache 2.2.3 don't start : R_PPC_REL24 relocation error

 ID:   39002
 Updated by:   [EMAIL PROTECTED]
 Reported By:  benoitc at archlinuxppc dot org
-Status:   Open
+Status:   Feedback
 Bug Type: Apache2 related
 Operating System: Arch Linux PPC
 PHP Version:  5.1.6
 New Comment:

Remove all those ./configure options and try with only these:
./configure --with-apxs2 --disable-all



Previous Comments:


[2006-09-30 09:32:33] benoitc at archlinuxppc dot org

Description:

Apache 2.2.3 don't start with last version of php 5.1.6. I have this
error :





Reproduce code:
---
Php configure line :

 ./configure --with-apxs2 --prefix=/usr --sysconfdir=/etc \
--with-layout=PHP \
--with-ttf --enable-mailparse --with-config-file-scan-dir=/etc \
--enable-bcmath=shared --enable-calendar=shared --enable-ftp=shared
\
--enable-gd-native-ttf --enable-magic-quotes --enable-posix=shared
\
--enable-session --enable-shared --enable-shmop=shared
--enable-pdo=shared \
--enable-sqlite-utf8 --enable-sockets=shared --enable-xml\
--enable-sysvsem=shared --enable-sysvshm=shared
--enable-sysvmsg=shared \
--enable-track-vars --enable-trans-sid --enable-safe-mode \
--with-imap --with-imap-ssl --with-ncurses --with-readline \
--with-bz2=shared --with-curl --with-mime-magic \
--with-freetype-dir=/usr --with-gd=shared --enable-exif
--with-jpeg-dir=/usr \
--enable-dba --without-db2 --without-db3 --with-inifile
--with-flatfile \
--with-gdbm --with-ldap=shared --with-openssl --with-gettext \
--with-unixODBC=shared,/usr --with-pdo-odbc=shared,unixODBC,/usr \
--with-mysqli=shared,/usr/bin/mysql_config
--with-mysql-sock=/tmp/mysql.sock \
--with-pdo-mysql=shared,/usr --with-mysql=shared,/usr \
--with-pgsql=shared --with-pgsql-sock=/tmp/pgsql.sock
--with-pdo-pgsql=shared,/usr \
--with-sqlite=shared --with-pdo-sqlite=shared,/usr \
--with-pear=/usr/share/pear --with-dom --with-dom-xslt --with-xsl
\
--with-png-dir=/usr --with-regex=php --with-zlib
--enable-soap=shared \
--enable-mbstring=all --enable-mbregex --with-snmp=shared,/usr 




Actual result:
--
httpd: Syntax error on line 114 of /etc/httpd/conf/httpd.conf: Cannot
load /etc/httpd/modules/libphp5.so into server:
/etc/httpd/modules/libphp5.so: R_PPC_REL24 relocation at 0x0d81ae40 for
symbol `free' out of range





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

#38998 [Bgs->Opn]: wrong default values in constructor

2006-10-02 Thread camka at email dot ee

 ID:   38998
 User updated by:  camka at email dot ee
 Reported By:  camka at email dot ee
-Status:   Bogus
+Status:   Open
 Bug Type: MySQLi related
 Operating System: win 2000
 PHP Version:  5.1.6
 New Comment:

This does not describe, why the first case does not give an error at
all, even if the host is not reachable or does not exist:

$m = mysqli(); // with no parameters


Previous Comments:


[2006-10-02 08:54:51] [EMAIL PROTECTED]

NULL values passed as parameter to mysqli::__construct() have a special
meaning, which are described in the docs.



[2006-09-29 22:42:06] camka at email dot ee

Description:

If passing NULL parameters in mysqli::__construct, as they are by
default, the values are not actually taken from php.ini (or apache
conf) file.

Tested with both 5.1.6 and 5.2 latest snapshot.

Reproduce code:
---
virtual host conf:
php_admin_value "mysqli.default_host" zorro
php_admin_value "mysqli.default_user" rootf
php_admin_value "mysqli.default_pw" ff



Expected result:

Access denied for user 'rootf'@'zorro' (using password: YES) 
Access denied for user 'rootf'@'zorro' (using password: YES)
Access denied for user 'rootf'@'zorro' (using password: YES)
Access denied for user 'rootf'@'zorro' (using password: YES)

Actual result:
--
[empty]
Access denied for user 'rootf'@'localhost' (using password: YES) 
Access denied for user 'ODBC'@'localhost' (using password: YES) 
Access denied for user 'ODBC'@'localhost' (using password: NO) 





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

#38998 [Opn->Bgs]: wrong default values in constructor

 ID:   38998
 Updated by:   [EMAIL PROTECTED]
 Reported By:  camka at email dot ee
-Status:   Open
+Status:   Bogus
 Bug Type: MySQLi related
 Operating System: win 2000
 PHP Version:  5.1.6
 New Comment:

NULL values passed as parameter to mysqli::__construct() have a special
meaning, which are described in the docs.


Previous Comments:


[2006-09-29 22:42:06] camka at email dot ee

Description:

If passing NULL parameters in mysqli::__construct, as they are by
default, the values are not actually taken from php.ini (or apache
conf) file.

Tested with both 5.1.6 and 5.2 latest snapshot.

Reproduce code:
---
virtual host conf:
php_admin_value "mysqli.default_host" zorro
php_admin_value "mysqli.default_user" rootf
php_admin_value "mysqli.default_pw" ff



Expected result:

Access denied for user 'rootf'@'zorro' (using password: YES) 
Access denied for user 'rootf'@'zorro' (using password: YES)
Access denied for user 'rootf'@'zorro' (using password: YES)
Access denied for user 'rootf'@'zorro' (using password: YES)

Actual result:
--
[empty]
Access denied for user 'rootf'@'localhost' (using password: YES) 
Access denied for user 'ODBC'@'localhost' (using password: YES) 
Access denied for user 'ODBC'@'localhost' (using password: NO) 





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

#39011 [Opn->Bgs]: foreach($_GET as $key => &$value) causes later bugs passing $_GET as a paramete