#20461 [NEW]: Unable to access $PHP_AUTH_USER or $PHP_AUTH_PW

[shawn]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4.8
PHP version:  4CVS-2002-11-17
PHP Bug Type: Apache related
Bug description:  Unable to access $PHP_AUTH_USER or $PHP_AUTH_PW

I recently decided to upgrade to GD 2.0 but was having problems getting it
to compile with 4.2.3 or any of the older versions of PHP, which is odd
because I've had it work before.  Anyways, as a last resort, I decided to
download one of the stable CVS snapshots and, lo and behold, it worked
fine.

The only problem I'm having now is that I can't seem to access
$PHP_AUTH_USER or $PHP_AUTH_PW, and I have a few applications on my site
that depend on being able to access these variables.  The variables appear
to be empty when I reference them.  I am using the exact same configure
line when I compiled the CVS version of PHP as I used when I tried the
other versions...

./configure --with-apxs --with-mysql --enable-ftp --with-session
--with-zlib-dir=/usr/local --with-gd=/usr/local --with-jpeg-dir=/usr/local
--with-png-dir=/u
sr/local --with-freetype-dir=/usr/local --with-mcal=/usr/local
--with-mhash=/usr/local

I have GD 2.0 installed under /usr/local, as indicated by the configure
line above.  If you need any additional information, please contact me. 
Thanks in advance for your help.
-- 
Edit bug report at http://bugs.php.net/?id=20461&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20461&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20461&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20461&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20461&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20461&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20461&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20461&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20461&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20461&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20461&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20461&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20461&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20461&r=isapi

#20460 [NEW]: Additional fscanf argument

[paul79]

From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.7
PHP version:  4.2.3
PHP Bug Type: Feature/Change Request
Bug description:  Additional fscanf argument

Not sure if this was already considered, but I didn't see it documented
anywhere and thought it would be nice to have.  It doesn't state in the
documentation about the  maximum length of the string being  read can be,
nor do I know what it currenly is.  I think it's 1024.  I have a line in a
file that's 1630 characters long.  When a run the program with fscanf, it
obvisouly doesn't read the whole line.

For instance:

list($v1, $v2) = fscanf($pt, "%[^|]|%[^\n]\n");

The "\n" is never reached and the program breaks.

There is a work around, which would be to substitute the fscanf with
something like:

split("\|", fgets($pt, 8026));

So, I guess what I'm getting at is, is it at all possible to:

a) add a length the read to fscanf
or
b) update the documentation to show this limitation


Thanks For Listening,
Paul
-- 
Edit bug report at http://bugs.php.net/?id=20460&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20460&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20460&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20460&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20460&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20460&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20460&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20460&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20460&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20460&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20460&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20460&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20460&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20460&r=isapi

#20452 [Fbk->Opn]: Problems requiring/including when original file is a symlink

[pupeno]

 ID:   20452
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux Mandrake 9.0
 PHP Version:  4.2.3
 New Comment:

I don't have a 'working' on line example to show you this and I 
don't have posibilities to do it right now, I'm sorry, but I'll try to

show you here what I mean with an example. 
Let's supouse I have one script in this file 
/var/php/scripts/index.php 
and I have a symlink to that file like this 
/var/www/htdocs/index.php -> ../../php/scripts/index.php 
and this file contains the following: 
 
When I run it, for require("dir/include.php"); it tryes to include 
/var/php/scripts/dir/include.php (the relative path from the 
original location of the file) but for require("../dir/include.php");
it 
tryes to icnlude /var/www/dir/include.php (real path for 
/var/www/htdocs/../dir/include.php) (it is resolving the relative 
path from the symlink and not the original file). 
I'm not sure with behaviour is the right one, but this mix is not 
the right one for sure, I think. 
I hope it helps, if you need more help, just contact me. 
Thank you.


Previous Comments:


[2002-11-16 11:48:31] [EMAIL PROTECTED]

Could you show an example of what you mean?



[2002-11-15 17:35:13] [EMAIL PROTECTED]

I'm requesting a page, the file that is called is   
index.php, but this file is a symlink from somewhere else.   
When I require a file from index.php, if there's no '..' 
(dots) on  the path (a relative path, but not going back), 
the relative path is from where  the original file is, but 
if there are  '..' on the path, the relative path is   
from where the symlink is (although php identifies the 
script as the original file in the error message).  
   




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

#20250 [Com]: Make fails with GD2.0.4

[mcdaniew]

 ID:   20250
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: Redhat 7.2, Redhat 8.0
 PHP Version:  4.2.3
 New Comment:

I know that this problem has been solved in CVS. I even looked at the
code and it should work, but it still runs as if the code didnt
preprocess this: #if HAVE_LIBGD204
Why might this be?

io_ctx->free is replaced with io_ctx->gd_free in gd 2.0.4 but my
compiler still tries the io_ctx->free. Am I missing setting some
environment variable somewhere?

Any help you can give me would be of great assistance
-wade

./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-zlib
--with-bz2 --enable-calendar --with-gd=/usr/local/
--with-jpeg-dir=/usr/ --with-png-dir=/usr/ --with-tiff-dir=/usr/
--with-zlib-dir=/usr/ --with-gettext --with-imap
--with-imap-ssl=/usr/local/ssl/ --enable-mime-magic
--with-mysql=/usr/local/ --enable-sockets --with-pdflib
--with-swf=/usr/local/ --with-kerberos


Previous Comments:


[2002-11-12 00:40:46] [EMAIL PROTECTED]

gdIOCtx struct defined in gd_io.h has changed in gd2.0.4.

should we use gd_free instead of free?

typedef struct gdIOCtx {
int (*getC)(struct gdIOCtx*);
int (*getBuf)(struct gdIOCtx*, void*, int);

void (*putC)(struct gdIOCtx*, int);
int (*putBuf)(struct gdIOCtx*, const void*, int);

int (*seek)(struct gdIOCtx*, const int);
long(*tell)(struct gdIOCtx*);

void(*gd_free)(struct gdIOCtx*);

} gdIOCtx;



[2002-11-04 18:01:52] [EMAIL PROTECTED]

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.





[2002-11-04 18:01:36] [EMAIL PROTECTED]

Forgot to metion that the error messages are exactly the same for
RedHat8.0 as well.



[2002-11-04 18:00:12] [EMAIL PROTECTED]

compile fails when compiling with GD2.0.4 (built as static).

Reproducable on both RedHat7.2 and RedHat 8.0

configure command:
./configure \
--with-apxs=/usr/sbin/apxs \
--with-kerberos=/usr \
--with-config-file-path=/etc \
--with-PEAR \
--with-openssl \
--with-mcrypt \
--with-bz2 \
--with-curl=/usr \
--enable-ftp \
--with-gd=../gd-2.0.4 \
--enable-gd-native-ttf \
--enable-gd-imgstrttf \
--with-jpeg-dir=/usr/lib \
--with-png-dir=/usr/lib \
--with-tiff-dir=/usr \
--with-zlib-dir=/usr/share \
--with-xpm-dir=/usr/X11R6/lib/ \
--with-freetype-dir=/usr/include/freetype2/freetype \
--with-ttf=/usr/include/freetype2 \
--with-t1lib=/usr/include \
--with-gettext=/usr/share/gettext \
--with-imap-ssl \
--with-unixODBC \
--with-pgsql=/usr \
--with-mysql=/usr \
--enable-sockets \
--with-regex \
--with-xmlrpc \
--with-expat

