#35300 [Opn-Bgs]: PHP cannot read file names with multibyte character encoding

2005-11-20 Thread sniper
 ID:   35300
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dmceo415 at yahoo dot com
-Status:   Open
+Status:   Bogus
-Bug Type: Directory function related
+Bug Type: *General Issues
 Operating System: Windows XP
 PHP Version:  5.0.5
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

There are already feature requests for this. This is not a bug but
missing feature. And this missing feature will be in PHP 6.



Previous Comments:


[2005-11-20 00:50:46] dmceo415 at yahoo dot com

Description:

On an NTFS-formatted drive, Windows XP stores every character of a file
name in two bytes. Specifically, the encoding is UTF-16LE.

PHP's readdir has no problem reading NTFS file names that consist
only of characters included in the ISO-8859-1 repertoire. For these
characters, the first UTF-16LE byte is the same as the ISO-8859-1
representation, and the second byte is simply 0x00, the null byte,
which causes no damage.

However, for two-byte characters at higher code points - Chinese
characters, for example - readdir fails.

To illustrate, I created a directory with two files. One of the files
is named with Chinese characters; the other is named with ISO-8859-1
compatible characters. The following code:

if ($dir = opendir('.\TestFiles')) {
  while (false !== ($file = readdir($dir))) {
echo $file . 'br';
  }
}

produces this output:

.
..
???.m4a
Greensleeves.m4a

Clearly, readdir does not handle the two-byte Chinese characters
correctly. Instead, it returns question marks. This is a big problem if
one wants to use a PHP script to back up an NTFS-formatted drive.

(And, by the way, using mb_internal_encoding(UTF-16LE) does not solve
the problem; this seems to have no impact on readdir.)

Expected result:

readdir should be able to handle UTF-16 (i.e., two-byte) characters

Actual result:
--
readdir does not interpret two-byte characters correctly





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


#35301 [Opn-Bgs]: open_basedir allows one file in dir but not others further in

2005-11-20 Thread sniper
 ID:   35301
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bgshea at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Safe Mode/open_basedir
 Operating System: Linux 2.6
 PHP Version:  5.0.5
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.




Previous Comments:


[2005-11-20 08:46:47] bgshea at gmail dot com

Description:

[Sun Nov 20 00:36:12 2005] [error] [client 68.35.85.123] PHP Warning: 
readfile() [a href='function.readfile'function.readfile/a\
]: open_basedir restriction in effect.
File(/home/bgshea/g2data/cache/module/core/0/0/0.inc) is not within the
allowed path(s): (/\
mnt/sdc1/pub/www/:/usr/local/php-5.0.5/lib/:/mnt/sdc1/home/:/mnt/sdc1/pub/webfiles/)
in /mnt/sdc1/home/bgshea/webpage/fopen.php on \
line 12, referer: http://www.hackthebox.org/~bgshea/

NOTE: /home is a symlink to /mnt/sdc1/home

This is my first bug report, so if this does not post right, I'm sorry.
BTW: I've spent 5 hours trying to fix this, looked at all bugs related
to open_basedir and could not figure this out.

Reproduce code:
---
//Test a file open under /home/ works
$file=fopen(/home/bgshea/webpage/info.php, r );
fclose( $file );
//test a file read under /home/bgshea/g2data, works
readfile( /home/bgshea/g2data/install.log );
//This should work, but fails. Why? no symlinks here.
readfile(/home/bgshea/g2data/cache/module/core/0/0/0.inc);


open_basedir was set in httpd.conf to be
/mnt/sdc1/pub/www/:/usr/local/php-5.0.5/lib/:/mnt/sdc1/home/:/mnt/sdc1/pub/webfiles/


Expected result:

/home/bgshea/g2data/cache/module/core/0/0/0.inc file should be opened

Actual result:
--
Error message reported in log file, php script is terminated





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



#35288 [Fbk-Opn]: make test fails on FreeBSD

2005-11-20 Thread webmaster at negeta dot com
 ID:   35288
 User updated by:  webmaster at negeta dot com
 Reported By:  webmaster at negeta dot com
-Status:   Feedback
+Status:   Open
 Bug Type: ICONV related
 Operating System: FreeBSD 5.4
 PHP Version:  5.1.0RC6
 New Comment:

Only HAVE_ICONV is exist in my system.

Thank you for your patch, but it is not solve the problem.
This patch is not undef `iconv' when HAVE_LIBICONV is not defined.

As a test, I deleted first #ifdef HAVE_LIBICONV and #endif,
it force undef 'iconv', and problem was not reproduce.
But I can't estimate about side-effect on other system.


Previous Comments:


[2005-11-19 21:41:37] [EMAIL PROTECTED]

Also, is HAVE_BSD_ICONV defined on your system?



[2005-11-19 21:37:17] [EMAIL PROTECTED]

Try the following patch:
http://bb.prohost.org/patch/iconv.txt



[2005-11-19 17:55:52] webmaster at negeta dot com

I found how this problem occurs on my env.

0. C function iconv is exist, and libiconv is not.
1. configure detects #define HAVE_ICONV 1
  and HAVE_LIBICONV is not defined.
2. #define iconv libiconv in /usr/local/include/iconv.h line 80.
3. #undef iconv is not execute in ext/iconv/iconv.c line 55.
4. `libiconv' links to php_if_iconv in ext/iconv/iconv.c line 68. PHP
function libiconv is created.



[2005-11-19 14:28:02] [EMAIL PROTECTED]

Can't reproduce.
# ./sapi/cli/php -r 'iconv();'

Warning: iconv() expects exactly 3 parameters, 0 given in Command line
code on line 1
# uname -r
5.4-STABLE



[2005-11-19 14:07:12] webmaster at negeta dot com

I installed iconv from /usr/ports/converters/libiconv.
iconv.h is found in /usr/local/include.
I can find #define iconv libiconv in 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/35288

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


#35303 [NEW]: PDO prepare crashes

2005-11-20 Thread stochnagara at hotmail dot com
From: stochnagara at hotmail dot com
Operating system: windows xp
PHP version:  5CVS-2005-11-20 (snap)
PHP Bug Type: PDO related
Bug description:  PDO prepare crashes

Description:

PDO still crashes Apache when using child classes.
See bug #35118 - it's almost the same.

Reproduce code:
---
?
class MAppPDOStatement extends PDOStatement {
}

class MAppPDO extends PDO {
function prepare ($string, array $options = array()) {
$options [PDO::ATTR_STATEMENT_CLASS] = 'MAppPDOStatement';
parent::prepare ($string, $options);
}
}

$a = new MAppPDO(sqlite::memory:);
$a-prepare(insert into test (b) values (?));


Expected result:

no errors

Actual result:
--
Apache crashes.

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


#35304 [NEW]: PHP always segfaults with --without-sqlite

2005-11-20 Thread matteo at beccati dot com
From: matteo at beccati dot com
Operating system: Debian GNU/Linux testing/etch
PHP version:  5.1.0RC6
PHP Bug Type: Scripting Engine problem
Bug description:  PHP always segfaults with --without-sqlite

Description:

I was starting to test PHP5.1.0RC6.

make install was exiting with a segmentation fault, because running php
from command line always exit with a segfault. I tracked down that the
problem depends by the fact I used --without-sqlite in the configure
options.

Using the php5-200511200930 snapshot also leads to the same result.

Configure line used for the backtrace:
CFLAGS=-O0 ./configure --disable-cgi --without-sqlite


Actual result:
--
(gdb) run
Starting program: /root/compile/php5-200511200930/sapi/cli/php

Program received signal SIGSEGV, Segmentation fault.
0x08200adf in _zend_hash_add_or_update ()
(gdb) bt full
#0  0x08200adf in _zend_hash_add_or_update ()
No symbol table info available.
#1  0x080ce8c4 in php_pdo_register_driver ()
No symbol table info available.
#2  0x080d8fc7 in zm_startup_pdo_sqlite ()
No symbol table info available.
#3  0x081fcd27 in zend_startup_module_ex ()
No symbol table info available.
#4  0x08202047 in zend_hash_apply ()
No symbol table info available.
#5  0x081fceb6 in zend_startup_modules ()
No symbol table info available.
#6  0x081ba3c2 in php_module_startup ()
No symbol table info available.
#7  0x082674dd in main ()
No symbol table info available.


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


#34883 [Bgs-Csd]: crash when accessing superglobals

2005-11-20 Thread sveta at microbecal dot com
 ID:   34883
 User updated by:  sveta at microbecal dot com
 Reported By:  sveta at microbecal dot com
-Status:   Bogus
+Status:   Closed
 Bug Type: Apache2 related
 Operating System: Windows XP SP1
 PHP Version:  5CVS-2005-10-16 (snap)
 New Comment:

In RC7 works fine in my environment


Previous Comments:


[2005-10-23 23:54:58] [EMAIL PROTECTED]

I can only assume that there is something wrong with your environment
since it does work on all of my test systems and we have not recieved
any reports of PHP crashing on simple phpinfo().



[2005-10-23 23:36:00] sveta at microbecal dot com

I have tried without any dlls too. First trace (TowerExplode () )
without any dll's.
I have access to 3 Windows XP machine: one with SP2 (worked fine, but
builds not same: some hours differents) and 2 with SP1 (works with
crashes).



[2005-10-23 23:23:19] [EMAIL PROTECTED]

Just verified with the latest CVS and the phpinfo page displays just
fine when using PHP without any additional extensions. You must have
mixed up dlls from several different PHP versions, or are loading some
extension which is causing the crash.



[2005-10-21 11:31:41] sveta at microbecal dot com

If so why previous versions of PHP 5.1 brunch worked fine?



[2005-10-21 09:08:18] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.





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

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


#35205 [Asn]: oci_connect is not closing opened connections after script execution

2005-11-20 Thread robertg2 at hope dot ac dot uk
 ID:   35205
 User updated by:  robertg2 at hope dot ac dot uk
 Reported By:  robertg2 at hope dot ac dot uk
 Status:   Assigned
 Bug Type: OCI8 related
 Operating System: Solaris 8
 PHP Version:  5.0.5
 Assigned To:  tony2001
 New Comment:

