date:20020924


 ID:   19585
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Linux 2.4.2 (Redhat 6.2)
 PHP Version:  4.2.2
 New Comment:

Please try using this CVS snapshot:

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


Previous Comments:


[2002-09-24 20:14:30] [EMAIL PROTECTED]

Description 
--- 
In some cases (I can't reproduce it easily, seeing it 
maybe once every two days) PHP seems to be crashing 
apache.  I have two almost identical machines (production 
& development), and after switching the session handler 
from mm to files on the production machine the crashes 
_seem_ to have stopped there, but still happen on the 
development machine (which is still using mm). 
 
PHP Script 
--- 
Since I can't reproduce the crash on demand I'm not sure 
exactly where in the php script the crash is occuring. 
However the following line seems most likely, given the 
backtrace below, this is the first reference to session 
stuff in the script(s) that are crashing 
 
if (!session_is_registered("ngInfo")) 
session_register("ngInfo"); 
 
PHP Version/Modules 
--- 
(Using RPMS from http://rpms.arvin.dk/php, rebuilt againt 
pdflib 3.0.3 rather than pdflib 4.x).  phpa 1.3.2 
(http://php-accelerator.co.uk/) is also installed 
 
./configure' '--prefix=/usr' '--enable-pic' 
'--disable-rpath' '--with-layout=GNU' '--with-apxs' 
'--libdir=/usr/lib/php4' '--datadir=/usr/share/php' 
'--with-config-file-path=/etc' 
'--enable-inline-optimization' '--enable-magic-quotes' 
'--enable-track-vars' '--enable-memory-limit' 
'--enable-bcmath' '--with-iconv' '--with-pcre-regex=/usr' 
'--enable-sigchild' '--with-xml' '--with-expat-dir=/usr' 
'--with-openssl' '--enable-ftp=shared' 
'--enable-exif=shared' '--enable-sysvsem=shared' 
'--enable-sysvshm=shared' '--enable-shmop=shared' 
'--with-unixODBC=shared' '--with-mysql=shared,/usr' 
'--with-ldap=shared' '--with-pgsql=shared' 
'--with-gettext=shared' '--with-snmp=shared' 
'--enable-ucd-snmp-hack' '--with-sybase-ct=shared,/usr' 
'--with-oci8=shared,/usr/local/oracle/product/8i' 
'--with-swf=shared,/home/troels/rpm/BUILD/php-4.2.2/swflib' 
'--enable-sockets=shared' '--with-gmp=shared' 
'--with-dom=shared' 
'--with-qtdom=shared,/usr/lib/qt-2.3.1' '--enable-wddx' 
'--with-curl=shared' '--enable-apc=shared' 
'--with-ming=shared' '--with-imlib=shared' 
'--with-recode=shared' '--enable-calendar=shared' 
'--enable-posix=shared' '--with-mcal=shared,/usr' 
'--with-zlib' '--with-mm' 
 
gdb Backtrace 
-- 
I managed to attach gdb and get the following backtrace 
from just after the segfault 
(gdb) bt 
#0  0x4027f4f0 in ps_sd_lookup () from 
/etc/httpd/modules/libphp4.so 
#1  0x4027f8e1 in ps_read_mm () from 
/etc/httpd/modules/libphp4.so 
#2  0x4027bec1 in php_session_initialize () from 
/etc/httpd/modules/libphp4.so 
#3  0x4027d23b in php_session_start () from 
/etc/httpd/modules/libphp4.so 
#4  0x4027e111 in zif_session_register () from 
/etc/httpd/modules/libphp4.so 
#5  0x4023dc15 in execute () from 
/etc/httpd/modules/libphp4.so 
#6  0x424fac23 in file_is_shm_ignored () from 
/usr/local/zend/phpa-1.3.2.so 
#7  0x4025d3f3 in php_execute_script () from 
/etc/httpd/modules/libphp4.so 
#8  0x40258f82 in apache_php_module_main () from 
/etc/httpd/modules/libphp4.so 
#9  0x40259a94 in send_php () from 
/etc/httpd/modules/libphp4.so 
#10 0x40259af7 in send_parsed_php () from 
/etc/httpd/modules/libphp4.so 
#11 0x8053781 in ap_invoke_handler () 
#12 0x806200b in ap_some_auth_required () 
#13 0x80622be in ap_internal_redirect () 
#14 0x401e26fd in mod_gzip_redir1_handler () from 
/etc/httpd/modules/mod_gzip.so 
#15 0x401e163a in mod_gzip_handler () from 
/etc/httpd/modules/mod_gzip.so 
#16 0x8053781 in ap_invoke_handler () 
#17 0x806200b in ap_some_auth_required () 
#18 0x806205c in ap_process_request () 
#19 0x805be42 in ap_child_terminate () 
#20 0x805c023 in ap_child_terminate () 
#21 0x805c2e3 in ap_child_terminate () 
#22 0x805c706 in ap_child_terminate () 
#23 0x805cb9f in main () 
#24 0x400c69cb in __libc_start_main (main=0x805c920 
, argc=1, argv=0xbb1c, init=0x804f39c <_init>, 
fini=0x807b78c <_fini>, rtld_fini=0x4000aea0 
<_dl_fini>, stack_end=0xbb14) at 
../sysdeps/generic/libc-start.c:92 
 
 
Environment (Both Machines) 
--- 
Redhat 6.2 (x86) 
Kernel 2.4.2 
PHP 4.2.2 [ + phpa 1.3.2 ], running as apache module 
Apache 1.3.22 (redhat patched version) 
 + mod_accounting 
 + mod_mp3 
 + mod_gzip 
 
 
 




-- 
Edit this bug report at http://bugs.php.net/?id=19585&ed

#19585 [NEW]: mm session handler causes segfault

2002-09-24 Thread tcarter


From: [EMAIL PROTECTED]
Operating system: Linux 2.4.2 (Redhat 6.2)
PHP version:  4.2.2
PHP Bug Type: Session related
Bug description:  mm session handler causes segfault

Description 
--- 
In some cases (I can't reproduce it easily, seeing it 
maybe once every two days) PHP seems to be crashing 
apache.  I have two almost identical machines (production 
& development), and after switching the session handler 
from mm to files on the production machine the crashes 
_seem_ to have stopped there, but still happen on the 
development machine (which is still using mm). 
 
PHP Script 
--- 
Since I can't reproduce the crash on demand I'm not sure 
exactly where in the php script the crash is occuring. 
However the following line seems most likely, given the 
backtrace below, this is the first reference to session 
stuff in the script(s) that are crashing 
 
if (!session_is_registered("ngInfo")) 
session_register("ngInfo"); 
 
PHP Version/Modules 
--- 
(Using RPMS from http://rpms.arvin.dk/php, rebuilt againt 
pdflib 3.0.3 rather than pdflib 4.x).  phpa 1.3.2 
(http://php-accelerator.co.uk/) is also installed 
 
./configure' '--prefix=/usr' '--enable-pic' 
'--disable-rpath' '--with-layout=GNU' '--with-apxs' 
'--libdir=/usr/lib/php4' '--datadir=/usr/share/php' 
'--with-config-file-path=/etc' 
'--enable-inline-optimization' '--enable-magic-quotes' 
'--enable-track-vars' '--enable-memory-limit' 
'--enable-bcmath' '--with-iconv' '--with-pcre-regex=/usr' 
'--enable-sigchild' '--with-xml' '--with-expat-dir=/usr' 
'--with-openssl' '--enable-ftp=shared' 
'--enable-exif=shared' '--enable-sysvsem=shared' 
'--enable-sysvshm=shared' '--enable-shmop=shared' 
'--with-unixODBC=shared' '--with-mysql=shared,/usr' 
'--with-ldap=shared' '--with-pgsql=shared' 
'--with-gettext=shared' '--with-snmp=shared' 
'--enable-ucd-snmp-hack' '--with-sybase-ct=shared,/usr' 
'--with-oci8=shared,/usr/local/oracle/product/8i' 
'--with-swf=shared,/home/troels/rpm/BUILD/php-4.2.2/swflib' 
'--enable-sockets=shared' '--with-gmp=shared' 
'--with-dom=shared' 
'--with-qtdom=shared,/usr/lib/qt-2.3.1' '--enable-wddx' 
'--with-curl=shared' '--enable-apc=shared' 
'--with-ming=shared' '--with-imlib=shared' 
'--with-recode=shared' '--enable-calendar=shared' 
'--enable-posix=shared' '--with-mcal=shared,/usr' 
'--with-zlib' '--with-mm' 
 
gdb Backtrace 
-- 
I managed to attach gdb and get the following backtrace 
from just after the segfault 
(gdb) bt 
#0  0x4027f4f0 in ps_sd_lookup () from 
/etc/httpd/modules/libphp4.so 
#1  0x4027f8e1 in ps_read_mm () from 
/etc/httpd/modules/libphp4.so 
#2  0x4027bec1 in php_session_initialize () from 
/etc/httpd/modules/libphp4.so 
#3  0x4027d23b in php_session_start () from 
/etc/httpd/modules/libphp4.so 
#4  0x4027e111 in zif_session_register () from 
/etc/httpd/modules/libphp4.so 
#5  0x4023dc15 in execute () from 
/etc/httpd/modules/libphp4.so 
#6  0x424fac23 in file_is_shm_ignored () from 
/usr/local/zend/phpa-1.3.2.so 
#7  0x4025d3f3 in php_execute_script () from 
/etc/httpd/modules/libphp4.so 
#8  0x40258f82 in apache_php_module_main () from 
/etc/httpd/modules/libphp4.so 
#9  0x40259a94 in send_php () from 
/etc/httpd/modules/libphp4.so 
#10 0x40259af7 in send_parsed_php () from 
/etc/httpd/modules/libphp4.so 
#11 0x8053781 in ap_invoke_handler () 
#12 0x806200b in ap_some_auth_required () 
#13 0x80622be in ap_internal_redirect () 
#14 0x401e26fd in mod_gzip_redir1_handler () from 
/etc/httpd/modules/mod_gzip.so 
#15 0x401e163a in mod_gzip_handler () from 
/etc/httpd/modules/mod_gzip.so 
#16 0x8053781 in ap_invoke_handler () 
#17 0x806200b in ap_some_auth_required () 
#18 0x806205c in ap_process_request () 
#19 0x805be42 in ap_child_terminate () 
#20 0x805c023 in ap_child_terminate () 
#21 0x805c2e3 in ap_child_terminate () 
#22 0x805c706 in ap_child_terminate () 
#23 0x805cb9f in main () 
#24 0x400c69cb in __libc_start_main (main=0x805c920 
, argc=1, argv=0xbb1c, init=0x804f39c <_init>, 
fini=0x807b78c <_fini>, rtld_fini=0x4000aea0 
<_dl_fini>, stack_end=0xbb14) at 
../sysdeps/generic/libc-start.c:92 
 
 
Environment (Both Machines) 
--- 
Redhat 6.2 (x86) 
Kernel 2.4.2 
PHP 4.2.2 [ + phpa 1.3.2 ], running as apache module 
Apache 1.3.22 (redhat patched version) 
 + mod_accounting 
 + mod_mp3 
 + mod_gzip 
 
 
 
-- 
Edit bug report at http://bugs.php.net/?id=19585&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19585&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19585&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19585&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19585&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19585&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19585&r=support
Expected be

#9852 [Com]: Header redirect and db connection cause "CGI misbehaved"

2002-09-24 Thread davidr

ID: 9852
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.2.1
New Comment:

After some further testing on this PHP bug, I'll have to claim my
previous comment about upgrading MDAC to be a bit of a Red Herring.

However, my comment about running the IIS slot as an Administrator is
still valid, it seems that when the scripts are being executed as an
administrator (either by setting the anonymous IUSR to be an
administrator or removing anonymous access and authenticating with an
administrator account), this bug didn't occur in the 200 or so requests
that I made to the server yet when I drop the slot back to being run as
the IUSR it fails immediately.

The bug now seems to be not related to a Header redirect since I can
replicate it almost every time without fail by browsing to one of my
plain HTML pages which loads approximately 30 images by using a PHP
script to produce the image. A database connection is created in that
image script as it lookups the image's ID (a random 15 character
string) which maps it to the physical location of the image.

I have tried to throttle the bandwidth setting as mentioned earlier but
with no success.

I have also been seeing these "Application Popup Errors" at the same
time that the PHP script returns its CGI Header error. This popups
occur on the console and are exactly the same each time, they consist
of;

---
Title Bar: php.exe - Application Error

The application failed to initialize properly (0xc142). Click OK
to terminate the application
---

Server Information:
P3-1Ghz
512Mb RAM
Win2000 Server (SP3), IIS5
Hotfixes:
Q326830
Q295688
Q147222
IIS is configured to run as a host header server.

Unfortunately in my circumstances, it prevents the company I work for
the ability to allow our clients to use PHP on our live web servers
until this bug is fixed up. If this bug can be re-opened and looked
into, I'm sure we would all be very grateful for it.

Cheers

Previous Comments:

[2002-08-28 13:59:31] [EMAIL PROTECTED]

A few notes to add to the above comment. Our client does not have the
Performance Option set to foreground. The CGI error doesn't happen any
more thanks to either MDAC 2.7 or MS02-009. Wish I knew which of the
two fixed the CGI errors

[2002-08-28 13:52:53] [EMAIL PROTECTED]

I agree with Scott. PHP should be made to work with enterprise
products. Even if the problem is not PHP's fault we still need to know
exactly what causes it.

It's very interesting that when Scott sets Performance Options to
forground it solves his CGI error completely. It's even more
interesting that MDAC 2.7 doesn't help him.

This is our latest experience with a client who just installed our PHP
application.

Client System Configuration:
1.4 GIG processor, M$ 2000 Server, IIS, PHP, M$ SQL Server.

Client installed our application. CGI errors out the ying-yang (this
error happens more frequently on a machine with a fast processor). Told
Client to install MDAC 2.7 RTM. Unfortunately (or fortunately depending
on how you look at it), the client also decided to install this patch
at the same time:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-009.asp

So, we've found some new, interesting information from Micro$oft:
"Incorrect VBScript Handling in IE can Allow Web Pages to Read Local
Files"

Micro$oft also talks about third party scripting languages:
"... Microsoft has become aware of a handful of third-party
applications that depend on unforeseen behavior in VBScript that this
patch disables."

So good news and bad news. Bad news: We don't know if MDAC 2.7 fixed
our clients CGI erros or if the MS02-009 fixed it.
Good news: we've found yet another possible solution (MS02-009)

If anyone has a really fast machine out there maybe they can test this
MS02-009 fix. Please post your findings here.

Ottawa

[2002-08-28 02:28:14] [EMAIL PROTECTED]

Hi all,

As a followup a few weeks later, I can confirm that setting the server
performance to optimise for 'Forground Applications' solves the CGI
Error problem completely.

My guess is that PHP is launched as a CGI in user space (owned by
IUSR_*), so tuning the server this way gives it more processing time.
I guess the MSSQL module likes it this way.

I have also had emails from others asking for assistance on this, and
have had positive feedback from them that it fixed their problem, too.

Scott.

[2002-08-05 02:14:38] [EMAIL PROTECTED]

Further to my other posts, some more constructive data

#19567 [Bgs->Opn]: Access Violation at memory address 77F83941

2002-09-24 Thread drew . c . swan


 ID:   19567
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: IIS related
 Operating System: Windoes 2000 SP2
 PHP Version:  4.2.3
 New Comment:

changed status


Previous Comments:


[2002-09-24 17:45:43] [EMAIL PROTECTED]

Tried the latest snapshot.

Still get the same error.

this is the output from the spider.php file
start: http://csmtemlst-web/development
URL = (begin >)=> http://csmtemlst-web/development
need parse
start load
PHP has encountered an Access Violation at 77F83941

The web server is a Compaq ProLiant DL360 G2 Dual processor

Any ideas



[2002-09-24 00:38:36] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2002-09-23 23:56:55] [EMAIL PROTECTED]

After installing PHP 4.2.2 and 4.2.3 and trying to use the phpMySearch
application, when running the spider.php file I get an access
violation.
The phpMySearch people seem to think it is a bug with php.

See the thread 

http://phpmysearch.web4.hm/modules.php?op=modload&name=phpBB_14&file=ind
ex&action=viewtopic&topic=90&forum=9&3 

for more info. Another user has the same problem I do.

Server: IIS 5.0
OS: Win 2K SP2
PHP vers: 4.2.2 and 4.2.3 (ISAPI) and 4.2.3 CGI
PHP Modules : php_curl.dll

event log below

Desc:
The application, , generated an application error The error occurred
on
09/24/2002 @ 14:36:38.889 The exception generated was c005 at
address 77F83941 (RtlpWaitForCriticalSection) 

if you want the rest of the details email me and I'll send them to you.
It's kind of long.



[2002-09-23 23:52:47] [EMAIL PROTECTED]

After installing PHP 4.2.2 and 4.2.3 and trying to use the phpMySearch
application, when running the spider.php file I get an access
violation. The phpMySearch people seem to think it is a bug with php.

See the thread 

http://phpmysearch.web4.hm/modules.php?op=modload&name=phpBB_14&file=index&action=viewtopic&topic=90&forum=9&3


for more info. Another user has the same problem I do.

Server: IIS 5.0
OS: Win 2K SP2
PHP vers: 4.2.2 and 4.2.3 (ISAPI) and 4.2.3 CGI
PHP Modules : php_curl.dll

event log below

Desc:
The application, , generated an application error The error occurred on
09/24/2002 @ 14:36:38.889 The exception generated was c005 at
address 77F83941 (RtlpWaitForCriticalSection) 

details:
: 0d 0a 0d 0a 41 70 70 6c   Appl
0008: 69 63 61 74 69 6f 6e 20   ication 
0010: 65 78 63 65 70 74 69 6f   exceptio
0018: 6e 20 6f 63 63 75 72 72   n occurr
0020: 65 64 3a 0d 0a 20 20 20   ed:..   
0028: 20 20 20 20 20 41 70 70App
0030: 3a 20 20 28 70 69 64 3d   :  (pid=
0038: 31 32 35 32 29 0d 0a 20   1252).. 
0040: 20 20 20 20 20 20 20 57  W
0048: 68 65 6e 3a 20 39 2f 32   hen: 9/2
0050: 34 2f 32 30 30 32 20 40   4/2002 @
0058: 20 31 34 3a 33 36 3a 3314:36:3
0060: 38 2e 38 38 39 0d 0a 20   8.889.. 
0068: 20 20 20 20 20 20 20 45  E
0070: 78 63 65 70 74 69 6f 6e   xception
0078: 20 6e 75 6d 62 65 72 3anumber:
0080: 20 63 30 30 30 30 30 30c00
0088: 35 20 28 61 63 63 65 73   5 (acces
0090: 73 20 76 69 6f 6c 61 74   s violat
0098: 69 6f 6e 29 0d 0a 0d 0a   ion)
00a0: 2a 2d 2d 2d 2d 3e 20 53   *> S
00a8: 79 73 74 65 6d 20 49 6e   ystem In
00b0: 66 6f 72 6d 61 74 69 6f   formatio
00b8: 6e 20 3c 2d 2d 2d 2d 2a   n <*
00c0: 0d 0a 20 20 20 20 20 20   ..  
00c8: 20 20 43 6f 6d 70 75 74 Comput
00d0: 65 72 20 4e 61 6d 65 3a   er Name:
00d8: 20 43 53 4d 54 45 4d 4cCSMTEML
00e0: 53 54 2d 57 45 42 0d 0a   ST-WEB..
00e8: 20 20 20 20 20 20 20 20   
00f0: 55 73 65 72 20 4e 61 6d   User Nam
00f8: 65 3a 20 41 64 6d 69 6e   e: Admin
0100: 69 73 74 72 61 74 6f 72   istrator
0108: 0d 0a 20 20 20 20 20 20   ..  
0110: 20 20 4e 75 6d 62 65 72 Number
0118: 20 6f 66 20 50 72 6f 63of Proc
0120: 65 73 73 6f 72 73 3a 20   essors: 
0128: 32 0d 0a 20 20 20 20 20   2.. 
0130: 20 20 20 50 72 6f 63 65  Proce
0138: 73 73 6f 72 20 54 79 70   ssor Typ
0140: 65 3a 20 78 38 36 20 46   e: x86 F
0148: 61 6d 69 6c 79 20 36 20   amily 6 
0150: 4d 6f 64 65 6c 20 31 31   Model 11
0158: 20 53 74 65 70 70 69 6eSteppin
0160: 67 20 31 0d 0a 20 20 20   g 1..   
0168: 20 20 20 20 20 57 69 6eWin
0170: 64 6f 77 73 20 32 30 30   dows 200
0178: 30 20 56 65 72 73 69 6f   0 Versio
0180: 6e 3a 20 35 2e 30 0d 0a   n: 5.0..
0188: 20 20 20 20 20 20 20 20   
0190: 43 75 72 72 65 6e 74 20   Current 
0198: 42 75 69 6c 64 3a 20 32   Build: 2
01a0: 3

#19584 [Fbk->Bgs]: ob_implicit_flush may not be working


 ID:   19584
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Bogus
 Bug Type: Sockets related
 Operating System: Windows 2000 Advanced Server IIS
 PHP Version:  4.2.3
 New Comment:

Your wish is our command :)


Previous Comments:


[2002-09-24 17:53:17] [EMAIL PROTECTED]

Just tried edink's suggestion, seems to work
output_buffering = Off

Throw me into the bogus pile! =)



[2002-09-24 17:48:07] [EMAIL PROTECTED]

I downloaded the CVS snapshot and set it up.

-My php.ini is residing in c:\winnt, and when i upgraded to the latest
version (4.2.3), i went line by line and made sure my php.ini wasn't
missing anything from the new php.ini in 4.2.3

-My PATH environment variable has c:\php\dlls and c:\php\extensions in
it, so i didn't copy anything to the winnt folders

-For each time i tried a different version, i shut down my web server,
rebooted, renamed c:\php to something like c:\php_4.1.2, then renamed
the version i wanted (c:\php_4.2.3) to c:\php.  Then I started up my
web server

-I use the same php folder structure as the original that came out of
the ZIP file except i have an added sessiondata\path\for\session\data
folder and uploadtemp, which I've duplicated throughout each
installation:
c:\php (currently the CVS version i downloaded)
c:\php_4.1.2
c:\php_4.2.2
c:\php_4.2.3

-I created a file c:\test.php which contains:


Here are the results of running this file (in this case i didn't reboot
or anything, i just ran php.exe right from the folder)

http://www.genevus.com/download/php_4.1.2.gif
http://www.genevus.com/download/php_4.2.2.gif
http://www.genevus.com/download/php_4.2.3.gif
http://www.genevus.com/download/php_cvs.gif



[2002-09-24 17:36:07] [EMAIL PROTECTED]

And try to disable output buffering in your php.ini. Maybe you have
used php.ini-recommended after upgrading to 4.2.3?



[2002-09-24 17:21:14] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Also, make sure you really replace all the old php related files with
the new ones found in the release package.
(php4ts.dll being the most important)




[2002-09-24 17:09:41] [EMAIL PROTECTED]