GD2.0.4 compiled from source (in /usr/src/redhat/BUILD/gd-2.0.4/):
./configure
make libgd.a



Description:
'configure' completes perfectly

make fails with the following:
[php 4.2.2]

Making all in gd
make[2]: Entering directory `/usr/src/redhat/BUILD/php-4.2.2/ext/gd'
make[3]: Entering directory `/usr/src/redhat/BUILD/php-4.2.2/ext/gd'
/bin/sh /usr/src/redhat/BUILD/php-4.2.2/libtool --silent --mode=compile
gcc
-I. -I/usr/src/redhat/BUILD/php-4.2.2/ext/gd
-I/usr/src/redhat/BUILD/php-4.2.2/main
-I/usr/src/redhat/BUILD/php-4.2.2
-I/usr/include/apache -I/usr/src/redhat/BUILD/php-4.2.2/Zend
-I/usr/include/freetype2/freetype -I/usr/src/redhat/BUILD/gd-2.0.4
-I/usr/include/mysql -I/usr/local/include -I/usr/include/pgsql
-I/usr/src/redhat/BUILD/php-4.2.2/ext/xml/expat
-I/usr/src/redhat/BUILD/php-4.2.2/ext/xmlrpc/libxmlrpc  -DLINUX=22
-DEAPI
-DEAPI_MM -DEAPI_MM_CORE_PATH=/var/run/httpd.mm
-I/usr/src/redhat/BUILD/php-4.2.2/TSRM -g -O2 -prefer-pic  -c gd.c
In file included from gd.c:83:
gd_ctx.c: In function `_php_image_output_ctx':
gd_ctx.c:70: structure has no member named `free'
gd_ctx.c:98: structure has no member named `free'
gd.c: In function `_php_image_type':
gd.c:1014: structure has no member named `free'
gd.c:1017: structure has no member named `free'
gd.c: In function `_php_image_create_from':
gd.c:1208: structure has no member named `free'
make[3]: *** [gd.lo] Error 1
make[3]: Leaving directory `/usr/src/redhat/BUILD/php-4.2.2/ext/gd'
make[2]: *** [all-

#20459 [NEW]: functions contained in if/else

[pickleman78]

From: [EMAIL PROTECTED]
Operating system: Windows ME
PHP version:  4.3.0-pre2
PHP Bug Type: Feature/Change Request
Bug description:  functions contained in if/else

Well, this is just a featire request/concept thing. Could you make it where
if you declare a function in an if/else statement, and you call it outside
of that statement, before it returns an error, it checks and sees if the
function was declared an if/else statement? I don't know if this is
possiblem but just a thought
-- 
Edit bug report at http://bugs.php.net/?id=20459&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20459&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20459&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20459&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20459&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20459&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20459&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20459&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20459&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20459&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20459&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20459&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20459&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20459&r=isapi

#20449 [Com]: sessions randomly fail

[josh]

 ID:   20449
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Session related
 Operating System: redhat 7.3
 PHP Version:  4.3.0-dev
 New Comment:

Ok, I can only open or close this.  If you'd like, change it to
feedback.  I will provide more details soon.

I'm very anxious to help squash this problem.


Previous Comments:


[2002-11-16 20:32:11] [EMAIL PROTECTED]

As for an example script...I don't think I could make it short. 
However, the script is only a shopping cart. I'm not doing anything out
of the ordinary.  It is a simple array of strings.  I try to store the
array as a session.  

Like I said before, I've never been able to break it myself.  However,
I do see evidence of it breaking. (ie. the e-mail that is sent to me)

I guess it should be possible to write a script that continuously tries
to add to cart then checkout and see if it would break that way.  

I will do so and get back to you.  In the meantime, I will change the
status of this to feedback.



[2002-11-16 19:55:52] [EMAIL PROTECTED]

The php version I'm using at the moment is
PHP Version 4.4.0-dev

Any other info can be found here.
http://www.t-shirtking.com/temp/phpinfo.php



[2002-11-15 19:32:38] [EMAIL PROTECTED]

Can you add _short_ example script here that shows the problem, as I'm
using sessions a lot and never have had any problems with them. Albeit
I haven't tried to overload them too much either. Maybe you're doing
something that isn't really been thought about when the session
extension was written?




[2002-11-15 19:26:09] [EMAIL PROTECTED]

Please put correct version number in the report..
I assume it's 4.3.0-dev but if it's something else, please
change it.




[2002-11-15 16:35:46] [EMAIL PROTECTED]

I've experienced the same problem, on various platforms. SPARC Solaris
8 with PHP 4.2.2, Intel Linux 2.4 with PHP 4.2.3, and RedHat Alpha
Linux 2.4 with PHP 4.2.3.  

However I'm not using it in the context of a shopping cart, my
application is that of a "Checksheet" that we use to mark off Quality
Assurance items. The Checksheet is large so I store the form contents
in a session. They can move through all kinds of menus and parts of the
Checksheet and the work is stored entirely in a session. About 8 people
use this Checksheet system throughout the day 7 days a week, about once
a day suddenly the Checksheet system will say they aren't logged in,
and when they relogin in, their work is gone. I've implemented a quick
and dirty save to database feature for long term storage and I've
encouraged my users to frequently save. The save merely serializes the
Checksheet object that is normally stored in a session, and saves it to
a database.



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

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

#20449 [Com]: sessions randomly fail

[josh]

 ID:   20449
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Session related
 Operating System: redhat 7.3
 PHP Version:  4.3.0-dev
 New Comment:

As for an example script...I don't think I could make it short. 
However, the script is only a shopping cart. I'm not doing anything out
of the ordinary.  It is a simple array of strings.  I try to store the
array as a session.  

Like I said before, I've never been able to break it myself.  However,
I do see evidence of it breaking. (ie. the e-mail that is sent to me)

I guess it should be possible to write a script that continuously tries
to add to cart then checkout and see if it would break that way.  

I will do so and get back to you.  In the meantime, I will change the
status of this to feedback.


Previous Comments:


[2002-11-16 19:55:52] [EMAIL PROTECTED]

The php version I'm using at the moment is
PHP Version 4.4.0-dev

Any other info can be found here.
http://www.t-shirtking.com/temp/phpinfo.php



[2002-11-15 19:32:38] [EMAIL PROTECTED]

Can you add _short_ example script here that shows the problem, as I'm
using sessions a lot and never have had any problems with them. Albeit
I haven't tried to overload them too much either. Maybe you're doing
something that isn't really been thought about when the session
extension was written?




[2002-11-15 19:26:09] [EMAIL PROTECTED]

Please put correct version number in the report..
I assume it's 4.3.0-dev but if it's something else, please
change it.




[2002-11-15 16:35:46] [EMAIL PROTECTED]

I've experienced the same problem, on various platforms. SPARC Solaris
8 with PHP 4.2.2, Intel Linux 2.4 with PHP 4.2.3, and RedHat Alpha
Linux 2.4 with PHP 4.2.3.  

However I'm not using it in the context of a shopping cart, my
application is that of a "Checksheet" that we use to mark off Quality
Assurance items. The Checksheet is large so I store the form contents
in a session. They can move through all kinds of menus and parts of the
Checksheet and the work is stored entirely in a session. About 8 people
use this Checksheet system throughout the day 7 days a week, about once
a day suddenly the Checksheet system will say they aren't logged in,
and when they relogin in, their work is gone. I've implemented a quick
and dirty save to database feature for long term storage and I've
encouraged my users to frequently save. The save merely serializes the
Checksheet object that is normally stored in a session, and saves it to
a database.



[2002-11-15 14:15:51] [EMAIL PROTECTED]

Quick question.

What should session.save_handler be in the php.ini file when using my
own mysql session handlers?  Should it remain files or should it get
set to user to make the session_set_save_handler work properly?  The
documentation is somewhat unclear on this.



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

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

#20449 [Com]: sessions randomly fail

[josh]

 ID:   20449
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Session related
 Operating System: redhat 7.3
 PHP Version:  4.3.0-dev
 New Comment:

The php version I'm using at the moment is
PHP Version 4.4.0-dev

Any other info can be found here.
http://www.t-shirtking.com/temp/phpinfo.php


Previous Comments:


[2002-11-15 19:32:38] [EMAIL PROTECTED]

Can you add _short_ example script here that shows the problem, as I'm
using sessions a lot and never have had any problems with them. Albeit
I haven't tried to overload them too much either. Maybe you're doing
something that isn't really been thought about when the session
extension was written?




[2002-11-15 19:26:09] [EMAIL PROTECTED]

Please put correct version number in the report..
I assume it's 4.3.0-dev but if it's something else, please
change it.




[2002-11-15 16:35:46] [EMAIL PROTECTED]

I've experienced the same problem, on various platforms. SPARC Solaris
8 with PHP 4.2.2, Intel Linux 2.4 with PHP 4.2.3, and RedHat Alpha
Linux 2.4 with PHP 4.2.3.  

However I'm not using it in the context of a shopping cart, my
application is that of a "Checksheet" that we use to mark off Quality
Assurance items. The Checksheet is large so I store the form contents
in a session. They can move through all kinds of menus and parts of the
Checksheet and the work is stored entirely in a session. About 8 people
use this Checksheet system throughout the day 7 days a week, about once
a day suddenly the Checksheet system will say they aren't logged in,
and when they relogin in, their work is gone. I've implemented a quick
and dirty save to database feature for long term storage and I've
encouraged my users to frequently save. The save merely serializes the
Checksheet object that is normally stored in a session, and saves it to
a database.



[2002-11-15 14:15:51] [EMAIL PROTECTED]

Quick question.

What should session.save_handler be in the php.ini file when using my
own mysql session handlers?  Should it remain files or should it get
set to user to make the session_set_save_handler work properly?  The
documentation is somewhat unclear on this.



[2002-11-15 13:58:51] [EMAIL PROTECTED]

I am already using the save handler to use my own mysql backend.  

Please don't close this bug again.  I am using CVS from a build on
11-14-2002.  I still get random session failure.  

Here is a list of other bugs that are related to this.
Bug #19029
Bug #17846
Bug #19972
Bug #19022

As far as I can tell, these other bugs were never fully resolved.

BTW, while I allow php to set a cookie, I don't use it at all.  I
manually set session_id by using the session passed via the url.



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

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

#15978 [Bgs]: Losing fields values after opening a new window

[nicos]

 ID:   15978
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Session related
 Operating System: WIN 2K
 PHP Version:  4.0.6
 New Comment:

As Sander said, this has nothing to do with PHP really, PHP is
server-side and can't deal with that. That depend only of your browser
and I don't think this can be fixed excepted if you use cookies,
assuming your browser is allowing them. Anyway sessions should be kept
if you don't close your first browser page to open the second one, if
it doesn't you've just forgot to add session_start() in the second
page.

Thanks for your report.


Previous Comments:


[2002-11-16 17:34:07] [EMAIL PROTECTED]

I have exactly the same problem.

I am using the phakt 1.3 extension to build a PHP site with UltraDev
(www.interakt.ro). My site restricts access to users according to their
access level.

I have a menu in my main page which has links to several other pages.
When a user clicks on a link, a new window opens (target="_blank") with
the linked page.

The 'Restrict Access to Page' server behavior sometimes (almost half of
the times I tried it) denies access to a logged in, legitimate user,
while other times it works fine.

I did a little experiment: while having the page open, I modified the
code and removed the target="_blank" from the link. I refreshed the
page, and clicked it. And it worked. The linked page opened correctly -
but not in a new window of course.

Apparently the problem appears whenever a new browser window opens. 

If the problem is browser-related, is there any way do you know of any
way it can be solved?

Thnx



[2002-03-10 06:36:33] [EMAIL PROTECTED]

This behaviour depends on your browser, not on PHP.



[2002-03-09 19:43:34] [EMAIL PROTECTED]

Really strange...I believe it is a session problem
(session_cache_limiter)

Here is the thing:
I'm using PHP4 sessions, and so have set the session_cache_limiter to
'private, must revalidate', to keep history.
I have a page A.PHP with form. This page calls B.php. After sending
datas from a.php to b.php and then hit the back button (to go back to
a.PHP), I found my formfields with values always here. OK. Everything
works fine.

But when I send datas from a.php to b.php ,and then, on b.php page, I
open a new window (with http://bugs.php.net/?id=15978&edit=1

#15978 [Com]: Losing fields values after opening a new window

[christos . e]

 ID:   15978
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Session related
 Operating System: WIN 2K
 PHP Version:  4.0.6
 New Comment:

I have exactly the same problem.

I am using the phakt 1.3 extension to build a PHP site with UltraDev
(www.interakt.ro). My site restricts access to users according to their
access level.

I have a menu in my main page which has links to several other pages.
When a user clicks on a link, a new window opens (target="_blank") with
the linked page.

The 'Restrict Access to Page' server behavior sometimes (almost half of
the times I tried it) denies access to a logged in, legitimate user,
while other times it works fine.

I did a little experiment: while having the page open, I modified the
code and removed the target="_blank" from the link. I refreshed the
page, and clicked it. And it worked. The linked page opened correctly -
but not in a new window of course.

Apparently the problem appears whenever a new browser window opens. 

If the problem is browser-related, is there any way do you know of any
way it can be solved?

Thnx


Previous Comments:


[2002-03-10 06:36:33] [EMAIL PROTECTED]

This behaviour depends on your browser, not on PHP.



[2002-03-09 19:43:34] [EMAIL PROTECTED]

Really strange...I believe it is a session problem
(session_cache_limiter)

Here is the thing:
I'm using PHP4 sessions, and so have set the session_cache_limiter to
'private, must revalidate', to keep history.
I have a page A.PHP with form. This page calls B.php. After sending
datas from a.php to b.php and then hit the back button (to go back to
a.PHP), I found my formfields with values always here. OK. Everything
works fine.

But when I send datas from a.php to b.php ,and then, on b.php page, I
open a new window (with http://bugs.php.net/?id=15978&edit=1

#20215 [Opn->Bgs]: fputs(); (Line Feed / Carriage Return)

[wez]

 ID:   20215
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: Windows 2000
 PHP Version:  4.2.3
 New Comment:

I can't reproduce the problem using PHP 4.3RC1 or the slightly more up
to date PHP 4.3 development branch and
the script that you provided, either under win XP with IIS
or linux.

I'm using php.ini-recommended, so please make sure that
you don't have any zany settings turned on in your php.ini or server
configuration.



Previous Comments:


[2002-11-16 06:22:55] [EMAIL PROTECTED]

The last PHP CVS snapshot (Win32) doesn't correct the bug  
Demo/Source :
http://www.serveurperso.com/temp/fputs.php
The function always adds some incorrects CRLF.



[2002-11-16 01:12:37] [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-11-01 16:16:31] [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-11-01 16:05:39] [EMAIL PROTECTED]

To every writings the function "fput" adds jumps of lines in too much.

Sample script :


 

 
 






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

#15975 [Bgs]: Parse error for lates version of browscap.ini

[iliaa]

 ID:   15975
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Windows 2000
 PHP Version:  4.1.1
 New Comment:

Not anymore, the file is no longer bundled.


Previous Comments:


[2002-11-16 13:41:50] [EMAIL PROTECTED]

Sorry, previous comment should have read "windows binary distribution",
don't know about other distributions.

At least I see you have finally accepted this as a bug in the 4.2.3
distribution and have apparently fixed it in CVS (Bug #19902)



[2002-11-16 13:19:31] [EMAIL PROTECTED]

Sorry [EMAIL PROTECTED] but this is a bug either in PHP or in browscap.ini
and is not bogus at all!

The **STANDARD** 4.2.3 windows distribution of PHP (.zip) includes this
bug.

The is *NOT* a support request.



[2002-08-14 21:20:13] [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.

PHP does not support ! | ( ) characters as potential values, to prevent
this problem remove those characters from the values of the entries
inside your browscap.ini file.



[2002-03-09 16:56:30] [EMAIL PROTECTED]

While reading the lates version of browscap.ini (version february 2002)
the parser stumbles over brackets.

E.g. an entry like:

platform=Windows XP (Q312461)

will trigger the error: 

PHP: Error parsing e:\PHP\browscap.ini on line 1397

When removing the brackets, e.g.

platform=Windows XP Q312461

the parser does not stumble. Brackets appear on about 10-20 lines in
the browscap.ini. It is a drag to remove all the brackets for each and
every update of the file. Fix seems to be relatively quick, with a
great benefit.

This bug may have a similar cause as bug #10060.




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

#20458 [NEW]: --with-qtdom=shared broken

[nigel . jewell]

From: [EMAIL PROTECTED]
Operating system: Redhat Linux 7.3
PHP version:  4.2.3
PHP Bug Type: *Compile Issues
Bug description:  --with-qtdom=shared broken

Compiling PHP with 4.2.3 and the configure option "--with-qtdom=shared"
does not build qtdom.
-- 
Edit bug report at http://bugs.php.net/?id=20458&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20458&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20458&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20458&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20458&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20458&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20458&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20458&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20458&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20458&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20458&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20458&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20458&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20458&r=isapi

#20451 [Fbk->Opn]: imagepstext generates weird images since PHP 4.3.0-pre1

[fdsoft]

 ID:   20451
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: GD related
 Operating System: Red Hat Linux 7.3
 PHP Version:  4.3.0-pre2
 New Comment:

Reopening the report


Previous Comments:


[2002-11-15 23:06:10] [EMAIL PROTECTED]

I forgot to mention that I use t1lib 1.3.1 from the following address
to enable the imageps* functions in the gd extension (--with-t1lib
configure option):

ftp://sunsite.unc.edu/pub/Linux/libs/graphics/t1lib-1.3.1.tar.gz



[2002-11-15 23:03:00] [EMAIL PROTECTED]

Yes, certainly, here's the whole code and the font in question:

http://web.axelero.hu/fdsoft/temp/fonttest.zip

There are some really ugly calculations and a brute force way of
determining the size of the would-be image in the code, since
imagepsbbox function didn't quite work well either. At least that was
the case with PHP 4.2.x, and since I added this workaround, I've yet to
re-check that in 4.3.0.

Now for this weird output problem I can't figure out a workaround, and
this was absolutely perfect with PHP 4.2.x., hence my bug report.
It's likely that the fonts I use are of low quality or buggy or both;
but that doesn't change the fact that this was working nicely with the
older versions.

Thanks



[2002-11-15 21:18:24] [EMAIL PROTECTED]

Can you please provide a complete and working example script? This one
you added does not work.

--Jani




[2002-11-15 17:08:45] [EMAIL PROTECTED]

I use the GD extension to generate .png images automatically for
displaying text with a specific Type1 font, using the imagepstext
function.

PHP 4.2.x generates these images perfectly, while using PHP 4.3.0-pre1
and -pre2 results in some really weird output.

Here are some examples to show the difference:
http://web.axelero.hu/fdsoft/temp/images.html

There actually seems to be two seperate problems:
- the characters are not lined up properly any more
- anti-aliasing produces weird output (most pronounced when the
resulting image is viewed in IE 6, less ugly but still noticeable in
Mozilla)

The anti-aliasing problem pretty much goes away if I recompile PHP
4.3.0-pre2 to use my old GD 1.8.4 (from the Red Hat rpms) instead of
PHP's built-in version of GD.

The php code in question:


$fonthandle=@imagepsloadfont(FONT_PATH.$font);
imagepsencodefont($fonthandle, FONT_PATH.'IsoLatin1.enc');

$im = imagecreate($imgwidth, $imgheight);
$background_color = imagecolorallocate ($im, $background[0],
$background[1], $background[2]);
imagecolortransparent($im, $background_color);
$text_color = imagecolorallocate ($im, 
$color[0], $color[1], $color[2]);
imagepstext($im, $txt, $fonthandle, $size, $text_color,
$background_color,$x, $y, 0, 0, 0, 16);
imagepng($im);




Finally my php configure options:


--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu
--target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include
--libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var
--sharedstatedir=/usr/com --mandir=/usr/share/man
--infodir=/usr/share/info --prefix=/usr --with-config-file-path=/etc
--with-exec-dir=/usr/bin --enable-force-cgi-redirect --disable-debug
--enable-dbg=shared --with-dbg-profiler --enable-pic --disable-rpath
--enable-inline-optimization --with-bz2 --with-db3
--with-curl=/usr/local --with-freetype-dir=/usr --with-png-dir=/usr
--with-gd=shared --enable-gd-native-ttf --with-ttf --with-t1lib
--with-gettext=shared --with-ncurses --with-iconv=shared
--with-jpeg-dir=/usr --with-openssl --with-png --with-regex=system
--with-expat-dir=/usr --with-zlib --with-layout=GNU --enable-bcmath
--enable-exif --enable-ftp
--enable-sockets --enable-sysvsem --enable-sysvshm
--enable-discard-path --enable-track-vars --enable-trans-sid
--enable-wddx --enable-exif --enable-memory-limit --enable-bcmath
--enable-shmop --enable-versioning --enable-calendar --enable-dbx
--enable-dio --enable-mcal --with-readline  --with-mysql=shared,/usr
--with-sybase-ct=shared,/usr/local --with-pgsql=shared
--with-unixODBC=shared --with-interbase=shared,/opt/interbase
--with-imap=shared --with-imap-ssl --with-kerberos=/usr/kerberos
--with-zip=shared --with-pspell=shared --with-ming=shared
--with-pdflib=shared --with-pear=/usr/share/pear
--with-apxs=/usr/sbin/apxs


The '--with-gd=shared' option was changed to '--with-gd=shared,/usr' to
produce the "without built-in GD" output.




-- 
Edit this bug report at http://bugs.ph

#15975 [Com]: Parse error for lates version of browscap.ini

[adf]

 ID:   15975
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Windows 2000
 PHP Version:  4.1.1
 New Comment:

Sorry, previous comment should have read "windows binary distribution",
don't know about other distributions.

At least I see you have finally accepted this as a bug in the 4.2.3
distribution and have apparently fixed it in CVS (Bug #19902)


Previous Comments:


[2002-11-16 13:19:31] [EMAIL PROTECTED]

Sorry [EMAIL PROTECTED] but this is a bug either in PHP or in browscap.ini
and is not bogus at all!

The **STANDARD** 4.2.3 windows distribution of PHP (.zip) includes this
bug.

The is *NOT* a support request.



[2002-08-14 21:20:13] [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.

PHP does not support ! | ( ) characters as potential values, to prevent
this problem remove those characters from the values of the entries
inside your browscap.ini file.



[2002-03-09 16:56:30] [EMAIL PROTECTED]

While reading the lates version of browscap.ini (version february 2002)
the parser stumbles over brackets.

E.g. an entry like:

platform=Windows XP (Q312461)

will trigger the error: 

PHP: Error parsing e:\PHP\browscap.ini on line 1397

When removing the brackets, e.g.

platform=Windows XP Q312461

the parser does not stumble. Brackets appear on about 10-20 lines in
the browscap.ini. It is a drag to remove all the brackets for each and
every update of the file. Fix seems to be relatively quick, with a
great benefit.

This bug may have a similar cause as bug #10060.




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

#15975 [Com]: Parse error for lates version of browscap.ini

[adf]

 ID:   15975
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Windows 2000
 PHP Version:  4.1.1
 New Comment:

Sorry [EMAIL PROTECTED] but this is a bug either in PHP or in browscap.ini
and is not bogus at all!

The **STANDARD** 4.2.3 windows distribution of PHP (.zip) includes this
bug.

The is *NOT* a support request.


Previous Comments:


[2002-08-14 21:20:13] [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.

PHP does not support ! | ( ) characters as potential values, to prevent
this problem remove those characters from the values of the entries
inside your browscap.ini file.



[2002-03-09 16:56:30] [EMAIL PROTECTED]

While reading the lates version of browscap.ini (version february 2002)
the parser stumbles over brackets.

E.g. an entry like:

platform=Windows XP (Q312461)

will trigger the error: 

PHP: Error parsing e:\PHP\browscap.ini on line 1397

When removing the brackets, e.g.

platform=Windows XP Q312461

the parser does not stumble. Brackets appear on about 10-20 lines in
the browscap.ini. It is a drag to remove all the brackets for each and
every update of the file. Fix seems to be relatively quick, with a
great benefit.

This bug may have a similar cause as bug #10060.




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

#20109 [Ctl]: iplanet 6 core dump w/NSAPI load

[cjs]

 ID:   20109
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: iPlanet related
 Operating System: Solaris 9
-PHP Version:  4CVS-2002-10-26
+PHP Version:  php4-STABLE-20021116
 New Comment:

Updated to iPlanet-WebServer-Enterprise/6.0SP5 and tried 
php4-STABLE-200211161630. Same crash, no change.


[16/Nov/2002:14:07:33] catastrophe (22765): Server crash detected
(signal SIGBUS)
[16/Nov/2002:14:07:33] info (22765): Crash occurred in NSAPI SAF
php4_execute
[16/Nov/2002:14:07:33] info (22765): Crash occurred in function
php_register_variable_ex from module
/usr/iplanet/servers/bin/libphp4.so


Previous Comments:


[2002-11-02 14:11:14] [EMAIL PROTECTED]

As much as I don't like nsapi, we can't have it not working for 4.3.0
release... since it has historically worked (sometimes).



[2002-10-27 08:49:16] [EMAIL PROTECTED]

Tried php4-200210262100, same crash, same backtrace.

Crash:
[27/Oct/2002:09:45:07] catastrophe (29972): Server crash detected
(signal SIGBUS)
[27/Oct/2002:09:45:07] info (29972): Crash occurred in NSAPI SAF
php4_execute
[27/Oct/2002:09:45:07] info (29972): Crash occurred in function
php_register_variable_ex from module
/usr/iplanet/servers/bin/libphp4.so
[27/Oct/2002:09:45:12] failure (29957): Child process admin thread is
shutting down

Backtrace:
#0  0xfe629ccc in php_register_variable_ex (var=0xfe6c05c0
"REQUEST_LINE", 
val=0xfda5f6b8, track_vars_array=0xfe6c05c0, tsrm_ls=0x1792d8)
at /home/cjs/work/php4-200210262100/main/php_variables.c:176
#1  0xfe62988c in php_register_variable_safe (var=0xfe6c05c0
"REQUEST_LINE", 
strval=0xc722f0 "GET /phpinfo.php HTTP/1.1", str_len=25, 
track_vars_array=0x35a6d8, tsrm_ls=0x1792d8)
at /home/cjs/work/php4-200210262100/main/php_variables.c:56
#2  0xfe6297a4 in php_register_variable (var=0xfe6c05c0 "REQUEST_LINE",

strval=0xc722f0 "GET /phpinfo.php HTTP/1.1",
track_vars_array=0x35a6d8, 
tsrm_ls=0x1792d8)
at /home/cjs/work/php4-200210262100/main/php_variables.c:37
#3  0xfe678e10 in sapi_nsapi_register_server_variables (
track_vars_array=0x35a6d8, tsrm_ls=0x1792d8)
at /home/cjs/work/php4-200210262100/sapi/nsapi/nsapi.c:290
#4  0xfe61e7b4 in php_hash_environment (tsrm_ls=0x1792d8)
at /home/cjs/work/php4-200210262100/main/main.c:1220
#5  0xfe61d278 in php_request_startup (tsrm_ls=0x1792d8)
at /home/cjs/work/php4-200210262100/main/main.c:857
#6  0xfe679590 in nsapi_module_main (request_context=0xc72d60, 
tsrm_ls=0x1792d8)
at /home/cjs/work/php4-200210262100/sapi/nsapi/nsapi.c:460
#7  0xfe679768 in php4_execute (pb=0xc3f88, sn=0xc36a48, rq=0xc36a90)
at /home/cjs/work/php4-200210262100/sapi/nsapi/nsapi.c:525
#8  0xff1d89b4 in
__0FNfunc_exec_strP6KFuncStructP6GpblockP6HSessionP6HRequest
() from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so
#9  0xff1d9cf8 in INTobject_execute ()
   from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so
#10 0xff1dd8e8 in INTservact_service ()
   from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so
#11 0xff1dde84 in INTservact_handle_processed ()
   from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so
#12 0xff215c0c in __0fLHttpRequestUUnacceleratedRespondPCcTBPc ()
   from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so
#13 0xff2150c0 in __0fLHttpRequestNHandleRequestP6Gnetbuf ()
   from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so
#14 0xff213388 in __0fNDaemonSessionDrunv ()
   from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so
#15 0xff163b80 in ThreadMain ()
   from /usr/iplanet/servers/bin/https/lib/libnsprwrap.so
#16 0xfede76a0 in _pt_root ()
   from /usr/iplanet/servers/bin/https/lib/libnspr4.so



[2002-10-26 17:01:52] [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've just commited a patch to the CVS that may address the problem you
are seeing.



[2002-10-26 15:19:19] [EMAIL PROTECTED]

Recompiled with the latest snap (php4-200210261200) and with Forte 7
compilers (previous was with gcc 2.95.3) . Similar crash, here is the
dbx backtrace:

t@18 (l@18) terminated by signal SEGV (no mapping at the fault
address)
0xfd8f6834: DumpThreads+0x000c: ldub[%o0 + 0x38], %o0
Current function is php_register_variable
   37   php_register_variable_safe(var, strval, strlen(strval),
track_vars_array TSRMLS_CC);

(dbx) where
current thread: t@18
  [1] DumpThreads(0x0, 0x587040, 0x17c, 0xfdbd4de4, 0xfdb89080, 0x0),

#20455 [Fbk->Csd]: Many warnings Warning during "make test" with --enable-safe-mode

[php]

 ID:   20455
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Closed
 Bug Type: *Compile Issues
 Operating System: Linux (SusE 8.0, Kernel 2.4.19)
 PHP Version:  4.3.0-pre2
 New Comment:

php4-200211161630 works.


Previous Comments:


[2002-11-16 11:42:02] [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-11-16 11:09:54] [EMAIL PROTECTED]

I've forgot to mention that when running "make install"
SAFE_MODE-warnings appear, too.



[2002-11-16 10:54:21] [EMAIL PROTECTED]

I compiled PHP 4.3.0-pre2 with the congigure option --enable-safemode.
While running "make test" I've got hundreds of Safe-Mode-warnings.
Maipulating all php.ini's I've found on my machine didn't help. The
only thing I was able to to was to run configure and make again without
--enabnle-safe-mode, then make test worked.




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

#20106 [Com]: crashing apache with phpMyAdmin

[ahulse]

 ID:   20106
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Apache2 related
 Operating System: Windows XP
 PHP Version:  4.3.0-pre1
 New Comment:

I to have similar problems. My setup is a Win2000 SP3, running Apache
2.0.43 w/PHP as a Apache 2.0 Filter (I can reproduce this on any 4.3.0
build I have tried, and am currently running Nov 16 2002 10:12:13
Latest STABLE 4.3.0-dev). I have tried this with phpMyAdmin current
2.3.3-dev builds from the past month. I am also running MySQL
4.0.4-beta (but have seen it in the past running MySQL 3.23.52). I am
running with 1GB of memory and have configured Win00 for such memory.

Selecting a link into phpMyAdmin Index page and navigating through
various options will ultimately cause Apache2 to take a dump. I have
not found a function that reproduces the dump every time (after a fresh
start of Apache2), but inevitably Apache2 takes a dump. After the first
dump, phpMyAdmin options seem cause dumps more easily. Restarting
Apache2 allows me to work for a while longer before the dumps startup
again.

I may or maynot have selected the link causing the prior to Apache2
taking the dump, i.e. I have caused the dump by selecting a phpMyAdmin
based link for the first time (after an Apache2 restart), I have also
created it by re-selecting a link, and I have also gone multiple links
into phpMyAdmin w/o a problem and caused the dump by using the browser
"Back Page" option. I can cause this with or without doing any
updates.

Basically, you can cause the abend simply by wondering around in
phpMyAdmin for a while and backing up. The page/link does not seem to
matter, just the fact I am spending time in phpMyAdmin.

I have both a DrWatson log and User.dmp from the Apache2 server if you
would like them.

NOTE: I can NOT reproduce with the the any of the 4.2.4-dev releases I
have run. They are rock solid and hours of working with phpMyAdmin on
the same configuration have never caused Apache2 to take a dump. I have
also not been able to reproduce this with any of my own pages, or other
PHP based products (both using and not using MySQL).


Previous Comments:


[2002-10-27 18:32:34] [EMAIL PROTECTED]

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

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

Thank you for your interest in PHP.


Try the newly released 4.3.0-pre2, if you still experience the crash,
please provide the shortest possible script that can be used to
replicate the problem.



[2002-10-26 18:29:31] [EMAIL PROTECTED]

1.3.27 & 2.0.43 were the versions it happened with



[2002-10-26 12:49:09] [EMAIL PROTECTED]

And that version of apache would be?



[2002-10-26 12:39:33] [EMAIL PROTECTED]

using the latest dev build of php causes apache to crash when using
phpMyAdmin and going to 'users' on the main page when using it as
'root', this also happened during phpinfo(); but i haven't been able to
reproduce it with phpinfo(); there is no information given with the
error, the 'send a bug report to microsoft' dialog comes up, and says
apache has had a fatal error, after downgrading apache so that i could
use the stable version of php, the problem appears to be fixed.




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

#19349 [NoF->Opn]: odbc_longreadlen() does not work

[truth]

 ID:   19349
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   No Feedback
+Status:   Open
 Bug Type: ODBC related
 Operating System: SuSE 8.0
 PHP Version:  4.2.1
 New Comment:

Script is pretty simple. It's hard to just cut and paste because I have
everything spread out in a bunch of classes.

$linkid = odbc_pconnect("database", "username", "password");
$result = odbc_exec($linkid, "SELECT SUBSTR(document, 1, 200) FROM
documents WHERE doc_id = 1);
odbc_longreadlen($result, 200);
odbc_binmode($result, ODBC_BINMODE_PASSTHRU);
$column = odbc_result($result, 1);

// A short example of what I'm trying to do.
// $column should be filled with up to 200 bytes of data.
// By default, it's up to 4096 bytes of data, or whatever is
// set in the php.ini file.


Previous Comments:


[2002-11-16 01:13:36] [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-11-02 14:51:11] [EMAIL PROTECTED]

can you please provide the full script sample for this?  I think I do
see what is wrong, but want to make sure.



[2002-09-11 10:27:31] [EMAIL PROTECTED]

I have a script that runs a select statement from a 10MB CLOB field
(among others). I run the following :

odbc_longreadlen($resultid, 300);

Then I run:

$document = odbc_result($resultid, 2);

The problem is, $document ends up with 4096 bytes of data (the default,
NOT 300). If I edit php.ini and set up odbc_lrl to 200 in
there, then $document ends up with 2MBin it. It acts like the function
odbc_longreadlen does not work at all.

I don't know how much more information I can give other than
odbc_longreadlen does not seem to do anything at all.



[2002-09-11 09:49:21] [EMAIL PROTECTED]

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

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

Thank you for your interest in PHP.






[2002-09-10 20:33:11] [EMAIL PROTECTED]

I am using PHP with ODBC (IBM DB2) support and since upgrading to 4.2.1
from 4.0.4pl1, my odbc_longreadlen() function no longer works. I have
to set it in the configuration file now, as that is the only place that
it works properly.

In addition, when it's set above 200 in the config file, httpd
starts taking 75% of the CPU (system, not user) and the data never gets
to PHP. Am I hitting some type of limitation? How else do I get my 10MB
CLOB out of DB2?




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

#20457 [Opn->Csd]: APACHE_VERSION variable in configure is nonsense

[sniper]

 ID:   20457
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: Solaris 8
 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-11-16 11:45:38] [EMAIL PROTECTED]

Inside the sections for apxs and apxs2 (on lines 3326 and 3722) of the
configure script, it tries to set a variable named APACHE_VERSION with
the results of expr:

APACHE_VERSION=`expr $4 \* 100 + $5 \* 1000 + $6`

This apparently assumes (prays?) that the user will have specified an
Apache source directory after the first argument. Of course when I
run:

configure --with-apxs=/usr/local/apache2/bin/apxs

...as is recommended in the documentation, $4, $5, and $6 are set to
'usr', 'local', and 'apache2', which causes expr to fail.




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

#20452 [Opn->Fbk]: Problems requiring/including when original file is a symlink

[iliaa]

 ID:   20452
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: Linux Mandrake 9.0
 PHP Version:  4.2.3
 New Comment:

Could you show an example of what you mean?


Previous Comments:


[2002-11-15 17:35:13] [EMAIL PROTECTED]

I'm requesting a page, the file that is called is   
index.php, but this file is a symlink from somewhere else.   
When I require a file from index.php, if there's no '..' 
(dots) on  the path (a relative path, but not going back), 
the relative path is from where  the original file is, but 
if there are  '..' on the path, the relative path is   
from where the symlink is (although php identifies the 
script as the original file in the error message).  
   




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

#20457 [NEW]: APACHE_VERSION variable in configure is nonsense

[jared]

From: [EMAIL PROTECTED]
Operating system: Solaris 8
PHP version:  4.2.3
PHP Bug Type: Compile Failure
Bug description:  APACHE_VERSION variable in configure is nonsense

Inside the sections for apxs and apxs2 (on lines 3326 and 3722) of the
configure script, it tries to set a variable named APACHE_VERSION with the
results of expr:

APACHE_VERSION=`expr $4 \* 100 + $5 \* 1000 + $6`

This apparently assumes (prays?) that the user will have specified an
Apache source directory after the first argument. Of course when I run:

configure --with-apxs=/usr/local/apache2/bin/apxs

...as is recommended in the documentation, $4, $5, and $6 are set to
'usr', 'local', and 'apache2', which causes expr to fail.
-- 
Edit bug report at http://bugs.php.net/?id=20457&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20457&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20457&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20457&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20457&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20457&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20457&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20457&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20457&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20457&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20457&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20457&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20457&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20457&r=isapi

#20455 [Opn->Fbk]: Many warnings Warning during "make test" with --enable-safe-mode

[iliaa]

 ID:   20455
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: *Compile Issues
 Operating System: Linux (SusE 8.0, Kernel 2.4.19)
 PHP Version:  4.3.0-pre2
 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-11-16 11:09:54] [EMAIL PROTECTED]

I've forgot to mention that when running "make install"
SAFE_MODE-warnings appear, too.



[2002-11-16 10:54:21] [EMAIL PROTECTED]

I compiled PHP 4.3.0-pre2 with the congigure option --enable-safemode.
While running "make test" I've got hundreds of Safe-Mode-warnings.
Maipulating all php.ini's I've found on my machine didn't help. The
only thing I was able to to was to run configure and make again without
--enabnle-safe-mode, then make test worked.




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

#20456 [Opn->Bgs]: Apache 2.0.4 and sapi_apache2.c

[iliaa]

 ID:   20456
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Apache2 related
 Operating System: Redhat 8.0
 PHP Version:  4.3.0-pre2
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

The php library generated for Apache 2 needs to be copied manually to
/usr/local/srv/www/libexec/libphp4.so from sapi/apache2filter/. Because
you have not done so, Apache is still trying to load the old PHP.


Previous Comments:


[2002-11-16 11:05:21] [EMAIL PROTECTED]

I know this has been listed before, but not with my os.

httpd: module
"/usr/src/build/144344-i386/BUILD/php-4.2.2/sapi/apache2filter/sapi_apache2.c"
is not compatible with this version of Apache (found 20020628, need
20020903).

I installed 4.3.0-dev yestererday, yet the problem persists.  Where is
that file being called from? I have the latest versions of Apache2 and
php... don't I?




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

#20455 [Opn]: Many warnings Warning during "make test" with --enable-safe-mode

[php]

 ID:   20455
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: *Compile Issues
 Operating System: Linux (SusE 8.0, Kernel 2.4.19)
 PHP Version:  4.3.0-pre2
 New Comment:

I've forgot to mention that when running "make install"
SAFE_MODE-warnings appear, too.


Previous Comments:


[2002-11-16 10:54:21] [EMAIL PROTECTED]

I compiled PHP 4.3.0-pre2 with the congigure option --enable-safemode.
While running "make test" I've got hundreds of Safe-Mode-warnings.
Maipulating all php.ini's I've found on my machine didn't help. The
only thing I was able to to was to run configure and make again without
--enabnle-safe-mode, then make test worked.




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

#20456 [NEW]: Apache 2.0.4 and sapi_apache2.c

[ekvin]

From: [EMAIL PROTECTED]
Operating system: Redhat 8.0
PHP version:  4.3.0-pre2
PHP Bug Type: Apache2 related
Bug description:  Apache 2.0.4 and sapi_apache2.c

I know this has been listed before, but not with my os.

httpd: module
"/usr/src/build/144344-i386/BUILD/php-4.2.2/sapi/apache2filter/sapi_apache2.c"
is not compatible with this version of Apache (found 20020628, need
20020903).

I installed 4.3.0-dev yestererday, yet the problem persists.  Where is
that file being called from? I have the latest versions of Apache2 and
php... don't I?
-- 
Edit bug report at http://bugs.php.net/?id=20456&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20456&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20456&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20456&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20456&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20456&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20456&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20456&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20456&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20456&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20456&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20456&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20456&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20456&r=isapi

#20455 [NEW]: Many warnings Warning during "make test" with --enable-safe-mode

[php]

From: [EMAIL PROTECTED]
Operating system: Linux (SusE 8.0, Kernel 2.4.19)
PHP version:  4.3.0-pre2
PHP Bug Type: *Compile Issues
Bug description:  Many warnings Warning during "make test" with --enable-safe-mode

I compiled PHP 4.3.0-pre2 with the congigure option --enable-safemode.
While running "make test" I've got hundreds of Safe-Mode-warnings.
Maipulating all php.ini's I've found on my machine didn't help. The only
thing I was able to to was to run configure and make again without
--enabnle-safe-mode, then make test worked.
-- 
Edit bug report at http://bugs.php.net/?id=20455&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20455&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20455&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20455&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20455&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20455&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20455&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20455&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20455&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20455&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20455&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20455&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20455&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20455&r=isapi

#20433 [Opn]: Unaligned access error messages at runtime

[nohn]

 ID:   20433
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Warning
-Operating System: Tru64
+Operating System: Tru64, NetBSD(Alpha platform)
 PHP Version:  4.3.0-RC1
 New Comment:

Verified on NetBSD/Alpha.


Previous Comments:


[2002-11-15 05:34:33] [EMAIL PROTECTED]

Verified with 4.3.0RC1



[2002-11-14 15:34:13] [EMAIL PROTECTED]

When testing cli/cgi, unaligned access messages are displayed.

Following modifications fixes problem.

in main/php_globals.h
int log_errors_max_len
changed to
long log_errors_max_len

in ext/standard/file.h
int default_socket_timeout
int auto_detect_line_endings
changed to
long default_socket_timeout
long auto_detect_line_endings





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

#19259 [Ctl->Csd]: sort-functions don't work

[nohn]

 ID:   19259
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Critical
+Status:   Closed
 Bug Type: Arrays related
 Operating System: OSF1 V4.0
 PHP Version:  4.3.0 RC1
 New Comment:

Closed. The testcases were wrong, not the function itself.


Previous Comments:


[2002-11-15 10:37:58] [EMAIL PROTECTED]

Broken again in 4.3.0RC1:



/usr/users/nohn/php-4.3.0RC1/ext/standard/tests/array/002.phpt


 EXPECTED OUTPUT
-- Testing arsort() -- 
No second argument:
array(8) {
  ["-2147483647"]=>
  array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
  }
  ["test"]=>
  int(27)
  [2147483647]=>
  string(4) "test"
  [-2147483648]=>
  string(6) "monkey"
  [5]=>
  string(4) "Test"
  [17]=>
  string(27) "PHP: Hypertext Preprocessor"
  [0]=>
  string(3) "PHP"
  [16777216]=>
  float(-0.33)
}
Using SORT_REGULAR:
array(8) {
  ["-2147483647"]=>
  array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
  }
  ["test"]=>
  int(27)
  [2147483647]=>
  string(4) "test"
  [-2147483648]=>
  string(6) "monkey"
  [5]=>
  string(4) "Test"
  [17]=>
  string(27) "PHP: Hypertext Preprocessor"
  [0]=>
  string(3) "PHP"
  [16777216]=>
  float(-0.33)
}
Using SORT_NUMERIC:
array(8) {
  ["test"]=>
  int(27)
  ["-2147483647"]=>
  array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
  }
  [0]=>
  string(3) "PHP"
  [17]=>
  string(27) "PHP: Hypertext Preprocessor"
  [-2147483648]=>
  string(6) "monkey"
  [5]=>
  string(4) "Test"
  [2147483647]=>
  string(4) "test"
  [16777216]=>
  float(-0.33)
}
Using SORT_STRING
array(8) {
  [2147483647]=>
  string(4) "test"
  [-2147483648]=>
  string(6) "monkey"
  [5]=>
  string(4) "Test"
  [17]=>
  string(27) "PHP: Hypertext Preprocessor"
  [0]=>
  string(3) "PHP"
  ["-2147483647"]=>
  array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
  }
  ["test"]=>
  int(27)
  [16777216]=>
  float(-0.33)
}

 -- Testing asort() -- 
No second argument:
array(8) {
  [16777216]=>
  float(-0.33)
  [0]=>
  string(3) "PHP"
  [17]=>
  string(27) "PHP: Hypertext Preprocessor"
  [5]=>
  string(4) "Test"
  [-2147483648]=>
  string(6) "monkey"
  [2147483647]=>
  string(4) "test"
  ["test"]=>
  int(27)
  ["-2147483647"]=>
  array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
  }
}
Using SORT_REGULAR:
array(8) {
  [16777216]=>
  float(-0.33)
  [0]=>
  string(3) "PHP"
  [17]=>
  string(27) "PHP: Hypertext Preprocessor"
  [5]=>
  string(4) "Test"
  [-2147483648]=>
  string(6) "monkey"
  [2147483647]=>
  string(4) "test"
  ["test"]=>
  int(27)
  ["-2147483647"]=>
  array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
  }
}
Using SORT_NUMERIC:
array(8) {
  [16777216]=>
  float(-0.33)
  [-2147483648]=>
  string(6) "monkey"
  [2147483647]=>
  string(4) "test"
  [5]=>
  string(4) "Test"
  [17]=>
  string(27) "PHP: Hypertext Preprocessor"
  [0]=>
  string(3) "PHP"
  ["-2147483647"]=>
  array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
  }
  ["test"]=>
  int(27)
}
Using SORT_STRING
array(8) {
  [16777216]=>
  float(-0.33)
  ["test"]=>
  int(27)
  ["-2147483647"]=>
  array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
  }
  [0]=>
  string(3) "PHP"
  [17]=>
  string(27) "PHP: Hypertext Preprocessor"
  [5]=>
  string(4) "Test"
  [-2147483648]=>
  string(6) "monkey"
  [2147483647]=>
  string(4) "test"
}

 -- Testing krsort() -- 
No second argument:
array(8) {
  [2147483647]=>
  string(4) "test"
  [16777216]=>
  float(-0.33)
  [17]=>
  string(27) "PHP: Hypertext Preprocessor"
  [5]=>
  string(4) "Test"
  ["test"]=>
  int(27)
  [0]=>
  string(3) "PHP"
  ["-2147483647"]=>
  array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
  }
  [-2147483648]=>
  string(6) "monkey"
}
Using SORT_REGULAR:
array(8) {
  [2147483647]=>
  string(4) "test"
  [16777216]=>
  float(-0.33)
  [17]=>
  string(27) "PHP: Hypertext Preprocessor"
  [5]=>
  string(4) "Test"
  ["test"]=>
  int(27)
  [0]=>
  string(3) "PHP"
  ["-2147483647"]=>
  array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
  }
  [-2147483648]=>
  string(6) "monkey"
}
Using SORT_NUMERIC:
array(8) {
  [2147483647]=>
  string(4) "test"
  [16777216]=>
  float(-0.33)
  [17]=>
  string(2

#19529 [Asn->Csd]: Occational "Commands out of sync" errors

[georg]

 ID:   19529
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Closed
 Bug Type: MySQL related
 Operating System: Linux 2.4.18
 PHP Version:  4.2.3
 Assigned To:  georg
 New Comment:

Fixed in cvs/4_3 Branch.




Previous Comments:


[2002-11-12 08:19:05] [EMAIL PROTECTED]

sorry for my wrong reporting, my problem is made by my wrong re-built,
after done ./cvsclean and ./config.nice and make/make install, problem
gone
:)

by now, i have to stick to 4.2.2, hope this bug(#19529) will be fix
soon



[2002-11-12 03:24:36] [EMAIL PROTECTED]

forgot to say, my php is 4.2.2



[2002-11-11 00:18:05] [EMAIL PROTECTED]

i did't get any error with
apache1.3.26
mod php compiled with mysql4.0.2 client lib
connect to mysql4.0.4
but once i rebuild php, with mysql4.0.4 client lib, get the same error
as u
unnable to do mysql_select_db, and unnable to connect from remote,
event use connect do not help(not sure)

hope this info help u guys



[2002-10-24 20:53:27] [EMAIL PROTECTED]

Workarounds:
A) Don't use persistent connections.
B) If you must, you need to edit PHP source, 
ext/mysql/php_mysql.c (I think). Look for a callback 
function that has ROLLBACK in it. Either disable the 
callback or comment out all the lines in it.

PHP 4.3.0 should do (B) over what is in 4.2.1. Better to 
still not have transactional garantee than to break all 
sites and then still not have transactional garantee.

My $0.02.



[2002-10-24 02:33:52] [EMAIL PROTECTED]

Upgraded to PHP 4.2.3, using EZ Portal Content Server.

Linux 2.2.15

MySQL client 3.22.32

Apache 1.3.26

Was working before upgrade to PHP 4.2.3, now getting 30% 
command sync errors, this is not a heavily loaded site, 
just in dev stage. 

I have stopped httpd, mysql, and restarted, and problem is 
exhibited straight away.

Thus doubtful load or time related. 

Turned off persistant connections, problem went away.

Fix soon?



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

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

#20215 [NoF->Opn]: fputs(); (Line Feed / Carriage Return)

[admin]

 ID:   20215
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   No Feedback
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: Windows 2000
 PHP Version:  4.2.3
 New Comment:

The last PHP CVS snapshot (Win32) doesn't correct the bug  
Demo/Source :
http://www.serveurperso.com/temp/fputs.php
The function always adds some incorrects CRLF.


Previous Comments:


[2002-11-16 01:12:37] [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-11-01 16:16:31] [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-11-01 16:05:39] [EMAIL PROTECTED]

To every writings the function "fput" adds jumps of lines in too much.

Sample script :


 

 
 






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