Tony,

Unfortunately it doesn't look like it picked up the instant client in
compilation as the new style \\HOSTNAME\DBNAME referencing feature
doesn't work.  So still it's unclear whether compiling with the instant
client would reproduce the problem.

Will try again tonight.


Previous Comments:


[2005-11-20 01:55:28] robertg2 at hope dot ac dot uk

Sorry for the delay in testing.

The connection is closed off correctly when compiled against
InstantClient 10.



[2005-11-15 19:09:31] [EMAIL PROTECTED]

... and it works fine even if the MPM if worker, so this is not a
multithreading related issue.
Please try to build PHP with Oracle Instant Client and see if it
helps.




[2005-11-15 14:47:40] [EMAIL PROTECTED]

Just for the record: I can't reproduce on Linux and on Solaris with
Apache2/prefork.




[2005-11-14 01:39:02] robertg2 at hope dot ac dot uk

I believe you.  We both want the same thing right?

In this role, I answer to my boss first.  To the University's students
second.  And to the PHP community a far third.

I'm well aware that to fix this bug I should to help you, and that's
why I shall schedule maintenance and take one of the web servers out of
the load balancing circuit when is convenient for me and the
organisation and the students it serves.

A traveller from Bug #29779, there's nothing more in PHP - and I'm a
PHP fanatic - to see a reliable oci8 library.

I'm lurking on Undernet about to ambush you when you get on :p.



[2005-11-14 00:34:19] [EMAIL PROTECTED]

It'll take some time for me to install OCI client at Solaris and build
PHP --with-oci8, so I doubt I'll be able to do it in the nearest days.

Though, that doesn't mean that I won't do it at all.
I believe it'd be easier to install debugger and to see if this is a
problem of PHP or a problem of Oracle Client on Solaris (and to help
*yourself* this way).
Reconfirming and re-re-confirming doesn't add any value, believe me.



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

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


#35205 [Asn]: oci_connect is not closing opened connections after script execution

2005-11-20 Thread robertg2 at hope dot ac dot uk
 ID:   35205
 User updated by:  robertg2 at hope dot ac dot uk
 Reported By:  robertg2 at hope dot ac dot uk
 Status:   Assigned
 Bug Type: OCI8 related
 Operating System: Solaris 8
 PHP Version:  5.0.5
 Assigned To:  tony2001
 New Comment:

oh and... as for the comment I made at 1:55am... that was a mistake.  I
hadn't taken the oci_close statement out of the code.

Sorry :(


Previous Comments:


[2005-11-20 13:15:55] robertg2 at hope dot ac dot uk

Tony,

Unfortunately it doesn't look like it picked up the instant client in
compilation as the new style \\HOSTNAME\DBNAME referencing feature
doesn't work.  So still it's unclear whether compiling with the instant
client would reproduce the problem.

Will try again tonight.



[2005-11-20 01:55:28] robertg2 at hope dot ac dot uk

Sorry for the delay in testing.

The connection is closed off correctly when compiled against
InstantClient 10.



[2005-11-15 19:09:31] [EMAIL PROTECTED]

... and it works fine even if the MPM if worker, so this is not a
multithreading related issue.
Please try to build PHP with Oracle Instant Client and see if it
helps.




[2005-11-15 14:47:40] [EMAIL PROTECTED]

Just for the record: I can't reproduce on Linux and on Solaris with
Apache2/prefork.




[2005-11-14 01:39:02] robertg2 at hope dot ac dot uk

I believe you.  We both want the same thing right?

In this role, I answer to my boss first.  To the University's students
second.  And to the PHP community a far third.

I'm well aware that to fix this bug I should to help you, and that's
why I shall schedule maintenance and take one of the web servers out of
the load balancing circuit when is convenient for me and the
organisation and the students it serves.

A traveller from Bug #29779, there's nothing more in PHP - and I'm a
PHP fanatic - to see a reliable oci8 library.

I'm lurking on Undernet about to ambush you when you get on :p.



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

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


#35292 [Fbk-Opn]: Can't connect to local MySQL server through socket

2005-11-20 Thread dgrimes at scvl dot com
 ID:   35292
 User updated by:  dgrimes at scvl dot com
 Reported By:  dgrimes at scvl dot com
-Status:   Feedback
+Status:   Open
 Bug Type: MySQL related
 Operating System: SCO OpenServer
 PHP Version:  4.4.1
 New Comment:

Yes. The path to the socket is correct. The only thing I do to make it
work is refresh the page two or three times and it will eventually
connect. Another thing, if I use PHP 4.2.3 or less, I don't have the
problem at all.

I noticed that beginning in PHP 4.3.0 many changes were made in the
area of sockets. What is the large negative number that is returned in
the message (-2146870980)? What I've seen in the past when the path is
incorrect is this:

2002 - Can't connect to local MySQL server through socket
'/d/mysql/var/mysqlx.sock' (2)

Notice that (2) is a positive integer and not negative. All I did was
change mysql.sock to mysqlx.sock in the php.ini file. What's also
interesting is that I received the other error (-2146870980) two times
before getting the correct error (2).

MySQL isn't logging anything so as far as it's concerned, nothing has
made an attempt to connect. I thought it might be a timeout so I tried
setting some of the timeout values but it didn't help. Is it possible
that PHP isn't waiting long enough for MySQL to respond? Is the error
saying that it can't find the socket file or that it simply can't
connect to the socket file?

If you'd like, I can place some debug code in the connect function to
see what is happening or I can compile with debug to watch it execute
but I'll need instructions on where to place break points and what
symbols to look at.

Dean


Previous Comments:


[2005-11-20 08:52:09] [EMAIL PROTECTED]

Are you sure that path to the socket is correct?




[2005-11-19 14:58:53] dgrimes at scvl dot com

Still have the same problem with the latest snapshot.

Dean



[2005-11-19 14:25:17] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2005-11-19 14:18:21] dgrimes at scvl dot com

Description:

I am having random failure on making a connection to MySQL. This the
code used to make the connection and has been for several years.

if (!$this-linkid =
mysql_connect($this-host,$this-user,$this-pass))

DBError(mysql_errno(),mysql_error(),LINKID-$db,$this-mailerr,$this-sendto);

The following error is returned randomly however it happens usually
right after starting apache or after a period of inactivity:

2002 - Can't connect to local MySQL server through socket
'/d/mysql/var/mysql.so
ck' (-2146870980)

Starting with version PHP 4.3.0 is when the problem started. Version
4.2.x does not have this problem. I compiled every version until I
found where the problem started. I am currently trying to move from
4.0.6 to 4.4.1 but need to get this issue addressed.

My system:
SCO OpenServer 5.0.4 and 5.0.6
MySQL 4.1.15
Apache 1.3.34

Reproduce code:
---
if (!$this-linkid =
mysql_connect($this-host,$this-user,$this-pass))
 DBError(mysql_errno(),mysql_error(),$this-linkid
LINKID-$db,$this-m
ailerr,$this-sendto);


Expected result:

I expected to get a resource ID returned.

Actual result:
--
2002 - Can't connect to local MySQL server through socket
'/d/mysql/var/mysql.so
ck' (-2146870980)






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


#35301 [Bgs]: open_basedir allows one file in dir but not others further in

2005-11-20 Thread bgshea at gmail dot com
 ID:   35301
 User updated by:  bgshea at gmail dot com
 Reported By:  bgshea at gmail dot com
 Status:   Bogus
 Bug Type: Safe Mode/open_basedir
 Operating System: Linux 2.6
 PHP Version:  5.0.5
 New Comment:

Indeed, you are correct, the fact that 0.inc does not exist in the dir
causes the failure, the bug seems to be in the documentation on how to
use open_basedir.

I overlooked a previous bug report (Bug #30188).

For all that read these bugs, you need to check for file existance
(file_exists(/path/to/file) ). 

Maybe the open_basedir should be called something else cause it is
mis-leading if it also dis-allows on a file by file basis.

I'm gonna post this in the docs as well.

Thanks for the little bit help.


Previous Comments:


[2005-11-20 10:14:03] [EMAIL PROTECTED]

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.





[2005-11-20 08:46:47] bgshea at gmail dot com

Description:

[Sun Nov 20 00:36:12 2005] [error] [client 68.35.85.123] PHP Warning: 
readfile() [a href='function.readfile'function.readfile/a\
]: open_basedir restriction in effect.
File(/home/bgshea/g2data/cache/module/core/0/0/0.inc) is not within the
allowed path(s): (/\
mnt/sdc1/pub/www/:/usr/local/php-5.0.5/lib/:/mnt/sdc1/home/:/mnt/sdc1/pub/webfiles/)
in /mnt/sdc1/home/bgshea/webpage/fopen.php on \
line 12, referer: http://www.hackthebox.org/~bgshea/

NOTE: /home is a symlink to /mnt/sdc1/home

This is my first bug report, so if this does not post right, I'm sorry.
BTW: I've spent 5 hours trying to fix this, looked at all bugs related
to open_basedir and could not figure this out.

Reproduce code:
---
//Test a file open under /home/ works
$file=fopen(/home/bgshea/webpage/info.php, r );
fclose( $file );
//test a file read under /home/bgshea/g2data, works
readfile( /home/bgshea/g2data/install.log );
//This should work, but fails. Why? no symlinks here.
readfile(/home/bgshea/g2data/cache/module/core/0/0/0.inc);


open_basedir was set in httpd.conf to be
/mnt/sdc1/pub/www/:/usr/local/php-5.0.5/lib/:/mnt/sdc1/home/:/mnt/sdc1/pub/webfiles/


Expected result:

/home/bgshea/g2data/cache/module/core/0/0/0.inc file should be opened

Actual result:
--
Error message reported in log file, php script is terminated





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


#35305 [NEW]: include with GET vars crash PHP

2005-11-20 Thread labsy at seznam dot org
From: labsy at seznam dot org
Operating system: Windows 2003
PHP version:  5.0.5
PHP Bug Type: IIS related
Bug description:  include with GET vars crash PHP

Description:

Ocasionally my PHP crashes on IIS 6.0 with error:

PHP encountered access violation at...

From that moment further PHP pages don't work until I restart IIS, but
other pages, like ASP and HTML, parse normally.

I found one piece of code which MAY (but does not always) reproduce PHP
crash on IIS. It may occure when PHP include command tries to include a
file with GET vars inside a block of another PHP/HTML mixed block.

Reproduce code:
---
?php
 echo Hello PHP World br\n;
{
?
Hello HTML world! This is HTML part of code.
   ?php // Here we include a file with GET var 
 // and produce PHP crash
include test_bug2.php?b=dfdfdfdf;
   ?
?php }
?

Expected result:

An ERROR should be produced:

Warning: main(test_bug2.php?b=dfdfdfdf) [function.main]: failed to open
stream: Invalid argument in test_bug1.php on line 

Actual result:
--
Instead, on Win 2003 with IIS, this code SOMETIMES causes PHP to crash
with error:

PHP has encountered access violation at address ...

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


#35292 [Opn-Fbk]: Can't connect to local MySQL server through socket

2005-11-20 Thread sniper
 ID:   35292
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dgrimes at scvl dot com
-Status:   Open
+Status:   Feedback
 Bug Type: MySQL related
 Operating System: SCO OpenServer
 PHP Version:  4.4.1
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2005-11-20 13:34:36] dgrimes at scvl dot com