Now I can't get it working in 4.2.2 anymore

Probably my configuration then... Always works with 4.1.2 though, so
I'm not sure what to think anymore.



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

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

#19584 [Com]: ob_implicit_flush may not be working


 ID:   19584
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Sockets related
 Operating System: Windows 2000 Advanced Server IIS
 PHP Version:  4.2.3
 New Comment:

Just tried edink's suggestion, seems to work
output_buffering = Off

Throw me into the bogus pile! =)


Previous Comments:


[2002-09-24 17:48:07] [EMAIL PROTECTED]

I downloaded the CVS snapshot and set it up.

-My php.ini is residing in c:\winnt, and when i upgraded to the latest
version (4.2.3), i went line by line and made sure my php.ini wasn't
missing anything from the new php.ini in 4.2.3

-My PATH environment variable has c:\php\dlls and c:\php\extensions in
it, so i didn't copy anything to the winnt folders

-For each time i tried a different version, i shut down my web server,
rebooted, renamed c:\php to something like c:\php_4.1.2, then renamed
the version i wanted (c:\php_4.2.3) to c:\php.  Then I started up my
web server

-I use the same php folder structure as the original that came out of
the ZIP file except i have an added sessiondata\path\for\session\data
folder and uploadtemp, which I've duplicated throughout each
installation:
c:\php (currently the CVS version i downloaded)
c:\php_4.1.2
c:\php_4.2.2
c:\php_4.2.3

-I created a file c:\test.php which contains:


Here are the results of running this file (in this case i didn't reboot
or anything, i just ran php.exe right from the folder)

http://www.genevus.com/download/php_4.1.2.gif
http://www.genevus.com/download/php_4.2.2.gif
http://www.genevus.com/download/php_4.2.3.gif
http://www.genevus.com/download/php_cvs.gif



[2002-09-24 17:36:07] [EMAIL PROTECTED]

And try to disable output buffering in your php.ini. Maybe you have
used php.ini-recommended after upgrading to 4.2.3?



[2002-09-24 17:21:14] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Also, make sure you really replace all the old php related files with
the new ones found in the release package.
(php4ts.dll being the most important)




[2002-09-24 17:09:41] [EMAIL PROTECTED]

Now I can't get it working in 4.2.2 anymore

Probably my configuration then... Always works with 4.1.2 though, so
I'm not sure what to think anymore.



[2002-09-24 16:54:06] [EMAIL PROTECTED]

I have been running a looping script using php.exe from the
command-line using 4.1.2 to run tasks I pull out of a database. I
needed to use socket_set_timeout but my build of 4.1.2 didn't support
it.

I upgraded to 4.2.2 and my script worked, but socket_set_timeout wasn't
supported in this one either.

So I upgraded to 4.2.3 and now my script doesn't even output anything.
ob_implicit_flush doesn't *seem* to be working.  PHP doesn't echo
anything, it just seems to be hanging in my loop.

Will be easier to explain with a code example:

set_time_limit(0);
ob_implicit_flush();

for(;;)
{
 echo "hello\n";
 sleep(10);
}

This code works just fine in 4.1.2, same for 4.2.2.  But not in 4.2.3.




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

#19584 [Com]: ob_implicit_flush may not be working


 ID:   19584
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Sockets related
 Operating System: Windows 2000 Advanced Server IIS
 PHP Version:  4.2.3
 New Comment:

I downloaded the CVS snapshot and set it up.

-My php.ini is residing in c:\winnt, and when i upgraded to the latest
version (4.2.3), i went line by line and made sure my php.ini wasn't
missing anything from the new php.ini in 4.2.3

-My PATH environment variable has c:\php\dlls and c:\php\extensions in
it, so i didn't copy anything to the winnt folders

-For each time i tried a different version, i shut down my web server,
rebooted, renamed c:\php to something like c:\php_4.1.2, then renamed
the version i wanted (c:\php_4.2.3) to c:\php.  Then I started up my
web server

-I use the same php folder structure as the original that came out of
the ZIP file except i have an added sessiondata\path\for\session\data
folder and uploadtemp, which I've duplicated throughout each
installation:
c:\php (currently the CVS version i downloaded)
c:\php_4.1.2
c:\php_4.2.2
c:\php_4.2.3

-I created a file c:\test.php which contains:


Here are the results of running this file (in this case i didn't reboot
or anything, i just ran php.exe right from the folder)

http://www.genevus.com/download/php_4.1.2.gif
http://www.genevus.com/download/php_4.2.2.gif
http://www.genevus.com/download/php_4.2.3.gif
http://www.genevus.com/download/php_cvs.gif


Previous Comments:


[2002-09-24 17:36:07] [EMAIL PROTECTED]

And try to disable output buffering in your php.ini. Maybe you have
used php.ini-recommended after upgrading to 4.2.3?



[2002-09-24 17:21:14] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Also, make sure you really replace all the old php related files with
the new ones found in the release package.
(php4ts.dll being the most important)




[2002-09-24 17:09:41] [EMAIL PROTECTED]

Now I can't get it working in 4.2.2 anymore

Probably my configuration then... Always works with 4.1.2 though, so
I'm not sure what to think anymore.



[2002-09-24 16:54:06] [EMAIL PROTECTED]

I have been running a looping script using php.exe from the
command-line using 4.1.2 to run tasks I pull out of a database. I
needed to use socket_set_timeout but my build of 4.1.2 didn't support
it.

I upgraded to 4.2.2 and my script worked, but socket_set_timeout wasn't
supported in this one either.

So I upgraded to 4.2.3 and now my script doesn't even output anything.
ob_implicit_flush doesn't *seem* to be working.  PHP doesn't echo
anything, it just seems to be hanging in my loop.

Will be easier to explain with a code example:

set_time_limit(0);
ob_implicit_flush();

for(;;)
{
 echo "hello\n";
 sleep(10);
}

This code works just fine in 4.1.2, same for 4.2.2.  But not in 4.2.3.




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

#19567 [Bgs]: Access Violation at memory address 77F83941

2002-09-24 Thread drew . c . swan


 ID:   19567
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: IIS related
 Operating System: Windoes 2000 SP2
 PHP Version:  4.2.3
 New Comment:

Tried the latest snapshot.

Still get the same error.

this is the output from the spider.php file
start: http://csmtemlst-web/development
URL = (begin >)=> http://csmtemlst-web/development
need parse
start load
PHP has encountered an Access Violation at 77F83941

The web server is a Compaq ProLiant DL360 G2 Dual processor

Any ideas


Previous Comments:


[2002-09-24 00:38:36] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2002-09-23 23:56:55] [EMAIL PROTECTED]

After installing PHP 4.2.2 and 4.2.3 and trying to use the phpMySearch
application, when running the spider.php file I get an access
violation.
The phpMySearch people seem to think it is a bug with php.

See the thread 

http://phpmysearch.web4.hm/modules.php?op=modload&name=phpBB_14&file=ind
ex&action=viewtopic&topic=90&forum=9&3 

for more info. Another user has the same problem I do.

Server: IIS 5.0
OS: Win 2K SP2
PHP vers: 4.2.2 and 4.2.3 (ISAPI) and 4.2.3 CGI
PHP Modules : php_curl.dll

event log below

Desc:
The application, , generated an application error The error occurred
on
09/24/2002 @ 14:36:38.889 The exception generated was c005 at
address 77F83941 (RtlpWaitForCriticalSection) 

if you want the rest of the details email me and I'll send them to you.
It's kind of long.



[2002-09-23 23:52:47] [EMAIL PROTECTED]

After installing PHP 4.2.2 and 4.2.3 and trying to use the phpMySearch
application, when running the spider.php file I get an access
violation. The phpMySearch people seem to think it is a bug with php.

See the thread 

http://phpmysearch.web4.hm/modules.php?op=modload&name=phpBB_14&file=index&action=viewtopic&topic=90&forum=9&3


for more info. Another user has the same problem I do.

Server: IIS 5.0
OS: Win 2K SP2
PHP vers: 4.2.2 and 4.2.3 (ISAPI) and 4.2.3 CGI
PHP Modules : php_curl.dll

event log below

Desc:
The application, , generated an application error The error occurred on
09/24/2002 @ 14:36:38.889 The exception generated was c005 at
address 77F83941 (RtlpWaitForCriticalSection) 

details:
: 0d 0a 0d 0a 41 70 70 6c   Appl
0008: 69 63 61 74 69 6f 6e 20   ication 
0010: 65 78 63 65 70 74 69 6f   exceptio
0018: 6e 20 6f 63 63 75 72 72   n occurr
0020: 65 64 3a 0d 0a 20 20 20   ed:..   
0028: 20 20 20 20 20 41 70 70App
0030: 3a 20 20 28 70 69 64 3d   :  (pid=
0038: 31 32 35 32 29 0d 0a 20   1252).. 
0040: 20 20 20 20 20 20 20 57  W
0048: 68 65 6e 3a 20 39 2f 32   hen: 9/2
0050: 34 2f 32 30 30 32 20 40   4/2002 @
0058: 20 31 34 3a 33 36 3a 3314:36:3
0060: 38 2e 38 38 39 0d 0a 20   8.889.. 
0068: 20 20 20 20 20 20 20 45  E
0070: 78 63 65 70 74 69 6f 6e   xception
0078: 20 6e 75 6d 62 65 72 3anumber:
0080: 20 63 30 30 30 30 30 30c00
0088: 35 20 28 61 63 63 65 73   5 (acces
0090: 73 20 76 69 6f 6c 61 74   s violat
0098: 69 6f 6e 29 0d 0a 0d 0a   ion)
00a0: 2a 2d 2d 2d 2d 3e 20 53   *> S
00a8: 79 73 74 65 6d 20 49 6e   ystem In
00b0: 66 6f 72 6d 61 74 69 6f   formatio
00b8: 6e 20 3c 2d 2d 2d 2d 2a   n <*
00c0: 0d 0a 20 20 20 20 20 20   ..  
00c8: 20 20 43 6f 6d 70 75 74 Comput
00d0: 65 72 20 4e 61 6d 65 3a   er Name:
00d8: 20 43 53 4d 54 45 4d 4cCSMTEML
00e0: 53 54 2d 57 45 42 0d 0a   ST-WEB..
00e8: 20 20 20 20 20 20 20 20   
00f0: 55 73 65 72 20 4e 61 6d   User Nam
00f8: 65 3a 20 41 64 6d 69 6e   e: Admin
0100: 69 73 74 72 61 74 6f 72   istrator
0108: 0d 0a 20 20 20 20 20 20   ..  
0110: 20 20 4e 75 6d 62 65 72 Number
0118: 20 6f 66 20 50 72 6f 63of Proc
0120: 65 73 73 6f 72 73 3a 20   essors: 
0128: 32 0d 0a 20 20 20 20 20   2.. 
0130: 20 20 20 50 72 6f 63 65  Proce
0138: 73 73 6f 72 20 54 79 70   ssor Typ
0140: 65 3a 20 78 38 36 20 46   e: x86 F
0148: 61 6d 69 6c 79 20 36 20   amily 6 
0150: 4d 6f 64 65 6c 20 31 31   Model 11
0158: 20 53 74 65 70 70 69 6eSteppin
0160: 67 20 31 0d 0a 20 20 20   g 1..   
0168: 20 20 20 20 20 57 69 6eWin
0170: 64 6f 77 73 20 32 30 30   dows 200
0178: 30 20 56 65 72 73 69 6f   0 Versio
0180: 6e 3a 20 35 2e 30 0d 0a   n: 5.0..
0188: 20 20 20 20 20 20 20 20   
0190: 43 75 72 72 65 6e 74 20   Current 
0198: 42 75 69 6c 64 3a 20 32   Build: 2
01a0: 31 39 35 0d 0a 20 20 20   195..   
01a8: 20 20 20 20 20 53 65 72Ser
01b0: 76 69 63 65 20 50 61 63   vice Pac
01b8: 6b 3a 20 32 0d 0a 20 20   k: 2

#19207 [Opn->Ver]: php-cgi.exe does not correctly set HTTP status


 ID:   19207
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Verified
 Bug Type: IIS related
 Operating System: Windows 2000/.Net Server RC1
 PHP Version:  4CVS-2002-08-30


Previous Comments:


[2002-09-24 13:03:38] [EMAIL PROTECTED]

I'm currently using IIS 6.0 in Windows.Net Server RC1 (build 3663). 
Again, CGI PHP 4.2.2/4.2.3 works fine just not CGI PHP 4.3.0.



[2002-09-24 11:48:11] [EMAIL PROTECTED]

what version of IIS are you using.. this works fine on Win XP Pro (No
service pack) so IIS 5.0.

- James
--  
James Moore
[EMAIL PROTECTED]



[2002-09-05 11:22:02] [EMAIL PROTECTED]

Just tried the latest snapshot php4-win32-200209051400.zip and the
issue still exists.  php-cgi.exe returns the following headers:

Status: 401
Content-type: text/html
WWW-authenticate: basic realm=Logon

The correct headers for php-cgi.exe to work in IIS should be:

HTTP/1.1 401 Unauthorized
Content-type: text/html
WWW-authenticate: basic realm=Logon



[2002-09-04 21:30:20] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

I believe there was just a patch submitted that fixes this.  I could be
wrong though too, please test and update if still valid. :\



[2002-08-30 20:09:13] [EMAIL PROTECTED]

The following code fragment works great with PHP 4.2.2 on IIS:

  Header("WWW-authenticate: basic realm=Logon");
  Header("HTTP/1.1 401 Unauthorized");
  echo "\n";
  echo " \n";
  echo " Authorization Required\n";
  echo " \n";
  echo " \n";
  echo "  Invalid username and password with which to access this
webpage.\n";
  echo " \n";
  echo "\n";
  exit;

This code works correctly in 4.2.2.  It sets the status of the page to
401 and makes the browser prompt for the password.

However using php-cgi.exe in the latest 4.3.0 development builds in IIS
the code does not work.  The browser receive a "HTTP/1.1 200 OK"
instead of "HTTP/1.1 401 Unauthorized".  If I simply run the CGI script
from the command prompt using php-cgi.exe in 4.3.0 I get the
following:

Status: 401
Content-type: text/html
WWW-authenticate: basic realm=Logon


 
 Authorization Required
 
 
  Invalid username and password with which to access this
webpage.
 


Running php.exe 4.2.2 from the console I get the following:

HTTP/1.1 401 Unauthorized
Content-type: text/html
WWW-authenticate: basic realm=Logon


 
 Authorization Required
 
 
  Invalid username and password with which to access this
webpage.
 


Noticed that php 4.2.2 correctly returns the HTTP page status as
"HTTP/1.1 401 Unauthorized" and php 4.3.0 only returns the tag "Status:
401".

The new tag "Status: 401" does not work in IIS, it needs to be the full
"HTTP/1.1 401 Unauthorized".




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

#19423 [Com]: Problem with extension_dir in PHP.ini

2002-09-24 Thread cbrady


 ID:   19423
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: *Web Server problem
 Operating System: Windows 9x/NT/ME/2000/XP
 PHP Version:  4.2.3
 New Comment:

I'm using the ISAPI version on Win2k IIS.

My install drive for php is I:\php\

My php.ini is in the H:\winnt\ directory (the phpinfo() function
reports that is were it found it).

Php.ini coding :

; Directory in which the loadable extensions (modules) reside.
extension_dir = I:/php/extensions/


As long as I don't specify a extension to load, php works fine. But,
once I un remark an extension (ei. php_mssql.dll), it gives the "unable
to load dynamic library 'I:/php/extensions/php_mssql.dll' The support
module not found" message.

I've tried both ways, I:\\ and I:/


Previous Comments:


[2002-09-24 17:10:49] [EMAIL PROTECTED]

No php.ini does not have to be on the c: drive. 

However please make sure you are using the c:\\ or c:/ syntax. Also
make sure that your php.ini file is in the correct location (look at
the output of phpinfo()). With the cli and cgi versions you can often
get away with putting the php.ini file in the same dir as the
executable and it will find it there.

- James



[2002-09-24 17:03:32] [EMAIL PROTECTED]

Same issue. However, its it a requirement that the php directory be on
the c: drive?

I have the same problem with any php version I install on the Win2k
Server.



[2002-09-21 14:27:49] [EMAIL PROTECTED]

try changing 'c:\php\extensions' to 'c:\\php\\extensions' or
'c:/php/extensions' and see if it begins to work.



[2002-09-16 08:32:29] [EMAIL PROTECTED]

Oh yeah, I forgot to add that all the pertinent files for this
extension are in the %system% directory!



[2002-09-16 08:29:45] [EMAIL PROTECTED]

To mficher:

If you can give me some cookbook instructions on how to use this tool,
then I would be glad to give it a try.  It looks as though it needs a
running process, but the error occurs when I start IIS.  How can I
accomplish what you need?



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

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

#14483 [Csd]: -twolevel_namespace and multiple definitions errors

2002-09-24 Thread kalowsky


 ID:   14483
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: Mac OS X 10.1
 PHP Version:  4.2.0-dev
 New Comment:

yes, pear doesn't work yet.  we know this.


Previous Comments:


[2002-09-24 14:32:55] [EMAIL PROTECTED]

Eveything I did was in root (su)...

system.log shows:
Sep 24 11:31:00 path046 SystemStarter: Apache web server 
(446) did not complete successfully. 

httpd/error_log shows nothing significant (previous errors 
when running).

I'll look into pear I suppose...

Brian



[2002-09-24 13:25:58] [EMAIL PROTECTED]

Eveything I did was in root (su)...

system.log shows:
Sep 24 11:31:00 path046 SystemStarter: Apache web server 
(446) did not complete successfully. 

httpd/error_log shows nothing significant (previous errors 
when running).

I'll look into pear I suppose...

Brian



[2002-09-24 12:59:13] [EMAIL PROTECTED]

Thanks for pointing me to snaps! Config went much 
smoother, however I get the following error from Apache:

[path046:/Users/bripakes] bripakes# apachectl start
Syntax error on line 242 of /etc/httpd/httpd.conf:
Cannot load /usr/libexec/httpd/libphp4.so into server: 
(reason unknown)
/usr/sbin/apachectl start: httpd could not be started

I noticed the owner and group were different so I changed 
them to root/wheel. And PEAR gave me errors so I used 
--disable-pear in my config.

Any ideas?



[2002-09-24 12:15:58] [EMAIL PROTECTED]

I notice you're logged in as "bripakes".  I think you need to be "root"
to control apache, and it's even best if you install it as "root". 
Forget "sudo" and all of that happy bull.  Just "su" and do what you
need to do, then go back to being a normal user.  If you're still
confused, read the following logs, they should provide some guidance:

tail -50 /var/log/system.log
tail -50 /var/log/httpd/error_log

-Abner



[2002-09-24 12:07:38] [EMAIL PROTECTED]

Thanks for pointing me to snaps! Config went much 
smoother, however I get the following error from Apache:

[path046:/Users/bripakes] bripakes# apachectl start
Syntax error on line 242 of /etc/httpd/httpd.conf:
Cannot load /usr/libexec/httpd/libphp4.so into server: 
(reason unknown)
/usr/sbin/apachectl start: httpd could not be started

I noticed the owner and group were different so I changed 
them to root/wheel. And PEAR gave me errors so I used 
--disable-pear in my config.

Any ideas?



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

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

#19584 [Fbk]: ob_implicit_flush may not be working


 ID:   19584
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Sockets related
 Operating System: Windows 2000 Advanced Server IIS
 PHP Version:  4.2.3
 New Comment:

And try to disable output buffering in your php.ini. Maybe you have
used php.ini-recommended after upgrading to 4.2.3?


Previous Comments:


[2002-09-24 17:21:14] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Also, make sure you really replace all the old php related files with
the new ones found in the release package.
(php4ts.dll being the most important)




[2002-09-24 17:09:41] [EMAIL PROTECTED]

Now I can't get it working in 4.2.2 anymore

Probably my configuration then... Always works with 4.1.2 though, so
I'm not sure what to think anymore.



[2002-09-24 16:54:06] [EMAIL PROTECTED]

I have been running a looping script using php.exe from the
command-line using 4.1.2 to run tasks I pull out of a database. I
needed to use socket_set_timeout but my build of 4.1.2 didn't support
it.

I upgraded to 4.2.2 and my script worked, but socket_set_timeout wasn't
supported in this one either.

So I upgraded to 4.2.3 and now my script doesn't even output anything.
ob_implicit_flush doesn't *seem* to be working.  PHP doesn't echo
anything, it just seems to be hanging in my loop.

Will be easier to explain with a code example:

set_time_limit(0);
ob_implicit_flush();

for(;;)
{
 echo "hello\n";
 sleep(10);
}

This code works just fine in 4.1.2, same for 4.2.2.  But not in 4.2.3.




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

#19552 [Bgs]: path is always where php was compiled


 ID:   19552
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Apache2 related
 Operating System: linux
 PHP Version:  4.2.3
 New Comment:

There was a bug with virtual directory support in 4.2.3 used with
multithreaded web servers. It's been fixed in both STABLE and HEAD
branches.

You should not rely on environment for CWD in a multithreaded server,
since all threads share the same. The directory you're getting is
probably the one you were in when starting Apache2. Use getcwd()
instead.


Previous Comments:


[2002-09-24 16:18:31] [EMAIL PROTECTED]

it causes php scripts to not run.  the problem isn't that $_ENV['PWD']
is wrong, it's that php looks in the wrong place for files to include.

if I "include 'foo.php';"  it will look for it in
/home/sproctor/php-xxx instead of from the location of the file.

The CGI version works fine, the apache1 version works fine, the apache2
version fails.  It's not too big of a deal for me thought because we
have the CGI version working.

Perhaps it's a bug in apache2, either way PHP seems rather unusable as
an apache2 module right now.

Thanks for the help,
Sean



[2002-09-24 15:56:13] [EMAIL PROTECTED]

This might be for one of two reasons, this was the dir you started
apache from, or it might be a bug in apache2. I cannot see how this bug
comes from PHP. 

The variables' and the values for them are taken directly from the
server or environment variables provided to PHP.

Bogusify.

- James



[2002-09-24 15:27:12] [EMAIL PROTECTED]

I tried the latest version.  now $_ENV['PWD'] is just
/home/sproctor/php4-200209240900.  I imagine it's an apache2 issue
because that's the only weird thing I'm doing.  apache2 works fine on
our server for everything else.  I'll try building it as a CGI and see
if that works.



[2002-09-23 05:27:48] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2002-09-22 16:53:11] [EMAIL PROTECTED]

$_ENV['PWD'] always returns /home/sproctor/php-4.2.3 (where php was
compiled).  I expect it to be /var/www/reliance/pn (where the script is
run from).  I compiled php with apxs2 and apache 2.0.40.

It's not just the variable that's wrong, but doing something like
include "filename" will search in /home/sproctor/php-4.2.3, for
clarity.

Thanks!




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

#19584 [Opn->Fbk]: ob_implicit_flush may not be working


 ID:   19584
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Sockets related
 Operating System: Windows 2000 Advanced Server IIS
 PHP Version:  4.2.3
 New Comment:

Please try using this CVS snapshot:

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

Also, make sure you really replace all the old php related files with
the new ones found in the release package.
(php4ts.dll being the most important)



Previous Comments:


[2002-09-24 17:09:41] [EMAIL PROTECTED]

Now I can't get it working in 4.2.2 anymore

Probably my configuration then... Always works with 4.1.2 though, so
I'm not sure what to think anymore.



[2002-09-24 16:54:06] [EMAIL PROTECTED]

I have been running a looping script using php.exe from the
command-line using 4.1.2 to run tasks I pull out of a database. I
needed to use socket_set_timeout but my build of 4.1.2 didn't support
it.

I upgraded to 4.2.2 and my script worked, but socket_set_timeout wasn't
supported in this one either.

So I upgraded to 4.2.3 and now my script doesn't even output anything.
ob_implicit_flush doesn't *seem* to be working.  PHP doesn't echo
anything, it just seems to be hanging in my loop.

Will be easier to explain with a code example:

set_time_limit(0);
ob_implicit_flush();

for(;;)
{
 echo "hello\n";
 sleep(10);
}

This code works just fine in 4.1.2, same for 4.2.2.  But not in 4.2.3.




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

#19423 [Fbk]: Problem with extension_dir in PHP.ini


 ID:   19423
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: *Web Server problem
 Operating System: Windows 9x/NT/ME/2000/XP
 PHP Version:  4.2.3
 New Comment:

No php.ini does not have to be on the c: drive. 

However please make sure you are using the c:\\ or c:/ syntax. Also
make sure that your php.ini file is in the correct location (look at
the output of phpinfo()). With the cli and cgi versions you can often
get away with putting the php.ini file in the same dir as the
executable and it will find it there.

- James


Previous Comments:


[2002-09-24 17:03:32] [EMAIL PROTECTED]

Same issue. However, its it a requirement that the php directory be on
the c: drive?

I have the same problem with any php version I install on the Win2k
Server.



[2002-09-21 14:27:49] [EMAIL PROTECTED]

try changing 'c:\php\extensions' to 'c:\\php\\extensions' or
'c:/php/extensions' and see if it begins to work.



[2002-09-16 08:32:29] [EMAIL PROTECTED]

Oh yeah, I forgot to add that all the pertinent files for this
extension are in the %system% directory!



[2002-09-16 08:29:45] [EMAIL PROTECTED]

To mficher:

If you can give me some cookbook instructions on how to use this tool,
then I would be glad to give it a try.  It looks as though it needs a
running process, but the error occurs when I start IIS.  How can I
accomplish what you need?



[2002-09-16 03:24:32] [EMAIL PROTECTED]

Is there a chance to use the strace tool [1] to track what's going
on/wrong here? This tool may help tracking down which directory/files
are really accessed.

[1] http://razor.bindview.com/tools/desc/strace_readme.html



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

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

#19584 [Com]: ob_implicit_flush may not be working


 ID:   19584
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Sockets related
 Operating System: Windows 2000 Advanced Server IIS
 PHP Version:  4.2.3
 New Comment:

Now I can't get it working in 4.2.2 anymore

Probably my configuration then... Always works with 4.1.2 though, so
I'm not sure what to think anymore.


Previous Comments:


[2002-09-24 16:54:06] [EMAIL PROTECTED]

I have been running a looping script using php.exe from the
command-line using 4.1.2 to run tasks I pull out of a database. I
needed to use socket_set_timeout but my build of 4.1.2 didn't support
it.

I upgraded to 4.2.2 and my script worked, but socket_set_timeout wasn't
supported in this one either.

So I upgraded to 4.2.3 and now my script doesn't even output anything.
ob_implicit_flush doesn't *seem* to be working.  PHP doesn't echo
anything, it just seems to be hanging in my loop.

Will be easier to explain with a code example:

set_time_limit(0);
ob_implicit_flush();

for(;;)
{
 echo "hello\n";
 sleep(10);
}

This code works just fine in 4.1.2, same for 4.2.2.  But not in 4.2.3.




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

#18670 [Com]: strtotime() bug

2002-09-24 Thread spud


 ID:   18670
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Assigned
 Bug Type: Date/time related
 Operating System: RedHat Linux Linux linux1 2.2.16
 PHP Version:  4.2.2
 Assigned To:  rasmus
 New Comment:

In PHP 4.2.3, the difference between "2" and "next" are still screwy in
strtotime(). I'm trying to parse icalendar recurrence formats, so I
need to calculate things like the "second Monday" in a month. Sample
code below illustrates the difference between "2" and "next" (which
should be identical).

');
echo ('Start date: Sunday, Sep 1 2002');
$first = strtotime('first Monday',$start);
echo ('"First" Monday: '.date('l, M d Y',$first).'');
$oneth = strtotime('1 Monday',$start);
echo ('"1" Monday: '.date('l, M d Y',$oneth).'');
$next = strtotime('next Monday',$start);
echo ('"Next" Monday: '.date('l, M d Y',$next).'');
$twoth = strtotime('2 Monday',$start);
echo ('"2" Monday: '.date('l, M d Y',$twoth).'');
$third = strtotime('third Monday',$start);
echo ('"Third" Monday: '.date('l, M d Y',$third).'');
$threeth = strtotime('3 Monday',$start);
echo ('"3" Monday: '.date('l, M d Y',$threeth).'');
?>


Previous Comments:


[2002-07-31 18:07:05] [EMAIL PROTECTED]

Assigning to rasmus as it sounds like he already knows whats wrong.



[2002-07-31 10:51:09] [EMAIL PROTECTED]

so can we assign this bug to you Rasmus?



[2002-07-31 10:44:11] [EMAIL PROTECTED]

Sebastian, yes, that is because I changed how "next" works based on bug
report #18655

It works correctly for days now, but it does seem like month-handling
is messed up now.  



[2002-07-31 10:39:10] [EMAIL PROTECTED]

The problem is that it adds a full month to the current timestamp.  So
you end up getting the 31st of the next month and some months do not
have 31 days.  I'll need to do some reading to determine if strtotime()
is supposed to pick the beginning of the next month instead, or perhaps
the middle.



[2002-07-31 10:38:50] [EMAIL PROTECTED]

Strange... With PHP4.3.0-dev-20020730 on Compaq Tru64 the output is
"July October December".



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

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

#19423 [Com]: Problem with extension_dir in PHP.ini

2002-09-24 Thread cbrady


 ID:   19423
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: *Web Server problem
 Operating System: Windows 9x/NT/ME/2000/XP
 PHP Version:  4.2.3
 New Comment:

Same issue. However, its it a requirement that the php directory be on
the c: drive?

I have the same problem with any php version I install on the Win2k
Server.


Previous Comments:


[2002-09-21 14:27:49] [EMAIL PROTECTED]

try changing 'c:\php\extensions' to 'c:\\php\\extensions' or
'c:/php/extensions' and see if it begins to work.



[2002-09-16 08:32:29] [EMAIL PROTECTED]

Oh yeah, I forgot to add that all the pertinent files for this
extension are in the %system% directory!



[2002-09-16 08:29:45] [EMAIL PROTECTED]

To mficher:

If you can give me some cookbook instructions on how to use this tool,
then I would be glad to give it a try.  It looks as though it needs a
running process, but the error occurs when I start IIS.  How can I
accomplish what you need?



[2002-09-16 03:24:32] [EMAIL PROTECTED]

Is there a chance to use the strace tool [1] to track what's going
on/wrong here? This tool may help tracking down which directory/files
are really accessed.

[1] http://razor.bindview.com/tools/desc/strace_readme.html



[2002-09-16 02:39:04] [EMAIL PROTECTED]

This also occurs with MicroWeb-Server on Windows. So I reclassified it
to WebServer-Problem.

MicroWeb specific:
Setting the extension_dir is not possible. Specifying a directory in
the php.ini has no affect, although other settings can be configured
fine...
Microweb supports PHP only over CGI-Interface.



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

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

#19584 [NEW]: ob_implicit_flush may not be working


From: [EMAIL PROTECTED]
Operating system: Windows 2000 Advanced Server IIS
PHP version:  4.2.3
PHP Bug Type: Sockets related
Bug description:  ob_implicit_flush may not be working

I have been running a looping script using php.exe from the command-line
using 4.1.2 to run tasks I pull out of a database. I needed to use
socket_set_timeout but my build of 4.1.2 didn't support it.

I upgraded to 4.2.2 and my script worked, but socket_set_timeout wasn't
supported in this one either.

So I upgraded to 4.2.3 and now my script doesn't even output anything.
ob_implicit_flush doesn't *seem* to be working.  PHP doesn't echo
anything, it just seems to be hanging in my loop.

Will be easier to explain with a code example:

set_time_limit(0);
ob_implicit_flush();

for(;;)
{
 echo "hello\n";
 sleep(10);
}

This code works just fine in 4.1.2, same for 4.2.2.  But not in 4.2.3.
-- 
Edit bug report at http://bugs.php.net/?id=19584&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19584&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19584&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19584&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19584&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19584&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19584&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19584&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19584&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19584&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19584&r=globals

#19583 [Com]: Remove is_dst parameter from gmmktime?

2002-09-24 Thread at217


 ID:   19583
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Date/time related
 Operating System: Linux
 PHP Version:  4.2.3
 New Comment:

Here's one way to make the suggested change, if anyone cares to commit
it:

*** datetime.c-orig Tue Sep 24 16:18:27 2002
--- datetime.c  Tue Sep 24 18:35:03 2002
***
*** 83,93 
struct tm *ta, tmbuf;
time_t t;
int i, gmadjust, seconds, arg_count = ZEND_NUM_ARGS();
-   int is_dst = -1;
  
if (arg_count > 7 || zend_get_parameters_array_ex(arg_count,
arguments) == FAILURE) {
WRONG_PARAM_COUNT;
}
/* convert supplied arguments to longs */
for (i = 0; i < arg_count; i++) {
convert_to_long_ex(arguments[i]);
--- 83,97 
struct tm *ta, tmbuf;
time_t t;
int i, gmadjust, seconds, arg_count = ZEND_NUM_ARGS();
  
if (arg_count > 7 || zend_get_parameters_array_ex(arg_count,
arguments) == FAILURE) {
WRONG_PARAM_COUNT;
}
+ if (gm && arg_count == 7) {
+ // TO DO: issue a warning here, but keep going (so
WRONG_PARAM_COUNT won't work)
+ arg_count--;
+ }
+ 
/* convert supplied arguments to longs */
for (i = 0; i < arg_count; i++) {
convert_to_long_ex(arguments[i]);
***
*** 119,125 
*/
switch(arg_count) {
case 7:
!   ta->tm_isdst = is_dst = Z_LVAL_PP(arguments[6]);
/* fall-through */
case 6:
/* special case: 
--- 123,129 
*/
switch(arg_count) {
case 7:
!   ta->tm_isdst = Z_LVAL_PP(arguments[6]);
/* fall-through */
case 6:
/* special case: 
***
*** 169,176 
}
  
seconds = mktime(ta);
-   if (is_dst == -1)
-   is_dst = ta->tm_isdst;
  
if (gm) {
  #if HAVE_TM_GMTOFF
--- 173,178 
***
*** 185,193 
** the value of timezone - 3600 seconds.
*/
  #ifdef __CYGWIN__
!   gmadjust = -(is_dst ? _timezone - 3600 : _timezone);
  #else
!   gmadjust = -(is_dst ? timezone - 3600 : timezone);
  #endif
  #endif
seconds += gmadjust;
--- 187,195 
** the value of timezone - 3600 seconds.
*/
  #ifdef __CYGWIN__
!   gmadjust = -(ta->tm_isdst ? _timezone - 3600 : _timezone);
  #else
!   gmadjust = -(ta->tm_isdst ? timezone - 3600 : timezone);
  #endif
  #endif
seconds += gmadjust;
***
*** 197,203 
  }
  /* }}} */
  
! /* {{{ proto int mktime(int hour, int min, int sec, int mon, int day,
int year)
 Get UNIX timestamp for a date */
  PHP_FUNCTION(mktime)
  {
--- 199,205 
  }
  /* }}} */
  
! /* {{{ proto int mktime(int hour, int min, int sec, int mon, int day,
int year, int is_dst)
 Get UNIX timestamp for a date */
  PHP_FUNCTION(mktime)
  {


Previous Comments:


[2002-09-24 16:39:48] [EMAIL PROTECTED]

Passing anything but -1 for the is_dst argument of gmmktime can result
in times that are off by an hour, if the system's local time zone uses
DST. For example, I assumed that passing 0 would the right thing to do
(not in DST), but if the date falls within my local DST range, the time
I get back is an hour ahead. This is because, internally, PHP calls
mktime and then tries to adjust the local time to GMT.

Of course, this is easy enough to work around, and I will put a note on
the manual page, but I still think the parameter is irrelevant for
gmmktime, and since its use can cause errors, it would be nice if it
were removed, or at least ignored (if one wants to avoid breaking
existing code; although a warning would probably be good).


/* Demostrate problem with gmmktime() */
// These should produce the same value, as GMT has no DST.
echo gmmktime(0, 0, 0, 7, 23, 2002, 0) ."\n";
echo gmmktime(0, 0, 0, 7, 23, 2002) . "\n";





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

#19583 [NEW]: Remove is_dst parameter from gmmktime?

2002-09-24 Thread at217


From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.2.3
PHP Bug Type: Date/time related
Bug description:  Remove is_dst parameter from gmmktime?

Passing anything but -1 for the is_dst argument of gmmktime can result in
times that are off by an hour, if the system's local time zone uses DST.
For example, I assumed that passing 0 would the right thing to do (not in
DST), but if the date falls within my local DST range, the time I get back
is an hour ahead. This is because, internally, PHP calls mktime and then
tries to adjust the local time to GMT.

Of course, this is easy enough to work around, and I will put a note on
the manual page, but I still think the parameter is irrelevant for
gmmktime, and since its use can cause errors, it would be nice if it were
removed, or at least ignored (if one wants to avoid breaking existing
code; although a warning would probably be good).


/* Demostrate problem with gmmktime() */
// These should produce the same value, as GMT has no DST.
echo gmmktime(0, 0, 0, 7, 23, 2002, 0) ."\n";
echo gmmktime(0, 0, 0, 7, 23, 2002) . "\n";

-- 
Edit bug report at http://bugs.php.net/?id=19583&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19583&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19583&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19583&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19583&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19583&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19583&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19583&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19583&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19583&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19583&r=globals

#19552 [Com]: path is always where php was compiled

2002-09-24 Thread sproctor


 ID:   19552
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Apache2 related
 Operating System: linux
 PHP Version:  4.2.3
 New Comment:

it causes php scripts to not run.  the problem isn't that $_ENV['PWD']
is wrong, it's that php looks in the wrong place for files to include.

if I "include 'foo.php';"  it will look for it in
/home/sproctor/php-xxx instead of from the location of the file.

The CGI version works fine, the apache1 version works fine, the apache2
version fails.  It's not too big of a deal for me thought because we
have the CGI version working.

Perhaps it's a bug in apache2, either way PHP seems rather unusable as
an apache2 module right now.

Thanks for the help,
Sean


Previous Comments:


[2002-09-24 15:56:13] [EMAIL PROTECTED]

This might be for one of two reasons, this was the dir you started
apache from, or it might be a bug in apache2. I cannot see how this bug
comes from PHP. 

The variables' and the values for them are taken directly from the
server or environment variables provided to PHP.

Bogusify.

- James



[2002-09-24 15:27:12] [EMAIL PROTECTED]

I tried the latest version.  now $_ENV['PWD'] is just
/home/sproctor/php4-200209240900.  I imagine it's an apache2 issue
because that's the only weird thing I'm doing.  apache2 works fine on
our server for everything else.  I'll try building it as a CGI and see
if that works.



[2002-09-23 05:27:48] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2002-09-22 16:53:11] [EMAIL PROTECTED]

$_ENV['PWD'] always returns /home/sproctor/php-4.2.3 (where php was
compiled).  I expect it to be /var/www/reliance/pn (where the script is
run from).  I compiled php with apxs2 and apache 2.0.40.

It's not just the variable that's wrong, but doing something like
include "filename" will search in /home/sproctor/php-4.2.3, for
clarity.

Thanks!




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

#18022 [NoF->Opn]: fopen does not work with php://stdin anymore


 ID:   18022
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   No Feedback
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: Solaris 8 Sparc
 PHP Version:  4.2.1
-Assigned To:  
+Assigned To:  wez
 New Comment:

I'm keeping this open, as I'm working with someone to verify if the fix
I comitted to HEAD is actually working...


Previous Comments:


[2002-09-21 02:02:05] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2002-08-25 07:04:16] [EMAIL PROTECTED]

I've committed a potential fix for HEAD; I'm not sure if
this can be fixed properly in PHP 4.2.x.
Please verify if the latest unstable snapshot now works
for you.



[2002-08-24 05:55:38] [EMAIL PROTECTED]

Could you check main/php_config.h and see if HAVE_FLUSHIO
is defined?
I think that might be the cause of the problem (and that
this will also be reproduceable with streams in HEAD). 



[2002-08-23 22:05:52] [EMAIL PROTECTED]

Nevermind..I should have read the report twice before replying. The
first script works fine for me when using 
PHP 4.3.0-dev (CLI).

Can you please try it yourself too?

http://snaps.php.net/php4-latest.tar.gz




[2002-08-23 22:03:14] [EMAIL PROTECTED]

The other report didn't get any feedback so I'm opening this one. Seems
to be real problem, at least I couldn't get neither of these scripts to
work.. (or I misunderstood what I shoud pass them? :)




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

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

#16892 [Ver->Fbk]: reading data from fsockopen/fopen times out


 ID:   16892
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Verified
+Status:   Feedback
 Bug Type: Documentation problem
 Operating System: Linux
 PHP Version:  4.2.0
 New Comment:

Can you try a non-stable snapshot from http://snaps.php.net and see if
that behaves a little better?


Previous Comments:


[2002-07-02 16:42:27] [EMAIL PROTECTED]

Hmm...strange combination of OSses, anyway, I can't reproduce this
error with my Redhat-system here, and IMHO the 4th parameter of
fsockopen is sufficiently documented. Still leaving this as "verified" 
(during Bughunt)




[2002-04-29 06:45:01] [EMAIL PROTECTED]

The timeout parameter is the timeout for the connection setup.  To set
a timeout for socket reads/writes, use the socket_set_timeout()
function.
I'm making this a documentation problem, because we don't make this
very clear.



[2002-04-28 22:16:12] [EMAIL PROTECTED]

I'm having trouble reading the data from responses over socket
connections.

For instance, this code (similar to that on the online docs for
fsockopen, example 1),

$fp = fsockopen ("localhost", 80, $errno, $errstr, 10);
if (!$fp) {
echo "$errstr ($errno)\n";
} else {
fputs ($fp, "GET / HTTP/1.0\r\nHost: localhost\r\n\r\n");
while (!feof($fp)) {
echo fread ($fp,128);
}
fclose ($fp);
}

results in a timeout on the fread line (even if I let it run for 300
seconds). I also tried the udp example (example 2,
"fsocketopen("udp://127.0.0.1"...) on the documentation page and had
the same problem. Also note that the fourth parameter to the fsockopen
doesn't seem to be working in this case since this code took 300
seconds to timeout, not the 10 specified. The CPU usage by php went to
100% during the attempted excution of this code.

I have the same problem if I try using fopen to open a web page and
read the data (as in the below code). It always hangs on the fread or
fgets of the file pointer with the response in it. I know the remote
service (e.g., the web server) is actually sending a response string
because I can see it in the server log.

My hardware is a bit unusual. I'm running SuSe linux kernel
2.4.7-SuSe-SMP under VM on an IBM mainframe. I had these errors with
php versions 4.2.0, 4.1.2, and 4.0.6. 

I tried to replicate the problem on an intel box with RedHat 7.2 kernel
2.4.9 and php 4.0.6, but failed. The most abnormal behaviour I could
find on that platform was that "fopen" and then "fread" of remote or
local web pages took *way* too long.

For instance, this code eventually got the desired response, but it
took about 20-24 seconds:

$fp = fopen("http://localhost/";, "r");
$text = fread($fp, 20);
fclose($fp);
echo $text;

If I used fsockopen (e.g., with the first piece of code above) on this
box it ran in less than a second and gave the expected response. 

Any help is much appreciated. I really need to figure out how to read
data over sockets on that first machine.

Thanks,
Graham Warden
[EMAIL PROTECTED]

p.s.
This is somewhat related to my previous bug post (#10996) about a year
ago.




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

#19552 [Opn->Bgs]: path is always where php was compiled


 ID:   19552
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Apache2 related
 Operating System: linux
 PHP Version:  4.2.3
 New Comment:

This might be for one of two reasons, this was the dir you started
apache from, or it might be a bug in apache2. I cannot see how this bug
comes from PHP. 

The variables' and the values for them are taken directly from the
server or environment variables provided to PHP.

Bogusify.

- James


Previous Comments:


[2002-09-24 15:27:12] [EMAIL PROTECTED]

I tried the latest version.  now $_ENV['PWD'] is just
/home/sproctor/php4-200209240900.  I imagine it's an apache2 issue
because that's the only weird thing I'm doing.  apache2 works fine on
our server for everything else.  I'll try building it as a CGI and see
if that works.



[2002-09-23 05:27:48] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2002-09-22 16:53:11] [EMAIL PROTECTED]

$_ENV['PWD'] always returns /home/sproctor/php-4.2.3 (where php was
compiled).  I expect it to be /var/www/reliance/pn (where the script is
run from).  I compiled php with apxs2 and apache 2.0.40.

It's not just the variable that's wrong, but doing something like
include "filename" will search in /home/sproctor/php-4.2.3, for
clarity.

Thanks!




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

#19582 [Opn->Csd]: Easier Heredoc mode


 ID:   19582
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: Debian GNU/Linux
 PHP Version:  4.2.3
 New Comment:

I dont think this syntax is particularly intuative and would lead to a
lot of very ugly code.

Remember you only ever write the code once but you are likley to read
it many times (fixing bugs etc) so you are better off spending a bit
more time writing it and making it easier to understand.

Many thanks for your thoughts,

- James


Previous Comments:


[2002-09-24 15:39:47] [EMAIL PROTECTED]

Hello,

First of all, I would like to say (as hundreds of people says to you
each day) that you're all doing a GREAT JOB !

I feel kinda stupid to ask you to consider this feature request, so
please consider this as the only thing PHP should include to make my
little person very very happy :))

Here's the point :
When dealing html which is not mine but generated by a graphist who use
dreamweaver or something, I spent a lot of time (and I think lot of
people too) quoting, cleaning, line breaking html code. This happens
for parts of code which have to be repeated and have to contains output
of variables and functions.

Then I discovered while reading the doc :) that php has perl- like
HEREDOC mode. It sound cool !
I'm using this mode a lot, but when I want to output the result of a
function, i'm forced to go out of the heredoc mode, or set a variable
with the result of the function before using heredoc mode, and I think
the code is getting ugly when doing this.

I think the heredoc mode would be very very cool if it was python like.
I should use something like that.

echo """ Some html lines, $var $var2 
more html
more $vars """ . function_output() . """ more html ...""";