Yes. The path to the socket is correct. The only thing I do to make it
work is refresh the page two or three times and it will eventually
connect. Another thing, if I use PHP 4.2.3 or less, I don't have the
problem at all.

I noticed that beginning in PHP 4.3.0 many changes were made in the
area of sockets. What is the large negative number that is returned in
the message (-2146870980)? What I've seen in the past when the path is
incorrect is this:

2002 - Can't connect to local MySQL server through socket
'/d/mysql/var/mysqlx.sock' (2)

Notice that (2) is a positive integer and not negative. All I did was
change mysql.sock to mysqlx.sock in the php.ini file. What's also
interesting is that I received the other error (-2146870980) two times
before getting the correct error (2).

MySQL isn't logging anything so as far as it's concerned, nothing has
made an attempt to connect. I thought it might be a timeout so I tried
setting some of the timeout values but it didn't help. Is it possible
that PHP isn't waiting long enough for MySQL to respond? Is the error
saying that it can't find the socket file or that it simply can't
connect to the socket file?

If you'd like, I can place some debug code in the connect function to
see what is happening or I can compile with debug to watch it execute
but I'll need instructions on where to place break points and what
symbols to look at.

Dean



[2005-11-20 08:52:09] [EMAIL PROTECTED]

Are you sure that path to the socket is correct?




[2005-11-19 14:58:53] dgrimes at scvl dot com

Still have the same problem with the latest snapshot.

Dean



[2005-11-19 14:25:17] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2005-11-19 14:18:21] dgrimes at scvl dot com

Description:

I am having random failure on making a connection to MySQL. This the
code used to make the connection and has been for several years.

if (!$this-linkid =
mysql_connect($this-host,$this-user,$this-pass))

DBError(mysql_errno(),mysql_error(),LINKID-$db,$this-mailerr,$this-sendto);

The following error is returned randomly however it happens usually
right after starting apache or after a period of inactivity:

2002 - Can't connect to local MySQL server through socket
'/d/mysql/var/mysql.so
ck' (-2146870980)

Starting with version PHP 4.3.0 is when the problem started. Version
4.2.x does not have this problem. I compiled every version until I
found where the problem started. I am currently trying to move from
4.0.6 to 4.4.1 but need to get this issue addressed.

My system:
SCO OpenServer 5.0.4 and 5.0.6
MySQL 4.1.15
Apache 1.3.34

Reproduce code:
---
if (!$this-linkid =
mysql_connect($this-host,$this-user,$this-pass))
 DBError(mysql_errno(),mysql_error(),$this-linkid
LINKID-$db,$this-m
ailerr,$this-sendto);


Expected result:

I expected to get a resource ID returned.

Actual result:
--
2002 - Can't connect to local MySQL server through socket
'/d/mysql/var/mysql.so
ck' (-2146870980)






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


#35305 [Opn-Fbk]: include with GET vars crash PHP

2005-11-20 Thread sniper
 ID:   35305
 Updated by:   [EMAIL PROTECTED]
 Reported By:  labsy at seznam dot org
-Status:   Open
+Status:   Feedback
 Bug Type: IIS related
 Operating System: Windows 2003
 PHP Version:  5.0.5
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2005-11-20 17:44:49] labsy at seznam dot org

Description:

Ocasionally my PHP crashes on IIS 6.0 with error:

PHP encountered access violation at...

From that moment further PHP pages don't work until I restart IIS, but
other pages, like ASP and HTML, parse normally.

I found one piece of code which MAY (but does not always) reproduce PHP
crash on IIS. It may occure when PHP include command tries to include
a file with GET vars inside a block of another PHP/HTML mixed block.

Reproduce code:
---
?php
 echo Hello PHP World br\n;
{
?
Hello HTML world! This is HTML part of code.
   ?php // Here we include a file with GET var 
 // and produce PHP crash
include test_bug2.php?b=dfdfdfdf;
   ?
?php }
?

Expected result:

An ERROR should be produced:

Warning: main(test_bug2.php?b=dfdfdfdf) [function.main]: failed to open
stream: Invalid argument in test_bug1.php on line 

Actual result:
--
Instead, on Win 2003 with IIS, this code SOMETIMES causes PHP to crash
with error:

PHP has encountered access violation at address ...





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


#35304 [Opn-Fbk]: PHP always segfaults with --without-sqlite

2005-11-20 Thread sniper
 ID:   35304
 Updated by:   [EMAIL PROTECTED]
 Reported By:  matteo at beccati dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: Debian GNU/Linux testing/etch
 PHP Version:  5.1.0RC6
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2005-11-20 12:57:15] matteo at beccati dot com

Description:

I was starting to test PHP5.1.0RC6.

make install was exiting with a segmentation fault, because running php
from command line always exit with a segfault. I tracked down that the
problem depends by the fact I used --without-sqlite in the configure
options.

Using the php5-200511200930 snapshot also leads to the same result.

Configure line used for the backtrace:
CFLAGS=-O0 ./configure --disable-cgi --without-sqlite


Actual result:
--
(gdb) run
Starting program: /root/compile/php5-200511200930/sapi/cli/php

Program received signal SIGSEGV, Segmentation fault.
0x08200adf in _zend_hash_add_or_update ()
(gdb) bt full
#0  0x08200adf in _zend_hash_add_or_update ()
No symbol table info available.
#1  0x080ce8c4 in php_pdo_register_driver ()
No symbol table info available.
#2  0x080d8fc7 in zm_startup_pdo_sqlite ()
No symbol table info available.
#3  0x081fcd27 in zend_startup_module_ex ()
No symbol table info available.
#4  0x08202047 in zend_hash_apply ()
No symbol table info available.
#5  0x081fceb6 in zend_startup_modules ()
No symbol table info available.
#6  0x081ba3c2 in php_module_startup ()
No symbol table info available.
#7  0x082674dd in main ()
No symbol table info available.






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


#35243 [Opn-Csd]: Crashes in php_mblen when compiled with thread-safety on Linux

2005-11-20 Thread sniper
 ID:   35243
 Updated by:   [EMAIL PROTECTED]
 Reported By:  shulmanb at il dot ibm dot com
-Status:   Open
+Status:   Closed
 Bug Type: *General Issues
 Operating System: Linux
 PHP Version:  5CVS-2005-11-19 (snap)
 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:


[2005-11-18 17:18:24] shulmanb at il dot ibm dot com

Done.

Can be found at: http://news.php.net/php.internals/20164



[2005-11-16 18:18:33] [EMAIL PROTECTED]

And if it's still a problem, provide the patch in unified diff format.



[2005-11-16 16:07:01] shulmanb at il dot ibm dot com

Description:

When running on Linux with --enable-maintainer-zts (and yes, I know
it's not wise...), crashes sometimes happen in
ext/standard/php_string.h when using the php_mblen macro.

This happens because in ext/standard/basic_functions.c, in the
basic_globals_ctor function, the value of mblen_state is not
initialized.

The basic_globals_ctor function should include the following lines as
part of the initialization:

#if defined(_REENTRANT)defined(HAVE_MBRLEN)defined(HAVE_MBSTATE_T)
memset(BG(mblen_state), 0, sizeof(BG(mblen_state)));
#endif

Unfortunately, I am unable to include code that demonstrate this, as
the crash strongly depends on the (random) value of mblen_state.






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


#28461 [Opn-Fbk]: segmentation fault when using backreferences on a long string

2005-11-20 Thread sniper
 ID:   28461
 Updated by:   [EMAIL PROTECTED]
 Reported By:  xanthor at xanthor dot tk
-Status:   Open
+Status:   Feedback
 Bug Type: PCRE related
 Operating System: *
 PHP Version:  4.4.1
 Assigned To:  andrei
 New Comment:

It's not really useful since it doesn't exist. Try again..



Previous Comments:


[2005-11-19 17:07:20] xanthor at xanthor dot tk

Here is the bactrace : http://rafb.net/paste/results/221Dcs52.html

I don't know if this will be usefull :¬/



[2005-11-16 10:21:24] [EMAIL PROTECTED]

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

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





[2005-11-16 04:48:51] xanthor at xanthor dot tk

Still crashes with 4.4.1, increasing the length of the string.



[2005-06-22 21:51:39] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Can't reproduce with latest PHP4 and PHP5 snapshots (PCRE was upgraded
to 5.0, this might have fixed it).



[2004-12-09 14:57:59] [EMAIL PROTECTED]

This is the standard PCRE uses on-stack recursion bug which has been
filed and closed umpteen times.  To reproduce just increase the length
of the string until exhausts your stack space.

One way PHP could mitigate the issue is to to set the match_limit field
in the pcre_extra structure which puts a limit on the depth of the stack
recursion.  



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

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


#35005 [Opn-Bgs]: Opening a lot of files result in no network connectivity

2005-11-20 Thread sniper
 ID:   35005
 Updated by:   [EMAIL PROTECTED]
 Reported By:  daniel at polkabrothers dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Network related
 Operating System: Mac OS X 10.4.2
 PHP Version:  5CVS-2005-10-31 (snap)
 New Comment:

Works fine for me. Just increase your limits and it will work.



Previous Comments:


[2005-10-27 23:17:00] daniel at polkabrothers dot com

I should probably add that I've tried running this both as 
root (su root; ulimit -n 5000) and using sudo (sudo php ...).

Same result.



[2005-10-27 23:06:30] daniel at polkabrothers dot com

I used ulimit -n to increase the number of allowed open 
files, otherwise it wouldn't even allow me to create 3000 
files.

Now ulimit -a gives me:

core file size(blocks, -c) 0
data seg size (kbytes, -d) 6144
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size   (kbytes, -m) unlimited
open files(-n) 10240
pipe size  (512 bytes, -p) 1
stack size(kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes(-u) 100
virtual memory(kbytes, -v) unlimited

Can't find anything else which relates to file descriptors 
and Mac OS X.



[2005-10-27 22:56:55] [EMAIL PROTECTED]

Looks like MacOSX has max number of file descriptors set to 1024 or
something like that.
I don't have MacOSX around here, but I guess this fact should be
documented somewhere @ apple.com.
Could you check it?



[2005-10-27 22:50:34] daniel at polkabrothers dot com

Have now done a bit more testing, and it only happens if you 
try to open more than 1017 files and then try to open a url.

Have tried opening urls with fopen(), curl_* and exec
(wget). Same end-result, they don't connect.

PHP doesn't generate any error messages when trying to open 
using fopen(). When trying it with the curl functions, curl 
returns with couldn't connect but if you turn on more 
debugging it comes back with Unknown error: 0. When trying 
to exec() wget it stops as soon as it gets a connection and 
is about to output 200 OK

(i have read the how to report bugs, but can't find what i'm 
missing to include)



[2005-10-27 22:31:53] daniel at polkabrothers dot com

Description:

When opening a lot (3000 in this case) files under Mac OS X, 
network connectivity disappears.

This has been tested under Linux 2.6, and works fine.

Reproduce code:
---
$fp = array();
for($x=0;$x3000;$x++) {
$fp[$x] = fopen(/tmp/$x, w);
}

$url_fp = fopen(http://www.google.com;, r);
var_dump(fread($url_fp, 1500));

Expected result:

To get the first 1500 bytes from www.google.com

Actual result:
--
string(0) 





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


#28461 [Fbk-Sus]: segmentation fault when using backreferences on a long string

2005-11-20 Thread sniper
 ID:   28461
 Updated by:   [EMAIL PROTECTED]
 Reported By:  xanthor at xanthor dot tk
-Status:   Feedback
+Status:   Suspended
 Bug Type: PCRE related
 Operating System: *
 PHP Version:  4.4.1
 Assigned To:  andrei
 New Comment:

Andrei says this is not possible to fix since we can't tell what the
limit for recursion should be.



Previous Comments:


[2005-11-20 19:22:55] [EMAIL PROTECTED]

It's not really useful since it doesn't exist. Try again..




[2005-11-19 17:07:20] xanthor at xanthor dot tk

Here is the bactrace : http://rafb.net/paste/results/221Dcs52.html

I don't know if this will be usefull :¬/



[2005-11-16 10:21:24] [EMAIL PROTECTED]

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

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





[2005-11-16 04:48:51] xanthor at xanthor dot tk

Still crashes with 4.4.1, increasing the length of the string.



[2005-06-22 21:51:39] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Can't reproduce with latest PHP4 and PHP5 snapshots (PCRE was upgraded
to 5.0, this might have fixed 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/28461

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


#35144 [Opn-Fbk]: odbc_connect segmentation fault

2005-11-20 Thread sniper
 ID:   35144
 Updated by:   [EMAIL PROTECTED]
 Reported By:  rberquist at sbdrepro dot com
-Status:   Open
+Status:   Feedback
 Bug Type: ODBC related
 Operating System: Highly customized RH
 PHP Version:  5CVS-2005-11-07 (snap)
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2005-11-08 22:01:23] rberquist at sbdrepro dot com

Well, using the isql command, the odbc works. With PHP, it does not.
This is what has led me to believe that it's not a unixODBC issue.
Also, setting up a mysql DSN entry in odbc.ini has proven successful.
It connects fine and allows query execution.

I've recently found out that it could possibly be the driver and am
currently working with the third party developers at the moment. The
driver is /usr/local/lib/libtfodbccl.so, which is referenced in the bt.
However, they contend that if it works with isql, then the problem is
not with the driver.

If you have any other ideas for troubleshooting and pinpointing the
issue, I'd be happy to comply.



[2005-11-08 21:44:28] [EMAIL PROTECTED]

Are you absolutely sure this isn't a bug in unixODBC? As the backtrace
would suggest it's crashing in there, not in PHP.



[2005-11-07 23:50:57] rberquist at sbdrepro dot com

The latest snapshot is installed along with PDO and pdo_odbc. pdo_odbc
was compile with 
./configure --with-unixODBC
Php (php5-200511072130) was compiled the same as before.

Using pdo_mysql connects fine to a mysql database. However, using odbc
with the third party provided driver(Thoroughbred Proprietary DBMS),
I'm getting segfaults again. However, still no problems using isql. The
backtrace of using pdo is as follows. Please let me know if you would
like another backtrace of just the vanilla odbc without pdo using the
latest snapshot. I also have odbc trace files if needed.

#0  0x in ?? ()
#1  0xb6f66f05 in extract_sql_error (henv=0x0, hdbc=0x8434a78,
hstmt=0x0,
connection=0x8431480, head=0x84319f0, return_code=1) at
__info.c:4365
#2  0xb6f67976 in function_return_ex (level=2, handle=0x8431480,
ret_code=1,
save_to_diag=138613888) at __info.c:4998
#3  0xb6f3ef17 in SQLDriverConnect (hdbc=0x8431480, hwnd=0x0,
conn_str_in=0x8436bcc DSN=CUSTOMER;UID=tsi,
len_conn_str_in=-27102,
conn_str_out=0xbfff95e0
DSN=CUSTOMER;DBQ=.;HOST=192.168.1.102;UID=tsi;SERVER=NotTheServer,
conn_str_out_max=1023, ptr_conn_str_out=0xbfff95de,
driver_completion=0) at SQLDriverConnect.c:1463
#4  0xb6ef1716 in pdo_odbc_handle_factory (dbh=0x84273fc,
driver_options=0x0)
at /home/rberquist/PDO_ODBC-1.0RC2/odbc_driver.c:395
#5  0x080d1182 in zif_PDO_dbh_constructor (ht=1,
return_value=0x8435f3c,
return_value_ptr=0x0, this_ptr=0x84273bc, return_value_used=0)
at /home/rberquist/php5-200511072130/ext/pdo/pdo_dbh.c:374
#6  0x0826b846 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfff9ed0)
#7  0x0826bd92 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfff9ed0)
at zend_vm_execute.h:310
#8  0x0826b4f6 in execute (op_array=0x8431304) at zend_vm_execute.h:88
#9  0x08243a0c in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/rberquist/php5-200511072130/Zend/zend.c:1087
#10 0x082025b2 in php_execute_script (primary_file=0xbfffc2f0)
at /home/rberquist/php5-200511072130/main/main.c:1677
#11 0x082b17c6 in main (argc=2, argv=0xbfffc3d4)
at /home/rberquist/php5-200511072130/sapi/cli/php_cli.c:1041



[2005-11-07 23:06:00] [EMAIL PROTECTED]

Can you also try PDO_ODBC to see if it has a similar issue?



[2005-11-07 22:49:45] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/35144

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


#35298 [Bgs]: Access Violation Crash IIS 6

2005-11-20 Thread alacn dot uhahaa at gmail dot com
 ID:   35298
 User updated by:  alacn dot uhahaa at gmail dot com
 Reported By:  alacn dot uhahaa at gmail dot com
 Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Windows 2003
 PHP Version:  4.4.1
 New Comment:

the problem is at zend_execute_API.c

the access violation happens when it free the library before
timeout_thread_proc() finish,

at zend_shutdown_timeout_thread()
after PostThreadMessage it should wait some time to the
timeout_thread_proc() finish.

if it dont wait, the timeout_thread_proc() will walk in NULL bytes
because the code was released by the IIS


Previous Comments:


[2005-11-19 22:24:48] [EMAIL PROTECTED]

We are aware of PHP's problems with stability under IIS and are working

to rectify the problem. Unfortunatly your bug report does not contain
any
extra useful information and we already have enough bug reports open
about
this issue. If you can provide more detailed information such as a 
reproducable crash or a backtrace please do so and reopen this bug. 
Otherwise please keep trying new releases as we are working to resolve 
the problems on this platform
 
Thanks for your interest in PHP.





[2005-11-19 22:19:18] alacn dot uhahaa at gmail dot com

Description:

while recycling iis6 worker process when an user is uploading a file,
php crash with access violation zend timeout window: w3wp - read error
at address 0x019052a5

Reproduce code:
---
at php.ini
post_max_size = 1032M
upload_max_filesize = 1024M

while an user is uploading a file (post, upload form) (use a big file,
so it wont end before we finish), open iis mmc, go to application
pools, select the php pool (DefaultAppPool if you didnt change it),
right click on it and recycle

im using Windows 2003, IIS6, php 4.4.1 isapi

Expected result:

it should recycle without crash

Actual result:
--
php crash with access violation
zend timeout window: w3wp
read error at address 0x019052a5






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


#35298 [Bgs-Opn]: Access Violation Crash IIS 6