This would be very cool. But php is already very very cool !!

Again, thanks you all for keeping this great job !!





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

#19362 [Opn->Bgs]: mktime return bad date

2002-09-24 Thread iliaa


 ID:   19362
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Date/time related
 Operating System: Solaris 8
 PHP Version:  4.2.2
 New Comment:

Cannot replicate on Solaris,Linux or Windows.


Previous Comments:


[2002-09-24 15:40:44] [EMAIL PROTECTED]

On Solaris 8 (SPARC) with 4.2.3, I'm getting

103284 = mktime(0,0,0,09,24,2002)
103284 = mktime(0,0,0,09,24,2002)

Which is what I'd expect, is it not?

J



[2002-09-11 13:47:54] [EMAIL PROTECTED]

This code is supposed to return the same output in the two "echos"
because we simple take the date from the S.O. then I split it in the
variables for day, month and year and then when we create the date
again from this very same value it gives the wrong output in a Solaris
8 machine with php 4.2.2 and 4.2.3

It works ok in Solaris 7 and php 4.1.1


$FechaDeHoy = mktime(0,0,0,$tm,$td,$ta)";

$td = gmdate("d",$FechaDeHoy);
$tm = gmdate("m",$FechaDeHoy);
$ta = gmdate("Y",$FechaDeHoy);
$FechaDeHoy = mktime(0,0,0,$tm,$td,$ta);
echo "$FechaDeHoy = mktime(0,0,0,$tm,$td,$ta)";

?>




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

#19362 [Com]: mktime return bad date

2002-09-24 Thread dark_panda


 ID:   19362
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Date/time related
 Operating System: Solaris 8
 PHP Version:  4.2.2
 New Comment:

On Solaris 8 (SPARC) with 4.2.3, I'm getting

103284 = mktime(0,0,0,09,24,2002)
103284 = mktime(0,0,0,09,24,2002)

Which is what I'd expect, is it not?

J


Previous Comments:


[2002-09-11 13:47:54] [EMAIL PROTECTED]

This code is supposed to return the same output in the two "echos"
because we simple take the date from the S.O. then I split it in the
variables for day, month and year and then when we create the date
again from this very same value it gives the wrong output in a Solaris
8 machine with php 4.2.2 and 4.2.3

It works ok in Solaris 7 and php 4.1.1


$FechaDeHoy = mktime(0,0,0,$tm,$td,$ta)";

$td = gmdate("d",$FechaDeHoy);
$tm = gmdate("m",$FechaDeHoy);
$ta = gmdate("Y",$FechaDeHoy);
$FechaDeHoy = mktime(0,0,0,$tm,$td,$ta);
echo "$FechaDeHoy = mktime(0,0,0,$tm,$td,$ta)";

?>




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

#19582 [NEW]: Easier Heredoc mode

2002-09-24 Thread agr


From: [EMAIL PROTECTED]
Operating system: Debian GNU/Linux
PHP version:  4.2.3
PHP Bug Type: Feature/Change Request
Bug description:  Easier Heredoc mode

Hello,

First of all, I would like to say (as hundreds of people says to you each
day) that you're all doing a GREAT JOB !

I feel kinda stupid to ask you to consider this feature request, so please
consider this as the only thing PHP should include to make my little
person very very happy :))

Here's the point :
When dealing html which is not mine but generated by a graphist who use
dreamweaver or something, I spent a lot of time (and I think lot of people
too) quoting, cleaning, line breaking html code. This happens for parts of
code which have to be repeated and have to contains output of variables
and functions.

Then I discovered while reading the doc :) that php has perl- like HEREDOC
mode. It sound cool !
I'm using this mode a lot, but when I want to output the result of a
function, i'm forced to go out of the heredoc mode, or set a variable with
the result of the function before using heredoc mode, and I think the code
is getting ugly when doing this.

I think the heredoc mode would be very very cool if it was python like. I
should use something like that.

echo """ Some html lines, $var $var2 
more html
more $vars """ . function_output() . """ more html ...""";

This would be very cool. But php is already very very cool !!

Again, thanks you all for keeping this great job !!

-- 
Edit bug report at http://bugs.php.net/?id=19582&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19582&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19582&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19582&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19582&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19582&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19582&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19582&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19582&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19582&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19582&r=globals

#19552 [Fbk->Opn]: path is always where php was compiled

2002-09-24 Thread sproctor


 ID:   19552
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: linux
 PHP Version:  4.2.3
 New Comment:

I tried the latest version.  now $_ENV['PWD'] is just
/home/sproctor/php4-200209240900.  I imagine it's an apache2 issue
because that's the only weird thing I'm doing.  apache2 works fine on
our server for everything else.  I'll try building it as a CGI and see
if that works.


Previous Comments:


[2002-09-23 05:27:48] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2002-09-22 16:53:11] [EMAIL PROTECTED]

$_ENV['PWD'] always returns /home/sproctor/php-4.2.3 (where php was
compiled).  I expect it to be /var/www/reliance/pn (where the script is
run from).  I compiled php with apxs2 and apache 2.0.40.

It's not just the variable that's wrong, but doing something like
include "filename" will search in /home/sproctor/php-4.2.3, for
clarity.

Thanks!




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

#14483 [Com]: -twolevel_namespace and multiple definitions errors


 ID:   14483
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: Mac OS X 10.1
 PHP Version:  4.2.0-dev
 New Comment:

Eveything I did was in root (su)...

system.log shows:
Sep 24 11:31:00 path046 SystemStarter: Apache web server 
(446) did not complete successfully. 

httpd/error_log shows nothing significant (previous errors 
when running).

I'll look into pear I suppose...

Brian


Previous Comments:


[2002-09-24 13:25:58] [EMAIL PROTECTED]

Eveything I did was in root (su)...

system.log shows:
Sep 24 11:31:00 path046 SystemStarter: Apache web server 
(446) did not complete successfully. 

httpd/error_log shows nothing significant (previous errors 
when running).

I'll look into pear I suppose...

Brian



[2002-09-24 12:59:13] [EMAIL PROTECTED]

Thanks for pointing me to snaps! Config went much 
smoother, however I get the following error from Apache:

[path046:/Users/bripakes] bripakes# apachectl start
Syntax error on line 242 of /etc/httpd/httpd.conf:
Cannot load /usr/libexec/httpd/libphp4.so into server: 
(reason unknown)
/usr/sbin/apachectl start: httpd could not be started

I noticed the owner and group were different so I changed 
them to root/wheel. And PEAR gave me errors so I used 
--disable-pear in my config.

Any ideas?



[2002-09-24 12:15:58] [EMAIL PROTECTED]

I notice you're logged in as "bripakes".  I think you need to be "root"
to control apache, and it's even best if you install it as "root". 
Forget "sudo" and all of that happy bull.  Just "su" and do what you
need to do, then go back to being a normal user.  If you're still
confused, read the following logs, they should provide some guidance:

tail -50 /var/log/system.log
tail -50 /var/log/httpd/error_log

-Abner



[2002-09-24 12:07:38] [EMAIL PROTECTED]

Thanks for pointing me to snaps! Config went much 
smoother, however I get the following error from Apache:

[path046:/Users/bripakes] bripakes# apachectl start
Syntax error on line 242 of /etc/httpd/httpd.conf:
Cannot load /usr/libexec/httpd/libphp4.so into server: 
(reason unknown)
/usr/sbin/apachectl start: httpd could not be started

I noticed the owner and group were different so I changed 
them to root/wheel. And PEAR gave me errors so I used 
--disable-pear in my config.

Any ideas?



[2002-09-23 13:48:54] [EMAIL PROTECTED]

Use PHP 4.3.0-dev from http://snaps.php.net

http://panther.criticalnexus.com/info.php

-Abner



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

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

#19275 [Opn->Csd]: socket_create causes seg fault / unaligned trap

2002-09-24 Thread jason


 ID:   19275
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Sockets related
 Operating System: Debian2.2r3 on Alpha, ker.2.2.19
 PHP Version:  4.2.3
 New Comment:

I tested this on Debian 3.0 Linux 2.4.18-smp Alpha DS20, and was not
able to reproduce the problem. The place at which your debugger is
reporting that php is dying, should not trigger a segfault. You have a
compiler or os problem.

Thanks,
-Jason



Previous Comments:


[2002-09-08 08:34:38] [EMAIL PROTECTED]

>  ID:   19275
>  Updated by:   [EMAIL PROTECTED]
>  Reported By:  [EMAIL PROTECTED]
> -Status:   Open
> +Status:   Feedback
>  Bug Type: Sockets related
>  Operating System: Debian2.2r3 on Alpha, ker.2.2.19
>  PHP Version:  4.2.3
>  New Comment:
> 
> Please try using this CVS snapshot:
> 
>   http://snaps.php.net/php4-latest.tar.gz
>  
> For Windows:
>  
>   http://snaps.php.net/win32/php4-win32-latest.zip
> 
> The sockets code in CVS is much different than what you've got.  With
a
> 4.3.0 coming soon, it would be good to see if this continues to be a
> problem for you.

I just tried, unfortunaly, the problem remain the same. Here are the
details.

The version I used: php4-200209080300

$ ./php -v
php(14837): unaligned trap at 000120295990: 00012043653c 2d 1
php(14837): unaligned trap at 000120295990: 00012043503c 2d 1
PHP 4.3.0-dev (cgi), Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies

(note the unaligned trap, that do no exist with the stable versions)

My config is quite the same, I just removed MySQL support because it
causes a
compilation problem which has probably nothing to do with our problem)

$ cat configure-php4-200209080300-1.sh
#!/bin/sh

  ../php4-200209080300/configure\
 --with-zlib\
 --enable-calendar  \
 --enable-dbase \
 --enable-ftp   \
 --with-gd=/usr \
 --with-jpeg-dir=/usr   \
 --with-png-dir=/usr\
 --enable-gd-native-ttf \
 --with-freetype-dir=/usr/local \
 --with-pdflib  \
 --enable-exif  \
 --enable-sockets   \
 --enable-pcntl \
 --enable-debug

$ cat ../socket_create.php


$ ./php -q ../socket_create.php
php(14840): unaligned trap at 000120295990: 00012043653c 2d 1
php(14840): unaligned trap at 000120295990: 00012043503c 2d 1
Erreur de segmentation [segmentation fault]

(gdb) run -q ../socket_create.php
Starting program: /home/fric/make/php-standalone/build/./php -q
../socket_create.php
php(14844): unaligned trap at 000120295990: 00012043653c 2d 1
php(14844): unaligned trap at 000120295990: 00012043503c 2d 1

Program received signal SIGSEGV, Segmentation fault.
0x1201325e0 in zif_socket_create (ht=3, return_value=0x1204b58c0,
this_ptr=0x0, return_value_used=1)
at
/home/fric/make/php-standalone/php4-200209080300/ext/sockets/sockets.c:931
931 php_sock->bsd_socket = socket(arg1, arg2, arg3);

(gdb) bt
#0  0x1201325e0 in zif_socket_create (ht=3, return_value=0x1204b58c0,
this_ptr=0x0, return_value_used=1)
at
/home/fric/make/php-standalone/php4-200209080300/ext/sockets/sockets.c:931
#1  0x12029c6a8 in execute (op_array=0x1204b5a30)
at
/home/fric/make/php-standalone/php4-200209080300/Zend/zend_execute.c:1602#2
 0x12027de40 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at
/home/fric/make/php-standalone/php4-200209080300/Zend/zend.c:814
#3  0x12022c888 in php_execute_script (primary_file=0x11998)
at
/home/fric/make/php-standalone/php4-200209080300/main/main.c:1510
#4  0x1202a53bc in main (argc=3, argv=0x11be8)
at
/home/fric/make/php-standalone/php4-200209080300/sapi/cgi/cgi_main.c:1046

With best regard

Fabrice Haberer-Proust

Proust Media
Kerngasse 3/1
79576 Weil am Rhein
Germany



[2002-09-07 21:03:32] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

The sockets code in CVS is much different than what you've got.  With a
4.3.0 coming soon, it would be good to see if this continues to be a
problem for you.



[2002-09-07 06:46:42] [EMAIL PROTECTED]

I cannot use the socket_create function on my Alpha, I only get a
segmentation fault. I already noticed this problem with  
PHP4.2.2.

$ cat socket_create.php 


$ build/php -q socket_create.php
ph

#19581 [Opn->Bgs]: Time for PHP to document regular expression syntax

2002-09-24 Thread rasmus


 ID:   19581
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Documentation problem
 Operating System: All
 PHP Version:  4.2.3
 New Comment:

Well, we also don't document SQL or most other features that come from
external libraries/packages.  There is nothing PHP-specific about the
regular expressions on PHP.  The preg_* syntax is documented at
http://www.pcre.org/man.txt and the ereg_* is straight POSIX 1003.2
which is widely documented.  If someone was to sit down and write
better regular expression docs, then they would probably not end up in
the php docs anyway but rather at pcre.org or as an addendum to the
POSIX spec.


Previous Comments:


[2002-09-24 13:16:02] [EMAIL PROTECTED]

The exact page to which I am referring is:

http://www.php.net/manual/en/ref.regex.php



[2002-09-24 13:06:41] [EMAIL PROTECTED]

I know maybe nobody wants to take on the task of properly documenting
regular expressions, but, hey, is the following (taken from the PHP
site documentation) REALLY the best that can be done:

"PHP uses the POSIX extended regular expressions as defined by POSIX
1003.2. For a full description of POSIX regular expressions see the
regex man pages included in the regex directory in the PHP
distribution. It's in manpage format, so you'll want to do something
along the lines of man /usr/local/src/regex/regex.7 in order to read
it."

I simply think that the described document, or at least the essence of
its contents, should be included on the website.

I am, I think, a typical PHP user - I use PHP, and when I want
documentation on a PHP item, I go to the PHP website.  To be greeted by
such statements is absurd.  Even if I thought I understood what it was
suggesting, you seriously cannot be expecting the average PHP
programmer to really do what is suggested?

Regular expressions are voodoo as it is, without making the eager new
magician perform fantastic magic even to be able to find the book of
spells.

Generally, the PHP documentation is fantastic.  The search facility is
wonderful.  It is well structured.  It is comprehensive.  It is
complete.

But this part on regular expressions is abysmal.