2005-11-20 Thread alacn dot uhahaa at gmail dot com
 ID:   35298
 User updated by:  alacn dot uhahaa at gmail dot com
 Reported By:  alacn dot uhahaa at gmail dot com
-Status:   Bogus
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows 2003
 PHP Version:  4.4.1
 New Comment:

i think that it could be fixed with WaitForSingleObject, making it wait
a bit of time to the timeout thread end.


Previous Comments:


[2005-11-20 19:40:01] alacn dot uhahaa at gmail dot com

the problem is at zend_execute_API.c

the access violation happens when it free the library before
timeout_thread_proc() finish,

at zend_shutdown_timeout_thread()
after PostThreadMessage it should wait some time to the
timeout_thread_proc() finish.

if it dont wait, the timeout_thread_proc() will walk in NULL bytes
because the code was released by the IIS



[2005-11-19 22:24:48] [EMAIL PROTECTED]

We are aware of PHP's problems with stability under IIS and are working

to rectify the problem. Unfortunatly your bug report does not contain
any
extra useful information and we already have enough bug reports open
about
this issue. If you can provide more detailed information such as a 
reproducable crash or a backtrace please do so and reopen this bug. 
Otherwise please keep trying new releases as we are working to resolve 
the problems on this platform
 
Thanks for your interest in PHP.





[2005-11-19 22:19:18] alacn dot uhahaa at gmail dot com

Description:

while recycling iis6 worker process when an user is uploading a file,
php crash with access violation zend timeout window: w3wp - read error
at address 0x019052a5

Reproduce code:
---
at php.ini
post_max_size = 1032M
upload_max_filesize = 1024M

while an user is uploading a file (post, upload form) (use a big file,
so it wont end before we finish), open iis mmc, go to application
pools, select the php pool (DefaultAppPool if you didnt change it),
right click on it and recycle

im using Windows 2003, IIS6, php 4.4.1 isapi

Expected result:

it should recycle without crash

Actual result:
--
php crash with access violation
zend timeout window: w3wp
read error at address 0x019052a5






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


#35298 [Opn]: Access Violation Crash IIS 6

2005-11-20 Thread alacn dot uhahaa at gmail dot com
 ID:   35298
 User updated by:  alacn dot uhahaa at gmail dot com
 Reported By:  alacn dot uhahaa at gmail dot com
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows 2003
 PHP Version:  4.4.1
 New Comment:

yah, i think its fixed now,

at zend_execute_API.c

[...]

static WNDCLASS wc;
static HWND timeout_window;
static HANDLE timeout_thread_event;
static DWORD timeout_thread_id;
static int timeout_thread_initialized=0;

static HANDLE timeout_thread_finish_event; //added

[...]

static unsigned __stdcall timeout_thread_proc(void *pArgs)
{
[...]
DestroyWindow(timeout_window);
UnregisterClass(wc.lpszClassName, NULL);

SetEvent(timeout_thread_finish_event); //added

return 0;
}


void zend_init_timeout_thread()
{
timeout_thread_event = CreateEvent(NULL, FALSE, FALSE, NULL);

timeout_thread_finish_event = CreateEvent(0, 0, 0, 0); //added

_beginthreadex(NULL, 0, timeout_thread_proc, NULL, 0,
timeout_thread_id);
WaitForSingleObject(timeout_thread_event, INFINITE);
}


void zend_shutdown_timeout_thread()
{
if (!timeout_thread_initialized) {
  return;
}
PostThreadMessage(timeout_thread_id, WM_QUIT, 0, 0);

WaitForSingleObject(timeout_thread_finish_event, 3); //added
}


Previous Comments:


[2005-11-20 19:45:39] alacn dot uhahaa at gmail dot com

i think that it could be fixed with WaitForSingleObject, making it wait
a bit of time to the timeout thread end.



[2005-11-20 19:40:01] alacn dot uhahaa at gmail dot com

the problem is at zend_execute_API.c

the access violation happens when it free the library before
timeout_thread_proc() finish,

at zend_shutdown_timeout_thread()
after PostThreadMessage it should wait some time to the
timeout_thread_proc() finish.

if it dont wait, the timeout_thread_proc() will walk in NULL bytes
because the code was released by the IIS



[2005-11-19 22:24:48] [EMAIL PROTECTED]

We are aware of PHP's problems with stability under IIS and are working

to rectify the problem. Unfortunatly your bug report does not contain
any
extra useful information and we already have enough bug reports open
about
this issue. If you can provide more detailed information such as a 
reproducable crash or a backtrace please do so and reopen this bug. 
Otherwise please keep trying new releases as we are working to resolve 
the problems on this platform
 
Thanks for your interest in PHP.





[2005-11-19 22:19:18] alacn dot uhahaa at gmail dot com

Description:

while recycling iis6 worker process when an user is uploading a file,
php crash with access violation zend timeout window: w3wp - read error
at address 0x019052a5

Reproduce code:
---
at php.ini
post_max_size = 1032M
upload_max_filesize = 1024M

while an user is uploading a file (post, upload form) (use a big file,
so it wont end before we finish), open iis mmc, go to application
pools, select the php pool (DefaultAppPool if you didnt change it),
right click on it and recycle

im using Windows 2003, IIS6, php 4.4.1 isapi

Expected result:

it should recycle without crash

Actual result:
--
php crash with access violation
zend timeout window: w3wp
read error at address 0x019052a5






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


#35303 [Opn-Csd]: PDO prepare crashes

2005-11-20 Thread iliaa
 ID:   35303
 Updated by:   [EMAIL PROTECTED]
 Reported By:  stochnagara at hotmail dot com
-Status:   Open
+Status:   Closed
 Bug Type: PDO related
 Operating System: windows xp
 PHP Version:  5CVS-2005-11-20 (snap)
 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:


[2005-11-20 12:50:02] stochnagara at hotmail dot com

Description:

PDO still crashes Apache when using child classes.
See bug #35118 - it's almost the same.

Reproduce code:
---
?
class MAppPDOStatement extends PDOStatement {
}

class MAppPDO extends PDO {
function prepare ($string, array $options = array()) {
$options [PDO::ATTR_STATEMENT_CLASS] = 'MAppPDOStatement';
parent::prepare ($string, $options);
}
}

$a = new MAppPDO(sqlite::memory:);
$a-prepare(insert into test (b) values (?));


Expected result:

no errors

Actual result:
--
Apache crashes.





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


#35143 [Asn-Csd]: gettimeofday() ignores current time zone

2005-11-20 Thread derick
 ID:   35143
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tomas_matousek at hotmail dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Date/time related
 Operating System: WinXP
 PHP Version:  5.1.0RC4
 Assigned To:  derick
 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.

Fixed for 5.1.0 and 6.0.0


Previous Comments:


[2005-11-07 21:38:59] [EMAIL PROTECTED]

Assigned to the master of timezones.



[2005-11-07 20:38:19] tomas_matousek at hotmail dot com

Description:

I assume gettimeofday() should return minuteswest and dsttime
according to the current time zone set by date_default_timezone_set,
right?
It doesn't work. It returns the system time zone instead.

Reproduce code:
---
date_default_timezone_set(UTC);

var_dump(date_default_timezone_get());

var_dump(gettimeofday());

Expected result:

string(3) UTC
array(4) {
  [sec]=
  int(1131392140)
  [usec]=
  int(31336)
  [minuteswest]=
  int(0)
  [dsttime]=
  int(0)
}



Actual result:
--
string(3) UTC
array(4) {
  [sec]=
  int(1131392140)
  [usec]=
  int(31336)
  [minuteswest]=
  int(-60)
  [dsttime]=
  int(1)
}







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


#35298 [Opn-Fbk]: Access Violation Crash IIS 6

2005-11-20 Thread sniper
 ID:   35298
 Updated by:   [EMAIL PROTECTED]
 Reported By:  alacn dot uhahaa at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Windows 2003
 PHP Version:  4.4.1
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2005-11-20 20:08:24] alacn dot uhahaa at gmail dot com

yah, i think its fixed now,

at zend_execute_API.c

[...]

static WNDCLASS wc;
static HWND timeout_window;
static HANDLE timeout_thread_event;
static DWORD timeout_thread_id;
static int timeout_thread_initialized=0;

static HANDLE timeout_thread_finish_event; //added

[...]

static unsigned __stdcall timeout_thread_proc(void *pArgs)
{
[...]
DestroyWindow(timeout_window);
UnregisterClass(wc.lpszClassName, NULL);

SetEvent(timeout_thread_finish_event); //added

return 0;
}


void zend_init_timeout_thread()
{
timeout_thread_event = CreateEvent(NULL, FALSE, FALSE, NULL);

timeout_thread_finish_event = CreateEvent(0, 0, 0, 0); //added

_beginthreadex(NULL, 0, timeout_thread_proc, NULL, 0,
timeout_thread_id);
WaitForSingleObject(timeout_thread_event, INFINITE);
}


void zend_shutdown_timeout_thread()
{
if (!timeout_thread_initialized) {
  return;
}
PostThreadMessage(timeout_thread_id, WM_QUIT, 0, 0);

WaitForSingleObject(timeout_thread_finish_event, 3); //added
}



[2005-11-20 19:45:39] alacn dot uhahaa at gmail dot com

i think that it could be fixed with WaitForSingleObject, making it wait
a bit of time to the timeout thread end.



[2005-11-20 19:40:01] alacn dot uhahaa at gmail dot com

the problem is at zend_execute_API.c

the access violation happens when it free the library before
timeout_thread_proc() finish,

at zend_shutdown_timeout_thread()
after PostThreadMessage it should wait some time to the
timeout_thread_proc() finish.

if it dont wait, the timeout_thread_proc() will walk in NULL bytes
because the code was released by the IIS



[2005-11-19 22:24:48] [EMAIL PROTECTED]

We are aware of PHP's problems with stability under IIS and are working

to rectify the problem. Unfortunatly your bug report does not contain
any
extra useful information and we already have enough bug reports open
about
this issue. If you can provide more detailed information such as a 
reproducable crash or a backtrace please do so and reopen this bug. 
Otherwise please keep trying new releases as we are working to resolve 
the problems on this platform
 
Thanks for your interest in PHP.





[2005-11-19 22:19:18] alacn dot uhahaa at gmail dot com

Description:

while recycling iis6 worker process when an user is uploading a file,
php crash with access violation zend timeout window: w3wp - read error
at address 0x019052a5

Reproduce code:
---
at php.ini
post_max_size = 1032M
upload_max_filesize = 1024M

while an user is uploading a file (post, upload form) (use a big file,
so it wont end before we finish), open iis mmc, go to application
pools, select the php pool (DefaultAppPool if you didnt change it),
right click on it and recycle

im using Windows 2003, IIS6, php 4.4.1 isapi

Expected result:

it should recycle without crash

Actual result:
--
php crash with access violation
zend timeout window: w3wp
read error at address 0x019052a5






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


#35304 [Fbk-Opn]: PHP always segfaults with --without-sqlite

2005-11-20 Thread matteo at beccati dot com
 ID:   35304
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Debian GNU/Linux testing/etch
 PHP Version:  5.1.0RC6
 New Comment:

The snap doesn't segfault at start, but does on make test:

(gdb) set args -d 'open_basedir=' -d 'safe_mode=0' -d
'output_buffering=0' -d 'memory_limit=-1'
/root/compile/php5-200511201930/run-tests.php
(gdb) run
Starting program: /root/compile/php5-200511201930/sapi/cli/php -d
'open_basedir=' -d 'safe_mode=0' -d 'output_buffering=0' -d
'memory_limit=-1' /root/compile/php5-200511201930/run-tests.php

Program received signal SIGSEGV, Segmentation fault.
0x08200adf in _zend_hash_add_or_update (ht=0x8322160,
arKey=0x827ab2c sqlite, nKeyLength=6, pData=0xb960,
nDataSize=4,
pDest=0x0, flag=2) at
/root/compile/php5-200511201930/Zend/zend_hash.c:213
213 p = ht-arBuckets[nIndex];
(gdb) bt full
#0  0x08200adf in _zend_hash_add_or_update (ht=0x8322160,
arKey=0x827ab2c sqlite, nKeyLength=6, pData=0xb960,
nDataSize=4,
pDest=0x0, flag=2) at
/root/compile/php5-200511201930/Zend/zend_hash.c:213
h = 475667703
nIndex = 0
p = (Bucket *) 0x1
#1  0x080ce8c4 in php_pdo_register_driver (driver=0x8312438)
at /root/compile/php5-200511201930/ext/pdo/pdo.c:170
No locals.
#2  0x080d8fc7 in zm_startup_pdo_sqlite (type=1, module_number=8)
at /root/compile/php5-200511201930/ext/pdo_sqlite/pdo_sqlite.c:80
No locals.
#3  0x081fcd27 in zend_startup_module_ex (module=0x835cc30)
at /root/compile/php5-200511201930/Zend/zend_API.c:1320
name_len = 9
lcname = 0x832c084 splsubject
#4  0x08202047 in zend_hash_apply (ht=0x8327780,
apply_func=0x81fcbe8 zend_startup_module_ex)
at /root/compile/php5-200511201930/Zend/zend_hash.c:664
p = (Bucket *) 0x835cbf8
#5  0x081fceb6 in zend_startup_modules ()
at /root/compile/php5-200511201930/Zend/zend_API.c:1367
No locals.
#6  0x081ba3c2 in php_module_startup (sf=0x8320620,
additional_modules=0x0,
num_additional_modules=0)
at /root/compile/php5-200511201930/main/main.c:1533
zuf = {error_function = 0x81b89f6 php_error_cb,
  printf_function = 0x81b8351 php_printf,
  write_function = 0x81b9e34 php_body_write_wrapper,
  fopen_function = 0x81b907c php_fopen_wrapper_for_zend,
  message_handler = 0x81b91a9 php_message_handler_for_zend,
  block_interruptions = 0, unblock_interruptions = 0,
  get_configuration_directive = 0x81b9159
php_get_configuration_directive_for_zend, ticks_function = 0x81c61db
php_run_ticks,
  on_timeout = 0x81b931b php_on_timeout,
  stream_open_function = 0x81b90cc php_stream_open_for_zend,
  vspprintf_function = 0x81bd903 vspprintf,
  getenv_function = 0x81c135c sapi_getenv}
zuv = {import_use_extension = 0x8296dc8 .php,
  import_use_extension_length = 137475840, html_errors = 1 '\001'}
module_number = 0
php_os = 0x8296d4f Linux
#7  0x082674dd in main (argc=10, argv=0xbca4)
at /root/compile/php5-200511201930/sapi/cli/php_cli.c:655
exit_status = 0
c = -1
file_handle = {type = 0 '\0',
  filename = 0x1 Address 0x1 out of bounds, opened_path = 0xbbdc
,
  handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, reader = 0,
  closer = 0xbc50, fteller = 0x400167f8, interactive =
134602782}},
  free_filename = 142 '\216'}
behavior = 1
orig_optind = 1
orig_optarg = 0x0
arg_free = 0x0
arg_excp = (char **) 0xbb9c
script_file = 0x0
global_vars = {head = 0xbc14, tail = 0xbc28,
  count = 1073772579, size = 3221224468, dtor = 0x40016950,
  persistent = 8 '\b', traverse_ptr = 0x400ae6a8}
interactive = 0
module_started = 0
lineno = 0
exec_direct = 0x0
exec_run = 0x0
exec_begin = 0x0
exec_end = 0x0
param_error = 0x0
hide_argv = 0


Previous Comments:


[2005-11-20 18:55:45] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-11-20 12:57:15] matteo at beccati dot com

Description:

I was starting to test PHP5.1.0RC6.

make install was exiting with a segmentation fault, because running php
from command line always exit with a segfault. I tracked down that the
problem depends by the fact I used --without-sqlite in the configure
options.

Using the php5-200511200930 snapshot also leads to the same result.

Configure line used for the backtrace:
CFLAGS=-O0 ./configure --disable-cgi --without-sqlite


Actual result:
--
(gdb) run
Starting program: /root/compile/php5-200511200930/sapi/cli/php

Program received 

#28461 [Sus]: segmentation fault when using backreferences on a long string

2005-11-20 Thread xanthor at xanthor dot tk
 ID:   28461
 User updated by:  xanthor at xanthor dot tk
 Reported By:  xanthor at xanthor dot tk
 Status:   Suspended
 Bug Type: PCRE related
 Operating System: *
 PHP Version:  4.4.1
 Assigned To:  andrei
 New Comment:

 It's not really useful since it doesn't exist. Try again..
You should have been a bit faster to look at it, while it was online.

I re-paste it here :

#0  0x080ad99c in match (eptr=0x8358fe4 ' ' repeats 200 times...,
ecode=0x834faf5 I, offset_top=6, md=0xbffaa264, ims=0, 
eptrb=0x0, flags=2) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:357
357 {
(gdb) bt
#0  0x080ad99c in match (eptr=0x8358fe4 ' ' repeats 200 times...,
ecode=0x834faf5 I, offset_top=6, md=0xbffaa264, ims=0, 
eptrb=0x0, flags=2) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:357
#1  0x080adb9b in match (eptr=Variable eptr is not available.
) at /home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:747
#2  0x080b1222 in match (eptr=Variable eptr is not available.
) at /home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:589
#3  0x080b2327 in match (eptr=Variable eptr is not available.
) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:1123
#4  0x080b1222 in match (eptr=Variable eptr is not available.
) at /home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:589
#5  0x080b2327 in match (eptr=Variable eptr is not available.
) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:1123
#6  0x080b1222 in match (eptr=Variable eptr is not available.
) at /home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:589
#7  0x080b2327 in match (eptr=Variable eptr is not available.
) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:1123
#8  0x080b1222 in match (eptr=Variable eptr is not available.
) at /home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:589
#9  0x080b2327 in match (eptr=Variable eptr is not available.
) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:1123
#10 0x080b1222 in match (eptr=Variable eptr is not available.
) at /home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:589
#11 0x080b2327 in match (eptr=Variable eptr is not available.
) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:1123
#12 0x080b1222 in match (eptr=Variable eptr is not available.
) at /home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:589
#13 0x080b2327 in match (eptr=Variable eptr is not available.
) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:1123

And same thing again and again...


Previous Comments:


[2005-11-20 19:34:05] [EMAIL PROTECTED]

Andrei says this is not possible to fix since we can't tell what the
limit for recursion should be.




[2005-11-20 19:22:55] [EMAIL PROTECTED]

It's not really useful since it doesn't exist. Try again..




[2005-11-19 17:07:20] xanthor at xanthor dot tk

Here is the bactrace : http://rafb.net/paste/results/221Dcs52.html

I don't know if this will be usefull :¬/



[2005-11-16 10:21:24] [EMAIL PROTECTED]

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

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





[2005-11-16 04:48:51] xanthor at xanthor dot tk

Still crashes with 4.4.1, increasing the length of the string.



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

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


#35292 [Fbk-Opn]: Can't connect to local MySQL server through socket

2005-11-20 Thread dgrimes at scvl dot com
 ID:   35292
 User updated by:  dgrimes at scvl dot com
 Reported By:  dgrimes at scvl dot com
-Status:   Feedback
+Status:   Open
 Bug Type: MySQL related
 Operating System: SCO OpenServer
 PHP Version:  4.4.1
 New Comment:

I tried PHP5 but could not get a clean compile out of it yet. First I
was missing two libraries, libxml2 and libxslt and then SQLLite has
problems then PATH_MAX is not defined. I finally worked past those and
now I get errors installing to apache. There are some undefined
symbols.

Even if I did have a clean compile today, I've already completed
testing PHP4 with my current project and with our existing systems. I
just don't have time to implement PHP5 without going through all of the
documentation and testing again, which is a lot of work. I am planning
to deploy to the chain the 2nd week in January. With the holiday season
just around the corner, my work load will not permit me to alter my
design to include PHP5.