Specifically, what I would like to see (I have never seen the above
documentation, so I don't know what is in it), is a proper description
of each of the possible values within a regular expression, including
the 'magic' values like [:alphanum:], with plenty of good examples.

It perhaps needs several pages organised in a structured way to cover
the complex topic.

I understand when faced with the task, the early documenters held their
hands up in horror at the large task.  But, in my humble opinion, this
is a gaping hole in an otherwise excellent documentation.  I say it is
time for the hole to be filled.

Thanks!


Hugh Prior




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

#14483 [Com]: -twolevel_namespace and multiple definitions errors


 ID:   14483
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: Mac OS X 10.1
 PHP Version:  4.2.0-dev
 New Comment:

Eveything I did was in root (su)...

system.log shows:
Sep 24 11:31:00 path046 SystemStarter: Apache web server 
(446) did not complete successfully. 

httpd/error_log shows nothing significant (previous errors 
when running).

I'll look into pear I suppose...

Brian


Previous Comments:


[2002-09-24 12:59:13] [EMAIL PROTECTED]

Thanks for pointing me to snaps! Config went much 
smoother, however I get the following error from Apache:

[path046:/Users/bripakes] bripakes# apachectl start
Syntax error on line 242 of /etc/httpd/httpd.conf:
Cannot load /usr/libexec/httpd/libphp4.so into server: 
(reason unknown)
/usr/sbin/apachectl start: httpd could not be started

I noticed the owner and group were different so I changed 
them to root/wheel. And PEAR gave me errors so I used 
--disable-pear in my config.

Any ideas?



[2002-09-24 12:15:58] [EMAIL PROTECTED]

I notice you're logged in as "bripakes".  I think you need to be "root"
to control apache, and it's even best if you install it as "root". 
Forget "sudo" and all of that happy bull.  Just "su" and do what you
need to do, then go back to being a normal user.  If you're still
confused, read the following logs, they should provide some guidance:

tail -50 /var/log/system.log
tail -50 /var/log/httpd/error_log

-Abner



[2002-09-24 12:07:38] [EMAIL PROTECTED]

Thanks for pointing me to snaps! Config went much 
smoother, however I get the following error from Apache:

[path046:/Users/bripakes] bripakes# apachectl start
Syntax error on line 242 of /etc/httpd/httpd.conf:
Cannot load /usr/libexec/httpd/libphp4.so into server: 
(reason unknown)
/usr/sbin/apachectl start: httpd could not be started

I noticed the owner and group were different so I changed 
them to root/wheel. And PEAR gave me errors so I used 
--disable-pear in my config.

Any ideas?



[2002-09-23 13:48:54] [EMAIL PROTECTED]

Use PHP 4.3.0-dev from http://snaps.php.net

http://panther.criticalnexus.com/info.php

-Abner



[2002-09-23 13:10:49] [EMAIL PROTECTED]

PHP 4.2.3 fails 'make install' with:

Making install in .
/usr/src/php-4.2.3/build/shtool mkdir -p "/usr/libexec/
httpd" && apxs -S LIBEXECDIR="/usr/libexec/httpd" -i -a -n 
php4 libs/libphp4.dylib
apxs:Error: file libs/libphp4.dylib is not a DSO
make[1]: *** [install-sapi] Error 1
make: *** [install-recursive] Error 1

Any suggestions?

I'm using 10.2.1 with Apache 1.3.26 (Darwin), Sybase 12.5, 
and PHP 4.2.3...

Tried both Marc Liyanage's site and Tenon's iTools site 
instructions, and both give same error...

Bri



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

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

#19581 [Opn]: Time for PHP to document regular expression syntax

2002-09-24 Thread phpbugs


 ID:   19581
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Documentation problem
 Operating System: All
 PHP Version:  4.2.3
 New Comment:

The exact page to which I am referring is:

http://www.php.net/manual/en/ref.regex.php


Previous Comments:


[2002-09-24 13:06:41] [EMAIL PROTECTED]

I know maybe nobody wants to take on the task of properly documenting
regular expressions, but, hey, is the following (taken from the PHP
site documentation) REALLY the best that can be done:

"PHP uses the POSIX extended regular expressions as defined by POSIX
1003.2. For a full description of POSIX regular expressions see the
regex man pages included in the regex directory in the PHP
distribution. It's in manpage format, so you'll want to do something
along the lines of man /usr/local/src/regex/regex.7 in order to read
it."

I simply think that the described document, or at least the essence of
its contents, should be included on the website.

I am, I think, a typical PHP user - I use PHP, and when I want
documentation on a PHP item, I go to the PHP website.  To be greeted by
such statements is absurd.  Even if I thought I understood what it was
suggesting, you seriously cannot be expecting the average PHP
programmer to really do what is suggested?

Regular expressions are voodoo as it is, without making the eager new
magician perform fantastic magic even to be able to find the book of
spells.

Generally, the PHP documentation is fantastic.  The search facility is
wonderful.  It is well structured.  It is comprehensive.  It is
complete.

But this part on regular expressions is abysmal.

Specifically, what I would like to see (I have never seen the above
documentation, so I don't know what is in it), is a proper description
of each of the possible values within a regular expression, including
the 'magic' values like [:alphanum:], with plenty of good examples.

It perhaps needs several pages organised in a structured way to cover
the complex topic.

I understand when faced with the task, the early documenters held their
hands up in horror at the large task.  But, in my humble opinion, this
is a gaping hole in an otherwise excellent documentation.  I say it is
time for the hole to be filled.

Thanks!


Hugh Prior




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

#19569 [Com]: urlencode() problem encoding strings containing single quotes

2002-09-24 Thread dbarndt


 ID:   19569
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: *URL Functions
 Operating System: Windows NT 4.0 SP6
 PHP Version:  4.2.3
 New Comment:

Thanks for the reply.  As a C/C++ developer for 13 years, but having
only recently been introduced to PHP, I am painfully well aware of the
joys and pitfalls of printf() functionality, and will look into print()
as you suggested.

Probably because of the late hour, I neglected to check the log or
support site.  So much for my first PHP bug submission.  I thought it
was probably something stupid.  My apologies for wasting your valuable
time.


Previous Comments:


[2002-09-24 03:02:51] [EMAIL PROTECTED]

Sorry, but the bug system is not the appropriate forum for asking
support questions. 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

Thank you for your interest in PHP.

do not use printf unless you know what you are doing,
use plain print or echo instead

*and* please have a look at your error log first
before reporting problems

you would have seen a message like

  Warning:  printf(): too few arguments in ... on line 9

due to the fact that urlencode() converts your string to
"Mickey%27s+Fun+House", so requesting to output the 2nd parameter (not
given here) as a 27 character wide string

see http://php.net/print and http://php.net/print for 
the different semantics of print() and printf()



[2002-09-24 02:03:33] [EMAIL PROTECTED]

fixed typo in title



[2002-09-24 02:01:29] [EMAIL PROTECTED]

I really hesitated putting this in as a bug, because it seems so
simple.  The urlencode() documentation seems to imply that the
following script should work fine, however it fails to output the
second printf() on my system.  I am running with the
php.ini-recommended INI file on Windows NT 4.0 SP6.  (I've tried
various combinations of htmlentities() and htmlspecialchars() with the
urlencode() as well, but so far without success.)

Here's the script:









If this is something stupid on my end, I apologize for the bother.

Thanks,
Dave Barndt




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

#19581 [NEW]: Time for PHP to document regular expression syntax

2002-09-24 Thread phpbugs


From: [EMAIL PROTECTED]
Operating system: All
PHP version:  4.2.3
PHP Bug Type: Documentation problem
Bug description:  Time for PHP to document regular expression syntax

I know maybe nobody wants to take on the task of properly documenting
regular expressions, but, hey, is the following (taken from the PHP site
documentation) REALLY the best that can be done:

"PHP uses the POSIX extended regular expressions as defined by POSIX
1003.2. For a full description of POSIX regular expressions see the regex
man pages included in the regex directory in the PHP distribution. It's in
manpage format, so you'll want to do something along the lines of man
/usr/local/src/regex/regex.7 in order to read it."

I simply think that the described document, or at least the essence of its
contents, should be included on the website.

I am, I think, a typical PHP user - I use PHP, and when I want
documentation on a PHP item, I go to the PHP website.  To be greeted by
such statements is absurd.  Even if I thought I understood what it was
suggesting, you seriously cannot be expecting the average PHP programmer
to really do what is suggested?

Regular expressions are voodoo as it is, without making the eager new
magician perform fantastic magic even to be able to find the book of
spells.

Generally, the PHP documentation is fantastic.  The search facility is
wonderful.  It is well structured.  It is comprehensive.  It is complete.

But this part on regular expressions is abysmal.

Specifically, what I would like to see (I have never seen the above
documentation, so I don't know what is in it), is a proper description of
each of the possible values within a regular expression, including the
'magic' values like [:alphanum:], with plenty of good examples.

It perhaps needs several pages organised in a structured way to cover the
complex topic.

I understand when faced with the task, the early documenters held their
hands up in horror at the large task.  But, in my humble opinion, this is
a gaping hole in an otherwise excellent documentation.  I say it is time
for the hole to be filled.

Thanks!


Hugh Prior
-- 
Edit bug report at http://bugs.php.net/?id=19581&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19581&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19581&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19581&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19581&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19581&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19581&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19581&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19581&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19581&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19581&r=globals

#19207 [Fbk->Opn]: php-cgi.exe does not correctly set HTTP status

2002-09-24 Thread Wendell


 ID:   19207
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: IIS related
 Operating System: Windows 2000/.Net Server RC1
 PHP Version:  4CVS-2002-08-30
 New Comment:

I'm currently using IIS 6.0 in Windows.Net Server RC1 (build 3663). 
Again, CGI PHP 4.2.2/4.2.3 works fine just not CGI PHP 4.3.0.


Previous Comments:


[2002-09-24 11:48:11] [EMAIL PROTECTED]

what version of IIS are you using.. this works fine on Win XP Pro (No
service pack) so IIS 5.0.

- James
--  
James Moore
[EMAIL PROTECTED]



[2002-09-05 11:22:02] [EMAIL PROTECTED]

Just tried the latest snapshot php4-win32-200209051400.zip and the
issue still exists.  php-cgi.exe returns the following headers:

Status: 401
Content-type: text/html
WWW-authenticate: basic realm=Logon

The correct headers for php-cgi.exe to work in IIS should be:

HTTP/1.1 401 Unauthorized
Content-type: text/html
WWW-authenticate: basic realm=Logon



[2002-09-04 21:30:20] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

I believe there was just a patch submitted that fixes this.  I could be
wrong though too, please test and update if still valid. :\



[2002-08-30 20:09:13] [EMAIL PROTECTED]

The following code fragment works great with PHP 4.2.2 on IIS:

  Header("WWW-authenticate: basic realm=Logon");
  Header("HTTP/1.1 401 Unauthorized");
  echo "\n";
  echo " \n";
  echo " Authorization Required\n";
  echo " \n";
  echo " \n";
  echo "  Invalid username and password with which to access this
webpage.\n";
  echo " \n";
  echo "\n";
  exit;

This code works correctly in 4.2.2.  It sets the status of the page to
401 and makes the browser prompt for the password.

However using php-cgi.exe in the latest 4.3.0 development builds in IIS
the code does not work.  The browser receive a "HTTP/1.1 200 OK"
instead of "HTTP/1.1 401 Unauthorized".  If I simply run the CGI script
from the command prompt using php-cgi.exe in 4.3.0 I get the
following:

Status: 401
Content-type: text/html
WWW-authenticate: basic realm=Logon


 
 Authorization Required
 
 
  Invalid username and password with which to access this
webpage.
 


Running php.exe 4.2.2 from the console I get the following:

HTTP/1.1 401 Unauthorized
Content-type: text/html
WWW-authenticate: basic realm=Logon


 
 Authorization Required
 
 
  Invalid username and password with which to access this
webpage.
 


Noticed that php 4.2.2 correctly returns the HTTP page status as
"HTTP/1.1 401 Unauthorized" and php 4.3.0 only returns the tag "Status:
401".

The new tag "Status: 401" does not work in IIS, it needs to be the full
"HTTP/1.1 401 Unauthorized".




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

#14483 [Com]: -twolevel_namespace and multiple definitions errors


 ID:   14483
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: Mac OS X 10.1
 PHP Version:  4.2.0-dev
 New Comment:

Thanks for pointing me to snaps! Config went much 
smoother, however I get the following error from Apache:

[path046:/Users/bripakes] bripakes# apachectl start
Syntax error on line 242 of /etc/httpd/httpd.conf:
Cannot load /usr/libexec/httpd/libphp4.so into server: 
(reason unknown)
/usr/sbin/apachectl start: httpd could not be started

I noticed the owner and group were different so I changed 
them to root/wheel. And PEAR gave me errors so I used 
--disable-pear in my config.

Any ideas?


Previous Comments:


[2002-09-24 12:15:58] [EMAIL PROTECTED]

I notice you're logged in as "bripakes".  I think you need to be "root"
to control apache, and it's even best if you install it as "root". 
Forget "sudo" and all of that happy bull.  Just "su" and do what you
need to do, then go back to being a normal user.  If you're still
confused, read the following logs, they should provide some guidance:

tail -50 /var/log/system.log
tail -50 /var/log/httpd/error_log

-Abner



[2002-09-24 12:07:38] [EMAIL PROTECTED]

Thanks for pointing me to snaps! Config went much 
smoother, however I get the following error from Apache:

[path046:/Users/bripakes] bripakes# apachectl start
Syntax error on line 242 of /etc/httpd/httpd.conf:
Cannot load /usr/libexec/httpd/libphp4.so into server: 
(reason unknown)
/usr/sbin/apachectl start: httpd could not be started

I noticed the owner and group were different so I changed 
them to root/wheel. And PEAR gave me errors so I used 
--disable-pear in my config.

Any ideas?



[2002-09-23 13:48:54] [EMAIL PROTECTED]

Use PHP 4.3.0-dev from http://snaps.php.net

http://panther.criticalnexus.com/info.php

-Abner



[2002-09-23 13:10:49] [EMAIL PROTECTED]

PHP 4.2.3 fails 'make install' with:

Making install in .
/usr/src/php-4.2.3/build/shtool mkdir -p "/usr/libexec/
httpd" && apxs -S LIBEXECDIR="/usr/libexec/httpd" -i -a -n 
php4 libs/libphp4.dylib
apxs:Error: file libs/libphp4.dylib is not a DSO
make[1]: *** [install-sapi] Error 1
make: *** [install-recursive] Error 1

Any suggestions?

I'm using 10.2.1 with Apache 1.3.26 (Darwin), Sybase 12.5, 
and PHP 4.2.3...

Tried both Marc Liyanage's site and Tenon's iTools site 
instructions, and both give same error...

Bri



[2002-04-23 14:27:26] [EMAIL PROTECTED]

Using the helpful and informative comments on this page I made a patch
which can be applied against the 4.2.0 release source distribution.

The basic 4.2.0 module compiles fine for me with the patch.

It is available at
http://www.entropy.ch/software/macosx/php/php-4.2.0-entropy.ch.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/14483

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

#14971 [Fbk->Ctl]: unhandled exception processing the ISAPI


 ID:   14971
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Critical
 Bug Type: IIS related
 Operating System: WIN2000 server (SP2)
-PHP Version:  4.1.1
+PHP Version:  Latest CVS
 New Comment:

Jani.. Im using latest CVS.

Anyway. A bit more of a probe and I have come up with the following
stack trace (Caused when IIS is under heavy load using the script 



and doing lots and lots of requests

NTDLL! 77f7d293()
_emalloc(unsigned int 256, char * 0x013b7a80 `string', unsigned int 27,
char * 0x, unsigned int 0) line 154 + 62 bytes
zend_stack_init(_zend_stack * 0x018f2ce0) line 27 + 30 bytes
zend_init_compiler_data_structures(void * * * 0x018f1fe0) line 73 + 21
bytes
init_compiler(void * * * 0x018f1fe0) line 100 + 9 bytes
zend_activate(void * * * 0x018f1fe0) line 588 + 9 bytes
php_request_startup(void * * * 0x018f1fe0) line 835 + 9 bytes
HttpExtensionProc(_EXTENSION_CONTROL_BLOCK * 0x00814888) line 756 + 12
bytes
WAM! 5a857a91()
WAM! 5a858634()
W3SVC! 5aa51473()
W3SVC! 5aa51385()
W3SVC! 5aa40a38()
W3SVC! 5aa40bc2()
W3SVC! 5aa4ad47()
W3SVC! 5aa3a6c9()
W3SVC! 5aa39187()
W3SVC! 5aa39416()
ISATQ! 65f18599()
ISATQ! 65f19630()
e877e317()

Havnt particularly looked at this in any depth yet but will do... Back
to critical as IIS is unstable.. although its not critical for all
systems it is for IIS & Windows so its certainly not a show stopper but
needs to be kept in mind and worked on gradually..



Previous Comments:


[2002-09-24 12:07:06] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

There were some thread-safety issues fixed just recently in CVS so
please try the snapshot.




[2002-09-24 12:01:14] [EMAIL PROTECTED]

As normal with these kinda bugs my ISAPI/IIS is rock solid so its very
difficult to track this down. Im moving this bug to critical as it
affects quite a few people. If any of you can compile on your
webservers I would be interested to see if you compile what happens.
Also make sure you always use the latest version of PHP as we are
always fixing Thread Safety issues (To the best of my knowledge this is
probably what is causing this).

Hopefully we can gradually improve performance of the ISAPI extension.
If you have any other information or a short script that seems to cause
it a lot then please add information about it in this bug report.

Also please try unloading extensions from PHP and testing without that
as it might be a thread safety issue in that extension.

Basically until we can get some more concerete information about this
lack of stability its very difficult to track down so anything that may
help is very welcome.

- James



[2002-03-07 04:44:56] [EMAIL PROTECTED]

We already had the php4isapi.dll als ISAPI-Filter included, but
nevertheless it does not work at all.

The crashes are gone for sure, but the new flavour ist that
sporadically the connection to an Oracle Database get's lost somehow,
somewhere, and all my scripts do not work anymore.

The problem occures more often after the server has had a heavy load.

Point is: PHP does not crash anymore, but in order to have a working DB
connection I have to restart the iisadmin-service.

regards,
Bernd



[2002-02-06 09:31:55] [EMAIL PROTECTED]

I was experiencing this type of crashing over and over myself with
win2k SP2.  The solution was to add the ISAPI DLL in the ISAPI Filters
list as well as the App Mappings.  After this ISAPI has been rock
solid.  This is the same solution as in this bug report:
http://bugs.php.net/bug.php?id=15324 .  

Note: I did not do this at first because the PHP Manual specifically
said that I should not do so
(http://www.php.net/manual/en/install.iis.php) unless I needed it for
HTTP Authentication.  Maybe someone should place some errata in the
documentation?



[2002-01-31 07:41:23] [EMAIL PROTECTED]

Hi there,

we've got the same problem too. Even on older Versions of PHP it
appeares from time to time. 4.1.1 creates the same SysLog-Message on
W2k Sp2, but we only use ODBC.
Only NET STOP IISADMIN solves the problem, but from time to time you
need to reboot the machine.

Using the Zend Optimizer or not is not the problem, it is re-creatable
without Zend...

One thing to mention is, that it only appears on querys that are quite
time consuming.

regards,
Bernd



The remainder of the comments for th

#14483 [Csd]: -twolevel_namespace and multiple definitions errors

2002-09-24 Thread abner


 ID:   14483
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: Mac OS X 10.1
 PHP Version:  4.2.0-dev
 New Comment:

I notice you're logged in as "bripakes".  I think you need to be "root"
to control apache, and it's even best if you install it as "root". 
Forget "sudo" and all of that happy bull.  Just "su" and do what you
need to do, then go back to being a normal user.  If you're still
confused, read the following logs, they should provide some guidance:

tail -50 /var/log/system.log
tail -50 /var/log/httpd/error_log

-Abner


Previous Comments:


[2002-09-24 12:07:38] [EMAIL PROTECTED]

Thanks for pointing me to snaps! Config went much 
smoother, however I get the following error from Apache:

[path046:/Users/bripakes] bripakes# apachectl start
Syntax error on line 242 of /etc/httpd/httpd.conf:
Cannot load /usr/libexec/httpd/libphp4.so into server: 
(reason unknown)
/usr/sbin/apachectl start: httpd could not be started

I noticed the owner and group were different so I changed 
them to root/wheel. And PEAR gave me errors so I used 
--disable-pear in my config.

Any ideas?



[2002-09-23 13:48:54] [EMAIL PROTECTED]

Use PHP 4.3.0-dev from http://snaps.php.net

http://panther.criticalnexus.com/info.php

-Abner



[2002-09-23 13:10:49] [EMAIL PROTECTED]

PHP 4.2.3 fails 'make install' with:

Making install in .
/usr/src/php-4.2.3/build/shtool mkdir -p "/usr/libexec/
httpd" && apxs -S LIBEXECDIR="/usr/libexec/httpd" -i -a -n 
php4 libs/libphp4.dylib
apxs:Error: file libs/libphp4.dylib is not a DSO
make[1]: *** [install-sapi] Error 1
make: *** [install-recursive] Error 1

Any suggestions?

I'm using 10.2.1 with Apache 1.3.26 (Darwin), Sybase 12.5, 
and PHP 4.2.3...

Tried both Marc Liyanage's site and Tenon's iTools site 
instructions, and both give same error...

Bri



[2002-04-23 14:27:26] [EMAIL PROTECTED]

Using the helpful and informative comments on this page I made a patch
which can be applied against the 4.2.0 release source distribution.

The basic 4.2.0 module compiles fine for me with the patch.

It is available at
http://www.entropy.ch/software/macosx/php/php-4.2.0-entropy.ch.patch



[2002-04-16 06:16:33] [EMAIL PROTECTED]

It's fixed in CVS, but not for PHP 4.2.x. Only PHP 4.3.x + will support
this.

Derick



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

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

#19580 [NEW]: Warning: incfile() [function.incfile]: 0 bytes of buffered data lost

2002-09-24 Thread neil . doody


From: [EMAIL PROTECTED]
Operating system: FREEBSD 4.7-RELEASE 2
PHP version:  4CVS-2002-09-24
PHP Bug Type: Unknown/Other Function
Bug description:  Warning: incfile() [function.incfile]: 0 bytes of buffered data lost

Running on Apache 2.0.42-Alpha2 with the latest CVS of PHP im getting the
following error that is produced with the code shown below, I have never
had this problem before nad the code has not changed for almost a year now
:-


Warning: incfile() [function.incfile]: 0 bytes of buffered data lost
during conversion to FILE*! in /usr/home/mpfreesc/public_html/index.php on
line 41


Code :-

function incfile($pt_infile) {
global $argv;
global $REMOTE_ADDR;
ob_start();
include($pt_infile);
$pt_ret_str = ob_get_contents();
ob_end_clean();
return $pt_ret_str;
}
-- 
Edit bug report at http://bugs.php.net/?id=19580&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19580&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19580&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19580&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19580&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19580&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19580&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19580&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19580&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19580&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19580&r=globals

#14483 [Com]: -twolevel_namespace and multiple definitions errors


 ID:   14483
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: Mac OS X 10.1
 PHP Version:  4.2.0-dev
 New Comment:

Thanks for pointing me to snaps! Config went much 
smoother, however I get the following error from Apache:

[path046:/Users/bripakes] bripakes# apachectl start
Syntax error on line 242 of /etc/httpd/httpd.conf:
Cannot load /usr/libexec/httpd/libphp4.so into server: 
(reason unknown)
/usr/sbin/apachectl start: httpd could not be started

I noticed the owner and group were different so I changed 
them to root/wheel. And PEAR gave me errors so I used 
--disable-pear in my config.

Any ideas?


Previous Comments:


[2002-09-23 13:48:54] [EMAIL PROTECTED]

Use PHP 4.3.0-dev from http://snaps.php.net

http://panther.criticalnexus.com/info.php

-Abner



[2002-09-23 13:10:49] [EMAIL PROTECTED]

PHP 4.2.3 fails 'make install' with:

Making install in .
/usr/src/php-4.2.3/build/shtool mkdir -p "/usr/libexec/
httpd" && apxs -S LIBEXECDIR="/usr/libexec/httpd" -i -a -n 
php4 libs/libphp4.dylib
apxs:Error: file libs/libphp4.dylib is not a DSO
make[1]: *** [install-sapi] Error 1
make: *** [install-recursive] Error 1

Any suggestions?

I'm using 10.2.1 with Apache 1.3.26 (Darwin), Sybase 12.5, 
and PHP 4.2.3...

Tried both Marc Liyanage's site and Tenon's iTools site 
instructions, and both give same error...

Bri



[2002-04-23 14:27:26] [EMAIL PROTECTED]

Using the helpful and informative comments on this page I made a patch
which can be applied against the 4.2.0 release source distribution.

The basic 4.2.0 module compiles fine for me with the patch.

It is available at
http://www.entropy.ch/software/macosx/php/php-4.2.0-entropy.ch.patch



[2002-04-16 06:16:33] [EMAIL PROTECTED]

It's fixed in CVS, but not for PHP 4.2.x. Only PHP 4.3.x + will support
this.

Derick



[2002-04-16 06:07:16] [EMAIL PROTECTED]

Unfortunately, this doesn't seem fixed in 4.2.0-RC-4.

1. Still getting yytext problems.  The duplicate definitions of "char
*yytext" in zend_ini_scanner and zend_language_scanner still exist. 
One of them has to go.  This is a fatal error.

2. Still getting the crazy amounts of multiply defined errors.  The fix
for this is as explained with the $deplibs business.  This is a fatal
error.

3. Still not compiling the apache module right. Also fatal.

apxs:Error: file libs/libphp4.dylib is not a DSO
make[1]: *** [install-sapi] Error 1
make: *** [install-recursive] Error 1


The only way to make this work is to use the libtool and other stuff
from the 4.0.6 branch, as you guys probably know already, and as
included above.

The struggle continues (?)...



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

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

#14971 [Ctl->Fbk]: unhandled exception processing the ISAPI


 ID:   14971
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Critical
+Status:   Feedback
 Bug Type: IIS related
 Operating System: WIN2000 server (SP2)
 PHP Version:  4.1.1
 New Comment:

Please try using this CVS snapshot:

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

There were some thread-safety issues fixed just recently in CVS so
please try the snapshot.



Previous Comments:


[2002-09-24 12:01:14] [EMAIL PROTECTED]

As normal with these kinda bugs my ISAPI/IIS is rock solid so its very
difficult to track this down. Im moving this bug to critical as it
affects quite a few people. If any of you can compile on your
webservers I would be interested to see if you compile what happens.
Also make sure you always use the latest version of PHP as we are
always fixing Thread Safety issues (To the best of my knowledge this is
probably what is causing this).

Hopefully we can gradually improve performance of the ISAPI extension.
If you have any other information or a short script that seems to cause
it a lot then please add information about it in this bug report.

Also please try unloading extensions from PHP and testing without that
as it might be a thread safety issue in that extension.

Basically until we can get some more concerete information about this
lack of stability its very difficult to track down so anything that may
help is very welcome.

- James



[2002-03-07 04:44:56] [EMAIL PROTECTED]

We already had the php4isapi.dll als ISAPI-Filter included, but
nevertheless it does not work at all.

The crashes are gone for sure, but the new flavour ist that
sporadically the connection to an Oracle Database get's lost somehow,
somewhere, and all my scripts do not work anymore.

The problem occures more often after the server has had a heavy load.

Point is: PHP does not crash anymore, but in order to have a working DB
connection I have to restart the iisadmin-service.

regards,
Bernd



[2002-02-06 09:31:55] [EMAIL PROTECTED]

I was experiencing this type of crashing over and over myself with
win2k SP2.  The solution was to add the ISAPI DLL in the ISAPI Filters
list as well as the App Mappings.  After this ISAPI has been rock
solid.  This is the same solution as in this bug report:
http://bugs.php.net/bug.php?id=15324 .  

Note: I did not do this at first because the PHP Manual specifically
said that I should not do so
(http://www.php.net/manual/en/install.iis.php) unless I needed it for
HTTP Authentication.  Maybe someone should place some errata in the
documentation?



[2002-01-31 07:41:23] [EMAIL PROTECTED]

Hi there,

we've got the same problem too. Even on older Versions of PHP it
appeares from time to time. 4.1.1 creates the same SysLog-Message on
W2k Sp2, but we only use ODBC.
Only NET STOP IISADMIN solves the problem, but from time to time you
need to reboot the machine.

Using the Zend Optimizer or not is not the problem, it is re-creatable
without Zend...

One thing to mention is, that it only appears on querys that are quite
time consuming.

regards,
Bernd



[2002-01-22 10:51:01] [EMAIL PROTECTED]

I have the same problem.  However, I even unloaded all extensions and
the Optimizer thinking that they had to do with it but it still
crashes.



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

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

#14971 [Opn->Ctl]: unhandled exception processing the ISAPI


 ID:   14971
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Critical
 Bug Type: IIS related
 Operating System: WIN2000 server (SP2)
 PHP Version:  4.1.1
 New Comment:

As normal with these kinda bugs my ISAPI/IIS is rock solid so its very
difficult to track this down. Im moving this bug to critical as it
affects quite a few people. If any of you can compile on your
webservers I would be interested to see if you compile what happens.
Also make sure you always use the latest version of PHP as we are
always fixing Thread Safety issues (To the best of my knowledge this is
probably what is causing this).

Hopefully we can gradually improve performance of the ISAPI extension.
If you have any other information or a short script that seems to cause
it a lot then please add information about it in this bug report.

Also please try unloading extensions from PHP and testing without that
as it might be a thread safety issue in that extension.

Basically until we can get some more concerete information about this
lack of stability its very difficult to track down so anything that may
help is very welcome.

- James


Previous Comments:


[2002-03-07 04:44:56] [EMAIL PROTECTED]

We already had the php4isapi.dll als ISAPI-Filter included, but
nevertheless it does not work at all.

The crashes are gone for sure, but the new flavour ist that
sporadically the connection to an Oracle Database get's lost somehow,
somewhere, and all my scripts do not work anymore.

The problem occures more often after the server has had a heavy load.

Point is: PHP does not crash anymore, but in order to have a working DB
connection I have to restart the iisadmin-service.

regards,
Bernd



[2002-02-06 09:31:55] [EMAIL PROTECTED]

I was experiencing this type of crashing over and over myself with
win2k SP2.  The solution was to add the ISAPI DLL in the ISAPI Filters
list as well as the App Mappings.  After this ISAPI has been rock
solid.  This is the same solution as in this bug report:
http://bugs.php.net/bug.php?id=15324 .  

Note: I did not do this at first because the PHP Manual specifically
said that I should not do so
(http://www.php.net/manual/en/install.iis.php) unless I needed it for
HTTP Authentication.  Maybe someone should place some errata in the
documentation?



[2002-01-31 07:41:23] [EMAIL PROTECTED]

Hi there,

we've got the same problem too. Even on older Versions of PHP it
appeares from time to time. 4.1.1 creates the same SysLog-Message on
W2k Sp2, but we only use ODBC.
Only NET STOP IISADMIN solves the problem, but from time to time you
need to reboot the machine.

Using the Zend Optimizer or not is not the problem, it is re-creatable
without Zend...

One thing to mention is, that it only appears on querys that are quite
time consuming.

regards,
Bernd



[2002-01-22 10:51:01] [EMAIL PROTECTED]

I have the same problem.  However, I even unloaded all extensions and
the Optimizer thinking that they had to do with it but it still
crashes.



[2002-01-14 07:12:28] [EMAIL PROTECTED]

I have this problem too...But, 
6 virtual servers work for me, and, the most surprising, given message
appears only on four of six



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

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

#19207 [Opn->Fbk]: php-cgi.exe does not correctly set HTTP status


 ID:   19207
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: IIS related
 Operating System: Windows 2000/.Net Server RC1
 PHP Version:  4CVS-2002-08-30
 New Comment:

what version of IIS are you using.. this works fine on Win XP Pro (No
service pack) so IIS 5.0.

- James
--  
James Moore
[EMAIL PROTECTED]


Previous Comments:


[2002-09-05 11:22:02] [EMAIL PROTECTED]

Just tried the latest snapshot php4-win32-200209051400.zip and the
issue still exists.  php-cgi.exe returns the following headers:

Status: 401
Content-type: text/html
WWW-authenticate: basic realm=Logon

The correct headers for php-cgi.exe to work in IIS should be:

HTTP/1.1 401 Unauthorized
Content-type: text/html
WWW-authenticate: basic realm=Logon



[2002-09-04 21:30:20] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

I believe there was just a patch submitted that fixes this.  I could be
wrong though too, please test and update if still valid. :\



[2002-08-30 20:09:13] [EMAIL PROTECTED]

The following code fragment works great with PHP 4.2.2 on IIS:

  Header("WWW-authenticate: basic realm=Logon");
  Header("HTTP/1.1 401 Unauthorized");
  echo "\n";
  echo " \n";
  echo " Authorization Required\n";
  echo " \n";
  echo " \n";
  echo "  Invalid username and password with which to access this
webpage.\n";
  echo " \n";
  echo "\n";
  exit;

This code works correctly in 4.2.2.  It sets the status of the page to
401 and makes the browser prompt for the password.

However using php-cgi.exe in the latest 4.3.0 development builds in IIS
the code does not work.  The browser receive a "HTTP/1.1 200 OK"
instead of "HTTP/1.1 401 Unauthorized".  If I simply run the CGI script
from the command prompt using php-cgi.exe in 4.3.0 I get the
following:

Status: 401
Content-type: text/html
WWW-authenticate: basic realm=Logon


 
 Authorization Required
 
 
  Invalid username and password with which to access this
webpage.
 


Running php.exe 4.2.2 from the console I get the following:

HTTP/1.1 401 Unauthorized
Content-type: text/html
WWW-authenticate: basic realm=Logon


 
 Authorization Required
 
 
  Invalid username and password with which to access this
webpage.
 


Noticed that php 4.2.2 correctly returns the HTTP page status as
"HTTP/1.1 401 Unauthorized" and php 4.3.0 only returns the tag "Status:
401".

The new tag "Status: 401" does not work in IIS, it needs to be the full
"HTTP/1.1 401 Unauthorized".




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

#17957 [Ver->Csd]: Empty backreferences broken

2002-09-24 Thread iliaa


 ID:   17957
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Verified
+Status:   Closed
 Bug Type: Regexps related
 Operating System: Linux 2.2.19
 PHP Version:  4.3.0-dev
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2002-07-09 08:04:36] [EMAIL PROTECTED]

reproduced.




[2002-07-09 06:34:22] [EMAIL PROTECTED]

Tried it with 4.3.0-dev downloaded from CVS this morning
and result is same. (Not sure if this is same as 
http://snaps.php.net?)



[2002-06-25 07:02:47] [EMAIL PROTECTED]

Can you try the latest snapshot from http://snaps.php.net, I think this
has been fixed.



[2002-06-24 18:08:45] [EMAIL PROTECTED]



produces:
a
b
a
\1b

should produce:
a
b
a
b

'./configure' '--with-apxs=/usr/sbin/apxs'
'--with-config-file-path=/usr/lib' '--with-curl'
'--with-pdflib=shared' '--with-mcrypt' '--with-pcre' '--with-dom'
'--with-pear' '--with-xml=shared' '--with-zlib-dir=/usr'
'--prefix=/usr' '--enable-debug=no' '--enable-safe-mode'
'--with-exec-dir=/usr/bin' '--with-mysql=/usr' '--with-regex=system'




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

#19578 [Com]: php_master_value not changeable with php_value

2002-09-24 Thread a . waller


 ID:   19578
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: PHP options/info functions
 Operating System: Linux
 PHP Version:  4.2.2
 New Comment:

I use apache 1.3.26. 
And, yes maybee I have misunderstood this command. But after re-reading
docs I understand it the same way.
Session autostart works. 
The master values in phpinfo() are only set by php.ini.
Shouldn´t they be set with php_master_* ?
And why can´t I overwrite a set php_master_value with php_value in a
virtualhost setting ?!

I can change a php_value in a virtualhost section if I don´t have set
this value with php_master_value.
Why ?


Previous Comments:


[2002-09-24 10:50:03] [EMAIL PROTECTED]

You propably have misunderstood what the master/local values mean.
Better question is: Does it work? (are session started automatically?)




[2002-09-24 10:08:19] [EMAIL PROTECTED]

Do you happen to run Apache 2? If so, try a snapshot from
http://snaps.php.net as this might have been fixed.



[2002-09-24 09:01:04] [EMAIL PROTECTED]

Hi !
I set 
  php_admin_flag session.auto_start on 
in httpd.conf !
I wanted to turn it of in a VirtualHost section with
  php_flag session.auto_start off !
In php.ini there is :
session.auto_start off
 
phpinfo() shows for session.auto_start
LocalValue : on
MasterValue : off

I seems to if i cannot change a value that´s been set by
php_master_value. 
Alex.




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

#19572 [Opn->Bgs]: Compilation fails with undefined reference to `__log1p'


 ID:   19572
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Linux (Suse 6.1)
 PHP Version:  4.2.3
 New Comment:

It has compiled fine with that older (?) version too.
You just had something missing in your system.



Previous Comments:


[2002-09-24 08:47:34] [EMAIL PROTECTED]

Upgrading gcc to version 2.95.3 has solved the problem.

Maybe something should be added to the FAQ to indicate that it won't
compile properly on older versions. The version I was using BTW was the
version installed with Suse 6.1 not something I added afterwards.



[2002-09-24 08:11:39] [EMAIL PROTECTED]

Can compile other stuff without problems - in fact I upgraded apache on
the machine just prior to attempting to compile php.

I have just installed gcc 2.95.3 on there and am in the process of
retrying php. I'll let you know if that fixes the problem.



[2002-09-24 06:21:41] [EMAIL PROTECTED]

Forgot to ask: Are you able to compile anything else? Do you have the
kernel headers links correctly set?




[2002-09-24 06:20:47] [EMAIL PROTECTED]

There might be something wrong (or missing) in your system.
Could you try installing GCC 2.95.3 ?




[2002-09-24 04:16:28] [EMAIL PROTECTED]

I am attempting to compile PHP under Linux with 
egcs-1.1.2. 
 
If I compile php as a DSO module it compiles fine but 
apache won't load it complaining of unresolved symbols. 
 
If I try and compile it into apache I get the following 
compilation errors : 
 
  -o httpd buildmark.o modules.o 
modules/standard/libstandard.a modules/proxy/libproxy.a 
modules/php4/libphp4.a main/libmain.a ./os/unix/libos.a 
ap/libap.a-Wl,-rpath,/usr/local/mysql/lib  -rdynamic 
-L/usr/local/mysql/lib -Lmodules/php4 -L../modules/php4 
-L../../modules/php4 -lmodphp4   -lmysqlclient -lz -lcrypt 
-lresolv -lm -ldl -lnsl  -lresolv -lcrypt   -lm -lcrypt 
-lndbm -lexpat 
modules/php4/libphp4.a(zend_ini_scanner.lo): warning: 
multiple common of `yytext' 
modules/php4/libphp4.a(zend_language_scanner.lo): warning: 
previous common is here 
modules/php4/libphp4.a(math.lo): In function `zif_atanh': 
/usr/include/__math.h:426: undefined reference to 
`__log1p' 
collect2: ld returned 1 exit status 
make[2]: *** [target_static] Error 1 
make[2]: Leaving directory `/home/pkett/apache_1.3.26/src' 
make[1]: *** [build-std] Error 2 
make[1]: Leaving directory `/home/pkett/apache_1.3.26' 
make: *** [build] Error 2 
 
 
I have tried with 4.2.2 and 4.2.3 with the same results - 
I suspect it's due to using egcs and not a more recent 
version of gcc but can anyone confirm this? 




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

#19565 [Bgs]: line comment interprets ?>

2002-09-24 Thread su-php


 ID:   19565
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Win 2K
 PHP Version:  4.2.1
 New Comment:

Ok, so it is defined in the manual.

However this is not intuitive behaviour.


Previous Comments:


[2002-09-23 19:00:23] [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





[2002-09-23 18:59:52] [EMAIL PROTECTED]

Sorry, but the bug system is not the appropriate forum for asking
support questions. 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

Thank you for your interest in PHP.



[2002-09-23 18:39:27] [EMAIL PROTECTED]

A single line comment still interprets the ?> character sequence.

-
"> */

// the next line is the problem
// 

// all done
?>
-

The above snippet will show the following on the web page, even though
NOTHING should show:

"> // all done ?>





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

#19579 [Bgs]: ora_logon function returns "Could not resolve TNS_NAME"


 ID:   19579
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Oracle related
 Operating System: NT4 SP6a
 PHP Version:  4.2.2
 New Comment:

Check this page:

http://www.php.net/manual/en/ref.oci8.php


Previous Comments:


[2002-09-24 10:50:41] [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



[2002-09-24 09:05:13] [EMAIL PROTECTED]

I use PHP3 with oracle 8.0.5 and it works fine.
I'd like to migrate to PHP4.

But when I use PHP4 with the same PHP scripts and the same oracle
database, I get the following error with the ora_logon function :
"Could not resolve TNS_NAME".




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

#19579 [Opn->Bgs]: ora_logon function returns "Could not resolve TNS_NAME"


 ID:   19579
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Oracle related
 Operating System: NT4 SP6a
 PHP Version:  4.2.2
 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


Previous Comments:


[2002-09-24 09:05:13] [EMAIL PROTECTED]

I use PHP3 with oracle 8.0.5 and it works fine.
I'd like to migrate to PHP4.

But when I use PHP4 with the same PHP scripts and the same oracle
database, I get the following error with the ora_logon function :
"Could not resolve TNS_NAME".




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

#19578 [Fbk]: php_master_value not changeable with php_value


 ID:   19578
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: PHP options/info functions
 Operating System: Linux
 PHP Version:  4.2.2
 New Comment:

You propably have misunderstood what the master/local values mean.
Better question is: Does it work? (are session started automatically?)



Previous Comments:


[2002-09-24 10:08:19] [EMAIL PROTECTED]

Do you happen to run Apache 2? If so, try a snapshot from
http://snaps.php.net as this might have been fixed.



[2002-09-24 09:01:04] [EMAIL PROTECTED]

Hi !
I set 
  php_admin_flag session.auto_start on 
in httpd.conf !
I wanted to turn it of in a VirtualHost section with
  php_flag session.auto_start off !
In php.ini there is :
session.auto_start off
 
phpinfo() shows for session.auto_start
LocalValue : on
MasterValue : off

I seems to if i cannot change a value that´s been set by
php_master_value. 
Alex.




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

#19577 [Opn->Bgs]: Compile PHP


 ID:   19577
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: Linux
 PHP Version:  4.2.1
 New Comment:

Getting it to work would require quite a lot of work and testing. And
still it wouldn't work for everybody.
It's really easy to compile it yourself anyway.
As long as you have the necessary libraries and such.



Previous Comments:


[2002-09-24 08:31:23] [EMAIL PROTECTED]

Dear developers

...this is not a bug, but I want to beg you to install a compiling
service (perheps a payable). If somebody wants to compile some options
for PHP it needs a lot of stuff (e.g. PDF or Oracle support). So I
think it will be a good idea if there is the possibility to select a
preferred PHP-constellation in a form, and then download the compiled
libphp.so (like for MAC-systems).
Is it possible to implement such a service?? Hope to hear from you...

Martin




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

#19578 [Opn->Fbk]: php_master_value not changeable with php_value

2002-09-24 Thread sander


 ID:   19578
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
-Bug Type: Documentation problem
+Bug Type: PHP options/info functions
 Operating System: Linux
 PHP Version:  4.2.2
 New Comment:

Do you happen to run Apache 2? If so, try a snapshot from
http://snaps.php.net as this might have been fixed.


Previous Comments:


[2002-09-24 09:01:04] [EMAIL PROTECTED]

Hi !
I set 
  php_admin_flag session.auto_start on 
in httpd.conf !
I wanted to turn it of in a VirtualHost section with
  php_flag session.auto_start off !
In php.ini there is :
session.auto_start off
 
phpinfo() shows for session.auto_start
LocalValue : on
MasterValue : off

I seems to if i cannot change a value that´s been set by
php_master_value. 
Alex.




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

#19576 [Opn->Bgs]: libtsrm.la not shared

2002-09-24 Thread sander


 ID:   19576
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Warning
 Operating System: hp ux 11.02
 PHP Version:  4.2.3
 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:


[2002-09-24 08:17:05] [EMAIL PROTECTED]

/src/php-4.2.3/ext/
standard/libstandard.la /src/php-4.2.3/ext/xml/libxml.la  TSR
M/libtsrm.la -lpam -lcrypt -lm -lnsl -lpthread -lcrypt 

*** Warning: This library needs some functionality provided by
-lcrypt.
*** I have the capability to make that library automatically link in
when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This library needs some functionality provided by
-lcrypt.
*** I have the capability to make that library automatically link in
when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
Making all in pear





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

#16810 [Com]: URL rewriting is not HTML/XHTML compliant

2002-09-24 Thread 247net


 ID:   16810
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Session related
 Operating System: Linux RedHat
 PHP Version:  4.0CVS-2002-04-2
 New Comment:

XHTML 1.1




=> Error: element "input" not allowed here; possible cause is an inline
element containing a block- level element

You have to wrap the form in a table to be valid. An other aproach is
to change url_rewriter.tags form=fakeentry to form=action. But php
doesn't overwrite the default php.ini.

btw. I have to change the arg_separator.output to "&" instead of
"&" to be valid.


Previous Comments:


[2002-04-25 18:13:35] [EMAIL PROTECTED]

now you're just making up reasons to waste bandwidth and create a silly
configuration knob. the patch has been reverted. the existing output is
entirely sufficient for all of the purposes you've listed, and
perfectly standards compliant.



[2002-04-25 16:09:34] [EMAIL PROTECTED]

We're generating an element to be used in one known way (for reference
by the PHP session library) and that can also be used in other
legitimate ways: addressed via a fragment or XPointer, via DHTML, etc. 
PHP doesn't generate markup that conforms only to its own needs, it
generates it to meet authors' needs, user agents expectations, and spec
requirements; the current patch does not conflict with existing specs,
allows for more reliable UA recognition under certain circumstances,
and makes the element more accessible to the author for legal
addressing or manipulation.

The value of session.name is configurable.  So if an author finds that
the hidden field's id conflicts with another element's id, they already
have the option to modify either or both elements in order to avoid
conflicts.

Preventing side-effects of rewriting on multi-form pages is an
interesting issue. Perhaps this could be remedied with a configuration
option (session.rewriting.hidden) allowing the author to designate
whether the hidden input should be written with an id attribute, name
attribute, or both.  That would permit for flexibility under differing
contexts, including text/html, text/xhtml, and text/xml.  The default
value would remain as before: "name" (only); but give authors the
option to change the behavior when needed.



[2002-04-25 14:59:20] [EMAIL PROTECTED]

we are *not* generating fragments that are expected to identified by
their url. we are generating a (hidden) form input element with a name.
we expect the browser to submit the value of that element with the
associated name. setting an id is pointless. (and potentially *wrong*
if there is more than one form on the page, which means we'll have
created two fragments with the same id.)



[2002-04-25 14:26:36] [EMAIL PROTECTED]

It should not be reversed.

The XHTML DTDs defines "id" as one of the core attributes (see
parameter entity "coreattrs") for most elements, including the input
element.

Section C.8 states "In XML, URI-references [RFC2396] that end with
fragment identifiers of the form "#foo" do not refer to elements with
an attribute name="foo"; rather, they refer to elements with an
attribute defined to be of type ID, e.g., the id attribute in HTML 4.
Many existing HTML clients don't support the use of ID-type attributes
in this way, so identical values may be supplied for both of these
attributes to ensure maximum forward and backward compatibility (e.g.,
...)."

One of the features of XML (and therefore XHTML), is that anchor
elements are no longer the only elements addressable by a fragment
identifier.  Note that section 3.2 states "When a user agent processes
an XHTML document as generic XML, it shall only recognize attributes of
type ID (e.g. the id attribute on most XHTML elements) as fragment
identifiers." So while "script.php#PHPSESSID" may sound like an
unlikely path, it is a legal one.



[2002-04-25 13:05:18] [EMAIL PROTECTED]

note that this is not correct with regards to input elements. the name
attribute is only deprecated for the a, applet, form, frame, iframe,
img, and map elements. (see C.8 of the xhtml spec, and the dtds.)

in fact, reverting this part of the patch would be a good idea. we're
defining input element names here, not fragment identifiers.



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

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

#19301 [Opn->Fbk]: curl_exec crashes


 ID:   19301
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: cURL related
 Operating System: Windows XP Professional CZ
 PHP Version:  4.2.3
 New Comment:

Could you try to reproduce this with a non-stable snapshot?
http://snaps.php.net/win32/php4-win32-latest.zip




Previous Comments:


[2002-09-24 08:41:05] [EMAIL PROTECTED]

Could this be related to how Windows DLLs vs apps works?

In Windows, you can't open a file and pass the handle of that file to
have it read from or written to in a DLL. They somehow don't allow that
kind of data to be shared like that.

It seems as if it could be, the PHP code opens the file and passes the
handle to the DLL that deals with it...

Just my thoughts. I might be completely wrong.



[2002-09-23 04:52:47] [EMAIL PROTECTED]

It seems the bug doesn't affect only WinNT/2K/XP systems but it's also
reproductible on Win98SE.



[2002-09-12 03:03:37] [EMAIL PROTECTED]

Same issue was reported against PHP 4.2.1 in bug 17782. I can see that
bug has been thought to be solved as it wasn't reproducible on Linux. 
Apparenly not the case. It must be a Windows only issue with CURL.

The offending code is the functionality enabled with
curl_setopt ($ch, CURLOPT_FILE, $fp);
with that line enabled curl_exec() crashes (application error/GPF) both
when running PHP from commandline and as module under Apache 1.3.26
Disabling above line with CURLOPT_FILE it works, but that is not very
usefull in my case as I need CURLOPT_FILE :-)

I assume the developer responsible for php_curl.dll (or someone else)
will be able to debug this on Windows?

>From my point of view this issue is beginning to get a bit critical, so
I wouldn't mind to see a quick solution



[2002-09-09 07:38:14] [EMAIL PROTECTED]

This is propably some win32 issue since I can not reproduce this with
PHP 4.2.3 / PHP 4.3.0-dev on Linux.




[2002-09-09 07:30:56] [EMAIL PROTECTED]

Ooops, I wanted to write 4.2.3, not 4.3.2.

Honza



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

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

#19579 [NEW]: ora_logon function returns "Could not resolve TNS_NAME"

2002-09-24 Thread noel . breton


From: [EMAIL PROTECTED]
Operating system: NT4 SP6a
PHP version:  4.2.2
PHP Bug Type: Oracle related
Bug description:  ora_logon function returns "Could not resolve TNS_NAME"

I use PHP3 with oracle 8.0.5 and it works fine.
I'd like to migrate to PHP4.

But when I use PHP4 with the same PHP scripts and the same oracle
database, I get the following error with the ora_logon function : "Could
not resolve TNS_NAME".
-- 
Edit bug report at http://bugs.php.net/?id=19579&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19579&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19579&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19579&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19579&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19579&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19579&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19579&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19579&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19579&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19579&r=globals

#19578 [NEW]: php_master_value not changeable with php_value

2002-09-24 Thread a . waller


From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.2.2
PHP Bug Type: Documentation problem
Bug description:  php_master_value not changeable with php_value

Hi !
I set 
  php_admin_flag session.auto_start on 
in httpd.conf !
I wanted to turn it of in a VirtualHost section with
  php_flag session.auto_start off !
In php.ini there is :
session.auto_start off
 
phpinfo() shows for session.auto_start
LocalValue : on
MasterValue : off

I seems to if i cannot change a value that´s been set by php_master_value.

Alex.
-- 
Edit bug report at http://bugs.php.net/?id=19578&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19578&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19578&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19578&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19578&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19578&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19578&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19578&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19578&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19578&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19578&r=globals

#19572 [Fbk->Opn]: Compilation fails with undefined reference to `__log1p'

2002-09-24 Thread pkett


 ID:   19572
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Linux (Suse 6.1)
 PHP Version:  4.2.3
 New Comment:

Upgrading gcc to version 2.95.3 has solved the problem.

Maybe something should be added to the FAQ to indicate that it won't
compile properly on older versions. The version I was using BTW was the
version installed with Suse 6.1 not something I added afterwards.


Previous Comments:


[2002-09-24 08:11:39] [EMAIL PROTECTED]

Can compile other stuff without problems - in fact I upgraded apache on
the machine just prior to attempting to compile php.

I have just installed gcc 2.95.3 on there and am in the process of
retrying php. I'll let you know if that fixes the problem.



[2002-09-24 06:21:41] [EMAIL PROTECTED]

Forgot to ask: Are you able to compile anything else? Do you have the
kernel headers links correctly set?




[2002-09-24 06:20:47] [EMAIL PROTECTED]

There might be something wrong (or missing) in your system.
Could you try installing GCC 2.95.3 ?




[2002-09-24 04:16:28] [EMAIL PROTECTED]

I am attempting to compile PHP under Linux with 
egcs-1.1.2. 
 
If I compile php as a DSO module it compiles fine but 
apache won't load it complaining of unresolved symbols. 
 
If I try and compile it into apache I get the following 
compilation errors : 
 
  -o httpd buildmark.o modules.o 
modules/standard/libstandard.a modules/proxy/libproxy.a 
modules/php4/libphp4.a main/libmain.a ./os/unix/libos.a 
ap/libap.a-Wl,-rpath,/usr/local/mysql/lib  -rdynamic 
-L/usr/local/mysql/lib -Lmodules/php4 -L../modules/php4 
-L../../modules/php4 -lmodphp4   -lmysqlclient -lz -lcrypt 
-lresolv -lm -ldl -lnsl  -lresolv -lcrypt   -lm -lcrypt 
-lndbm -lexpat 
modules/php4/libphp4.a(zend_ini_scanner.lo): warning: 
multiple common of `yytext' 
modules/php4/libphp4.a(zend_language_scanner.lo): warning: 
previous common is here 
modules/php4/libphp4.a(math.lo): In function `zif_atanh': 
/usr/include/__math.h:426: undefined reference to 
`__log1p' 
collect2: ld returned 1 exit status 
make[2]: *** [target_static] Error 1 
make[2]: Leaving directory `/home/pkett/apache_1.3.26/src' 
make[1]: *** [build-std] Error 2 
make[1]: Leaving directory `/home/pkett/apache_1.3.26' 
make: *** [build] Error 2 
 
 
I have tried with 4.2.2 and 4.2.3 with the same results - 
I suspect it's due to using egcs and not a more recent 
version of gcc but can anyone confirm this? 




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

#19301 [Com]: curl_exec crashes

2002-09-24 Thread daniel


 ID:   19301
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: cURL related
 Operating System: Windows XP Professional CZ
 PHP Version:  4.2.3
 New Comment:

Could this be related to how Windows DLLs vs apps works?

In Windows, you can't open a file and pass the handle of that file to
have it read from or written to in a DLL. They somehow don't allow that
kind of data to be shared like that.

It seems as if it could be, the PHP code opens the file and passes the
handle to the DLL that deals with it...

Just my thoughts. I might be completely wrong.


Previous Comments:


[2002-09-23 04:52:47] [EMAIL PROTECTED]

It seems the bug doesn't affect only WinNT/2K/XP systems but it's also
reproductible on Win98SE.



[2002-09-12 03:03:37] [EMAIL PROTECTED]

Same issue was reported against PHP 4.2.1 in bug 17782. I can see that
bug has been thought to be solved as it wasn't reproducible on Linux. 
Apparenly not the case. It must be a Windows only issue with CURL.

The offending code is the functionality enabled with
curl_setopt ($ch, CURLOPT_FILE, $fp);
with that line enabled curl_exec() crashes (application error/GPF) both
when running PHP from commandline and as module under Apache 1.3.26
Disabling above line with CURLOPT_FILE it works, but that is not very
usefull in my case as I need CURLOPT_FILE :-)

I assume the developer responsible for php_curl.dll (or someone else)
will be able to debug this on Windows?

>From my point of view this issue is beginning to get a bit critical, so
I wouldn't mind to see a quick solution



[2002-09-09 07:38:14] [EMAIL PROTECTED]

This is propably some win32 issue since I can not reproduce this with
PHP 4.2.3 / PHP 4.3.0-dev on Linux.




[2002-09-09 07:30:56] [EMAIL PROTECTED]

Ooops, I wanted to write 4.2.3, not 4.3.2.

Honza



[2002-09-09 07:28:51] [EMAIL PROTECTED]

Nope, PHP 4.3.2 was the first to get into the system. As I said, I even
tested it on clean system (Win2000ProCZ) where nothing else got
installed, not even web server (from W2000 i tried it only as php.exe
executable), and it gave me the crash on a clean system as well.

Honza



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

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

#19577 [NEW]: Compile PHP

2002-09-24 Thread Martin . Schmitz


From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.2.1
PHP Bug Type: *PDF functions
Bug description:  Compile PHP

Dear developers

...this is not a bug, but I want to beg you to install a compiling service
(perheps a payable). If somebody wants to compile some options for PHP it
needs a lot of stuff (e.g. PDF or Oracle support). So I think it will be a
good idea if there is the possibility to select a preferred
PHP-constellation in a form, and then download the compiled libphp.so
(like for MAC-systems).
Is it possible to implement such a service?? Hope to hear from you...

Martin
-- 
Edit bug report at http://bugs.php.net/?id=19577&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19577&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19577&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19577&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19577&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19577&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19577&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19577&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19577&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19577&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19577&r=globals

#19576 [NEW]: libtsrm.la not shared

2002-09-24 Thread ui02wilk


From: [EMAIL PROTECTED]
Operating system: hp ux 11.02
PHP version:  4.2.3
PHP Bug Type: Compile Warning
Bug description:  libtsrm.la not shared

/src/php-4.2.3/ext/
standard/libstandard.la /src/php-4.2.3/ext/xml/libxml.la  TSR
M/libtsrm.la -lpam -lcrypt -lm -lnsl -lpthread -lcrypt 

*** Warning: This library needs some functionality provided by -lcrypt.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This library needs some functionality provided by -lcrypt.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
Making all in pear

-- 
Edit bug report at http://bugs.php.net/?id=19576&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19576&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19576&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19576&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19576&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19576&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19576&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19576&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19576&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19576&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19576&r=globals

#19572 [Com]: Compilation fails with undefined reference to `__log1p'

2002-09-24 Thread pkett


 ID:   19572
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Linux (Suse 6.1)
 PHP Version:  4.2.3
 New Comment:

Can compile other stuff without problems - in fact I upgraded apache on
the machine just prior to attempting to compile php.

I have just installed gcc 2.95.3 on there and am in the process of
retrying php. I'll let you know if that fixes the problem.


Previous Comments:


[2002-09-24 06:21:41] [EMAIL PROTECTED]

Forgot to ask: Are you able to compile anything else? Do you have the
kernel headers links correctly set?




[2002-09-24 06:20:47] [EMAIL PROTECTED]

There might be something wrong (or missing) in your system.
Could you try installing GCC 2.95.3 ?




[2002-09-24 04:16:28] [EMAIL PROTECTED]

I am attempting to compile PHP under Linux with 
egcs-1.1.2. 
 
If I compile php as a DSO module it compiles fine but 
apache won't load it complaining of unresolved symbols. 
 
If I try and compile it into apache I get the following 
compilation errors : 
 
  -o httpd buildmark.o modules.o 
modules/standard/libstandard.a modules/proxy/libproxy.a 
modules/php4/libphp4.a main/libmain.a ./os/unix/libos.a 
ap/libap.a-Wl,-rpath,/usr/local/mysql/lib  -rdynamic 
-L/usr/local/mysql/lib -Lmodules/php4 -L../modules/php4 
-L../../modules/php4 -lmodphp4   -lmysqlclient -lz -lcrypt 
-lresolv -lm -ldl -lnsl  -lresolv -lcrypt   -lm -lcrypt 
-lndbm -lexpat 
modules/php4/libphp4.a(zend_ini_scanner.lo): warning: 
multiple common of `yytext' 
modules/php4/libphp4.a(zend_language_scanner.lo): warning: 
previous common is here 
modules/php4/libphp4.a(math.lo): In function `zif_atanh': 
/usr/include/__math.h:426: undefined reference to 
`__log1p' 
collect2: ld returned 1 exit status 
make[2]: *** [target_static] Error 1 
make[2]: Leaving directory `/home/pkett/apache_1.3.26/src' 
make[1]: *** [build-std] Error 2 
make[1]: Leaving directory `/home/pkett/apache_1.3.26' 
make: *** [build] Error 2 
 
 
I have tried with 4.2.2 and 4.2.3 with the same results - 
I suspect it's due to using egcs and not a more recent 
version of gcc but can anyone confirm this? 




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

#19575 [NEW]: Boolean prints 1 for TRUE but nothing for FALSE

2002-09-24 Thread jc


From: [EMAIL PROTECTED]
Operating system: Red Hat Linux 7.2
PHP version:  4.2.3
PHP Bug Type: Documentation problem
Bug description:  Boolean prints 1 for TRUE but nothing for FALSE

A boolean of TRUE will print as "1" whereas FALSE prints as "" 

This has caused me a problem since I had assume that TRUE would print as
TRUE and FALSE would print as FALSE.

Could you add this to the documentation. I could understand 1/0,
TRUE/FALSE, but "1"/"" is not evident at first.

I'd even suggest a change request that booleans print out as TRUE/FALSE
(since booleans really should not be 1/0 integers or empty/non-empty
strings but BOOLEANS) but I'm sure that would ge  shot down. :)
-- 
Edit bug report at http://bugs.php.net/?id=19575&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19575&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19575&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19575&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19575&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19575&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19575&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19575&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19575&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19575&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19575&r=globals

#19573 [Opn->Ver]: SessionID gets lost when using


 ID:   19573
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Verified
 Bug Type: Session related
 Operating System: Linux 2.4.18
-PHP Version:  4.2.1
+PHP Version:  4.2.1,4.3.0-dev
 New Comment:

Reproduced with latest CVS HEAD (4.3.0-dev).

Further tests showed that if the 'accept-charset' entry is after
'action' and url_rewriter.tags has "form=action" instead of
"form=fakeentry", it works.

The "fakeentry" does not work in any case.



Previous Comments:


[2002-09-24 05:01:59] [EMAIL PROTECTED]

The following form won't be correctly rewritten and will not
automatically get a session ID:



The same form without the accept-charset parameter will work.




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

#19452 [Fbk->Opn]: Apache2 with php4 freeze on HP-UX 11.00

2002-09-24 Thread mad


 ID:   19452
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: HP-UX 11.00
 PHP Version:  4CVS-2002-09-17
 New Comment:

Same issue with 4CVS-2009-09-24 (php4-20020924)

@++
JC


Previous Comments:


[2002-09-23 07:53:54] [EMAIL PROTECTED]

Please try a new snapshot. There were some thread-safety fixes
committed just recently.




[2002-09-23 04:55:45] [EMAIL PROTECTED]

Hellow,

CTRL + C on the httpd process do nothing.
The only way that I have to kill the process is "kill -9 12345"

So I think that I can't use gdb to debug in this case.

Name collision between 9826 9836
Name collision between gsi dtc300s
Name collision between dm1521 dm1520
Name collision between c108 c108
Name collision between ovt100 vt100
Name collision between 300 dtc300s
Name collision between t1061 t3700
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "hppa2.0n-hp-hpux11.00"...
Attaching to program: /PKl01h01/soft/web/httpd/bin/httpd, process
12815
ttrace wait: No such process.
A program is being debugged already.  Kill it? (y or n) n
Program not killed.
Name collision between 9826 9836
Name collision between gsi dtc300s
Name collision between dm1521 dm1520
Name collision between c108 c108
Name collision between ovt100 vt100
Name collision between 300 dtc300s
Name collision between t1061 t3700
(gdb) bt
warning: reading `flags' register: No such process
warning: reading `r3' register: No such process
warning: reading `flags' register: No such process
warning: reading `pcoqh' register: No such process
warning: reading `flags' register: No such process
warning: reading `flags' register: No such process
warning: reading `r3' register: No such process
#0  0x in ?? ()
warning: reading `rp' register: No such process
warning: reading `rp' register: No such process
Error accessing memory address 0x6f726b00: No such process.
(gdb)



[2002-09-18 18:54:24] [EMAIL PROTECTED]

Well, I should have given a bit more info than just the default reply.
You can 'bind' to a hanged process with GDB..

# gdb /path/to/httpd 12345

(where 12345 is the process id)

Then you can just stop the process with CTRL+C and then do 'bt' and see
where it hangs.





[2002-09-18 06:07:59] [EMAIL PROTECTED]

Hellow, 

Apache don't crash but freeze. 99 % of the CPU is used and apache can't
start properly. I can't generate a correct backtrace because http don't
crash so I must kill it : 

Name collision between 9826 9836
Name collision between gsi dtc300s
Name collision between dm1521 dm1520
Name collision between c108 c108
Name collision between ovt100 vt100
Name collision between 300 dtc300s
Name collision between t1061 t3700
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "hppa2.0n-hp-hpux11.00"...
Name collision between 9826 9836
Name collision between gsi dtc300s
Name collision between dm1521 dm1520
Name collision between c108 c108
Name collision between ovt100 vt100
Name collision between 300 dtc300s
Name collision between t1061 t3700
(gdb) run -X
Starting program: /PKl01h01/soft/web/httpd/bin/httpd -X

Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb) bt
No stack.
(gdb)



[2002-09-17 10:45:12] [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.





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

#19572 [Fbk]: Compilation fails with undefined reference to `__log1p'


 ID:   19572
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Linux (Suse 6.1)
 PHP Version:  4.2.3
 New Comment:

Forgot to ask: Are you able to compile anything else? Do you have the
kernel headers links correctly set?



Previous Comments:


[2002-09-24 06:20:47] [EMAIL PROTECTED]

There might be something wrong (or missing) in your system.
Could you try installing GCC 2.95.3 ?




[2002-09-24 04:16:28] [EMAIL PROTECTED]

I am attempting to compile PHP under Linux with 
egcs-1.1.2. 
 
If I compile php as a DSO module it compiles fine but 
apache won't load it complaining of unresolved symbols. 
 
If I try and compile it into apache I get the following 
compilation errors : 
 
  -o httpd buildmark.o modules.o 
modules/standard/libstandard.a modules/proxy/libproxy.a 
modules/php4/libphp4.a main/libmain.a ./os/unix/libos.a 
ap/libap.a-Wl,-rpath,/usr/local/mysql/lib  -rdynamic 
-L/usr/local/mysql/lib -Lmodules/php4 -L../modules/php4 
-L../../modules/php4 -lmodphp4   -lmysqlclient -lz -lcrypt 
-lresolv -lm -ldl -lnsl  -lresolv -lcrypt   -lm -lcrypt 
-lndbm -lexpat 
modules/php4/libphp4.a(zend_ini_scanner.lo): warning: 
multiple common of `yytext' 
modules/php4/libphp4.a(zend_language_scanner.lo): warning: 
previous common is here 
modules/php4/libphp4.a(math.lo): In function `zif_atanh': 
/usr/include/__math.h:426: undefined reference to 
`__log1p' 
collect2: ld returned 1 exit status 
make[2]: *** [target_static] Error 1 
make[2]: Leaving directory `/home/pkett/apache_1.3.26/src' 
make[1]: *** [build-std] Error 2 
make[1]: Leaving directory `/home/pkett/apache_1.3.26' 
make: *** [build] Error 2 
 
 
I have tried with 4.2.2 and 4.2.3 with the same results - 
I suspect it's due to using egcs and not a more recent 
version of gcc but can anyone confirm this? 




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

#19572 [Opn->Fbk]: Compilation fails with undefined reference to `__log1p'


 ID:   19572
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Linux (Suse 6.1)
 PHP Version:  4.2.3
 New Comment:

There might be something wrong (or missing) in your system.
Could you try installing GCC 2.95.3 ?



Previous Comments:


[2002-09-24 04:16:28] [EMAIL PROTECTED]

I am attempting to compile PHP under Linux with 
egcs-1.1.2. 
 
If I compile php as a DSO module it compiles fine but 
apache won't load it complaining of unresolved symbols. 
 
If I try and compile it into apache I get the following 
compilation errors : 
 
  -o httpd buildmark.o modules.o 
modules/standard/libstandard.a modules/proxy/libproxy.a 
modules/php4/libphp4.a main/libmain.a ./os/unix/libos.a 
ap/libap.a-Wl,-rpath,/usr/local/mysql/lib  -rdynamic 
-L/usr/local/mysql/lib -Lmodules/php4 -L../modules/php4 
-L../../modules/php4 -lmodphp4   -lmysqlclient -lz -lcrypt 
-lresolv -lm -ldl -lnsl  -lresolv -lcrypt   -lm -lcrypt 
-lndbm -lexpat 
modules/php4/libphp4.a(zend_ini_scanner.lo): warning: 
multiple common of `yytext' 
modules/php4/libphp4.a(zend_language_scanner.lo): warning: 
previous common is here 
modules/php4/libphp4.a(math.lo): In function `zif_atanh': 
/usr/include/__math.h:426: undefined reference to 
`__log1p' 
collect2: ld returned 1 exit status 
make[2]: *** [target_static] Error 1 
make[2]: Leaving directory `/home/pkett/apache_1.3.26/src' 
make[1]: *** [build-std] Error 2 
make[1]: Leaving directory `/home/pkett/apache_1.3.26' 
make: *** [build] Error 2 
 
 
I have tried with 4.2.2 and 4.2.3 with the same results - 
I suspect it's due to using egcs and not a more recent 
version of gcc but can anyone confirm this? 




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

#16859 [Ctl]: session_decode gives SEGV in PHP 4.2.0


 ID:   16859
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Session related
 Operating System: Solaris 2.6 (5.6)
-PHP Version:  4.2.0
+PHP Version:  4.2.0, 4.3.0-dev
 New Comment:

update versions.



Previous Comments:


[2002-09-24 03:43:18] [EMAIL PROTECTED]

reproduced with 4.3.0-dev

Derick



[2002-08-19 16:22:30] [EMAIL PROTECTED]

I should have added that we are using Apache 1.3.20 and that
session_decode() worked fine with PHP 4.1.2, but not with either PHP
4.2.1 or PHP 4.2.2.

Thanks.



[2002-08-19 16:11:32] [EMAIL PROTECTED]

session_decode() consistently causes a page fault using PHP 4.2.2 on
three development PCs -- two with WIN98 SE and one with WINDOWS 2000



[2002-06-13 18:11:10] [EMAIL PROTECTED]

I can also reproduce a Segmentation Fault with session_decode() on:

RedHat 7.3
Apache 1.3.23
PHP 4.2.1



[2002-06-09 22:56:55] [EMAIL PROTECTED]

Recompiled with --enable-debug on FreeBSD 4.5, and I'm getting  a
considerably different backtrace:

(gdb) bt
#0  0x8082108 in set_default_charset_by_name (cs_name=0x818d0cc
"signature",
flags=9) at charset.c:416
#1  0x8082879 in zm_info_pcre (zend_module=0x818200c) at php_pcre.c:88
#2  0x8082a25 in pcre_get_compiled_regex (
regex=0x818200c
"signature|s:8:\"Damn\\'..\";!daheader|!daHeaderRandom|!daIndexTop|!daMenuDeviations|daTaglines|s:2:\"no\";!daNewLimit|!daNewDevs|daBuddyList|N;daBuddyStatus|s:6:\"online\";!daNewDisplay|daSortBy|s:4:\"date\";d"...,

extra=0x81b, preg_options=0x8151044) at php_pcre.c:164
#3  0x8084c72 in preg_replace_impl (ht=1, return_value=0x818d0ac,
this_ptr=0x0, return_value_used=0, is_callable_replace=8 '\b')
at php_pcre.c:1009
#4  0x80fdf48 in tsrm_strndup (s=0x817f88c "\002", length=2)
at tsrm_virtual_cwd.c:161
#5  0x80e37b8 in zif_xml_parser_set_option (ht=8, return_value=0x0,
this_ptr=0x3, return_value_used=0) at xml.c:1519
#6  0x8061242 in php_module_startup (sf=0xbfbffc10) at main.c:971
#7  0x805f180 in main (argc=3, argv=0xbfbffc78) at cgi_main.c:649
#8  0x805e54d in acos ()



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

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

#19570 [Opn->Csd]: Not all cyrillic symbols present in HTML_ENTITIES table


 ID:   19570
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Gettext related
 Operating System: all
 PHP Version:  4.2.3
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.


Previous Comments:


[2002-09-24 03:54:10] [EMAIL PROTECTED]

This is the code:

$tt = get_html_translation_table (HTML_ENTITIES);
while (list ($key, $value) = each ($tt))
echo $key." -> ".htmlspecialchars ($value)."";

The result:

 ->  
¡ -> ¡
¢ -> ¢
£ -> £
¤ -> ¤
¥ -> ¥
¦ -> ¦
§ -> §
¨ -> ¨
© -> ©
ª -> ª
« -> «
¬ -> ¬
 -> 
® -> ®
¯ -> ¯
° -> °
± -> ±
² -> ²
³ -> ³
´ -> ´
µ -> µ
¶ -> ¶
· -> ·
¸ -> ¸
¹ -> ¹
º -> º
» -> »
¼ -> ¼
½ -> ½
¾ -> ¾
¿ -> ¿
À -> À
Á -> Á
Â -> Â
Ã -> Ã
Ä -> Ä
Å -> Å
Æ -> Æ
Ç -> Ç
È -> È
É -> É
Ê -> Ê
Ë -> Ë
Ì -> Ì
Í -> Í
Î -> Î
Ï -> Ï
Ð -> Ð
Ñ -> Ñ
Ò -> Ò
Ó -> Ó
Ô -> Ô
Õ -> Õ
Ö -> Ö
× -> ×
Ø -> Ø
Ù -> Ù
Ú -> Ú
Û -> Û
Ü -> Ü
Ý -> Ý
Þ -> Þ
ß -> ß
à -> à
á -> á
â -> â
ã -> ã
ä -> ä
å -> å
æ -> æ
ç -> ç
è -> è
é -> é
ê -> ê
ë -> ë
ì -> ì
í -> í
î -> î
ï -> ï
ð -> ð
ñ -> ñ
ò -> ò
ó -> ó
ô -> ô
õ -> õ
ö -> ö
÷ -> ÷
ø -> ø
ù -> ù
ú -> ú
û -> û
ü -> ü
ý -> ý
þ -> þ
& -> &
" -> "
< -> <
> -> >

The letter "ÿ" is missed in resulting table (the last letter in russian
alphabet, html translated string is ÿ)




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

#19574 [NEW]: Quoted printable encode

2002-09-24 Thread fporta


From: [EMAIL PROTECTED]
Operating system: any
PHP version:  4.2.2
PHP Bug Type: Feature/Change Request
Bug description:  Quoted printable encode

Please add a function quoted_printable_encode(), like imap_8bit() but
independent from imap module.
Thanks a lot. Francesco Porta
-- 
Edit bug report at http://bugs.php.net/?id=19574&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19574&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19574&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19574&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19574&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19574&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19574&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19574&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19574&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19574&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19574&r=globals

#19573 [NEW]: SessionID gets lost when using

2002-09-24 Thread katzenmayer


From: [EMAIL PROTECTED]
Operating system: Linux 2.4.18
PHP version:  4.2.1
PHP Bug Type: Session related
Bug description:  SessionID gets lost when using 

The following form won't be correctly rewritten and will not automatically
get a session ID:



The same form without the accept-charset parameter will work.
-- 
Edit bug report at http://bugs.php.net/?id=19573&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19573&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19573&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19573&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19573&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19573&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19573&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19573&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19573&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19573&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19573&r=globals

#16512 [Com]: PREG_SPLIT_DELIM_CAPTURE does not work

2002-09-24 Thread ed


 ID:   16512
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: PCRE related
 Operating System: Win32, Linux
 PHP Version:  4.1.2
 New Comment:

It will be a nice idea to put this example to documentation; I was
already going to send a bug report about PREG_SPLIT_DELIM_CAPTURE when
I found this article.


Previous Comments:


[2002-04-09 09:10:23] [EMAIL PROTECTED]

Read the manual:

PREG_SPLIT_DELIM_CAPTURE

If this flag is set, parenthesized expression in the delimiter pattern
will be captured and returned as well. This flag was added for 4.0.5.

So your pattern should look like:
/(a)/

and presto, it works.



[2002-04-09 08:59:34] [EMAIL PROTECTED]

PREG_SPLIT_DELIM_CAPTURE does not work - preg_split() simply omits the
delimiters disregarding the flag.

The following line:

print_r(preg_split('/a/', 'mama', -1, PREG_SPLIT_DELIM_CAPTURE));

...returns:

Array
(
[0] => m
[1] => m
[2] => 
)

...just like without the last argument - while it should return:

Array
(
[0] => m
[1] => a
[2] => m
[3] => a
[4] => 
)





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

#19494 [Fbk->Opn]: ldap_bind() fails and doesnt use bind-dn

2002-09-24 Thread cm


 ID:   19494
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: LDAP related
 Operating System: Linux 2.4.17
 PHP Version:  4.2.2 and 4.3.0-dev
 New Comment:

this is what the config line looks like:
$CONFIG["ldap_server"] = "ldaps://my.ldap.server";
and then i do:
$ds=ldap_connect($CONFIG["ldap_server"]);

even if there would be a difference shouldnt be the result of
ldap_connect be FALSE.
and ldap_error($ds) give an error

>From the docs:

 Returns a positive LDAP link identifier on success, or FALSE on error.


Previous Comments:


[2002-09-24 04:15:52] [EMAIL PROTECTED]

If $CONFIG["ldap-server"] is defined as "ldaps://my.ldap.server" then
it's exactly the same for PHP.
There is NO way that this could be a problem. Are you very sure there
isn't a trailing newline or a \0 somehwere?

Derick



[2002-09-24 04:12:47] [EMAIL PROTECTED]

Well it seems like ldap_connect has some problem.
1. Scenario
$ds=ldap_connect($CONFIG["ldap_server"]);
-> echo $ldap_error($ds) say "Success" but ldap_bind fails
(also $ds is true and var_dump says "ressource (X) of type (ldap
link)")
2. Scenario
$ds=ldap_connect("ldaps://my.ldap.server");
-> echo $ldap_error($ds) say success and ldap_bind works.

of course $CONFIG["ldap-server"] is defined as "ldaps://my.ldap.server"
i checked that 3 times.

So is this right that ldap_connect says everything is OK though it is
not really ?

Chris



[2002-09-23 08:54:10] [EMAIL PROTECTED]

very funny, when i use URL-syntax in ldap_connect it works. the state
after the ldap_connect seems to be identical except that the ldap_bind
now works with and without bind-dn



[2002-09-23 01:43:27] [EMAIL PROTECTED]

thought that too after i read that on some other bug here. i tried with
ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3) still no change.



[2002-09-20 13:47:05] [EMAIL PROTECTED]

I'm not so sure this is the problem, but are you running
OpenLDAP 2.1 server? By default it only accepts LDAPv3
binds, and the API by default do LDAPv2 binds. IF you do,
try to tell the API to use v3 binds using ldap_set_option().



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

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

#19572 [NEW]: Compilation fails with undefined reference to `__log1p'

2002-09-24 Thread pkett


From: [EMAIL PROTECTED]
Operating system: Linux (Suse 6.1)
PHP version:  4.2.3
PHP Bug Type: Compile Failure
Bug description:  Compilation fails with undefined reference to `__log1p'

I am attempting to compile PHP under Linux with 
egcs-1.1.2. 
 
If I compile php as a DSO module it compiles fine but 
apache won't load it complaining of unresolved symbols. 
 
If I try and compile it into apache I get the following 
compilation errors : 
 
  -o httpd buildmark.o modules.o 
modules/standard/libstandard.a modules/proxy/libproxy.a 
modules/php4/libphp4.a main/libmain.a ./os/unix/libos.a 
ap/libap.a-Wl,-rpath,/usr/local/mysql/lib  -rdynamic 
-L/usr/local/mysql/lib -Lmodules/php4 -L../modules/php4 
-L../../modules/php4 -lmodphp4   -lmysqlclient -lz -lcrypt 
-lresolv -lm -ldl -lnsl  -lresolv -lcrypt   -lm -lcrypt 
-lndbm -lexpat 
modules/php4/libphp4.a(zend_ini_scanner.lo): warning: 
multiple common of `yytext' 
modules/php4/libphp4.a(zend_language_scanner.lo): warning: 
previous common is here 
modules/php4/libphp4.a(math.lo): In function `zif_atanh': 
/usr/include/__math.h:426: undefined reference to 
`__log1p' 
collect2: ld returned 1 exit status 
make[2]: *** [target_static] Error 1 
make[2]: Leaving directory `/home/pkett/apache_1.3.26/src' 
make[1]: *** [build-std] Error 2 
make[1]: Leaving directory `/home/pkett/apache_1.3.26' 
make: *** [build] Error 2 
 
 
I have tried with 4.2.2 and 4.2.3 with the same results - 
I suspect it's due to using egcs and not a more recent 
version of gcc but can anyone confirm this? 
-- 
Edit bug report at http://bugs.php.net/?id=19572&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19572&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19572&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19572&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19572&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19572&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19572&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19572&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19572&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19572&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19572&r=globals

#19494 [Opn->Fbk]: ldap_bind() fails and doesnt use bind-dn


 ID:   19494
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: LDAP related
 Operating System: Linux 2.4.17
 PHP Version:  4.2.2 and 4.3.0-dev
 New Comment:

If $CONFIG["ldap-server"] is defined as "ldaps://my.ldap.server" then
it's exactly the same for PHP.
There is NO way that this could be a problem. Are you very sure there
isn't a trailing newline or a \0 somehwere?

Derick


Previous Comments:


[2002-09-24 04:12:47] [EMAIL PROTECTED]

Well it seems like ldap_connect has some problem.
1. Scenario
$ds=ldap_connect($CONFIG["ldap_server"]);
-> echo $ldap_error($ds) say "Success" but ldap_bind fails
(also $ds is true and var_dump says "ressource (X) of type (ldap
link)")
2. Scenario
$ds=ldap_connect("ldaps://my.ldap.server");
-> echo $ldap_error($ds) say success and ldap_bind works.

of course $CONFIG["ldap-server"] is defined as "ldaps://my.ldap.server"
i checked that 3 times.

So is this right that ldap_connect says everything is OK though it is
not really ?

Chris



[2002-09-23 08:54:10] [EMAIL PROTECTED]

very funny, when i use URL-syntax in ldap_connect it works. the state
after the ldap_connect seems to be identical except that the ldap_bind
now works with and without bind-dn



[2002-09-23 01:43:27] [EMAIL PROTECTED]

thought that too after i read that on some other bug here. i tried with
ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3) still no change.



[2002-09-20 13:47:05] [EMAIL PROTECTED]

I'm not so sure this is the problem, but are you running
OpenLDAP 2.1 server? By default it only accepts LDAPv3
binds, and the API by default do LDAPv2 binds. IF you do,
try to tell the API to use v3 binds using ldap_set_option().



[2002-09-19 07:14:23] [EMAIL PROTECTED]

>It's most likely some problem with your ldap server.
>Have you tried to connect to some public ldap server?

unlikely because i use it for nss_ldap and pam_ldap login on several
machines also as i wrote in the very beginning it binds but without the
given bind-dn

>Also, try adding 'echo ldap_error($ds);' after the >ldap_connect()
call.
this prints "Success"



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

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

#19292 [Com]: random error: open_basedir restriction in effect. File is in wrong directory

2002-09-24 Thread duracell


 ID:   19292
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Apache related
 Operating System: linux
 PHP Version:  4.2.3
 New Comment:

We have exactly the same problem.
1 request under 20 fail under this error :

Warning: open_basedir restriction in effect. File is in wrong directory
in
Unknown on line 0
Warning: Failed opening
'/space_3/www_main/www/board/tickets/voter_a.php' for
inclusion (include_path='.:/usr/local/lib/php') in Unknown on line 0

With php 4.2.3 (apache module) + apache 1.3.26 under debian 3.0 with no
open_basedir configuration on php.ini and our vhost.

duracell


Previous Comments:


[2002-09-19 11:13:43] [EMAIL PROTECTED]

PS: may be a session/temporary directory trouble ?



[2002-09-19 11:08:48] [EMAIL PROTECTED]

Hi,

I have this problem too, and started when I updated from 4.2.2
(patched) to 4.2.3 :

Redhat 7.3
Linux 2.4.18-3
Apache/1.3.26
PHP 4.2.3
Name Based Virtual Host

'./configure' '--with-apxs=/usr/local/apache/bin/apxs'
'--with-openssl=/usr/local/ssl' '-- enable-magic-quotes' '--with-zlib'
'--with-zlib-dir=/usr/local/src/zlib' '--enable-bcmath' '--
with-curl=/usr/local/src/curl-7.9.8'
'--with-fdftk=/usr/local/src/libFDF' '--enable-ftp' '--
with-gd=/usr/local/src/gd-1.8.4' '--with-mcrypt'
'--enable-gd-native-ttf' '--with-jpeg-dir=/ usr/local/src/jpeg-6b'
'--with-png-dir=/usr/local/src/libpng' '--with-imap=/usr/local/src/
imap-2001a' '--with-gettext'
'--with-imap-ssl=/usr/local/src/openssl-0.9.6g' '--with-
mysql=/usr/local/mysql' '--with-pdflib'
'--with-pdflib-dir=/usr/local/src/pdflib-4.0.2/pdflib'
'--with-jpeg-dir=/usr/local/src/jpeg-6b'
'--with-png-dir=/usr/local/src/libpng' '--enable- sockets'
'--with-regex=php' '--with-swf=/usr/local/lib/libSWF'
'--enable-sysvsem' '-- enable-sysvshm' '--enable-tokenizer'
'--enable-inline-optimization'



[2002-09-12 11:45:55] [EMAIL PROTECTED]

Hello PHP,

I Have also you Problem!

!!! PLEASE FIX THIS PROBLEM !!!
(that is a customer server.)



[2002-09-09 16:56:03] [EMAIL PROTECTED]

Hi,

I have also the problem.

Here is my Config:
'./configure' '--with-apache=../apache_1.3.26'
'--with-mysql=/usr/local/mysql' '--with-mcrypt=/usr/local'
'--with-png-dir=/usr/local' '--with-jpeg-dir=/usr/local'
'--with-curl=/usr/local' '--with-zlib=/usr/local' '--enable-ftp'
'--with-hyperwave' '--with-freetype-dir=/usr/local'
'--with-gd=/usr/local' '--with-swf=/usr/local' '--with-ttf=/usr/local'
'--with-imap=/usr/local' '--enable-gd-native-ttf'
'--with-mhash=/usr/local' '--enable-yp' '--enable-bcmath'
'--with-tiff-dir=/usr/local' '--with-t1lib=/usr/local'
'--enable-sysvshm=yes' '--enable-sysvsem=yes' '--enable-calendar'
'--enable-mbregex' '--enable-mbstring' '--enable-wddx' '--enable-exif'
'--enable-memory-limit' '--enable-freetype-4bit-antialias-hack'
'--with-bz2=/usr/local' '--with-gettext=/usr/local'
'--with-xpm-dir=/usr/X11R6' '--with-openssl=/usr/local/openssl'
'--disable-debug' '--with-dom=/usr/local' '--enable-gd-imgstrttf'
'--with-pdflib' '--with-xmlrpc' '--enable-xslt' '--with-xslt-sablot'
'--enable-magic-quotes' '--with-zip=/usr/local'
'--with-zlib=/usr/local' '--with-zlib-dir=/usr/local'
'--enable-sablot-errors-descriptive' '--with-kerberos'
'--with-iconv=/usr/local' '--with-imap-ssl=/usr/local/openssl'
'--enable-safe-mode' '--disable-pear'

Redhat 7.2
Linux 2.4.17
Apache 1.3.26
PHP 4.2.3

Please fix this...



[2002-09-09 06:31:01] [EMAIL PROTECTED]

I can confirm this bug on FreeBSD. We upgraded
yesterday to 4.2.3 and had in 2-3 virtual server
configs the opendir restriction.

Suddently PHP begins to complain about open_basedir
related errors in virtual server configs where no
openbasedir is set.

Looks like

php_admin_value open_basedir "some_path"


has a global effect !

Workaround is to set OpenBasedir in every configuration
:-((

Of course this breaks a lot of things like external include
dirs etc ...



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

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

#19494 [Bgs->Opn]: ldap_bind() fails and doesnt use bind-dn

2002-09-24 Thread cm


 ID:   19494
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: LDAP related
 Operating System: Linux 2.4.17
 PHP Version:  4.2.2 and 4.3.0-dev
 New Comment:

Well it seems like ldap_connect has some problem.
1. Scenario
$ds=ldap_connect($CONFIG["ldap_server"]);
-> echo $ldap_error($ds) say "Success" but ldap_bind fails
(also $ds is true and var_dump says "ressource (X) of type (ldap
link)")
2. Scenario
$ds=ldap_connect("ldaps://my.ldap.server");
-> echo $ldap_error($ds) say success and ldap_bind works.

of course $CONFIG["ldap-server"] is defined as "ldaps://my.ldap.server"
i checked that 3 times.

So is this right that ldap_connect says everything is OK though it is
not really ?

Chris


Previous Comments:


[2002-09-23 08:54:10] [EMAIL PROTECTED]

very funny, when i use URL-syntax in ldap_connect it works. the state
after the ldap_connect seems to be identical except that the ldap_bind
now works with and without bind-dn



[2002-09-23 01:43:27] [EMAIL PROTECTED]

thought that too after i read that on some other bug here. i tried with
ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3) still no change.



[2002-09-20 13:47:05] [EMAIL PROTECTED]

I'm not so sure this is the problem, but are you running
OpenLDAP 2.1 server? By default it only accepts LDAPv3
binds, and the API by default do LDAPv2 binds. IF you do,
try to tell the API to use v3 binds using ldap_set_option().



[2002-09-19 07:14:23] [EMAIL PROTECTED]

>It's most likely some problem with your ldap server.
>Have you tried to connect to some public ldap server?

unlikely because i use it for nss_ldap and pam_ldap login on several
machines also as i wrote in the very beginning it binds but without the
given bind-dn

>Also, try adding 'echo ldap_error($ds);' after the >ldap_connect()
call.
this prints "Success"



[2002-09-19 07:00:00] [EMAIL PROTECTED]

It's most likely some problem with your ldap server.
Have you tried to connect to some public ldap server?

Also, try adding 'echo ldap_error($ds);' after the ldap_connect()
call.





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

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

#19292 [Opn->Ctl]: random error: open_basedir restriction in effect. File is in wrong directory


 ID:   19292
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Critical
 Bug Type: Apache related
 Operating System: linux
 PHP Version:  4.2.3


Previous Comments:


[2002-09-19 11:13:43] [EMAIL PROTECTED]

PS: may be a session/temporary directory trouble ?



[2002-09-19 11:08:48] [EMAIL PROTECTED]

Hi,

I have this problem too, and started when I updated from 4.2.2
(patched) to 4.2.3 :

Redhat 7.3
Linux 2.4.18-3
Apache/1.3.26
PHP 4.2.3
Name Based Virtual Host

'./configure' '--with-apxs=/usr/local/apache/bin/apxs'
'--with-openssl=/usr/local/ssl' '-- enable-magic-quotes' '--with-zlib'
'--with-zlib-dir=/usr/local/src/zlib' '--enable-bcmath' '--
with-curl=/usr/local/src/curl-7.9.8'
'--with-fdftk=/usr/local/src/libFDF' '--enable-ftp' '--
with-gd=/usr/local/src/gd-1.8.4' '--with-mcrypt'
'--enable-gd-native-ttf' '--with-jpeg-dir=/ usr/local/src/jpeg-6b'
'--with-png-dir=/usr/local/src/libpng' '--with-imap=/usr/local/src/
imap-2001a' '--with-gettext'
'--with-imap-ssl=/usr/local/src/openssl-0.9.6g' '--with-
mysql=/usr/local/mysql' '--with-pdflib'
'--with-pdflib-dir=/usr/local/src/pdflib-4.0.2/pdflib'
'--with-jpeg-dir=/usr/local/src/jpeg-6b'
'--with-png-dir=/usr/local/src/libpng' '--enable- sockets'
'--with-regex=php' '--with-swf=/usr/local/lib/libSWF'
'--enable-sysvsem' '-- enable-sysvshm' '--enable-tokenizer'
'--enable-inline-optimization'



[2002-09-12 11:45:55] [EMAIL PROTECTED]

Hello PHP,

I Have also you Problem!

!!! PLEASE FIX THIS PROBLEM !!!
(that is a customer server.)



[2002-09-09 16:56:03] [EMAIL PROTECTED]

Hi,

I have also the problem.

Here is my Config:
'./configure' '--with-apache=../apache_1.3.26'
'--with-mysql=/usr/local/mysql' '--with-mcrypt=/usr/local'
'--with-png-dir=/usr/local' '--with-jpeg-dir=/usr/local'
'--with-curl=/usr/local' '--with-zlib=/usr/local' '--enable-ftp'
'--with-hyperwave' '--with-freetype-dir=/usr/local'
'--with-gd=/usr/local' '--with-swf=/usr/local' '--with-ttf=/usr/local'
'--with-imap=/usr/local' '--enable-gd-native-ttf'
'--with-mhash=/usr/local' '--enable-yp' '--enable-bcmath'
'--with-tiff-dir=/usr/local' '--with-t1lib=/usr/local'
'--enable-sysvshm=yes' '--enable-sysvsem=yes' '--enable-calendar'
'--enable-mbregex' '--enable-mbstring' '--enable-wddx' '--enable-exif'
'--enable-memory-limit' '--enable-freetype-4bit-antialias-hack'
'--with-bz2=/usr/local' '--with-gettext=/usr/local'
'--with-xpm-dir=/usr/X11R6' '--with-openssl=/usr/local/openssl'
'--disable-debug' '--with-dom=/usr/local' '--enable-gd-imgstrttf'
'--with-pdflib' '--with-xmlrpc' '--enable-xslt' '--with-xslt-sablot'
'--enable-magic-quotes' '--with-zip=/usr/local'
'--with-zlib=/usr/local' '--with-zlib-dir=/usr/local'
'--enable-sablot-errors-descriptive' '--with-kerberos'
'--with-iconv=/usr/local' '--with-imap-ssl=/usr/local/openssl'
'--enable-safe-mode' '--disable-pear'

Redhat 7.2
Linux 2.4.17
Apache 1.3.26
PHP 4.2.3

Please fix this...



[2002-09-09 06:31:01] [EMAIL PROTECTED]

I can confirm this bug on FreeBSD. We upgraded
yesterday to 4.2.3 and had in 2-3 virtual server
configs the opendir restriction.

Suddently PHP begins to complain about open_basedir
related errors in virtual server configs where no
openbasedir is set.

Looks like

php_admin_value open_basedir "some_path"


has a global effect !

Workaround is to set OpenBasedir in every configuration
:-((

Of course this breaks a lot of things like external include
dirs etc ...



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

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

#19570 [NEW]: Not all cyrillic symbols present in HTML_ENTITIES table

2002-09-24 Thread apetrenko


From: [EMAIL PROTECTED]
Operating system: all
PHP version:  4.2.3
PHP Bug Type: Gettext related
Bug description:  Not all cyrillic symbols present in HTML_ENTITIES table

This is the code:

$tt = get_html_translation_table (HTML_ENTITIES);
while (list ($key, $value) = each ($tt))
echo $key." -> ".htmlspecialchars ($value)."";

The result:

 ->  
¡ -> ¡
¢ -> ¢
£ -> £
¤ -> ¤
¥ -> ¥
¦ -> ¦
§ -> §
¨ -> ¨
© -> ©
ª -> ª
« -> «
¬ -> ¬
 -> 
® -> ®
¯ -> ¯
° -> °
± -> ±
² -> ²
³ -> ³
´ -> ´
µ -> µ
¶ -> ¶
· -> ·
¸ -> ¸
¹ -> ¹
º -> º
» -> »
¼ -> ¼
½ -> ½
¾ -> ¾
¿ -> ¿
À -> À
Á -> Á
Â -> Â
Ã -> Ã
Ä -> Ä
Å -> Å
Æ -> Æ
Ç -> Ç
È -> È
É -> É
Ê -> Ê
Ë -> Ë
Ì -> Ì
Í -> Í
Î -> Î
Ï -> Ï
Ð -> Ð
Ñ -> Ñ
Ò -> Ò
Ó -> Ó
Ô -> Ô
Õ -> Õ
Ö -> Ö
× -> ×
Ø -> Ø
Ù -> Ù
Ú -> Ú
Û -> Û
Ü -> Ü
Ý -> Ý
Þ -> Þ
ß -> ß
à -> à
á -> á
â -> â
ã -> ã
ä -> ä
å -> å
æ -> æ
ç -> ç
è -> è
é -> é
ê -> ê
ë -> ë
ì -> ì
í -> í
î -> î
ï -> ï
ð -> ð
ñ -> ñ
ò -> ò
ó -> ó
ô -> ô
õ -> õ
ö -> ö
÷ -> ÷
ø -> ø
ù -> ù
ú -> ú
û -> û
ü -> ü
ý -> ý
þ -> þ
& -> &
" -> "
< -> <
> -> >

The letter "ÿ" is missed in resulting table (the last letter in russian
alphabet, html translated string is ÿ)
-- 
Edit bug report at http://bugs.php.net/?id=19570&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19570&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19570&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19570&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19570&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19570&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19570&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19570&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19570&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19570&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19570&r=globals

#16859 [Opn->Ctl]: session_decode gives SEGV in PHP 4.2.0


 ID:   16859
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Critical
 Bug Type: Session related
 Operating System: Solaris 2.6 (5.6)
 PHP Version:  4.2.0
 New Comment:

reproduced with 4.3.0-dev

Derick


Previous Comments:


[2002-08-19 16:22:30] [EMAIL PROTECTED]

I should have added that we are using Apache 1.3.20 and that
session_decode() worked fine with PHP 4.1.2, but not with either PHP
4.2.1 or PHP 4.2.2.

Thanks.



[2002-08-19 16:11:32] [EMAIL PROTECTED]

session_decode() consistently causes a page fault using PHP 4.2.2 on
three development PCs -- two with WIN98 SE and one with WINDOWS 2000



[2002-06-13 18:11:10] [EMAIL PROTECTED]

I can also reproduce a Segmentation Fault with session_decode() on:

RedHat 7.3
Apache 1.3.23
PHP 4.2.1



[2002-06-09 22:56:55] [EMAIL PROTECTED]

Recompiled with --enable-debug on FreeBSD 4.5, and I'm getting  a
considerably different backtrace:

(gdb) bt
#0  0x8082108 in set_default_charset_by_name (cs_name=0x818d0cc
"signature",
flags=9) at charset.c:416
#1  0x8082879 in zm_info_pcre (zend_module=0x818200c) at php_pcre.c:88
#2  0x8082a25 in pcre_get_compiled_regex (
regex=0x818200c
"signature|s:8:\"Damn\\'..\";!daheader|!daHeaderRandom|!daIndexTop|!daMenuDeviations|daTaglines|s:2:\"no\";!daNewLimit|!daNewDevs|daBuddyList|N;daBuddyStatus|s:6:\"online\";!daNewDisplay|daSortBy|s:4:\"date\";d"...,

extra=0x81b, preg_options=0x8151044) at php_pcre.c:164
#3  0x8084c72 in preg_replace_impl (ht=1, return_value=0x818d0ac,
this_ptr=0x0, return_value_used=0, is_callable_replace=8 '\b')
at php_pcre.c:1009
#4  0x80fdf48 in tsrm_strndup (s=0x817f88c "\002", length=2)
at tsrm_virtual_cwd.c:161
#5  0x80e37b8 in zif_xml_parser_set_option (ht=8, return_value=0x0,
this_ptr=0x3, return_value_used=0) at xml.c:1519
#6  0x8061242 in php_module_startup (sf=0xbfbffc10) at main.c:971
#7  0x805f180 in main (argc=3, argv=0xbfbffc78) at cgi_main.c:649
#8  0x805e54d in acos ()



[2002-06-09 22:31:25] [EMAIL PROTECTED]

Forgot to mention, I have an example script including all session data
which crashes it:

http://neo.zero-gravity.org/bug16859.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/16859

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

#14136 [Opn->Csd]: Segfaults when forget xslt_free()