If you think that it will help troubleshoot the problem, I'll persue
PHP5 only to the extent that it will help us resolve this issue.

Here is the error when I execute make install for PHP5:

  page: php-config.1
Installing PEAR environment:  /usr/local/lib/php/
dynamic linker: /d/cdev/php5-200511201930/sapi/cli/php: relocation
error: symbol
 not found: xmlStructuredError
make[1]: *** [install-pear-installer] Killed
make: *** [install-pear] Error 2


Thanks,
Dean


Previous Comments:


[2005-11-20 18:55:02] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-11-20 13:34:36] dgrimes at scvl dot com

Yes. The path to the socket is correct. The only thing I do to make it
work is refresh the page two or three times and it will eventually
connect. Another thing, if I use PHP 4.2.3 or less, I don't have the
problem at all.

I noticed that beginning in PHP 4.3.0 many changes were made in the
area of sockets. What is the large negative number that is returned in
the message (-2146870980)? What I've seen in the past when the path is
incorrect is this:

2002 - Can't connect to local MySQL server through socket
'/d/mysql/var/mysqlx.sock' (2)

Notice that (2) is a positive integer and not negative. All I did was
change mysql.sock to mysqlx.sock in the php.ini file. What's also
interesting is that I received the other error (-2146870980) two times
before getting the correct error (2).

MySQL isn't logging anything so as far as it's concerned, nothing has
made an attempt to connect. I thought it might be a timeout so I tried
setting some of the timeout values but it didn't help. Is it possible
that PHP isn't waiting long enough for MySQL to respond? Is the error
saying that it can't find the socket file or that it simply can't
connect to the socket file?

If you'd like, I can place some debug code in the connect function to
see what is happening or I can compile with debug to watch it execute
but I'll need instructions on where to place break points and what
symbols to look at.

Dean



[2005-11-20 08:52:09] [EMAIL PROTECTED]

Are you sure that path to the socket is correct?




[2005-11-19 14:58:53] dgrimes at scvl dot com

Still have the same problem with the latest snapshot.

Dean



[2005-11-19 14:25:17] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/35292

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


#35292 [Opn-Fbk]: Can't connect to local MySQL server through socket

2005-11-20 Thread sniper
 ID:   35292
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dgrimes at scvl dot com
-Status:   Open
+Status:   Feedback
 Bug Type: MySQL related
 Operating System: SCO OpenServer
 PHP Version:  4.4.1
 New Comment:

I did not ask you to start using PHP 5, I asked to TEST it.
And use --disable-all to get as clean build as possible.

Anyway, this all seems some problem in your system alone. Nobody else
has reported any problem like this before.



Previous Comments:


[2005-11-20 23:41:45] dgrimes at scvl dot com

I tried PHP5 but could not get a clean compile out of it yet. First I
was missing two libraries, libxml2 and libxslt and then SQLLite has
problems then PATH_MAX is not defined. I finally worked past those and
now I get errors installing to apache. There are some undefined
symbols.

Even if I did have a clean compile today, I've already completed
testing PHP4 with my current project and with our existing systems. I
just don't have time to implement PHP5 without going through all of the
documentation and testing again, which is a lot of work. I am planning
to deploy to the chain the 2nd week in January. With the holiday season
just around the corner, my work load will not permit me to alter my
design to include PHP5.

If you think that it will help troubleshoot the problem, I'll persue
PHP5 only to the extent that it will help us resolve this issue.

Here is the error when I execute make install for PHP5:

  page: php-config.1
Installing PEAR environment:  /usr/local/lib/php/
dynamic linker: /d/cdev/php5-200511201930/sapi/cli/php: relocation
error: symbol
 not found: xmlStructuredError
make[1]: *** [install-pear-installer] Killed
make: *** [install-pear] Error 2


Thanks,
Dean



[2005-11-20 18:55:02] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-11-20 13:34:36] dgrimes at scvl dot com

Yes. The path to the socket is correct. The only thing I do to make it
work is refresh the page two or three times and it will eventually
connect. Another thing, if I use PHP 4.2.3 or less, I don't have the
problem at all.

I noticed that beginning in PHP 4.3.0 many changes were made in the
area of sockets. What is the large negative number that is returned in
the message (-2146870980)? What I've seen in the past when the path is
incorrect is this:

2002 - Can't connect to local MySQL server through socket
'/d/mysql/var/mysqlx.sock' (2)

Notice that (2) is a positive integer and not negative. All I did was
change mysql.sock to mysqlx.sock in the php.ini file. What's also
interesting is that I received the other error (-2146870980) two times
before getting the correct error (2).

MySQL isn't logging anything so as far as it's concerned, nothing has
made an attempt to connect. I thought it might be a timeout so I tried
setting some of the timeout values but it didn't help. Is it possible
that PHP isn't waiting long enough for MySQL to respond? Is the error
saying that it can't find the socket file or that it simply can't
connect to the socket file?

If you'd like, I can place some debug code in the connect function to
see what is happening or I can compile with debug to watch it execute
but I'll need instructions on where to place break points and what
symbols to look at.

Dean



[2005-11-20 08:52:09] [EMAIL PROTECTED]

Are you sure that path to the socket is correct?




[2005-11-19 14:58:53] dgrimes at scvl dot com

Still have the same problem with the latest snapshot.

Dean



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

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


#35292 [Fbk-Opn]: Can't connect to local MySQL server through socket

2005-11-20 Thread dgrimes at scvl dot com
 ID:   35292
 User updated by:  dgrimes at scvl dot com
 Reported By:  dgrimes at scvl dot com
-Status:   Feedback
+Status:   Open
 Bug Type: MySQL related
 Operating System: SCO OpenServer
 PHP Version:  4.4.1
 New Comment:

I agreed to test it. Maybe nobody else has reported this but I still
need to figure out what the problem is and get it fixed. I'm not trying
to be obstinate. I appreciate all of the help I have received from the
folks at PHP. I was just merely pointing out that even if PHP5 works, I
won't be able to use it.

Version 4.2.x doesn't exhibit the problem. Is there a way to review the
socket related changes in 4.3.0? Something that changed on that
transition is causing this problem on both 5.0.4 and 5.0.6 OpenServer
OS's. I'm willing to try anything you guy's suggest.

I tried building with --disable-all and received the following error on
make:

.lo Zend/zend_reflection_api.lo Zend/zend_execute.lo
sapi/cgi/cgi_main.lo sapi/c
gi/getopt.lo main/internal_functions.lo -lm -lsocket  -o sapi/cgi/php
Undefined   first referenced
 symbol in file
spl_ce_Countableext/standard/array.o
php_pcre_replacemain/SAPI.o
php_ob_gzhandler_check  main/output.o
uncompress  ext/standard/image.o
sapi/cgi/php: fatal error: Symbol referencing errors. No output written
to sapi/
cgi/php
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php] Error 1

Thanks,
Dean


Previous Comments:


[2005-11-21 00:05:39] [EMAIL PROTECTED]

I did not ask you to start using PHP 5, I asked to TEST it.
And use --disable-all to get as clean build as possible.

Anyway, this all seems some problem in your system alone. Nobody else
has reported any problem like this before.




[2005-11-20 23:41:45] dgrimes at scvl dot com

I tried PHP5 but could not get a clean compile out of it yet. First I
was missing two libraries, libxml2 and libxslt and then SQLLite has
problems then PATH_MAX is not defined. I finally worked past those and
now I get errors installing to apache. There are some undefined
symbols.

Even if I did have a clean compile today, I've already completed
testing PHP4 with my current project and with our existing systems. I
just don't have time to implement PHP5 without going through all of the
documentation and testing again, which is a lot of work. I am planning
to deploy to the chain the 2nd week in January. With the holiday season
just around the corner, my work load will not permit me to alter my
design to include PHP5.

If you think that it will help troubleshoot the problem, I'll persue
PHP5 only to the extent that it will help us resolve this issue.

Here is the error when I execute make install for PHP5:

  page: php-config.1
Installing PEAR environment:  /usr/local/lib/php/
dynamic linker: /d/cdev/php5-200511201930/sapi/cli/php: relocation
error: symbol
 not found: xmlStructuredError
make[1]: *** [install-pear-installer] Killed
make: *** [install-pear] Error 2


Thanks,
Dean



[2005-11-20 18:55:02] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-11-20 13:34:36] dgrimes at scvl dot com

Yes. The path to the socket is correct. The only thing I do to make it
work is refresh the page two or three times and it will eventually
connect. Another thing, if I use PHP 4.2.3 or less, I don't have the
problem at all.

I noticed that beginning in PHP 4.3.0 many changes were made in the
area of sockets. What is the large negative number that is returned in
the message (-2146870980)? What I've seen in the past when the path is
incorrect is this:

2002 - Can't connect to local MySQL server through socket
'/d/mysql/var/mysqlx.sock' (2)

Notice that (2) is a positive integer and not negative. All I did was
change mysql.sock to mysqlx.sock in the php.ini file. What's also
interesting is that I received the other error (-2146870980) two times
before getting the correct error (2).

MySQL isn't logging anything so as far as it's concerned, nothing has
made an attempt to connect. I thought it might be a timeout so I tried
setting some of the timeout values but it didn't help. Is it possible
that PHP isn't waiting long enough for MySQL to respond? Is the error
saying that it can't find the socket file or that it simply can't
connect to the socket file?

If you'd like, I can place some debug code in the connect function to
see what is happening or I can compile with debug to watch it execute
but I'll need instructions on where to place break points and what

#35307 [NEW]: By the unexpected header can be injected at the mb_send_mail

2005-11-20 Thread s dot masugata at digicom dot dnp dot co dot jp
From: s dot masugata at digicom dot dnp dot co dot jp
Operating system: Solaris8
PHP version:  4.4.2RC1
PHP Bug Type: mbstring related
Bug description:  By the unexpected header can be injected at the mb_send_mail

Description:

The unexpected header can be injected at the mb_send_mail function.
The mail function is doing the check of the unexpected  control code to
To and Subject.
However, the mb_send_mail function isn't doing a check.


By the feature of the function overload, mail function is exchanged for
the mb_send_mail function.
Therefore, it thinks that the check like the mail function is necessary
about the mb_send_mail function, too.

It is To that seems to need a check.
The report is PHP4 but needs the same correction about PHP5.


--- php-4.4.2RC1/ext/mbstring/mbstring.c,orig   2005-11-05
10:14:05.0 +0900
+++ php-4.4.2RC1/ext/mbstring/mbstring.c2005-11-21 09:42:42.0
+0900
@@ -3460,6 +3460,22 @@
  *  Sends an email message with MIME scheme
  */
 #if HAVE_SENDMAIL
+#define SKIP_LONG_HEADER_SEP_MBSTRING(str, pos)
\
+   if (str[pos] == '\r'  str[pos + 1] == '\n'  (str[pos + 2] == ' ' ||
str[pos + 2] == '\t')) {\
+   pos += 3;   
\
+   while (str[pos] == ' ' || str[pos] == '\t') {   
\
+   pos++;  
\
+   }   
\
+   continue;   
\
+   }   
\
+   else if (str[pos] == '\n'  (str[pos + 1] == ' ' || str[pos + 1] ==
'\t')) {\
+   pos += 2;   
\
+   while (str[pos] == ' ' || str[pos] == '\t') {   
\
+   pos++;  
\
+   }   
\
+   continue;   
\
+   }   
\
+
 PHP_FUNCTION(mb_send_mail)
 {
int argc, n;
@@ -3475,6 +3491,8 @@
mbfl_memory_device device;  /* automatic allocateable buffer for
additional header */
const mbfl_language *lang;
int err = 0;
+   char *to_r;
+   int to_len, i;
 
/* initialize */
mbfl_memory_device_init(device, 0, 0);
@@ -3501,6 +3519,29 @@
convert_to_string_ex(argv[0]);
if (Z_STRVAL_PP(argv[0])) {
to = Z_STRVAL_PP(argv[0]);
+   to_len = Z_STRLEN_PP(argv[0]);
+   if (to_len  0) {
+   to_r = estrndup(to, to_len);
+   for (; to_len; to_len--) {
+   if (!isspace((unsigned char) to_r[to_len - 1])) 
{
+   break;
+   }
+   to_r[to_len - 1] = '\0';
+   }
+   for (i = 0; to_r[i]; i++) {
+   if (iscntrl((unsigned char) to_r[i])) {
+   /* According to RFC 822, 
section 3.1.1 long headers may be
separated into
+* parts using CRLF followed at least 
one linear-white-space
character ('\t' or ' ').
+* To prevent these separators from 
being replaced with a space, we
use the
+* SKIP_LONG_HEADER_SEP_MBSTRING to 
skip over them.
+*/
+   SKIP_LONG_HEADER_SEP_MBSTRING(to_r, i);
+   to_r[i] = ' ';
+   }
+   }
+   } else {
+   to_r = to;
+   }
} else {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Missing To: 
field);
err = 1;
@@ -3599,12 +3640,15 @@
extra_cmd = php_escape_shell_cmd(extra_cmd);
} 
 
-   if (!err  php_mail(to, subject, message, headers, extra_cmd
TSRMLS_CC)) {
+   if (!err  php_mail(to_r, subject, message, headers, extra_cmd
TSRMLS_CC)) {
RETVAL_TRUE;

#35205 [Asn]: oci_connect is not closing opened connections after script execution

2005-11-20 Thread robertg2 at hope dot ac dot uk
 ID:   35205
 User updated by:  robertg2 at hope dot ac dot uk
 Reported By:  robertg2 at hope dot ac dot uk
 Status:   Assigned
 Bug Type: OCI8 related
 Operating System: Solaris 8
 PHP Version:  5.0.5
 Assigned To:  tony2001
 New Comment:

Okay, for real this time:

Using the 32-bit instantclient 10 doesn't seem to have an effect on the
behaviour in question.

?
oci_connect('user', 'pw', '//HOST/DBNAME');
?

After browsing to a script such as this via the web, the connection to
the database remains.


Previous Comments:


[2005-11-20 13:18:40] robertg2 at hope dot ac dot uk

oh and... as for the comment I made at 1:55am... that was a mistake.  I
hadn't taken the oci_close statement out of the code.

Sorry :(



[2005-11-20 13:15:55] robertg2 at hope dot ac dot uk

Tony,

Unfortunately it doesn't look like it picked up the instant client in
compilation as the new style \\HOSTNAME\DBNAME referencing feature
doesn't work.  So still it's unclear whether compiling with the instant
client would reproduce the problem.

Will try again tonight.



[2005-11-20 01:55:28] robertg2 at hope dot ac dot uk

Sorry for the delay in testing.

The connection is closed off correctly when compiled against
InstantClient 10.



[2005-11-15 19:09:31] [EMAIL PROTECTED]

... and it works fine even if the MPM if worker, so this is not a
multithreading related issue.
Please try to build PHP with Oracle Instant Client and see if it
helps.




[2005-11-15 14:47:40] [EMAIL PROTECTED]

Just for the record: I can't reproduce on Linux and on Solaris with
Apache2/prefork.




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

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


#35288 [Opn]: make test fails on FreeBSD

2005-11-20 Thread webmaster at negeta dot com
 ID:   35288
 User updated by:  webmaster at negeta dot com
 Reported By:  webmaster at negeta dot com
 Status:   Open
 Bug Type: ICONV related
 Operating System: FreeBSD 5.4
 PHP Version:  5.1.0RC6
 New Comment:

 0. C function iconv is exist, and libiconv is not.
It's not correct and my mistake.
Both functions are available in my system.

Please check libiconv before checking iconv.
Then HAVE_ICONV and HAVE_LIBICONV are defined by configure,
and the problem is not reproduce in my system.

Please commit this patch if it looks like good.
http://www.negeta.com/misc/acinclude.m4.patch


Previous Comments:


[2005-11-20 11:32:23] webmaster at negeta dot com

Only HAVE_ICONV is exist in my system.

Thank you for your patch, but it is not solve the problem.
This patch is not undef `iconv' when HAVE_LIBICONV is not defined.

As a test, I deleted first #ifdef HAVE_LIBICONV and #endif,
it force undef 'iconv', and problem was not reproduce.
But I can't estimate about side-effect on other system.



[2005-11-19 21:41:37] [EMAIL PROTECTED]

Also, is HAVE_BSD_ICONV defined on your system?



[2005-11-19 21:37:17] [EMAIL PROTECTED]

Try the following patch:
http://bb.prohost.org/patch/iconv.txt



[2005-11-19 17:55:52] webmaster at negeta dot com

I found how this problem occurs on my env.

0. C function iconv is exist, and libiconv is not.
1. configure detects #define HAVE_ICONV 1
  and HAVE_LIBICONV is not defined.
2. #define iconv libiconv in /usr/local/include/iconv.h line 80.
3. #undef iconv is not execute in ext/iconv/iconv.c line 55.
4. `libiconv' links to php_if_iconv in ext/iconv/iconv.c line 68. PHP
function libiconv is created.



[2005-11-19 14:28:02] [EMAIL PROTECTED]

Can't reproduce.
# ./sapi/cli/php -r 'iconv();'

Warning: iconv() expects exactly 3 parameters, 0 given in Command line
code on line 1
# uname -r
5.4-STABLE



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

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


#35249 [Csd]: Compile cannot link when libedit is enabled

2005-11-20 Thread php-david at tulloh dot id dot au
 ID:   35249
 User updated by:  php-david at tulloh dot id dot au
 Reported By:  php-david at tulloh dot id dot au
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: Debian Linux
 PHP Version:  5.1.0RC6
 Assigned To:  sniper
 New Comment:

works in 5.1 cvs, thankyou.


Previous Comments:


[2005-11-18 16:07:54] [EMAIL PROTECTED]

Fixed the other part of the problem.



[2005-11-18 09:48:09] [EMAIL PROTECTED]

Jani, did you really fix it?



[2005-11-18 04:03:56] php-david at tulloh dot id dot au

Fails in 5.1.0RC6
Fails in the 5.1 branch of CVS
Fails (in both) when the shared flag is removed.

The error is unchanged.



[2005-11-17 09:37:36] [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.





[2005-11-17 09:24:15] [EMAIL PROTECTED]

Fast fix: NEVER EVER compile anything as shared. :)




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

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


#35243 [Csd]: Crashes in php_mblen when compiled with thread-safety on Linux

2005-11-20 Thread shulmanb at il dot ibm dot com
 ID:   35243
 User updated by:  shulmanb at il dot ibm dot com
 Reported By:  shulmanb at il dot ibm dot com
 Status:   Closed
 Bug Type: *General Issues
 Operating System: Linux
 PHP Version:  5CVS-2005-11-19 (snap)
 New Comment:

Thanks for including the fix.

From what I've seen, it has been included in HEAD, and in 5.1.x.

Any chance of it being included in 5.0.x as well?


Previous Comments:


[2005-11-20 19:08:11] [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.





[2005-11-18 17:18:24] shulmanb at il dot ibm dot com

Done.

Can be found at: http://news.php.net/php.internals/20164



[2005-11-16 18:18:33] [EMAIL PROTECTED]

And if it's still a problem, provide the patch in unified diff format.



[2005-11-16 16:07:01] shulmanb at il dot ibm dot com

Description:

When running on Linux with --enable-maintainer-zts (and yes, I know
it's not wise...), crashes sometimes happen in
ext/standard/php_string.h when using the php_mblen macro.

This happens because in ext/standard/basic_functions.c, in the
basic_globals_ctor function, the value of mblen_state is not
initialized.

The basic_globals_ctor function should include the following lines as
part of the initialization:

#if defined(_REENTRANT)defined(HAVE_MBRLEN)defined(HAVE_MBSTATE_T)
memset(BG(mblen_state), 0, sizeof(BG(mblen_state)));
#endif

Unfortunately, I am unable to include code that demonstrate this, as
the crash strongly depends on the (random) value of mblen_state.






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