Bug #15926 Updated: sum error

[wei_wang]

 ID:   15926
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: *General Issues
 Operating System: sparc solaris 7
 PHP Version:  4.1.2
 New Comment:

if in sparc solaris 7 ,apache 1.3.23and php4.1.2,run this program ,it
is display :


bill_no=1bill_no=100

the bill_no isn`t add 1

but at x86 solaris 7 ,it is ok!


Previous Comments:


[2002-03-07 02:53:42] [EMAIL PROTECTED]

What is wrong with this?

It prints this for me:
bill_no=1bill_no=101

Derick



[2002-03-07 02:49:01] [EMAIL PROTECTED]

";
$bill_no=100+$bill_no %100;
echo "bill_no=$bill_no";
echo "";
?>




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

Bug #15926 Updated: sum error

[derick]

 ID:   15926
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: *General Issues
 Operating System: sparc solaris 7
 PHP Version:  4.1.2
 New Comment:

What is wrong with this?

It prints this for me:
bill_no=1bill_no=101

Derick


Previous Comments:


[2002-03-07 02:49:01] [EMAIL PROTECTED]

";
$bill_no=100+$bill_no %100;
echo "bill_no=$bill_no";
echo "";
?>




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

Bug #15654 Updated: PHP crashes using the zip functions

[lobbin]

 ID:   15654
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: ZZiplib Related
 Operating System: Mandrake Linux 8.1
 PHP Version:  4.1.1
 New Comment:

I can't reproduce this with current CVS, and latest zziplib (0.10.27).
I tried your zipfile aswell.

Can you try a snapshop from http://snaps.php.net and see if you still
have this crash?

-- robin


Previous Comments:


[2002-02-21 00:58:44] [EMAIL PROTECTED]

The zip functions in PHP4.1.1 appears to be causing PHP to crash with a
segmentation fault. When using it in my project I get a "document
contains no data".

I borrowed the script used in a previous bug report.


[leigh@eden debug]$ php-debug ./test.php 
X-Powered-By: PHP/4.1.1
Content-type: text/html

Ok, entering while..
Segmentation fault (core dumped)

The Backtrace:
(gdb) bt
#0  0x08115b82 in zend_fetch_resource (passed_id=0x81af524,
default_id=-1, resource_type_name=0x8155d4c "Zip Directory",
found_resource_type=0x0, 
num_resource_types=1) at zend_list.c:123
#1  0x080f86a3 in zif_zip_read (ht=1, return_value=0x81af4e4,
this_ptr=0x0, return_value_used=1) at zip.c:154
#2  0x0812e14a in execute (op_array=0x81ab324) at
./zend_execute.c:1590
#3  0x0810fe90 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at zend.c:814
#4  0x08065355 in php_execute_script (primary_file=0xb790) at
main.c:1307
#5  0x08062e4c in main (argc=2, argv=0xb834) at cgi_main.c:738
#6  0x4033f5b0 in __libc_start_main () from /lib/libc.so.6
(gdb) 

The zip was created using the zip.lib.php library used in phpMyAdmin
but the zip does work and the error still occurs when a zip is created
using the zip command on linux.
[leigh@eden debug]$ unzip test_zip.zip 
Archive:  test_zip.zip
  inflating: install/module_info.php  
  inflating: modules/test.php

The zip file I used can be downloaded from:
http://www.sitebox.org/test_zip.zip

I used zziplib-0.10.27 to compile PHP with zip support.

My configure script:'./configure' \
'--disable-static' \
'--enable-debug' \
'--disable-rpath' \
'--enable-pic' \
'--enable-inline-optimization' \
'--prefix=/usr' \
'--with-zlib' \
'--with-config-file-path=/etc' \
'--enable-magic-quotes' \
'--enable-debugger' \
'--enable-track-vars' \
'--enable-safe-mode' \
'--with-regex=system' \
'--with-versioning' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--with-mod_charset' \
'--enable-force-cgi-redirect' \
'--enable-trans-sid' \
'--with-dbase' \
'--with-filepro' \
'--enable-yp' \
'--enable-ftp' \
'--with-xml' \
'--with-gettext' \
'--with-mysql=/usr' \
'--with-pgsql' \
'--with-ldap' \
'--with-interbase=/opt/interbase' \
'--with-zip=/usr/local' \
"$@"





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

Bug #15926: sum error

[wei_wang]

From: [EMAIL PROTECTED]
Operating system: sparc solaris 7
PHP version:  4.1.2
PHP Bug Type: *General Issues
Bug description:  sum error

";
$bill_no=100+$bill_no %100;
echo "bill_no=$bill_no";
echo "";
?>
-- 
Edit bug report at http://bugs.php.net/?id=15926&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15926&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15926&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15926&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15926&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15926&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15926&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15926&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15926&r=submittedtwice

Bug #15925 Updated: ext/gd/config.m4 broken in HEAD

[derick]

 ID:   15925
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Critical
 Bug Type: GD related
-Operating System: doesn't matter a single bit
+Operating System: doesn't matter a single bit
 PHP Version:  4.0CVS-2002-03-07


Previous Comments:


[2002-03-07 02:28:15] [EMAIL PROTECTED]

Guys, ext/gd/config.m4 needs to be fixed before 4.2 goes out.  Right
now
it does a terrible job detecting gd2/freetype2 TTF functions as the
tests
are missing the required -lfreetype.  Rolling back to config.m4 from
the
4.1.2 release makes everything work just fine.

-Rasmus




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

Bug #15925: ext/gd/config.m4 broken in HEAD

[derick]

From: [EMAIL PROTECTED]
Operating system: doesn't matter a single bit
PHP version:  4.0CVS-2002-03-07
PHP Bug Type: GD related
Bug description:  ext/gd/config.m4 broken in HEAD

Guys, ext/gd/config.m4 needs to be fixed before 4.2 goes out.  Right now
it does a terrible job detecting gd2/freetype2 TTF functions as the tests
are missing the required -lfreetype.  Rolling back to config.m4 from the
4.1.2 release makes everything work just fine.

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

Bug #11950 Updated: not sending e-mail at all

[mfischer]

 ID:   11950
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Feedback
 Bug Type: Mail related
 Operating System: Debian Linux
 PHP Version:  4.0.5
 New Comment:

Please upgrade to a newer version and see if the problem still exists.


Previous Comments:


[2002-03-06 17:55:32] [EMAIL PROTECTED]

It happens the same to me when the mail server is running qmail, no
matter the os.



[2001-08-10 11:07:06] [EMAIL PROTECTED]

no feedback



[2001-07-09 03:57:36] [EMAIL PROTECTED]

hm, i can't really belive this ...

can you provide some example code
a little bit more complete?



[2001-07-07 18:08:45] [EMAIL PROTECTED]

A call to the mail function in the form:

   mail .

will not send an e-mail. Using the following format:

  $something = mail .

will send the e-mail correctly.

I've encoutered this problem using the free web hosting provided by
www.f2s.com, who are using Debian Linux.




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

Bug #13595 Updated: Solution for "PHP Fatal error: Unable to start session mm module in Unknown on

[mfischer]

 ID:   13595
 Updated by:   [EMAIL PROTECTED]
-Summary:  Solution for "PHP Fatal error:  Unable to start
   session mm module in Unknown on
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Analyzed
 Bug Type: Session related
 Operating System: Debian Sid
 PHP Version:  4.0.6
 New Comment:

Ah .. interesting ...

Did you set the save path explicitely to '/dev/null' ? (And if so,
why?)

All I know at the moment is that serveral session issues are adressed
at the moment. Marking this as analyzed until one of our session gurus
can answer this more accurat.


Previous Comments:


[2002-03-06 19:50:16] [EMAIL PROTECTED]

Thanks to [EMAIL PROTECTED], I found the problem using strace.  I had
'session.save_path' set to '/dev/null'.  

Why does 4.1.2 not handle this gracefully like 4.0.5, and is there any
way to get a more helpful error message in this case?

In case you're interested in the exact errors, I've included the errors
from the strace below:

unlink("/dev/null/session_mm_apache0.sem") = -1 ENOTDIR (Not a
directory)
open("/dev/null/session_mm_apache0.sem", O_RDWR|O_CREAT, 0600) = -1
ENOTDIR (Not a directory)
unlink("/dev/null/session_mm_apache0.sem") = -1 ENOTDIR (Not a
directory)



[2002-03-05 02:24:42] [EMAIL PROTECTED]

An other alternative would be to use use 'strace' on the apache process
(make sure you start apache with -X switch), maybe you can gather where
it has failed, e.g.

strace -e trace=file -o output /usr/sbin/apache -X

and see in file 'output' what fails.



[2002-03-05 02:17:02] [EMAIL PROTECTED]

Can you try a snapshot from snaps.php.net? It might be fixed, if not we
need feedback on that branch anyways.

regards,
Derick



[2002-03-05 01:48:33] [EMAIL PROTECTED]

I'm seeing this problem on Slackware 8.0, when upgrading 
from the original mod_php.tgz package (PHP 4.0.5) to the 
updated version (PHP 4.1.2).

I already checked, there is no 'session_mm.sem' file to 
remove (stopping apache automatically removes the file).  
So my question is, what is going on, and how do I fix it?



[2001-11-11 12:37:22] [EMAIL PROTECTED]

So it's not a bug in PHP. Thanks & Closing...



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

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

Bug #14733 Updated: header() not working

[php-bugs]

 ID:   14733
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: HTTP related
 Operating System: NT4sp6a
 PHP Version:  4.1.0
 New Comment:

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:


[2002-02-06 00:41:46] [EMAIL PROTECTED]

[EMAIL PROTECTED] - It sounds like your problem was solved. :)

[EMAIL PROTECTED] - If you are still experiencing this problem, please try
this test for me (in case you don't have ethereal as Daniel suggested).
This will help me determine where the problem lies, since there are many
pieces of software involved.

1) Create a simple sample script that has this problem. If your problem
is identical to the original submitter's, it sounds like you just need
one line of code with a call to the header function and use an HTTP
Location header as his example shows.

2) telnet to your web site on port 80
(If your web site is http://www.blah.com/ then telnet www.blah.com 80)

3) Manually type in an HTTP GET request. Here is an example (this is the
smallest request you can get away with):
GET /path/to/script.php HTTP/1.1
Host: blah.com

4) Post the exact output you receive back to this list.

Thanks for helping!

Chris Shiflett



[2002-01-12 11:30:08] [EMAIL PROTECTED]

this problem also exists on W2K IIS 5, Using PHP 4.0.6 CGI



[2002-01-08 13:58:11] [EMAIL PROTECTED]

the problem was O'Reilly Website Pro v3.0. After upgrading to Deerfield
Website Pro 3.1.11, the header() function now works fine!




[2001-12-30 14:22:51] [EMAIL PROTECTED]

could you please dump your webserver's output with ethereal?
http://www.ethereal.com/

thanks



[2001-12-30 14:07:01] [EMAIL PROTECTED]

The webserver is Website Pro 3.



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

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

Bug #14255 Updated: setcookie bug (Cookie is destroyed/Inaccessible)

[php-bugs]

 ID:   14255
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: HTTP related
 Operating System: Debian 2.2.19
 PHP Version:  4.0.6
 Assigned To:  shiflett
 New Comment:

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:


[2002-02-06 14:00:02] [EMAIL PROTECTED]

I'm changing the category to HTTP and status to feedback. I do not think
this is a bug but want to give the submitter time to respond to my
inquiry.



[2002-02-06 12:33:40] [EMAIL PROTECTED]

Is this even a bug?  It's under documentation problem.  Do I need to
change something in the documentation?




[2002-02-03 22:47:01] [EMAIL PROTECTED]

A couple of comments.

Kris, in regards to your comment on NOV-27-2001 at 1:48PM, that code
will fail because you cannot set a cookie and give a Location header in
the same HTTP response. Well, you *can*, but your cookie will not be
set. Since the server would not be able to identify the client without
the cookie, you get the unexpected behavior. This is a protocol-level
situation, but is generally *not* considered a bug in HTTP (in case you
got the feeling I was supporting that idea). Basically, PHP gives you
the freedom to specify your own headers in the HTTP response, but you
need to have a clear grasp of what they do to use them.

So, if this example was a clear illustration of the problem you've been
having, it's not a bug in PHP. You can spread that around to others who
are having the same problems.

Also, in regards to the time/date discussion, it is correct to say that
the browser uses the client time (obviously) to determine whether to
send a cookie along with subsequent HTTP requests. It is also correct to
say that the setcookie function uses the server time to set the
expiration date. However, since both are in GMT as [EMAIL PROTECTED]
explained (sorry, I don't know your name), this only matters if both
clocks are considerably out of sync or if the expiration time of the
cookie is extremely small. If this is a concern, consider using
client-side scripting to set the cookie, so that the browser itself
creates the cookie based on its own time. You can create the client-side
script itself using PHP, so that the cookie's value can still be
dynamically generated by your PHP scripts.

Hope that clears a few things up. If this didn't solve your problem,
please post another small example, and I'll try to reproduce your
environment.



[2001-12-05 06:52:05] [EMAIL PROTECTED]

Timezones do NOT matter. All times are GMT.
>From a HTTP-response: 
Set-Cookie: CookieName=CookieValue; expires=Mon, 28-Jan-02 00:47:45
GMT
So the only thing that should be noted is that the time on client and
server should be in sync for correct behaviour.



[2001-11-28 04:39:25] [EMAIL PROTECTED]

ok, stupid me regarding the claim that a zero value
(or a string as parameter, evaluating to zero)
actualy deletes a cookie

it indeed defines the cookie to be a session cookie
which is valid until the browser is closed instead
of until a certain date/time is reached

for the time parameter itself:
the time() function returns the server time
while the browser deciedes when to delete
a cookie by the client time

if client and server are not in sync or live in
different time zones you will get exactly the 
problems you experienced

you either have to use expiration times in the range of days isntead of
hours (as timezone differences can sum up to slightly more than 24 hours
in the worst case) or you have to use javascript Date.getTime() to fetch
the client time and transfer it to the server as a base for expiration
dates instead of using the time() function on the server

(will add a note to the setcookie documentation and work through the
notes later, bug type switched to documentation problem for now)




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

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

Bug #14032 Updated: Mail() always returns false but mail is sent

[php-bugs]

 ID:   14032
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Mail related
 Operating System: FreeBSD 4.2
 PHP Version:  4.0.6
 New Comment:

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:


[2002-02-18 03:08:21] [EMAIL PROTECTED]

I'm seeing this same problem.  mail() always returns false (looks like a
null string).  I'm also on FreeBSD with the same version of SendMail
(8.11.6)



[2002-02-06 15:47:20] [EMAIL PROTECTED]

Works fine for me...It might be a FreeBSD prob..What mailer are you
using?




[2001-11-12 09:39:33] [EMAIL PROTECTED]

I can see that this has been reported for Solaris too.

mail() always returns false but mail is sent successfully.

I'm running PHP 4.0.6 as an Apache module on a FreeBSD virtual server
host (at digitaldaze.com).

sendmail version is 8.11.6

I can reproduce this with a simple script:

if (mail("[EMAIL PROTECTED]","Test from PHP","Does this work?"))
echo "True";
else
echo "False";

Thanks
Ross





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

Bug #11578 Updated: http header order not respected and messages not transmitted

[php-bugs]

 ID:   11578
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: HTTP related
 Operating System: win32 (nt4 and 2000)
 PHP Version:  4.0.5
 New Comment:

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:


[2002-02-23 04:10:46] [EMAIL PROTECTED]

[EMAIL PROTECTED]  

thanks for your interest in my bugsuite... but i'm sorry to tell you
that the project was closed (due to no feedback..) and i've currently no
samples of my code running.. and i'm in difficult to find the latest
sources, i'll look for them and i'll send you via comments later, (maybe
today)

thank for your interest.
xavier.



[2002-02-06 01:02:54] [EMAIL PROTECTED]

[EMAIL PROTECTED] - Do you have a web site where this sample script
you pasted here is running? It would help me analyze this if I could
view the headers myself.

I have a very strong suspicion about what is going on. The Location
header is not simply another header, but rather it also alters the
server response code to be a 300 level response rather than a 200 OK. I
believe that the Location header might either be:
1) the only header in the response that is sent, so all of your
authentication headers are not sent, or
2) the only header that the HTTP client (browser) bothers to interpret
since the response code is a 301 Moved Permanently.

Your feedback would be greatly appreciated. Thanks for helping!



[2001-06-22 01:13:09] [EMAIL PROTECTED]

yes i've tried this second undocumented argument and like i've explained
it this solve the first part of my problem. but i think that i not
explain my problem correctly.
I call some getallheader successivly after have sended my arguments but
: it doesn't return that i see on the network and if after have written
the content of getallheader if i do a redirection my code doesn't work
(maybe the optimizer change the order of the execution ).
Thanks



[2001-06-21 17:58:53] [EMAIL PROTECTED]

Did you try with the 2nd (undocumented before) argument
for header() like Rasmus suggested??
And it still doesn't work? 





[2001-06-21 09:59:22] [EMAIL PROTECTED]

thanks a lot ramus for your help.. the first part of the problem was my
fault not the php fault.. but... the second part is always not
functionnal...
i can obtain the correct headers and response for the ntlm scheme but..
if i do a header("location : "); at the END of the program... the
value are not written correctly !!
maybe an optimizer miss optimization.
It strange that on a test without redirection all seems correct but
adding instruction after the write and the file was closed and flushed
this is not functionnal...
thank a lot and sorry to spam you with my little problem. but it's a
mission critical projet for France Telecom Mobile service (ORANGE) and i
prefer using php with linux than IIS... i need to prove the
possibilities of the open source platform..
Thank.



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

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

Bug #15924 Updated: mm prevent web server from starting without helpful message

[yohgaki]

 ID:   15924
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Analyzed
 Bug Type: Session related
 Operating System: unix likeos
-PHP Version:  4.0CVS-2002-03-06
+PHP Version:  4.0CVS-2002-03-0


Previous Comments:


[2002-03-06 22:39:47] [EMAIL PROTECTED]

Since Sache removed error message that I've added.
PHP will stop at start without helpful message.

BTW, current implementation is not acceptable, IMHO.
It breaks BC, if user has

session.save_path = "my user handler's db connection parameter here".

They must change their code with current implementaion.




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

Bug #15924: mm prevent web server from starting without helpful message

[yohgaki]

From: [EMAIL PROTECTED]
Operating system: unix likeos
PHP version:  4.0CVS-2002-03-06
PHP Bug Type: Session related
Bug description:  mm prevent web server from starting without helpful message

Since Sache removed error message that I've added.
PHP will stop at start without helpful message.

BTW, current implementation is not acceptable, IMHO.
It breaks BC, if user has

session.save_path = "my user handler's db connection parameter here".

They must change their code with current implementaion.
-- 
Edit bug report at http://bugs.php.net/?id=15924&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15924&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15924&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15924&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15924&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15924&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15924&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15924&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15924&r=submittedtwice

Bug #15727 Updated: session.gc_maxlifetime doesn't work

[yohgaki]

 ID:   15727
 Updated by:   [EMAIL PROTECTED]
-Summary:  session.gc_maxlifetime doesn't work
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  4.0CVS-2002-02-2
 New Comment:

I don't understand you question
Do you want to delete session file after 60 sec?
You cannot do that with files save handler, it does not work that way.


Previous Comments:


[2002-03-06 20:41:27] [EMAIL PROTECTED]

Thanks a lot!
but how should I set the parameter of
session.save_handler = files
now, if I wanna the content of the expired session files can not be
seen at 60 seconds.



[2002-03-06 01:40:27] [EMAIL PROTECTED]

This is not a bug but a limitation of files save handler.
If you don't want to see expired session data. You must implement your
own save handler or try

pgsql (session_pgsql)
or
msession

save handler.





[2002-02-26 03:29:36] [EMAIL PROTECTED]

My OS is Linux,and when I set the parameter 
session.gc_maxlifetime = 60
It should be expired after 60 seconds,but I found it doesn't work.I
also can get varibles once registered and the file is existing, too
bad!!
As i think it is maybe because the existence of cookies make the
uselessness of session.gc_maxlifetime,I set the
session.cookie_lifetime=60,to my surprise,the cookies expired in just 2
minutes and whatever I change the timelimit,it seemed to not about to
work and also expired in the exactly 2 minutes,except the customed 0.
That is concerned parameters in php.ini of my computer.


session.save_handler = files

; Argument passed to save_handler.  In the case of files, this is the
path
; where data files are stored.
session.save_path = /tmp
; where data files are stored.
session.save_path = /tmp

; Whether to use cookies.
session.use_cookies = 1


; Name of the session (used as cookie name).
session.name = PHPSESSID


; Name of the session (used as cookie name).
session.name = PHPSESSID

; Initialize session on request startup.
session.auto_start = 0

; Lifetime in seconds of cookie or, if 0, until browser is restarted.
session.cookie_lifetime = 0

; The path for which the cookie is valid.
session.cookie_path = /

; The domain for which the cookie is valid.
session.cookie_domain =

; Handler used to serialize data.  php is the standard serializer of
PHP.
session.serialize_handler = php

; Percentual probability that the 'garbage collection' process is
started
; on every session initialization.
session.gc_probability = 100

; After this number of seconds, stored data will be seen as 'garbage'
and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 60

; Check HTTP Referer to invalidate externally stored URLs containing
ids.
session.referer_check =

; How many bytes to read from the file.
session.entropy_length = 0

; Specified here to create the session id.
session.entropy_file =

;session.entropy_length = 16

;session.entropy_file = /dev/urandom
 ; Set to {nocache,private,public} to determine HTTP caching aspects.
session.cache_limiter = nocache

; Document expires after n minutes.
session.cache_expire = 180

; use transient sid support if enabled by compiling with
--enable-trans-sid.
session.use_trans_sid = 1

url_rewriter.tags =
"a=href,area=href,frame=src,input=src,form=fakeentry"





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

Bug #15921 Updated: Threads crash while saving current session.

[rlarson]

 ID:   15921
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Duplicate
 Bug Type: Session related
 Operating System: Redhat Linux 7.1
 PHP Version:  4.1.2
 New Comment:

Is there a workaround for it?


Previous Comments:


[2002-03-06 22:08:58] [EMAIL PROTECTED]

Thanks for the report, but It's known issue.
Easy one to fix, but it's not fixed fully yet.

Status = Duplicate



[2002-03-06 21:54:30] [EMAIL PROTECTED]

I have been able to make this happen on a fairly regular basis using a
user defined session handler.. 

You can grap the tarball of the session handler at
http://64.81.150.105/session.tar  

System is a Redhat 7.1.  
MySQL Version 3.23.39
Apache Version 1.3.20
PHP version 4.1.2 as a module
configure line: ./configure  --with-mysql
--with-apxs=/usr/local/apache/bin/apxs --with-gd

here is the bt:

Starting program: /usr/local/apache/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
zend_hash_internal_pointer_reset_ex (ht=0x3, pos=0xb080) at
zend_hash.c:978
978 *pos = ht->pListHead;
(gdb) bt
#0  zend_hash_internal_pointer_reset_ex (ht=0x3, pos=0xb080) at
zend_hash.c:978
#1  0x40267c5f in php_session_save_current_state () at session.c:544
#2  0x4026a1d2 in php_session_flush () at session.c:1381
#3  0x4026a1f7 in zm_deactivate_session (type=1, module_number=3) at
session.c:1393
#4  0x40228cdd in module_registry_cleanup (module=0x80d9178) at
zend_API.c:1165
#5  0x4022a954 in zend_hash_apply (ht=0x4030f460, apply_func=0x40228cb0
) at zend_hash.c:669
#6  0x402258da in zend_deactivate_modules () at zend.c:585
#7  0x402325ff in php_request_shutdown (dummy=0x0) at main.c:723
#8  0x4022fa8c in apache_php_module_main (r=0x80eee4c,
display_source_mode=0) at sapi_apache.c:96
#9  0x4023050e in send_php (r=0x80eee4c, display_source_mode=0,
filename=0x0) at mod_php4.c:575
#10 0x40230562 in send_parsed_php (r=0x80eee4c) at mod_php4.c:590
#11 0x08054633 in ap_invoke_handler () at eval.c:41
#12 0x08068179 in process_request_internal () at eval.c:41
#13 0x080681dc in ap_process_request () at eval.c:41
#14 0x0805f7ae in child_main () at eval.c:41
#15 0x0805f93c in make_child () at eval.c:41
#16 0x0805fa99 in startup_children () at eval.c:41
#17 0x080600d6 in standalone_main () at eval.c:41
#18 0x08060863 in main () at eval.c:41
#19 0x4008fe5e in __libc_start_main (main=0x806051c , argc=2,
ubp_av=0xbb0c, init=0x804ead0 <_init>, 
fini=0x809506c <_fini>, rtld_fini=0x4000d3c4 <_dl_fini>,
stack_end=0xbb04) at ../sysdeps/generic/libc-start.c:129


Starting program: /usr/local/apache/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
zend_hash_get_current_key_ex (ht=0x80fbdbc, str_index=0xb074,
str_length=0xb078, num_index=0xb07c, duplicate=0, 
pos=0xb080) at zend_hash.c:1035
1035if (p->nKeyLength) {
(gdb) bt
#0  zend_hash_get_current_key_ex (ht=0x80fbdbc, str_index=0xb074,
str_length=0xb078, num_index=0xb07c, duplicate=0, 
pos=0xb080) at zend_hash.c:1035
#1  0x40267cb7 in php_session_save_current_state () at session.c:545
#2  0x4026a1d2 in php_session_flush () at session.c:1381
#3  0x4026a1f7 in zm_deactivate_session (type=1, module_number=3) at
session.c:1393
#4  0x40228cdd in module_registry_cleanup (module=0x80d8c10) at
zend_API.c:1165
#5  0x4022a954 in zend_hash_apply (ht=0x4030f460, apply_func=0x40228cb0
) at zend_hash.c:669
#6  0x402258da in zend_deactivate_modules () at zend.c:585
#7  0x402325ff in php_request_shutdown (dummy=0x0) at main.c:723
#8  0x4022fa8c in apache_php_module_main (r=0x80ee8fc,
display_source_mode=0) at sapi_apache.c:96
#9  0x4023050e in send_php (r=0x80ee8fc, display_source_mode=0,
filename=0x0) at mod_php4.c:575
#10 0x40230562 in send_parsed_php (r=0x80ee8fc) at mod_php4.c:590
#11 0x08054633 in ap_invoke_handler () at eval.c:41
#12 0x08068179 in process_request_internal () at eval.c:41
#13 0x080681dc in ap_process_request () at eval.c:41
#14 0x0805f7ae in child_main () at eval.c:41
#15 0x0805f93c in make_child () at eval.c:41
#16 0x0805fa99 in startup_children () at eval.c:41
#17 0x080600d6 in standalone_main () at eval.c:41
#18 0x08060863 in main () at eval.c:41
#19 0x4008fe5e in __libc_start_main (main=0x806051c , argc=2,
ubp_av=0xbb0c, init=0x804ead0 <_init>, 
fini=0x809506c <_fini>, rtld_fini=0x4000d3c4 <_dl_fini>,
stack_end=0xbb04) at ../sysdeps/generic/libc-start.c:129





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

Bug #10585 Updated: Php can't connect to MySQL database

[yohgaki]

 ID:   10585
 Updated by:   [EMAIL PROTECTED]
-Summary:  Php can't connect to MySQL database
-Reported By:  [EMAIL PROTECTED]
+Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Feedback
 Bug Type: MySQL related
 Operating System: redhat 7
 PHP Version:  4.0.5
 New Comment:

And what is your PHP version?


Previous Comments:


[2002-03-06 15:38:52] [EMAIL PROTECTED]

Edit the mysql socket entry in the php.ini file and restart the httpd.

Try this:

mysql.default_socket = /var/lib/mysql/mysql.sock



[2001-05-01 20:24:30] [EMAIL PROTECTED]

There was a bug in the configure. Should be fixed in CVS
now.

--Jani




[2001-05-01 14:53:20] [EMAIL PROTECTED]

most likely a configuration error

ask a support forum like [EMAIL PROTECTED]



[2001-05-01 14:22:05] [EMAIL PROTECTED]

mysql version  3.23.33 All MySQL connections are broken error:

Warning: MySQL Connection Failed: Can't connect to local MySQL server
 through socket '/tmp/mysql.sock' (111) in
 /home/httpd/html/ion/ion/connect.php on line 4






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

Bug #15919 Updated: variables_order not works well

[yohgaki]

 ID:   15919
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Assigned
 Bug Type: PHP options/info functions
 Operating System: Linux
 PHP Version:  4.1.2
-Assigned To:  
+Assigned To:  rasmus
 New Comment:

It's known issue.

I guess Rasmus is working for it (not?)
Rasmus, I'll assign to you for now, since you have been posted the
issue 
to php-dev.


Previous Comments:


[2002-03-06 20:21:59] [EMAIL PROTECTED]

One of my PHP pages uses a global variable which gets its value from
either HTTP GET data or cookies.

Yesterday I upgraded PHP 4.1.2 from 4.0.1 and found that cookie value
prevails GET value for that global variable after hours of debugging.
Of course I have variables_order option set to "GPCS".

Why variables_order does not work correctly after I upgrade?





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

Bug #15923 Updated: unset($_SESSION) does not work

[yohgaki]

 ID:   15923
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Analyzed
 Bug Type: Session related
 Operating System: any
-PHP Version:  4.0CVS-2002-03-06
+PHP Version:  4.0CVS-2002-03-0


Previous Comments:


[2002-03-06 22:04:12] [EMAIL PROTECTED]

Since track vars are now refernece to each other, unset($_SESSION) does
not work. 

When track vars are saved, global symbol should be looked up and to
check if track vars are still there.

Address also shoudl be checked, since user may unset both.




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

Bug #15922 Updated: Possible segfault

[yohgaki]

 ID:   15922
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Analyzed
 Bug Type: Session related
 Operating System: any
-PHP Version:  4.0CVS-2002-03-06
+PHP Version:  4.0CVS-2002-03-0


Previous Comments:


[2002-03-06 22:00:57] [EMAIL PROTECTED]

I haven't try, but according to source unsetting track vars may
segfualt.
This should be fixed.

(i.e. track var's zval refcount is 2)




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

Bug #15921 Updated: Threads crash while saving current session.

[yohgaki]

 ID:   15921
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Duplicate
 Bug Type: Session related
 Operating System: Redhat Linux 7.1
 PHP Version:  4.1.2
 New Comment:

Thanks for the report, but It's known issue.
Easy one to fix, but it's not fixed fully yet.

Status = Duplicate


Previous Comments:


[2002-03-06 21:54:30] [EMAIL PROTECTED]

I have been able to make this happen on a fairly regular basis using a
user defined session handler.. 

You can grap the tarball of the session handler at
http://64.81.150.105/session.tar  

System is a Redhat 7.1.  
MySQL Version 3.23.39
Apache Version 1.3.20
PHP version 4.1.2 as a module
configure line: ./configure  --with-mysql
--with-apxs=/usr/local/apache/bin/apxs --with-gd

here is the bt:

Starting program: /usr/local/apache/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
zend_hash_internal_pointer_reset_ex (ht=0x3, pos=0xb080) at
zend_hash.c:978
978 *pos = ht->pListHead;
(gdb) bt
#0  zend_hash_internal_pointer_reset_ex (ht=0x3, pos=0xb080) at
zend_hash.c:978
#1  0x40267c5f in php_session_save_current_state () at session.c:544
#2  0x4026a1d2 in php_session_flush () at session.c:1381
#3  0x4026a1f7 in zm_deactivate_session (type=1, module_number=3) at
session.c:1393
#4  0x40228cdd in module_registry_cleanup (module=0x80d9178) at
zend_API.c:1165
#5  0x4022a954 in zend_hash_apply (ht=0x4030f460, apply_func=0x40228cb0
) at zend_hash.c:669
#6  0x402258da in zend_deactivate_modules () at zend.c:585
#7  0x402325ff in php_request_shutdown (dummy=0x0) at main.c:723
#8  0x4022fa8c in apache_php_module_main (r=0x80eee4c,
display_source_mode=0) at sapi_apache.c:96
#9  0x4023050e in send_php (r=0x80eee4c, display_source_mode=0,
filename=0x0) at mod_php4.c:575
#10 0x40230562 in send_parsed_php (r=0x80eee4c) at mod_php4.c:590
#11 0x08054633 in ap_invoke_handler () at eval.c:41
#12 0x08068179 in process_request_internal () at eval.c:41
#13 0x080681dc in ap_process_request () at eval.c:41
#14 0x0805f7ae in child_main () at eval.c:41
#15 0x0805f93c in make_child () at eval.c:41
#16 0x0805fa99 in startup_children () at eval.c:41
#17 0x080600d6 in standalone_main () at eval.c:41
#18 0x08060863 in main () at eval.c:41
#19 0x4008fe5e in __libc_start_main (main=0x806051c , argc=2,
ubp_av=0xbb0c, init=0x804ead0 <_init>, 
fini=0x809506c <_fini>, rtld_fini=0x4000d3c4 <_dl_fini>,
stack_end=0xbb04) at ../sysdeps/generic/libc-start.c:129


Starting program: /usr/local/apache/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
zend_hash_get_current_key_ex (ht=0x80fbdbc, str_index=0xb074,
str_length=0xb078, num_index=0xb07c, duplicate=0, 
pos=0xb080) at zend_hash.c:1035
1035if (p->nKeyLength) {
(gdb) bt
#0  zend_hash_get_current_key_ex (ht=0x80fbdbc, str_index=0xb074,
str_length=0xb078, num_index=0xb07c, duplicate=0, 
pos=0xb080) at zend_hash.c:1035
#1  0x40267cb7 in php_session_save_current_state () at session.c:545
#2  0x4026a1d2 in php_session_flush () at session.c:1381
#3  0x4026a1f7 in zm_deactivate_session (type=1, module_number=3) at
session.c:1393
#4  0x40228cdd in module_registry_cleanup (module=0x80d8c10) at
zend_API.c:1165
#5  0x4022a954 in zend_hash_apply (ht=0x4030f460, apply_func=0x40228cb0
) at zend_hash.c:669
#6  0x402258da in zend_deactivate_modules () at zend.c:585
#7  0x402325ff in php_request_shutdown (dummy=0x0) at main.c:723
#8  0x4022fa8c in apache_php_module_main (r=0x80ee8fc,
display_source_mode=0) at sapi_apache.c:96
#9  0x4023050e in send_php (r=0x80ee8fc, display_source_mode=0,
filename=0x0) at mod_php4.c:575
#10 0x40230562 in send_parsed_php (r=0x80ee8fc) at mod_php4.c:590
#11 0x08054633 in ap_invoke_handler () at eval.c:41
#12 0x08068179 in process_request_internal () at eval.c:41
#13 0x080681dc in ap_process_request () at eval.c:41
#14 0x0805f7ae in child_main () at eval.c:41
#15 0x0805f93c in make_child () at eval.c:41
#16 0x0805fa99 in startup_children () at eval.c:41
#17 0x080600d6 in standalone_main () at eval.c:41
#18 0x08060863 in main () at eval.c:41
#19 0x4008fe5e in __libc_start_main (main=0x806051c , argc=2,
ubp_av=0xbb0c, init=0x804ead0 <_init>, 
fini=0x809506c <_fini>, rtld_fini=0x4000d3c4 <_dl_fini>,
stack_end=0xbb04) at ../sysdeps/generic/libc-start.c:129





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

Bug #15086 Updated: trans sid still doesn't work with zlib.compression or ob_gzhandler (PHP 4.1.1)

[yohgaki]

 ID:   15086
 Updated by:   [EMAIL PROTECTED]
-Summary:  trans sid still doesn't work with zlib.compression or
   ob_gzhandler (PHP 4.1.1)
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Closed
 Bug Type: Session related
 Operating System: Debian
 PHP Version:  4.1.1
 Assigned To:  yohgaki
 New Comment:

Thank for feedback.
I'll update doc later so that user know what is going on.


Previous Comments:


[2002-03-06 21:39:54] [EMAIL PROTECTED]

One last update...  :)

Using the php.ini values to turn session.auto_start and
zlib.output_compression also appear to work great.

4.1.2 truly appears to fix this problem.



[2002-03-06 21:36:58] [EMAIL PROTECTED]

Works like a charm!

Just tried 4.1.2 using ob_start("ob_gzhandler") and session_start(),
and the SID was passed perfectly.

I'll fiddle with the php.ini settings too and see how we do, but that's
definitely good enough for me.

Kudos!



[2002-03-06 21:15:44] [EMAIL PROTECTED]

I've tried a number of different combinations of both php.ini settings
(zlib.output_compression and session.auto_start) as well as in-line
function calls (session_start, ob_start("ob_gzhandler")), and in every
situation I've found, the transient SID is lost when compression is
turned on.

Note that I'm using PHP 4.1.1 (4.1.2 is compiling as I type this) on
RedHat Linux 7.2, and did compile it with --enable-trans-sid.

Here's a summary of the 5 different tests I tried:

[Test 1] 
php.ini:
zlib.output_compression = Off
session.auto_start = 0  
--snip--


Testing
--snip--

Result:  PHPSESSID gets appended correctly. 


[Test 2]
php.ini:
zlib.output_compression = Off
session.auto_start = 1  
--snip--


Testing
--snip--

Result:  PHPSESSID gets appended correctly.


[Test 3]
php.ini:
zlib.output_compression = Off
session.auto_start = 0  
--snip--


Testing
--snip--

Result:  PHPSESSID is lost and not appended.


[Test 4]
php.ini:
zlib.output_compression = On
session.auto_start = 0
--snip--


Testing
--snip--

Result:  PHPSESSID is lost and not appended.


[Test 5]
php.ini:
zlib.output_compression = On
session.auto_start = 1
--snip--


Testing
--snip--

Result:  PHPSESSID is lost and not appended.



[2002-03-06 02:56:45] [EMAIL PROTECTED]

Could you try to start session manually in script and report the
result?
Does it work now? I think it should.



[2002-02-06 22:22:03] [EMAIL PROTECTED]

> User should make sure *not* to use session auto start to make trans
sid
> when zlib.ouput compression is enabled. 

should be

User should make sure *not* to use session auto start to make trans sid
work when zlib.ouput compression is enabled. 





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

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

Bug #15923: unset($_SESSION) does not work

[yohgaki]

From: [EMAIL PROTECTED]
Operating system: any
PHP version:  4.0CVS-2002-03-06
PHP Bug Type: Session related
Bug description:  unset($_SESSION) does not work

Since track vars are now refernece to each other, unset($_SESSION) does not
work. 

When track vars are saved, global symbol should be looked up and to check
if track vars are still there.

Address also shoudl be checked, since user may unset both.
-- 
Edit bug report at http://bugs.php.net/?id=15923&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15923&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15923&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15923&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15923&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15923&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15923&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15923&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15923&r=submittedtwice

Bug #15922: Possible segfault

[yohgaki]

From: [EMAIL PROTECTED]
Operating system: any
PHP version:  4.0CVS-2002-03-06
PHP Bug Type: Session related
Bug description:  Possible segfault

I haven't try, but according to source unsetting track vars may segfualt.
This should be fixed.

(i.e. track var's zval refcount is 2)
-- 
Edit bug report at http://bugs.php.net/?id=15922&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15922&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15922&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15922&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15922&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15922&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15922&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15922&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15922&r=submittedtwice

Bug #15921: Threads crash while saving current session.

[rlarson]

From: [EMAIL PROTECTED]
Operating system: Redhat Linux 7.1
PHP version:  4.1.2
PHP Bug Type: Session related
Bug description:  Threads crash while saving current session.

I have been able to make this happen on a fairly regular basis using a user
defined session handler.. 

You can grap the tarball of the session handler at
http://64.81.150.105/session.tar  

System is a Redhat 7.1.  
MySQL Version 3.23.39
Apache Version 1.3.20
PHP version 4.1.2 as a module
configure line: ./configure  --with-mysql
--with-apxs=/usr/local/apache/bin/apxs --with-gd

here is the bt:

Starting program: /usr/local/apache/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
zend_hash_internal_pointer_reset_ex (ht=0x3, pos=0xb080) at
zend_hash.c:978
978 *pos = ht->pListHead;
(gdb) bt
#0  zend_hash_internal_pointer_reset_ex (ht=0x3, pos=0xb080) at
zend_hash.c:978
#1  0x40267c5f in php_session_save_current_state () at session.c:544
#2  0x4026a1d2 in php_session_flush () at session.c:1381
#3  0x4026a1f7 in zm_deactivate_session (type=1, module_number=3) at
session.c:1393
#4  0x40228cdd in module_registry_cleanup (module=0x80d9178) at
zend_API.c:1165
#5  0x4022a954 in zend_hash_apply (ht=0x4030f460, apply_func=0x40228cb0
) at zend_hash.c:669
#6  0x402258da in zend_deactivate_modules () at zend.c:585
#7  0x402325ff in php_request_shutdown (dummy=0x0) at main.c:723
#8  0x4022fa8c in apache_php_module_main (r=0x80eee4c,
display_source_mode=0) at sapi_apache.c:96
#9  0x4023050e in send_php (r=0x80eee4c, display_source_mode=0,
filename=0x0) at mod_php4.c:575
#10 0x40230562 in send_parsed_php (r=0x80eee4c) at mod_php4.c:590
#11 0x08054633 in ap_invoke_handler () at eval.c:41
#12 0x08068179 in process_request_internal () at eval.c:41
#13 0x080681dc in ap_process_request () at eval.c:41
#14 0x0805f7ae in child_main () at eval.c:41
#15 0x0805f93c in make_child () at eval.c:41
#16 0x0805fa99 in startup_children () at eval.c:41
#17 0x080600d6 in standalone_main () at eval.c:41
#18 0x08060863 in main () at eval.c:41
#19 0x4008fe5e in __libc_start_main (main=0x806051c , argc=2,
ubp_av=0xbb0c, init=0x804ead0 <_init>, 
fini=0x809506c <_fini>, rtld_fini=0x4000d3c4 <_dl_fini>,
stack_end=0xbb04) at ../sysdeps/generic/libc-start.c:129


Starting program: /usr/local/apache/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
zend_hash_get_current_key_ex (ht=0x80fbdbc, str_index=0xb074,
str_length=0xb078, num_index=0xb07c, duplicate=0, 
pos=0xb080) at zend_hash.c:1035
1035if (p->nKeyLength) {
(gdb) bt
#0  zend_hash_get_current_key_ex (ht=0x80fbdbc, str_index=0xb074,
str_length=0xb078, num_index=0xb07c, duplicate=0, 
pos=0xb080) at zend_hash.c:1035
#1  0x40267cb7 in php_session_save_current_state () at session.c:545
#2  0x4026a1d2 in php_session_flush () at session.c:1381
#3  0x4026a1f7 in zm_deactivate_session (type=1, module_number=3) at
session.c:1393
#4  0x40228cdd in module_registry_cleanup (module=0x80d8c10) at
zend_API.c:1165
#5  0x4022a954 in zend_hash_apply (ht=0x4030f460, apply_func=0x40228cb0
) at zend_hash.c:669
#6  0x402258da in zend_deactivate_modules () at zend.c:585
#7  0x402325ff in php_request_shutdown (dummy=0x0) at main.c:723
#8  0x4022fa8c in apache_php_module_main (r=0x80ee8fc,
display_source_mode=0) at sapi_apache.c:96
#9  0x4023050e in send_php (r=0x80ee8fc, display_source_mode=0,
filename=0x0) at mod_php4.c:575
#10 0x40230562 in send_parsed_php (r=0x80ee8fc) at mod_php4.c:590
#11 0x08054633 in ap_invoke_handler () at eval.c:41
#12 0x08068179 in process_request_internal () at eval.c:41
#13 0x080681dc in ap_process_request () at eval.c:41
#14 0x0805f7ae in child_main () at eval.c:41
#15 0x0805f93c in make_child () at eval.c:41
#16 0x0805fa99 in startup_children () at eval.c:41
#17 0x080600d6 in standalone_main () at eval.c:41
#18 0x08060863 in main () at eval.c:41
#19 0x4008fe5e in __libc_start_main (main=0x806051c , argc=2,
ubp_av=0xbb0c, init=0x804ead0 <_init>, 
fini=0x809506c <_fini>, rtld_fini=0x4000d3c4 <_dl_fini>,
stack_end=0xbb04) at ../sysdeps/generic/libc-start.c:129

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

Bug #15086 Updated: trans sid still doesn't work with zlib.compression or ob_gzhandler (PHP 4.1.1)

[php]

 ID:   15086
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Session related
 Operating System: Debian
 PHP Version:  4.1.1
 Assigned To:  yohgaki
 New Comment:

One last update...  :)

Using the php.ini values to turn session.auto_start and
zlib.output_compression also appear to work great.

4.1.2 truly appears to fix this problem.


Previous Comments:


[2002-03-06 21:36:58] [EMAIL PROTECTED]

Works like a charm!

Just tried 4.1.2 using ob_start("ob_gzhandler") and session_start(),
and the SID was passed perfectly.

I'll fiddle with the php.ini settings too and see how we do, but that's
definitely good enough for me.

Kudos!



[2002-03-06 21:15:44] [EMAIL PROTECTED]

I've tried a number of different combinations of both php.ini settings
(zlib.output_compression and session.auto_start) as well as in-line
function calls (session_start, ob_start("ob_gzhandler")), and in every
situation I've found, the transient SID is lost when compression is
turned on.

Note that I'm using PHP 4.1.1 (4.1.2 is compiling as I type this) on
RedHat Linux 7.2, and did compile it with --enable-trans-sid.

Here's a summary of the 5 different tests I tried:

[Test 1] 
php.ini:
zlib.output_compression = Off
session.auto_start = 0  
--snip--


Testing
--snip--

Result:  PHPSESSID gets appended correctly. 


[Test 2]
php.ini:
zlib.output_compression = Off
session.auto_start = 1  
--snip--


Testing
--snip--

Result:  PHPSESSID gets appended correctly.


[Test 3]
php.ini:
zlib.output_compression = Off
session.auto_start = 0  
--snip--


Testing
--snip--

Result:  PHPSESSID is lost and not appended.


[Test 4]
php.ini:
zlib.output_compression = On
session.auto_start = 0
--snip--


Testing
--snip--

Result:  PHPSESSID is lost and not appended.


[Test 5]
php.ini:
zlib.output_compression = On
session.auto_start = 1
--snip--


Testing
--snip--

Result:  PHPSESSID is lost and not appended.



[2002-03-06 02:56:45] [EMAIL PROTECTED]

Could you try to start session manually in script and report the
result?
Does it work now? I think it should.



[2002-02-06 22:22:03] [EMAIL PROTECTED]

> User should make sure *not* to use session auto start to make trans
sid
> when zlib.ouput compression is enabled. 

should be

User should make sure *not* to use session auto start to make trans sid
work when zlib.ouput compression is enabled. 





[2002-02-06 22:20:52] [EMAIL PROTECTED]

Note to this report.

The reason trans sid does not work is related to output handler
registration order.  This is not a simple fix at all.  (I might set
status to Suspended)

User should make sure *not* to use session auto start to make trans sid
when zlib.ouput compression is enabled. 

The reason SID is not defined is not related to output control.  
I also made a patch to define SID constant always, but it's not applied
to CVS. (yet) 

If you have problem with SID not defined *even if* you have used
--enable-trans-sid when you configure PHP and session.trans_sid = 1 in
your php.ini, please submit a new bug report as session problem.



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

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

Bug #15086 Updated: trans sid still doesn't work with zlib.compression or ob_gzhandler (PHP 4.1.1)

[php]

 ID:   15086
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Session related
 Operating System: Debian
 PHP Version:  4.1.1
 Assigned To:  yohgaki
 New Comment:

Works like a charm!

Just tried 4.1.2 using ob_start("ob_gzhandler") and session_start(),
and the SID was passed perfectly.

I'll fiddle with the php.ini settings too and see how we do, but that's
definitely good enough for me.

Kudos!


Previous Comments:


[2002-03-06 21:15:44] [EMAIL PROTECTED]

I've tried a number of different combinations of both php.ini settings
(zlib.output_compression and session.auto_start) as well as in-line
function calls (session_start, ob_start("ob_gzhandler")), and in every
situation I've found, the transient SID is lost when compression is
turned on.

Note that I'm using PHP 4.1.1 (4.1.2 is compiling as I type this) on
RedHat Linux 7.2, and did compile it with --enable-trans-sid.

Here's a summary of the 5 different tests I tried:

[Test 1] 
php.ini:
zlib.output_compression = Off
session.auto_start = 0  
--snip--


Testing
--snip--

Result:  PHPSESSID gets appended correctly. 


[Test 2]
php.ini:
zlib.output_compression = Off
session.auto_start = 1  
--snip--


Testing
--snip--

Result:  PHPSESSID gets appended correctly.


[Test 3]
php.ini:
zlib.output_compression = Off
session.auto_start = 0  
--snip--


Testing
--snip--

Result:  PHPSESSID is lost and not appended.


[Test 4]
php.ini:
zlib.output_compression = On
session.auto_start = 0
--snip--


Testing
--snip--

Result:  PHPSESSID is lost and not appended.


[Test 5]
php.ini:
zlib.output_compression = On
session.auto_start = 1
--snip--


Testing
--snip--

Result:  PHPSESSID is lost and not appended.



[2002-03-06 02:56:45] [EMAIL PROTECTED]

Could you try to start session manually in script and report the
result?
Does it work now? I think it should.



[2002-02-06 22:22:03] [EMAIL PROTECTED]

> User should make sure *not* to use session auto start to make trans
sid
> when zlib.ouput compression is enabled. 

should be

User should make sure *not* to use session auto start to make trans sid
work when zlib.ouput compression is enabled. 





[2002-02-06 22:20:52] [EMAIL PROTECTED]

Note to this report.

The reason trans sid does not work is related to output handler
registration order.  This is not a simple fix at all.  (I might set
status to Suspended)

User should make sure *not* to use session auto start to make trans sid
when zlib.ouput compression is enabled. 

The reason SID is not defined is not related to output control.  
I also made a patch to define SID constant always, but it's not applied
to CVS. (yet) 

If you have problem with SID not defined *even if* you have used
--enable-trans-sid when you configure PHP and session.trans_sid = 1 in
your php.ini, please submit a new bug report as session problem.



[2002-01-17 11:03:34] [EMAIL PROTECTED]

When I compress my output with ob_gzhandler or with
zlib.output_compression trans sid doesn't work.
Without output compression trans sid works fine.
I use PHP 4.1.1 (Debian Package)

In following code php doesn't add the sid to the testlink
(sessioncookies are off)



Testlink






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

Bug #15086 Updated: trans sid still doesn't work with zlib.compression or ob_gzhandler (PHP 4.1.1)

[php]

 ID:   15086
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Session related
 Operating System: Debian
 PHP Version:  4.1.1
 Assigned To:  yohgaki
 New Comment:

I've tried a number of different combinations of both php.ini settings
(zlib.output_compression and session.auto_start) as well as in-line
function calls (session_start, ob_start("ob_gzhandler")), and in every
situation I've found, the transient SID is lost when compression is
turned on.

Note that I'm using PHP 4.1.1 (4.1.2 is compiling as I type this) on
RedHat Linux 7.2, and did compile it with --enable-trans-sid.

Here's a summary of the 5 different tests I tried:

[Test 1] 
php.ini:
zlib.output_compression = Off
session.auto_start = 0  
--snip--


Testing
--snip--

Result:  PHPSESSID gets appended correctly. 


[Test 2]
php.ini:
zlib.output_compression = Off
session.auto_start = 1  
--snip--


Testing
--snip--

Result:  PHPSESSID gets appended correctly.


[Test 3]
php.ini:
zlib.output_compression = Off
session.auto_start = 0  
--snip--


Testing
--snip--

Result:  PHPSESSID is lost and not appended.


[Test 4]
php.ini:
zlib.output_compression = On
session.auto_start = 0
--snip--


Testing
--snip--

Result:  PHPSESSID is lost and not appended.


[Test 5]
php.ini:
zlib.output_compression = On
session.auto_start = 1
--snip--


Testing
--snip--

Result:  PHPSESSID is lost and not appended.


Previous Comments:


[2002-03-06 02:56:45] [EMAIL PROTECTED]

Could you try to start session manually in script and report the
result?
Does it work now? I think it should.



[2002-02-06 22:22:03] [EMAIL PROTECTED]

> User should make sure *not* to use session auto start to make trans
sid
> when zlib.ouput compression is enabled. 

should be

User should make sure *not* to use session auto start to make trans sid
work when zlib.ouput compression is enabled. 





[2002-02-06 22:20:52] [EMAIL PROTECTED]

Note to this report.

The reason trans sid does not work is related to output handler
registration order.  This is not a simple fix at all.  (I might set
status to Suspended)

User should make sure *not* to use session auto start to make trans sid
when zlib.ouput compression is enabled. 

The reason SID is not defined is not related to output control.  
I also made a patch to define SID constant always, but it's not applied
to CVS. (yet) 

If you have problem with SID not defined *even if* you have used
--enable-trans-sid when you configure PHP and session.trans_sid = 1 in
your php.ini, please submit a new bug report as session problem.



[2002-01-17 11:03:34] [EMAIL PROTECTED]

When I compress my output with ob_gzhandler or with
zlib.output_compression trans sid doesn't work.
Without output compression trans sid works fine.
I use PHP 4.1.1 (Debian Package)

In following code php doesn't add the sid to the testlink
(sessioncookies are off)



Testlink






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

Bug #15920: range() with a step parameter

[pgerzson]

From: [EMAIL PROTECTED]
Operating system: Any
PHP version:  4.1.2
PHP Bug Type: Feature/Change Request
Bug description:  range() with a step parameter

I think it would be useful in some situation if the range() function can
take a third optional parameter (called "step" or whatever you want) which
specifies the space between two consecutive elements in the resulting
array. For example:

$array = range(1, 5, 2); // array(1,3,5);

It might be always positive to understand its effect easily.

$array = range('Z', 'A', 3); // array('Z', 'W', 'T', 'Q', ...);

If the second boundary cannot be included regarding to the step parameter,
just simply leave it out:

$array = range(1, 6, 2); // array(1,3,5);


That's all.

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

Bug #15727 Updated: session.gc_maxlifetime doesn't work

[zhaoxd]

 ID:   15727
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  4.0CVS-2002-02-2
 New Comment:

Thanks a lot!
but how should I set the parameter of
session.save_handler = files
now, if I wanna the content of the expired session files can not be
seen at 60 seconds.


Previous Comments:


[2002-03-06 01:40:27] [EMAIL PROTECTED]

This is not a bug but a limitation of files save handler.
If you don't want to see expired session data. You must implement your
own save handler or try

pgsql (session_pgsql)
or
msession

save handler.





[2002-02-26 03:29:36] [EMAIL PROTECTED]

My OS is Linux,and when I set the parameter 
session.gc_maxlifetime = 60
It should be expired after 60 seconds,but I found it doesn't work.I
also can get varibles once registered and the file is existing, too
bad!!
As i think it is maybe because the existence of cookies make the
uselessness of session.gc_maxlifetime,I set the
session.cookie_lifetime=60,to my surprise,the cookies expired in just 2
minutes and whatever I change the timelimit,it seemed to not about to
work and also expired in the exactly 2 minutes,except the customed 0.
That is concerned parameters in php.ini of my computer.


session.save_handler = files

; Argument passed to save_handler.  In the case of files, this is the
path
; where data files are stored.
session.save_path = /tmp
; where data files are stored.
session.save_path = /tmp

; Whether to use cookies.
session.use_cookies = 1


; Name of the session (used as cookie name).
session.name = PHPSESSID


; Name of the session (used as cookie name).
session.name = PHPSESSID

; Initialize session on request startup.
session.auto_start = 0

; Lifetime in seconds of cookie or, if 0, until browser is restarted.
session.cookie_lifetime = 0

; The path for which the cookie is valid.
session.cookie_path = /

; The domain for which the cookie is valid.
session.cookie_domain =

; Handler used to serialize data.  php is the standard serializer of
PHP.
session.serialize_handler = php

; Percentual probability that the 'garbage collection' process is
started
; on every session initialization.
session.gc_probability = 100

; After this number of seconds, stored data will be seen as 'garbage'
and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 60

; Check HTTP Referer to invalidate externally stored URLs containing
ids.
session.referer_check =

; How many bytes to read from the file.
session.entropy_length = 0

; Specified here to create the session id.
session.entropy_file =

;session.entropy_length = 16

;session.entropy_file = /dev/urandom
 ; Set to {nocache,private,public} to determine HTTP caching aspects.
session.cache_limiter = nocache

; Document expires after n minutes.
session.cache_expire = 180

; use transient sid support if enabled by compiling with
--enable-trans-sid.
session.use_trans_sid = 1

url_rewriter.tags =
"a=href,area=href,frame=src,input=src,form=fakeentry"





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

Bug #14497 Updated: PHP causes segfault when session handler=user

[yohgaki]

 ID:   14497
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Analyzed
 Bug Type: Session related
 Operating System: FreeBSD 4.4-Stable
-PHP Version:  4.1.0, 4-200112131200
+PHP Version:  4.1.0, 4-2001121
 Assigned To:  yohgaki


Previous Comments:


[2002-02-02 22:18:22] [EMAIL PROTECTED]

This bug has been fixed in CVS.



[2002-01-06 22:23:57] [EMAIL PROTECTED]

I've not committed the fix for this bug yet, but you can work around
the segfault. 

Return string when there is no data to read or failed to write. (i.e.
return '';) User session save handler expect string data, if you return
other than string, it segfualts.




[2001-12-21 03:36:49] [EMAIL PROTECTED]

Assigned to myself. By the I updated this bug report, I know the fix,
but I forgot what is was now :(  
I'll work on this after I finish things have to do




[2001-12-19 23:00:15] [EMAIL PROTECTED]

Is this fixed?
Anyone mind if I fix this and commit?
--
Yasuo Ohgaki




[2001-12-14 16:00:04] [EMAIL PROTECTED]

I had already tried out your user handlers (as you can see from the bug
report).  Your handlers weren't causing the crash but were helping in
making the crash happen. (I would guess that the initialization of the
internal data structures from your handlers allowed the invalid "return
false;" pointer to be fubar'd in such a way to cause a segfault.)

Read the bug report, it's all there, including on how I was reproducing
the crash.

Your session handlers have a few problems when there is concurrent
access for the same session id.  (It *DOES* happen, especially with
AvantGo clients, trust me on this one)  You also do not check for
expiration in your session_read.  Since garbage collection doesn't
happen on every single access, there's a possibility that stale data
would get loaded.

Also, since your session handlers aren't mentioned anywhere on the PHP
website under the session documentation, as well as not stressing the
fact that returning false will cause data corruption, it still doesn't
really address the issue.  

Personally I don't think the doing something in a script language
should cause a low-level crash. I believe there was another recent bug
dealing with the xslt extension that explained this issue well: "But
PHP generating nice corefiles is not ok."

At most I think PHP should return an error when the data isn't what was
expected, not segfault, or core, or crash.




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

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

Bug #14834 Updated: SegFault when passing HTTP_SESSION_VARS

[yohgaki]

 ID:   14834
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Analyzed
 Bug Type: Session related
 Operating System: Debian 3.0 (Woody)
 PHP Version:  4.1.0
 Assigned To:  yohgaki
 New Comment:

There is problem still


Previous Comments:


[2002-03-05 18:35:53] [EMAIL PROTECTED]

This bug has been fixed in CVS.

It's probably fixed in CVS. Please reopen if there is the problem.



[2002-03-05 03:43:55] [EMAIL PROTECTED]

Zeev was tried to fix (the idea was the same as mine when I update this
report)

There are issue about wrong reference to $_SESSION and
$HTTP_SESSION_VARS even with the patch. Therefore, I 
didn't committed. Problem is solved partially, there is a _serious_
problem for $_SESSION/$HTTP_SESSION_VARS.

This will be fixed by 4.2.0




[2002-02-13 22:39:44] [EMAIL PROTECTED]

Will be fixed soon



[2002-01-16 12:41:20] [EMAIL PROTECTED]

Confirmed with CVS snapshot php4-200201160300 (compiled as CGI), Linux
2.4.12.

PHP configuration is:
./configure --enable-debug



And another test case:




And the backtrace:


#0  0x8114b7e in _zend_is_inconsistent (ht=0x5a5a5a5a, file=0x8161e04
"zend_hash.c", line=975) at zend_hash.c:84
#1  0x8117116 in zend_hash_internal_pointer_reset_ex (ht=0x5a5a5a5a,
pos=0xb320) at zend_hash.c:975
#2  0x808c5e2 in php_session_save_current_state () at session.c:577
#3  0x808ecb5 in php_session_flush () at session.c:1450
#4  0x808ece6 in zm_deactivate_session (type=1, module_number=3) at
session.c:1467
#5  0x8113dbc in module_registry_cleanup (module=0x81ab508) at
zend_API.c:1166
#6  0x811664c in zend_hash_apply (ht=0x818b920, apply_func=0x8113d84
) at zend_hash.c:669
#7  0x8110d57 in zend_deactivate_modules () at zend.c:581
#8  0x806126e in php_request_shutdown (dummy=0x0) at main.c:722
#9  0x805fe14 in main (argc=2, argv=0xb9f4) at cgi_main.c:798
#10 0x400a5577 in __libc_start_main () from /lib/libc.so.6


The backtrace is the same as the one generated by the previous test
case.



[2002-01-06 22:30:18] [EMAIL PROTECTED]

Confirmed with 4.2.0-dev (2002/1/7). It does segfault with my linux
also.



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

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

Bug #15919: variables_order not works well

[mars]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.1.2
PHP Bug Type: PHP options/info functions
Bug description:  variables_order not works well

One of my PHP pages uses a global variable which gets its value from either
HTTP GET data or cookies.

Yesterday I upgraded PHP 4.1.2 from 4.0.1 and found that cookie value
prevails GET value for that global variable after hours of debugging. Of
course I have variables_order option set to "GPCS".

Why variables_order does not work correctly after I upgrade?

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

Bug #14780 Updated: Segmentation fault with "mm",PHP works fine with "files"

[yohgaki]

 ID:   14780
 Updated by:   [EMAIL PROTECTED]
-Summary:  Segmentation fault with "mm",PHP  works fine with
   "files"
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Analyzed
 Bug Type: Session related
 Operating System: RH 7.2
 PHP Version:  4.1.1
 Assigned To:  yohgaki


Previous Comments:


[2002-01-07 01:17:49] [EMAIL PROTECTED]

I haven't changed any, but it stopped segfaulting after cvs udpate.
Fixed in 4.2.0-dev.
Please reopen this report if you still have problem with 4.2.0-dev.



[2002-01-06 22:11:10] [EMAIL PROTECTED]

Changed Status to Critical.

There are many problems with external session save handlers.



[2002-01-06 22:01:57] [EMAIL PROTECTED]

Found the cause and work around. (Use of session_module_name() is
causing race) I need to reconsider how to make a real fix for this
segfault :)





[2002-01-06 06:19:55] [EMAIL PROTECTED]

Hi,

Here is my configure statement. Notice there's no pgsql:

./configure --with-mm --enable-inline-optimization --with-zlib
--with-oci8=/u01/app/or
acle/product/8.1.7 --disable-onstatement --enable-ftp --with-apxs 
--enable-shmop --en
able-sysvsem --with-gd


John Lim



[2002-01-02 17:08:20] [EMAIL PROTECTED]

I noticed this problem before your report :) It's not a mm, but pgsql
save handler though. Root of the problem is the same, I guess. 
I'm not 100% sure, yet, but multiple close calls may be the cause.





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

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

Bug #14628 Updated: Session functions block on lock

[yohgaki]

 ID:   14628
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Analyzed
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  4.1.0
 Assigned To:  yohgaki


Previous Comments:


[2002-03-06 02:51:10] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Since I've changed my patch a little. I'm not sure if it really fixed
or not.
If you still have this problem, please reopen. 



[2002-02-03 19:46:58] [EMAIL PROTECTED]

This may be fixed my patch



[2002-01-07 05:38:26] [EMAIL PROTECTED]

Hi

We are not running apache. We are runnig zeus with php running as a
fastcgi responder.  At the moment, I am running a script which checks
the state of the fastcgi/php processes and kill sany if locked on
opening session file for more than 30 seconds.

Thanks





[2002-01-06 20:17:07] [EMAIL PROTECTED]

I guess your httpd is crashing. Please check your apache log. Do you
get core file?





[2001-12-22 06:12:34] [EMAIL PROTECTED]

Hi

No Frames involved.  Thanks 

Chris




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

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

Bug #15096 Updated: Sessions with null session ID in the cookie crash PHP

[yohgaki]

 ID:   15096
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Analyzed
 Bug Type: Session related
 Operating System: Linux i686 2.4.16 SMP
 PHP Version:  4.1.1
 Assigned To:  yohgaki


Previous Comments:


[2002-03-05 18:35:07] [EMAIL PROTECTED]

This bug has been fixed in CVS.

It's probably fixed in CVS. Please reopen if there is the problem.



[2002-02-03 19:56:56] [EMAIL PROTECTED]

I haven't look a this report closely, but the backtrace is similar to
that I've seen. It may be fixed by my patch. Assigned to me for now.



[2002-01-18 10:07:10] [EMAIL PROTECTED]

Marking as critical until this is checked out.



[2002-01-18 05:03:09] [EMAIL PROTECTED]


First some brief history: last time I developed a session-based app
with PHP 4.0.6, sometimes and without a pattern when deleting a session
the client would end up with a session cookie which said
"PHPSESSID=deleted". The next time he visited the site his session
would have the ID "deleted" and when two users triggered the same bug
they would both end up as being logged in as someone else. So I put in
a simple check in my code which would forcibly kill the session, delete
the cookie and set the new session name to something random.

A version of the code under PHP 4.1.1 crashes PHP and causes "[notice]
child pid 14151 exit signal Segmentation fault (11)" in Apache's error
log.

Here is a sample page which triggers PHP to crash: (if the html gets
messed up email me for a copy)

--- snip session-tester.php


test


";
while( list( $n, $v ) = each( $array ) )
{
echo "$n$v\n";
}
echo "\n";
}

// if we got called with ?logout=true then the user wants to
end the session.
if (isset($HTTP_GET_VARS["logout"]))
{
session_start(); // it wasnt called yet.
session_unset();
session_destroy();

// REFERENCE #1 (OK)
//  setcookie(session_name(), session_id(), 0);

// REFERENCE #2 (NOT OK) - crashes
//  setcookie(session_name());

//  different ways of doing things after logging out -
echoing 'you are logged out' or redirecting back
//  into a new session.
//  header("Location: /session-tester.php");
echo "Okie, you are logged out... click here.";
exit;
}
else // user is not logging out
{
session_start();
session_register("somevar");
$HTTP_SESSION_VARS["somevar"]++;
}
?>
Welcome to the session tester. 
Click here to log
out (reset session).
Your session variable 'somevar' currently has the value
.
Your session cookie has the following parameters:
Your \$HTTP_COOKIE_VARS contains:";
tableprint($HTTP_COOKIE_VARS);
?>



--- snip session-tester.php


When opening the page, the session is initialized. If the page is
requested with ?logout=true, we enter the critical piece of code. If
'reference #1' line is uncommented, everything works fine and the
cookie is deleted (well, in some browsers, at least) which is the
behaviour I want.

However, line reference #2 (setcookie(session_name());) when
uncommented causes the client to store the session cookie with
PHPSESSID="". On subsequent requests to the page this crashes the
server's process. There is no way that the client with the null session
ID cookie can browse this page without crashing the server process, and
there is no way that the server can delete that cookie. The client has
to close the browser to end the session and destroy the cookie and only
then it will work again. Tested on IE6, Mozilla 0.9.7, Konqueror, etc.


GDB-ing httpd -X gives this:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 12935)]
zend_hash_internal_pointer_reset_ex (ht=0x0, pos=0xbfffeea8) at
zend_hash.c:984
984 *pos = ht->pListHead;
(gdb) where
#0  zend_hash_internal_pointer_reset_ex (ht=0x0, pos=0xbfffeea8) at
zend_hash.c:984
#1  0x080903bb in php_session_save_current_state () at session.c:544
#2  0x08092530 in php_session_flush () at session.c:1381
#3  0x08092553 in zm_deactivate_session (type=1, module_number=12) at
session.c:1393
#4  0x080f1011 in module_registry_cleanup (module=0x824a1a8) at
zend_API.c:1165
#5  0x080f296c in zend_hash_apply (ht=0x81efaa0, apply_func=0x80f0fe4
) at zend_hash.c:675
#6  0x080ee5b1 in zend_deactivate_modules () at

Bug #15168 Updated: (mm save handler) PHP segfaults saving sessions-vars

[yohgaki]

 ID:   15168
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Analyzed
 Bug Type: Session related
 Operating System: SuSE 7.3 /2.4.10
 PHP Version:  4.1.1
 Assigned To:  yohgaki


Previous Comments:


[2002-02-05 11:40:28] [EMAIL PROTECTED]

This bug has been fixed in CVS.



[2002-02-03 20:01:39] [EMAIL PROTECTED]

Will be fixed soon.



[2002-02-02 22:21:52] [EMAIL PROTECTED]

Changed summay (Added "mm save handler")



[2002-01-23 04:38:05] [EMAIL PROTECTED]

It's not a solution, but a workaround.
You can try user, msession or session_pgsql save handler module.

User is compile in by default.
--with-msession for msession (And you need lib and daemon for it. Refer
to manual)
session_pgsql is under PEAR CVS (/pear/PECL).

user/msession/session_pgsql works fine for me. (msession/session_pgsql
are experimental modules)




[2002-01-23 02:54:11] [EMAIL PROTECTED]

Seems that i get no segfaults with file, but i am loosing some of its
data. 

while $obj->ary(key=>value,key=>value); seems to survive, 
$obj->ary(key=>ary(key=>value)) seems to leave under certain
circumstances. will try to get this into a small example. 

Regards, 
Johann-Peter Hartmann



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

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

Bug #15322 Updated: php.ini : session.use_trans_sid=0 disables session-id creation too

[yohgaki]

 ID:   15322
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Analyzed
 Bug Type: Session related
 Operating System: SuSe 7.3
 PHP Version:  4.1.1
 Assigned To:  yohgaki


Previous Comments:


[2002-03-05 18:31:34] [EMAIL PROTECTED]

This bug has been fixed in CVS.





[2002-02-13 22:42:09] [EMAIL PROTECTED]

Will be fixed soon



[2002-02-04 03:33:52] [EMAIL PROTECTED]

In versions <4.1.x I did not compile with --enable-trans-sid, had
session.use_trans_sid=1 and used . The result was one
session-id. After the upgrade to 4.1.x I
get each session-id twice. All compiler settings remained
the same. As I understand --enable-trans-sid is now the default.

But how to get the same behaviour as before and is the implicit disable
of  by intention?

Further I'm not sure if the modification of the url_rewriter.tags is
the right way to handle this?



[2002-02-03 19:39:03] [EMAIL PROTECTED]

Current code does not set SID when trans sid is off.

Is there any version that does initialize SID always?



[2002-02-01 08:20:06] [EMAIL PROTECTED]

Before 4.1.x I didn't compile with --enable-trans-sid and used instead
the  expression
on pages very often.

With the new releases and --enable-trans-sid as default I now get the
session-id twice on every link 
which is the expected behaviour on first hand. I didn't want to edit
all pages.

My idea was to set "session.use_trans_sid=0" in php.ini to disable the
auto-session generation.

After this, even  does no longer generate a session-id, which
seems to be a bug!?

The only quick hack for the moment was to have
"session.use_trans_sid=1" and to modify
the url_rewriter.tags in php.ini:

Original: url_rewriter.tags =
"a=href,area=href,frame=src,input=src,form=fakeentry"

Modified: url_rewriter.tags =
"area=href,frame=src,input=src,form=fakeentry"

Is the new behaviour a feature or a bug?

Guenther




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

Bug #15359 Updated: php crashes if temp dir does not exist

[yohgaki]

 ID:   15359
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Analyzed
 Bug Type: Session related
 Operating System: winxp pro
 PHP Version:  4.1.1
 Assigned To:  yohgaki


Previous Comments:


[2002-03-06 01:26:35] [EMAIL PROTECTED]

This bug has been fixed in CVS.





[2002-02-03 19:27:22] [EMAIL PROTECTED]

Sorry, I've reverted the patch and I'm preparing new one and if it's
ok, it will be applied. 

Please wait a few days.



[2002-02-03 16:19:44] [EMAIL PROTECTED]

Yasuo Ohgaki fixed this in CVS some days ago



[2002-02-03 16:17:30] [EMAIL PROTECTED]

Oh.. The apache error log says:
Premature end of script headers.

Not a very good error message imo.



[2002-02-03 16:16:29] [EMAIL PROTECTED]

When the directory for temporary files (sessions) set in php.ini does
not exist, PHP crashes.

This is on 4.1.1 WindowsXP Pro with the CGI version.




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

Bug #15657 Updated: PHP terminated by Windows during session operation

[yohgaki]

 ID:   15657
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Analyzed
 Bug Type: Session related
 Operating System: Windows 2000
 PHP Version:  4.1.1
 Assigned To:  yohgaki


Previous Comments:


[2002-03-05 18:57:02] [EMAIL PROTECTED]

yasuo commited this patch a while ago IIRC.



[2002-02-26 07:04:02] [EMAIL PROTECTED]

I have patch to prevent crash with invalid save_path. (not commited)
But I didn't change default save_path for windows.

Sander, should we change the default or documentation in 
php.ini-(dist|recommened)?



[2002-02-26 04:27:28] [EMAIL PROTECTED]

[EMAIL PROTECTED]: those two messages are no bugs; RTM and/or ask
support questions on the apropriate mailinglist.



[2002-02-26 04:20:19] [EMAIL PROTECTED]

session_start(); crete this error in browser:
Cannot send session cookie - headers already sent by (output started at
test.php:1)in Line 2

Warning: Cannot send session cache limiter - headers already sent
(output started at test.php:1) in Line 2



[2002-02-22 12:19:45] [EMAIL PROTECTED]

Hasn't this been fixed already?



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

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

Bug #15733 Updated: The effect of session_set_cookie_params() lasts past a script termination

[yohgaki]

 ID:   15733
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Analyzed
 Bug Type: Session related
 Operating System: ALL
 PHP Version:  4.1.1
 Assigned To:  yohgaki


Previous Comments:


[2002-03-06 03:02:25] [EMAIL PROTECTED]

This is basiclly the same as "sticky session module name" bug report.
The cause of this is not in session module, probably.
(I'm guessing it's bug in ini value handling now) 

Assigned to me for now. 



[2002-02-27 01:53:07] [EMAIL PROTECTED]

But manual says that the function must take affect only during a script
execution time but not AFTER it's termination.



[2002-02-27 01:53:00] [EMAIL PROTECTED]

But manual says that the function must take affect only during a script
execution time but not AFTER it's termination.



[2002-02-26 21:08:28] [EMAIL PROTECTED]

I know it does :)
There is a user finally notice this problem.



[2002-02-26 10:36:02] [EMAIL PROTECTED]

The effect of session_set_cookie_params() lasts past a script
termination.




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

Bug #15573 Updated: save_handler mm - doesn't create _SESSION[bar] at the first-time

[yohgaki]

 ID:   15573
 Updated by:   [EMAIL PROTECTED]
-Summary:  save_handler mm - doesn't create _SESSION[bar] at the
   first-time
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Analyzed
 Bug Type: Session related
 Operating System: debian woody (3.0)
 PHP Version:  4.1.1
 Assigned To:  yohgaki


Previous Comments:


[2002-03-06 02:54:14] [EMAIL PROTECTED]

Cause is known. We need to come up with how we treat FAILURE from
session save handler's read function to fix this issue.

FAILURE means failed to get valid data entry for the session
oi
FAILURE means fatal errror that can be network connection, database
query, etc.





[2002-02-15 11:43:44] [EMAIL PROTECTED]

Hi,
if I use mm as save handler. I have to click twice at the first time to
increment the counter. With files it works fine.

cheers,
Marcus.

click me";
?>




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

Bug #15041 Updated: mm save handler does not work

[yohgaki]

 ID:   15041
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Analyzed
 Bug Type: Session related
 Operating System: linux
 PHP Version:  4.0CVS-2002-01-1
 Assigned To:  yohgaki


Previous Comments:


[2002-03-06 02:54:34] [EMAIL PROTECTED]

Cause is known. We need to come up with how we treat FAILURE from
session save handler's read function to fix this issue.

FAILURE means failed to get valid data entry for the session
oi
FAILURE means fatal errror that can be network connection, database
query, etc.



[2002-02-03 19:54:59] [EMAIL PROTECTED]

Will be fixed



[2002-01-15 04:46:59] [EMAIL PROTECTED]

PS(http_session_vars) is null and PHP cannot save data when
PS_WRITE_FUNC is called. PHP may crash under certain condition. 
Problem exists in 4.1.0 and 4.1.1 also.






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

Bug #15039 Updated: sticky save handler module setting

[yohgaki]

 ID:   15039
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Analyzed
 Bug Type: Session related
 Operating System: linux
-PHP Version:  4.0CVS-2002-01-15
+PHP Version:  4.0CVS-2002-01-1
 Assigned To:  yohgaki


Previous Comments:


[2002-02-03 19:54:31] [EMAIL PROTECTED]

Will be fixed



[2002-01-15 01:53:48] [EMAIL PROTECTED]

When session save handler module is specified with
session_module_name(), the setting became sticky. (i.e. the last
specified save handler is used for later requests)





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

Bug #14950 Updated: crash with __sleep() and __wakeup()

[yohgaki]

 ID:   14950
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Analyzed
 Bug Type: Session related
 Operating System: Debian SID
 PHP Version:  4.2.0-dev
 Assigned To:  yohgaki


Previous Comments:


[2002-03-06 03:25:20] [EMAIL PROTECTED]

Version update

I just take a look at what is going on, __sleep and __wakeup is messed
badly. It does not work at all and even crashes...




[2002-02-03 19:44:04] [EMAIL PROTECTED]

This will be next my target to fix :)



[2002-01-09 10:38:21] [EMAIL PROTECTED]

Forgot to tell : asking for .phps will show you the source in the
/test/session/ directory.



[2002-01-09 10:36:08] [EMAIL PROTECTED]

Passing objects using the magic __sleep() and __wakeup() methods
through sessions fail.

In the best case the script fails without error. In the worst, an
integer in session turns into the value of the PHP session ID and the
object is not registered.

Yasuo Ohgaki guesses it's a serialize/unserialize problem.

Make log :

/usr/src/web/php/php4/ext/standard/var_unserializer.re: In function
`php_var_unserialize':
/usr/src/web/php/php4/ext/standard/var_unserializer.re:304: warning:
comparison is always false due to limited range of data type

Tests : http://php.hellekin.com/test/session/
PHPInfo() : http://php.hellekin.com/info.php




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

Bug #13595 Updated: Solution for "PHP Fatal error: Unable to start session mm module in Unknown on

[matt]

 ID:   13595
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Session related
 Operating System: Debian Sid
 PHP Version:  4.0.6
 New Comment:

Thanks to [EMAIL PROTECTED], I found the problem using strace.  I had
'session.save_path' set to '/dev/null'.  

Why does 4.1.2 not handle this gracefully like 4.0.5, and is there any
way to get a more helpful error message in this case?

In case you're interested in the exact errors, I've included the errors
from the strace below:

unlink("/dev/null/session_mm_apache0.sem") = -1 ENOTDIR (Not a
directory)
open("/dev/null/session_mm_apache0.sem", O_RDWR|O_CREAT, 0600) = -1
ENOTDIR (Not a directory)
unlink("/dev/null/session_mm_apache0.sem") = -1 ENOTDIR (Not a
directory)


Previous Comments:


[2002-03-05 02:24:42] [EMAIL PROTECTED]

An other alternative would be to use use 'strace' on the apache process
(make sure you start apache with -X switch), maybe you can gather where
it has failed, e.g.

strace -e trace=file -o output /usr/sbin/apache -X

and see in file 'output' what fails.



[2002-03-05 02:17:02] [EMAIL PROTECTED]

Can you try a snapshot from snaps.php.net? It might be fixed, if not we
need feedback on that branch anyways.

regards,
Derick



[2002-03-05 01:48:33] [EMAIL PROTECTED]

I'm seeing this problem on Slackware 8.0, when upgrading 
from the original mod_php.tgz package (PHP 4.0.5) to the 
updated version (PHP 4.1.2).

I already checked, there is no 'session_mm.sem' file to 
remove (stopping apache automatically removes the file).  
So my question is, what is going on, and how do I fix it?



[2001-11-11 12:37:22] [EMAIL PROTECTED]

So it's not a bug in PHP. Thanks & Closing...



[2001-10-08 05:46:33] [EMAIL PROTECTED]

Hello there,

Every time I when I upgrade my Debian-install I get errors with
php4-cgi. When it is invoked, php4-cgi says "PHP Fatal error:  Unable
to start session mm module in Unknown on line 0".

I posted a message, and Peter Cech helped me out: rm
/etc/session_mm.sem did the job.

Cheers y'all

pla.




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

Bug #15918: DomAttribute missing "type" property

[bigredlinux]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.1.2
PHP Bug Type: DOM XML related
Bug description:  DomAttribute missing "type" property

It appears that the type property is missing from the DomAttribute class,
which makes it quite difficult to determine the type of node, since it is
necessary to code a workaround for cases where this property is missing. 
It would be nice if there was a function nodeType that would return this,
and possibly a function nodeName to return other rather case sensitive
results.
-- 
Edit bug report at http://bugs.php.net/?id=15918&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15918&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15918&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15918&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15918&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15918&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15918&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15918&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15918&r=submittedtwice

Bug #15917: Virtual host won't work _anymore_ with php-cgi

[spoon]

From: [EMAIL PROTECTED]
Operating system: WIndows XP Professional
PHP version:  4.1.1
PHP Bug Type: Apache related
Bug description:  Virtual host won't work _anymore_ with php-cgi

My virtual hosts for apache work_ed_ fine using the PHP CGI, up untill just
yesturday. The only modification to apache's conf file i made was
uncommenting the "AddType application/x-httpd-php-source .phps". That was
the only change between when it worked and did not.

Now my virtual hosts do not work (eg. foo.spoonfuls.net). When i switch
over to PHP Module, the virtual hosts work just fine, as they _did_ with
the php cgi.

I would gladly stay with the module, if not for the bug report i posted
about XP + apache 1.3.23 + PHP Module corrupting output.

I don't believe the uncommented 'AddType phps' created the problem,
becuase i commented it out and the virtual hosts still didn't work.

I think php _or_ apache both need some more xp work done on them still :-P
-- 
Edit bug report at http://bugs.php.net/?id=15917&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15917&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15917&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15917&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15917&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15917&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15917&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15917&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15917&r=submittedtwice

Bug #15476 Updated: corrupted outputs when using PHP as Apache Module under Windows XP

[spoon]

 ID:   15476
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Apache related
 Operating System: Windows XP
 PHP Version:  4.1.1
 New Comment:

I also have noticed this. My test-server runs XP w/ apache 1.3.23 and
PHP 4.1.1. I usualy use the CGI version of PHP, but i wanted to test a
function that is only available in the module of php, so i configed
apache for the module. 

It worked fine, except some of the php files (the one i tested
specifically was a php file with no php, just html) will randomly come
up as "Cannot be displayed" (IE Error) or will come up but be missing
HTML and have 2-4 extended characters (everything that isnt
0-9a-z!@#$%^&*()... like squares, and stuff).


Previous Comments:


[2002-02-15 10:03:07] [EMAIL PROTECTED]

We have found tha same thing with the same config.



[2002-02-09 17:13:34] [EMAIL PROTECTED]

Software:
Apache 1.3.23
PHP Version 4.1.1 and 4.1.0

Problem:

When running PHP as Apache Server Module (php4apache.dll)
output from the script gets corrupted randomly e.g. Tables thrown in
disorder etc.

This error does occur in php 4.1.0 and 4.1.1 but only when used as
Server Module. Running PHP as CGI version doesn´t produce errors.
The same configuration works well under Windows 2000 only Windows XP
seems affected.




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

Bug #11950 Updated: not sending e-mail at all

[surak]

 ID:   11950
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Mail related
 Operating System: Debian Linux
 PHP Version:  4.0.5
 New Comment:

It happens the same to me when the mail server is running qmail, no
matter the os.


Previous Comments:


[2001-08-10 11:07:06] [EMAIL PROTECTED]

no feedback



[2001-07-09 03:57:36] [EMAIL PROTECTED]

hm, i can't really belive this ...

can you provide some example code
a little bit more complete?



[2001-07-07 18:08:45] [EMAIL PROTECTED]

A call to the mail function in the form:

   mail .

will not send an e-mail. Using the following format:

  $something = mail .

will send the e-mail correctly.

I've encoutered this problem using the free web hosting provided by
www.f2s.com, who are using Debian Linux.




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

Bug #14292 Updated: Bare LF Issue - This time with DETAIL!

[surak]

 ID:   14292
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: *Mail Related
 Operating System: Windows 2000 Server/XP
 PHP Version:  4.0.6
 New Comment:

I'm running the infamous PHPTriad ( http://phptriad.sourceforge.net ),
which is Apache 1.3.14 and PHP 4.0.5. Every time I try to mail someone
using that simplest test "mail ('nono@nononono', 'test', 'test');"
and my smtp server is running qmail, this function returns a "server
error". When I switch the server to any other mail exchanger, like one
running sendmail or any other, everyting works fine. It was not just
one qmail server I tried; Every qmail server I can post mails fails
with mail() function when used remotely (as in this case, when you
specify a SMTP in php.ini). These same qmail servers works fine when
php is running locally and it doesn't need to make a SMTP connection.


Previous Comments:


[2002-01-10 02:07:25] [EMAIL PROTECTED]

No feedback. Closing.



[2001-12-20 09:45:47] [EMAIL PROTECTED]

Any feedback of this?

R.



[2001-12-02 02:22:47] [EMAIL PROTECTED]

The code that handles sending messages for Win32 uses 
proper CRLF sequences.

Do the most basic test email messages fail? Have you tried 
sending something like?

mail ('[EMAIL PROTECTED]', 'test', 'test');

If so, does it get rejected as well?




[2001-11-29 19:12:37] [EMAIL PROTECTED]

I would like to add that I have tried a perl script to send emails and
it works fine. No bare LF. However, I tried to install Sendmail for
Windows and I could not get that to run from php. So... we are back to
square 1. Trying to get the Bare LF out of SMTP.



[2001-11-29 18:29:46] [EMAIL PROTECTED]

I am running an apache web server using PHP 4.06 on Windows 2000 Server
and Windows XP (so we know it doesn't matter the OS as long as it's MS
and PHP). Now here's my delima.

I can send emails through MS Outlook to my specified mail address just
fine. There's no problems and it gets delivered right away. But when I
try sending an email through a web form, the unix mail server running
QMail rejects it with an error 451 Bare LF.

Here's an example: 

This email was sent from my Outlook Client through Postcast Email
Server Succesfully (I have  out server names for my protection):

Thread 1: 23:51:23 [<---] : HELO .xx.net
Thread 1: 23:51:23 [--->] : 220 gambit.xx.net ESMTP
Thread 1: 23:51:23 [<---] : MAIL FROM: <[EMAIL PROTECTED]>
Thread 1: 23:51:23 [--->] : 250 gambit.xx.net
Thread 1: 23:51:23 [<---] : RCPT TO: <[EMAIL PROTECTED]>
Thread 1: 23:51:23 [--->] : 250 ok
Thread 1: 23:51:23 [<---] : DATA
Thread 1: 23:51:23 [--->] : 250 ok
Thread 1: 23:51:23 [--->] : 354 go ahead
Thread 1: 23:51:23 [<---] : QUIT
Thread 1: 23:51:24 [--->] : 250 ok 1007074661 qp 3355

Now, this email was sent via a php script form through Postcast (I have
 out server names for my protection):

Thread 1: 23:37:55 [<---] : HELO xx.xx.net
Thread 1: 23:37:55 [--->] : 220 gambit.xx.net ESMTP
Thread 1: 23:37:55 [<---] : MAIL FROM: <[EMAIL PROTECTED]>
Thread 1: 23:37:55 [--->] : 250 gambit.x.net
Thread 1: 23:37:55 [<---] : RCPT TO: <[EMAIL PROTECTED]>
Thread 1: 23:37:55 [--->] : 250 ok
Thread 1: 23:37:55 [<---] : DATA
Thread 1: 23:37:55 [--->] : 250 ok
Thread 1: 23:37:56 [--->] : 354 go ahead
Thread 1: 23:37:56 [<---] : QUIT
Thread 1: 23:37:56 [--->] : 451 See
http://pobox.com/~djb/docs/smtplf.html. 

So what's the problem here? Do you think it could be that PHP 4.06 is
spitting out these bare LF or what? I mean it's obvious that Postmaster
Email Server is sending the mails just fine from Outlook and Outlook is
the source of the mail that sent succesfully, and the PHP script is the
one that sent Unsuccessfully.

I have tried at least 6 different SMTP servers for the win32 operating
systems. They all do the same thing. This is very bad for me because I
am having extreme difficulties running my site if every member signs up
that has a unix email account running on Qmail, pukes on me and I have
to send the emails directly to them. It's strange.

I hope we can figure this one out. I have researched the net but not
any information on this particular configuration.

Thanks,
Eric Rosebrock
http://wolfenstein.3dhavoc.net





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

Bug #15680 Updated: WIll not read this image at all

[helly]

 ID:   15680
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: GetImageSize related
 Operating System: solaris 2.7
 PHP Version:  4.1.1
 New Comment:

Works on winxp/cygwin


Previous Comments:


[2002-02-22 13:38:49] [EMAIL PROTECTED]

getimagesize will not read this image at all where it
will be read by a browser just fine:

http://www.adultdeal.com/logos/blurr_banner2.gif

Thanks




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

Bug #15910 Updated: php-3.0.18 configure --with-pgsql=DIRWITH-FOO

[sniper]

 ID:   15910
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: PostgreSQL related
 Operating System: Sol-8
 PHP Version:  4.1.2
 New Comment:

Update to PHP 4. PHP 3 is not supported anymore.



Previous Comments:


[2002-03-06 13:52:17] [EMAIL PROTECTED]

ln -s $PrefixPSQL /usr/local/pgsql
OPTIONS="$OPTIONS --with-pgsql=$PrefixPSQL"
...
./configure $OPTIONS
php-3.0.18 $ make
...
gcc -g -O2 -O2   -I. -I.   -I../apache_1.3.22/src/include
-I../apache_1.3.22/src
/os/unix -c internal_functions.c -o
internal_functions.o
In file included from internal_functions.c:59:
functions/php3_pgsql.h:46: libpq-fe.h: No such file or directory
functions/php3_pgsql.h:47: libpq/libpq-fs.h: No such file or directory
make: *** [internal_functions.o] Error 1
## Var PrefixPOSTGRES existiert nicht (-> PrefixPSQL)
## -IPOSTGREDIR fehlt
$ find / -name libpq-fs.h
/usr/local/pgsql-7.2/include/libpq/libpq-fs.h
/tmp/postgresql-7.2/src/include/libpq/libpq-fs.h
## Files sind aber da.
## Pfad (LD)? fuer postgresql fehlt.
## -> Fehler in configure-script , Makefile anpassen
## ---
## add -I/usr/local/pgsql-7.2/include to Makefile (INCLUDE=)
## Fehler ist weg, aber die erzeugte Lib funktioniert nicht.
## ---
## Ursache:
## - configure --with-pgsql=/usr/local/pgsql-7.2
##   -> generate Makefile mit:
##   INCLUDE = -I$(srcdir) -I.   -I/usr/local/apache/include  
##   ## -I$PrefixPSQL/include fehlt
## - configure --with-pgsql=/usr/local/pgsql
##   -> generate Makefile mit:
##   INCLUDE = -I$(srcdir) -I.   -I/usr/local/apache/include
-I/usr/local/pg
sql/include
##   ## -I$PrefixPSQL/include ist vorhanden
## -> Fehler in configure





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

Bug #15902 Updated: File Upload bug when sending many of files in upload multipart/form-data ?

[sniper]

 ID:   15902
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: Linux Slackware 7.1
 PHP Version:  4.1.2
 New Comment:

This works just fine with the latest CVS.

--Jani



Previous Comments:


[2002-03-06 14:16:58] [EMAIL PROTECTED]

Hi i instaled the php4-latest.tar.gz from snaps.php.net and now it
worked perfectly. with 20 and 40 files

but sorry for lack of knowlege, but i was woundering about the
possibility of new serious bugs at dev version, should i stay with this
version ? should i wait for 4.2 ? 

sorry to annoy but is there a way to update only the file upload part
in php 4.1.2 manually copying some files from the dev source ?

thank you for helping and helping me now on

Thanks a lot derick and ppl from php.net

Marcus Vinícius



[2002-03-06 13:01:03] [EMAIL PROTECTED]

I'll ask again, can you please try a snapshot from snaps.php.net?

Derick



[2002-03-06 11:44:33] [EMAIL PROTECTED]

I´ll post the code that i´m using

the point is using 20 different files of about 20 k each

use file.php?num=numberoffiles




 New Document 








 $v) { echo "$k => $v"; }
foreach ($HTTP_POST_FILES as $k => $v) { echo "$k ==> $v"; }

?>





=$i;$i++) {
 echo "";
}
?>









[2002-03-06 11:11:48] [EMAIL PROTECTED]

Hello,

the file upload code was rewritten for PHP 4.2.0, can you try a
snapshot from snaps.php.net and see if it works?

regards,
Derick



[2002-03-06 11:09:15] [EMAIL PROTECTED]

Sorry to annoy but i sent yesterday an email to Stefan Esser, and he
told me to open a bug report about the possibility of a bug in file
upload.

I updated my php to 4.1.2 and i´m having such a strange problem with
file upload i was woundering about a bug, because i tried to look at
rfc 2616 http1.1 and 1827, file
upload rfc and i didn´t find anything about it.

I wrote a code, that i can upload in one form unlimited files, at the
beggining i´m using

ini_set("upload_max_filesize","10M");
set_time_limit(0);

since then its all ok

it works all normally when i upload less than +- 20 or 25 files but
when i try 35
for example, the variables from post, that goes before the 35  tags doesn´t come...

i put a debug at the begging

foreach ($HTTP_POST_VARS as $k => $v) { echo "$k => $v"; }
foreach ($HTTP_POST_FILES as $k => $v) { echo "$k ==> $v"; }

when i get 10 or 15 files it returns to me

field1 => value
field2=> value
field3=> value
file1 ==> array
file2 ==> array
file3 ==> array
file4 ==> array
file5 ==> array
.. ==> array
field4 => value
field5 => value

but when i try 30 for example

it returns only

field1 => value
field2=> value
field3=> value
file1 ==> array

very strange isn´t it ?

I don´t know if there is any limitation in post data, but i thought
that if this exists it should return some warning or something, but it
seemed to me be very strange.

Sorry to annoy, or sorry if its not a bug, or limitation but im getting
mad with this :o/ thanx for the oportunity and sorry for poor english

Marcus Vinícius




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

Bug #12562 Updated: CGI Error-CGI application misbehaved

[robleo]

 ID:   12562
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: IIS related
 Operating System: Windows 2000 Server
 PHP Version:  4.0.6
 New Comment:

I have the following problem. With Win 2000 Server NOT PHP but
ACTIVESTATE PERL and ODBC connection with Sql Server.

I have noticed this strange thing and only with frames that connect
all TO ODBC SOURCE (parent frame and son frames) : SEE LOG OF INTERNET
INFORMATION SERVICES, the GET of the son frame comes firstly of get of
parent frame in the CGI ERROR'S cases


Previous Comments:


[2002-01-10 06:23:12] [EMAIL PROTECTED]

Same problem.
I have installed my application in some PCs but I have the problem only
in the production server (the fastest).

I have some frames in my pages and I use ODBC
If I try to reload the page with the error, it works fine



[2001-08-04 00:06:26] [EMAIL PROTECTED]

I install php 4.06 in windows 2000 server with IIS included in Windows
2000 server

I am using php_mssql.dll and php_pdf.dll.

I do repeat edit, update, list records database in same page, same
record 10 time.

In any random time when a list records there is error
CGI Error-CGI application misbehaved.

These error not happens in IIS 4.0 in windows NT 4.0- system.

Aris G






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

Bug #15822 Updated: session variables disappear

[i . frank]

 ID:   15822
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Duplicate
 Bug Type: Session related
 Operating System: Linux 2.2.19
 PHP Version:  4.1.2
 New Comment:

I had exactly the same problem. (PHP 4.1.2 and Linux 2.2.16) 
Calling session_register(mySessVar) after session_start() seems to fix
the problem - strange.


Previous Comments:


[2002-03-04 13:27:21] [EMAIL PROTECTED]

I did.

I also checked the changelog, but it's still not updated for 4.1.2.

I also checked the session fn docs, but didn't see anything relevant in
either the static documentation or the comments.

Perhaps the bug is marked as closed already?  I'm not sure I checked
for closed bugs, but you didn't include the original bug number when
telling me my entry was a duplicate, so I really have no idea what it
was I missed on my first search.

If it's a known bug, is it slated to be fixed?  In 4.2.0?  Is there a
work-around?  Again, my search for further information has left me dry.
 Any pointer to a worthwhile starting point, even just the original bug
#, would be far more useful than simply assuming I never bothered
looking and telling me to buzz off.



[2002-03-02 02:16:52] [EMAIL PROTECTED]

It's known problem. Session become read only.
Thanks for reporting but search reports first :)





[2002-03-01 16:32:53] [EMAIL PROTECTED]

My web host recently upgraded to PHP 4.1.2.  At the same time, my user
login scripts stopped working.  A session variable registered with
session_register() is not holding its information when the page
reloads.

Details:

I have a file included in every page that looks like:


class UserSession
{
var $user_id = 0;
var $username = "";
var $logged_in = false;
//other stuff elided
}

session_start();
global $user_session;
if (!session_is_registered("user_session"))
{
session_register("user_session");
$user_session = new UserSession();
}

function ProcessLogin($Username, $Password)
{
global $user_session;
//username and password are checked against DB contents
//if that's all good, get user row with mysql_fetch_array()
$user_session->user_id = $row[user_id];
$user_session->username = $row[user_name];
$user_session->logged_in = true;
//cookies are set and other stuff happens
}

When a page loads immediately after the user logs in, all is well, and
the values in $user_session are all as I expect them to be.  Reloading
the same page, though, causes $user_session to be set back to its
default values.  Before the 4.1.2 upgrade, this worked fine.

I've stripped the code down almost to what I show above, and it still
fails, so I'm pretty sure I'm not doing anything to stomp the values
later in the page.  I double-checked that on the page reload,
$user_session is still registered, and it appears to be.

The changelog at http://www.php.net/ChangeLog-4.php only goes up to
version 4.1.1, so I couldn't tell if there was any change to session
variable handling in 4.1.2.

Any thoughts?  All suggestions are appreciated.

Config line:
 './configure' '--with-mysql' '--with-apache=../apache_1.3.23'
'--enable-track-vars' '--with-xml' '--enable-memory-limit=yes'
'--enable-bcmath' '--with-gd=../gd-2.0.1' '--enable-gd-native-tt'
'--enable-gd-imgstrttf' '--with-gdbm=/usr/include' '--enable-calendar'
'--with-png-dir=/usr/lib' '--with-zlib-dir=/usr/include'
'--with-freetype-dir=/usr/local/include/freetype2'
'--with-jpeg-dir=/usr/local/lib' '--with-mcrypt' '--enable-trans-sid'
'--with-sablot=/usr/local/lib' '--with-imap' '--enable-xslt'
'--with-xslt-sablot' '--enable-sablot-errors-descriptive'

Host info:
Linux *.*.com 2.2.19-6.2.11 #1 Fri Oct 19 13:28:00 EDT 2001 i686
unknown

Server is latest stable Apache.




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

Bug #15916: wrong compile command sample on Chapter 28. Creating Extensions

[yorgo]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.1.2
PHP Bug Type: Documentation problem
Bug description:  wrong compile command sample on Chapter 28. Creating Extensions

http://www.php.net/manual/en/zend.creating.php#zend.creating.compiling

there are a compile command on Chapter 28. Creating Extensions. I just
test the sample code, compile it will use 
gcc -fpic -DCOMPILE_DL=1 -I/usr/local/include -I.. -I../.. -I../../main
-I../../Zend -I../../TSRM -c -o  

on php_root_path/ext/module_path/ to compile
-- 
Edit bug report at http://bugs.php.net/?id=15916&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15916&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15916&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15916&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15916&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15916&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15916&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15916&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15916&r=submittedtwice

Bug #15915: the sample code have some wrong on Creating Extensions

[yorgo]

From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.1.2
PHP Bug Type: Documentation problem
Bug description:  the sample code have some wrong on Creating Extensions

http://www.php.net/manual/en/zend.creating.php

/* implement standard "stub" routine to introduce ourselves to Zend */
#if COMPILE_DL_FIRST_MODULE <-- this i think can change to #if COMPILE_DL
ZEND_GET_MODULE(firstmod)
#endif

/* implement function that is meant to be made available to PHP */
ZEND_FUNCTION(first_module)
{
long parameter;

if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "l", ¶meter)
== FAILURE) {
return;
}

RETURN_LONG(parmeter);
.^^ parameter
}
-- 
Edit bug report at http://bugs.php.net/?id=15915&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15915&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15915&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15915&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15915&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15915&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15915&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15915&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15915&r=submittedtwice

Bug #14904 Updated: configuring apache with php4

[sbeard]

 ID:   14904
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Failure
 Operating System: AIX 4.3.3
 PHP Version:  4.1.1
 New Comment:

Im having the exact same problem when trying to install php 4.1.1
everything works fine until I get to the make install part and I get
this.

ld: 0711-317 ERROR: Undefined symbol: .alloca
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
make: 1254-004 The error code from the last command : 8.
stop.
make : 1254-004 The error code from the last command : 1.
stop.


Previous Comments:


[2002-01-07 08:32:24] [EMAIL PROTECTED]

ld : 0706-027 the -R /envpat/oracle/patdb/8.1.6/lib flag is ignored
ld: 0711-317 ERROR: Undefined symbol: .alloca
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
make: 1254-004 The error code from the last command : 8.
stop?
make : 1254-004 The error code from the last command : 2.
stop?
make : 1254-004 The error code from the last command : 2.
stop?




[2002-01-07 06:56:26] [EMAIL PROTECTED]

Materiel : IBM RS6000
OS : AIX 4.3.3
Compiler : IBM cc

I have apache v 1.3.20 in /usr/apache and i want to install php
module.
I give the last version of php 4.1.1 but in the installation, I occurs
some problems with apache.

Procedure : 

Installation of PHP module :

# /sauvegarde/tools/php-4.1.1> ./configure
–with-oci8=/envpat/oracle/patdb/8.1.6
–with-oracle=/envpat/oracle/patdb/8.1.6 –with-apache=../apache_1.3.20
–enable-track-vars

# /sauvegarde/tools/php-4.1.1>make

# /sauvegarde/tools/php-4.1.1>make install

this commands passed with success.

But when I want to configure apache for adding php4 module

Configuring apache :

# /sauvegarde/tools/apache_1.3.20 >./configure --prefix=/usr/apache
--activate-module=src/modules/php4/libphp4.a
Configuring for Apache, Version 1.3.20
 + using installation path layout: Apache (config.layout)
 + activated php4 module (modules/php4/libphp4.a)
Creating Makefile
Creating Configuration.apaci in src
Creating Makefile in src
 + configured for IBM AIX 4.3 platform
 + setting C compiler to cc
 + setting C pre-processor to cc -E
 + checking for system header files
 + adding selected modules
o php4_module uses ConfigStart/End
 + checking sizeof various data types
 + doing sanity check on compiler and options
Creating Makefile in src/support
Creating Makefile in src/os/unix
Creating Makefile in src/ap
Creating Makefile in src/main
Creating Makefile in src/lib/expat-lite
Creating Makefile in src/modules/standard
Creating Makefile in src/modules/php4

# make


-

<=== src/modules
cc -c  -I./os/unix -I./include   -DAIX=43
-DUSE_PTHREAD_SERIALIZED_ACCEP
-I/sauvegarde/tools/php-4.1.1 -I/sauvegarde/tools/php-4.1.1/main
-I/sauvegarde/t
auvegarde/tools/php-4.1.1/Zend -I/sauvegarde/tools/php-4.1.1/TSRM
-I/sauvegarde/
PAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci` modules.c
cc -c  -I./os/unix -I./include   -DAIX=43
-DUSE_PTHREAD_SERIALIZED_ACCEP
-I/sauvegarde/tools/php-4.1.1 -I/sauvegarde/tools/php-4.1.1/main
-I/sauvegarde/t
auvegarde/tools/php-4.1.1/Zend -I/sauvegarde/tools/php-4.1.1/TSRM
-I/sauvegarde/
PAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci` buildmark.c
cc  -DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT -U__STR__
-DAIX_BIND_PROCES
 -I/sauvegarde/tools/php-4.1.1/main -I/sauvegarde/tools/php-4.1.1/main
-I/sauveg
d -I/sauvegarde/tools/php-4.1.1/TSRM -I/sauvegarde/tools/php-4.1.1/TSRM
-I/sauve
L_NEEDED `./apaci` -lm -lpthread -ma   -o httpd buildmark.o modules.o 
modules/p
.a  ./os/unix/libos.a  ap/libap.a  lib/expat-lite/libexpat.a 
-R/envpat/oracle/p
php4 -L../modules/php4 -L../../modules/php4 -lmodphp4   -ldl -lld
-lbsd_r -lm -l
l  -lcrypt -lclntsh -lclntsh  
ld : 0706-027 the -R /envpat/oracle/patdb/8.1.6/lib flag is ignored
ld : 0711-317 ERREUR : Symbol not defined : .alloca
ld : 0711-345 Pour plus de d tails, utilisez
l'option -bloadmap ou -bnoquiet.
make : 1254-004 Code d'erreur de la derni re commande : 8.


Arrét.
make : 1254-004 Code d'erreur de la derni re commande : 2.


Arrét.
make : 1254-004 Code d'erreur de la derni re commande : 2.


Arrét.





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

Bug #15914: *lots* of compiler warnings...

[temp201]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.1.2
PHP Bug Type: Compile Warning
Bug description:  *lots* of compiler warnings...

Compiler warnings ?
You mean you want to see compiler warnings ?

Well if youv'e got gcc, try compiling with
-Wall -Wshadow -Wpointer-arith -Wcast-qual -W


Just to give a few serious examples here:

cast discards qualifiers from pointer target type
comparison between signed and unsigned
comparison of unsigned expression < 0 is always false
signed and unsigned type in conditional expression
declaration of `foo' shadows previous local
declaration of `foo' shadows global declaration
`foo' defined but not used
implicit declaration of function `foo'
left-hand operand of comma expression has no effect
missing initializer
passing arg 1 of `foo' discards qualifiers from pointer target type
`foo' declared `bar' but never defined
`register' is not at beginning of declaration
statement with no effect
`static' is not at beginning of declaration
unused parameter `foo'


Mind you, some of these, like "comparison between signed and unsigned" or
"signed and unsigned type in conditional expression" are even considered
FATAL or ILLEGAL by some compilers, instead of 'just' warnings...


May I even dare suggest the developers (the ones using gcc at least)
include the following:

CFLAGS="-Wall -Wshadow -Wpointer-arith -Wcast-qual -W"
CPPFLAGS="-Wall -Wshadow -Wpointer-arith -Wcast-qual -W"
export CFLAGS CPPFLAGS

to their .profiles ?

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

Bug #10585 Updated: Php can't connect to MySQL database

[php . ini]

 ID:   10585
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: MySQL related
 Operating System: redhat 7
 PHP Version:  4.0.5
 New Comment:

Edit the mysql socket entry in the php.ini file and restart the httpd.

Try this:

mysql.default_socket = /var/lib/mysql/mysql.sock


Previous Comments:


[2001-05-01 20:24:30] [EMAIL PROTECTED]

There was a bug in the configure. Should be fixed in CVS
now.

--Jani




[2001-05-01 14:53:20] [EMAIL PROTECTED]

most likely a configuration error

ask a support forum like [EMAIL PROTECTED]



[2001-05-01 14:22:05] [EMAIL PROTECTED]

mysql version  3.23.33 All MySQL connections are broken error:

Warning: MySQL Connection Failed: Can't connect to local MySQL server
 through socket '/tmp/mysql.sock' (111) in
 /home/httpd/html/ion/ion/connect.php on line 4






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

Bug #15913: imagettftext will not work

[shakad]

From: [EMAIL PROTECTED]
Operating system: Windows2000
PHP version:  4.1.1
PHP Bug Type: GD related
Bug description:  imagettftext will not work

imagettftext does not work when using php_gd2.dll with PHP 4.1.1.

The function works fine when using gd_dll with PHP4.1.1.
-- 
Edit bug report at http://bugs.php.net/?id=15913&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15913&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15913&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15913&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15913&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15913&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15913&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15913&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15913&r=submittedtwice

Bug #11676 Updated: A few apache children consume all memory and CPU.

[rodrigo]

 ID:   11676
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: linux 2.4.5 i386
 PHP Version:  4.0 Latest CVS (2001-06-25)
 New Comment:

Valerio, did you happen to solve the bug? I'm running through
practically the same bug.
Besides that I'm getting a lot of Segmentation faults in error_log.
I've been able to GDB some of child httpd processes before they died
and it happened with some PHP stuff too as detailed in:

http://marc.theaimsgroup.com/?l=apache-httpd-users&m=101482626416049&w=2

I'm anxious to know in what position this case is.


Previous Comments:


[2002-01-02 15:08:37] [EMAIL PROTECTED]

Ops...guess i missed the mail with the "feedback" status..
I will check as soon as i install php 4.1 (should be tomorrow if all
goes well...). Don't close this one since many were experiencing the
same problem than me...
i'll let you know!



[2002-01-02 13:56:38] [EMAIL PROTECTED]

No feedback. Closing.



[2001-12-12 08:20:11] [EMAIL PROTECTED]

Status = feedback



[2001-12-12 08:19:47] [EMAIL PROTECTED]

Could you try 4.1.0? see if it helps?



[2001-08-19 05:31:51] [EMAIL PROTECTED]

There's only one issue... how can I determine which script was running
on the processes that i find stuck?

In the meanwhile i installed the Zend Optimizer on the server, and the
problem seems to happen VERY less frequently... i know this is nearly
no help at all, but I'm doing all I can.

Anyway, i see some other guy had my same problem...



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

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

Bug #15841 Updated: CRLF to separate mail headers is incorrect

[rha]

 ID:   15841
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: *Mail Related
 Operating System: Linux
 PHP Version:  4.1.2
 New Comment:

The point is that it is incorrect to send DOS line endings to a Unix
command line program.

Sending a message through qmail (for example) with \r\n line endings
results in extraneous \r's in the delivered email. qmail assumes the
user knows what they're doing and converts only the '\r' characters to
'\r\n'. So if you use '\r\n' it injects '\r\r\n' into the SMTP
conversation.

e.g. 
Headers:
"X-1: test1\nX-2: test2\r\nX-3: test3\r\nX-4: test4:

Message:
Subject: test message
X-1: test1
X-2: test2^M
X-3: test3^M
X-4: test4

I notice that some mail readers sanitize the incoming message and strip
the extra \r's (e.g. Eudora) but Mozilla doesn't and only the first
extra header is displayed as a header while the others appear in the
body of the message.


Previous Comments:


[2002-03-06 12:28:00] [EMAIL PROTECTED]

i still do not see the point, even for unix/sendmail

even /usr/lib/sendmail will transfer the message
using SMTP, and during this step you will have
\r\n line endings anyway, or am i missing something?



[2002-03-06 11:04:38] [EMAIL PROTECTED]

The Right Thing(TM), then, is to determine which method (direct or SMTP
injection) is being done. If SMTP, use \r\n. If direct, determine what
the OS' line terminator is (\r\n for Windows, \n for Unix, \r for Mac
(?!)) and use that instead.



[2002-03-04 05:36:24] [EMAIL PROTECTED]

on windows we *do* talk STMP ...



[2002-03-03 16:27:44] [EMAIL PROTECTED]

This is causing mail generated by PHP to be BLOCKED as being
potentially a virus by some anti-virus SMTP servers.

The presence of "\r\n" in headers is typically a sign of a virus trying
to reach Outlook. Some antivirus products now totally block MIME mail
containing "\r\n".

This means all mail generated by PHP programs...



[2002-03-02 20:05:00] [EMAIL PROTECTED]

Last November the mail documentation was changed from saying:
"Multiple extra headers are separated with a newline."
to:
"Multiple extra headers are separated with a carriage return and
newline. Note: You must use \r\n to seperate headers, although some
Unix mail transfer agents may work with just a single newline (\n)."

This change is inaccurate. Line breaks in headers should be the native
line endings for the system on which PHP is running.

The mail() function is not talking to an SMTP server, so RFC2822 does
not apply here. mail() is talking to a command line program on the
local system, and it is reasonable to expect that program to require
system-native line breaks.

Use of CRLF is known to break qmail systems where no conversion of line
breaks occurs on the input data. In this case using CRLF causes all but
the first extra header to appear in the message body (CRLF is
interpreted as two line breaks).

Possibly the best resolution to this problem would be for the mail()
function to convert any line breaks in arg 4 into the system's native
line breaks.





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

Bug #15909 Updated: Session data not updated on page jump

[phpbug]

 ID:   15909
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Session related
 Operating System: Linux Gnu  2.2.12
 PHP Version:  4.1.2
 New Comment:

Re: [EMAIL PROTECTED] 
FYI, The code I'm working with uses a single session array variable
(with many elements) and a library routine to do page jumps.
Consequently I was able to fix this problem on all my pages by adding
one line of code to the pagejump library routine.


Previous Comments:


[2002-03-06 14:38:42] [EMAIL PROTECTED]

Just wanted to confirm I also experienced this problem after upgrading
to 4.1.2 for the security fix, so it's not an option to go back to an
older version of PHP.

The suggested $_SESSION[S][X] work around fixed my shopping cart but
this is going to be a huge chore to fix the entire site. 

Is there an ETA on this fix?



[2002-03-06 13:11:34] [EMAIL PROTECTED]

Several pages that worked in PHP 4.0.2 no longer work in 4.1.2. The
problem is that values added to a global session variable array just
before jumping to another page are not being stored.

For example, on page courses.php the user selects a course from a list.
The code for the course is stored in a session variable $S[event_code],
and the code pagejumps (by calling a library routine that calls
header()) to page course.php, to display data for that particular
course. The problem is, the value $S[event_code] no longer exists when
we get to the second page (course.php).

I can see the value in $S[event_code] if I var_dump($S)  before the
pagejump in courses.php. If I var_dump($S) just after arriving in page
course.php, I see the other contents of the $S array but not
$S[event_code].

Array $S is global and each page begins with
session_register("S");
The update takes place within a function that declares $S as global.

If I replace
$S[event_code] = $event_code;
with
$_SESSION[S][event_code] = $event_code; 
the value is passed.

PHP options enable_track_vars and register_globals are ON,
session.save_handler is files, session.serialize_handler is php.

Thank you.







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

Bug #15889 Updated: CGI Error when calling session_start()

[jkgraham]

 ID:   15889
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: IIS related
 Operating System: Windows XP
 PHP Version:  4.1.1
 New Comment:

That was it! Fixed, thanks!


Previous Comments:


[2002-03-06 06:10:35] [EMAIL PROTECTED]

Very likely to be caused by and incorrect session_savepath. If that's
not the case, reopen this report.

This bug has already been fixed in CVS.



[2002-03-05 17:46:03] [EMAIL PROTECTED]

I've narrowed the bad code down to this:

[START]
 


Hello!


[END]

When I try to go to this page a pop-op message is displayed that says:


"php.exe has encountered a problem and needs to close."

And it gives you the option to send a report to Microsoft.  This is the
standard program crash message for XP.  I select "Don't Send" and then
the following error appears in the browser:

[START]
CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:
[END]

SYSTEM:
I am using PHP 4.1.1, IIS5 and Windows XP.  I've installed the php.exe
in IIS with extension .php, "All Verbs" selected, "Script Engine"
checked, and "Check that file exists" checked.

SUMMARY:
I've check the other bug reports with this similiar error, but they are
reporting the problem with use of header() calls.

In the code, if I comment out the session_start() it works fine.  I
also have tried this script in Virtual and non-Virtual directories on
IIS - both return the error.

I have other fairly complex scripts running on this server (that don't
use sessions) that are working fine.

Any ideas?  

-Jon Graham





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

Bug #14755 Updated: 105.05$ becomes 105.5$ !!! - I found the fix.

[derick]

 ID:   14755
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Critical
+Status:   Closed
 Bug Type: InterBase related
 Operating System: ALL
 PHP Version:  4.1.1
 Assigned To:  derick
 New Comment:

Fixed in CVS


Previous Comments:


[2002-03-06 06:33:31] [EMAIL PROTECTED]

Assinging to me to check out before release

Derick



[2002-03-06 06:21:22] [EMAIL PROTECTED]

Hi; I am the original fixer...
Noticed that 

for (i = 0; i < -scale; i++)
number /= 10;

can be substituted with
number /= - 10 *  scale;

with a boost on performance. (remember that interbase 
stores the "scale" as a negative number).



[2002-01-02 11:30:07] [EMAIL PROTECTED]

This is a fix for 12383. Can somebody look into it and apply the fix?



[2001-12-29 13:22:59] [EMAIL PROTECTED]

Hello. I found a nasty bug in interbase extension, and I 
have the solution here. You have only to put it in the 
source code; I would but I don't know how to do this. I 
already posted the authors, but with no result.

104.05$ become 104.5$ !!!
When traslating scaled numeric fields (i.e. with 
decimals), the routine _php_ibase_var_pval is faulty;

here is the original code:

#ifdef SQL_INT64
   case SQL_INT64:
  val->type = IS_STRING;
  val->value.str.len = sprintf(string_data, "%Ld.%Ld",
  (ISC_INT64) (*((ISC_INT64 *)data) / 
  (int) pow(10.0, (double) -scale)),
  (ISC_INT64) abs((int) (*((ISC_INT64 *)data) % 
  (int) pow(10.0, (double) -scale;
  val->value.str.val = estrdup(string_data);
   break;
#endif

You can clearly see that this code is fine if the decimal 
part has no 0s before the first non 0 cipher. Here is
my correction:

#ifdef SQL_INT64
   case SQL_INT64:
  val->type = IS_STRING;
  /* Experimental section by Giancarlo Niccolai */
  if (scale) {
 int i, len;
 char dt[20];
 double number = (double) ((ISC_INT64)
(*((ISC_INT64 *)data)));
 for (i = 0; i < -scale; i++)
number /= 10;
 sprintf(dt, "%%0.%df", -scale);
 val->value.str.len = sprintf (string_data, dt , 
number);
  }
  else {
val->value.str.len = sprintf (string_data, "%Ld",
(ISC_INT64) (*((ISC_INT64 *)data)));
  }
  /* End of experimental section */
  val->value.str.val = estrdup(string_data);
   break;
#endif


Please, since Interbase is used for e-commerce, all the 
php-interbase applications can be at risk, if the site 
deals with cents...







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

Bug #12383 Updated: $105.04 becomes $105.4!!!

[derick]

 ID:   12383
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: InterBase related
 Operating System: LINUX
 PHP Version:  4.0.6
 New Comment:

Fixed in CVS, thx for this excellent report.

Derick


Previous Comments:


[2001-07-25 19:53:22] [EMAIL PROTECTED]

GGG!! Interbase module has this orrible bug. It 
transforms any BIG INTEGER (ISC_INT64) type with decimal 
points are stripped of it's zeroes between decimal point 
and the first non-zero decimal cipher

I.E. 150.0045 becomes 150.45.

This bug is very fast to find in the code, because the 
transformation from Interbase to PHP data is done with an 
instruction like

sprintf (buffer, "%f.%f", [find integer part], [find 
fractional part]); and no control over the zeroes in the 
fractional part. Even wrose, this calculus are done with 2 
heavy double "pow" calls, divisions and modules (with an 
horrible waste of time...

Now, if I had done an error like that in a programming 
execice, my teacher would have given "2" to me, (that is, 
F), even if I have studied Economics, not IT. How could 
this error have survived since now? It could cost a very 
high price for users, if you think that all the 
transactions in dollars, euros, punds and any currency 
with a fractional part IS WRONG!

Now, I have patced the source; find the static int 
_php_ibase_var_pval function in the interbase.c file, ad 
substitute what is inside the #ifdef SQL_INT64 with the 
following code:

#ifdef SQL_INT64
case SQL_INT64:
/* Experimental section by Giancarlo 
Niccolai */
if (scale) {
int i, len;
sprintf (string_data, "%Ld", 
(ISC_INT64) (*((ISC_INT64 *)data)));
len = strlen(string_data);
for (i = 0; i <= -scale; i ++) 
string_data[len-i+1] = 
string_data[len-i]; 
string_data[len-i+1] = '.';
val->value.str.len = len+1;
val->value.str.val = 
estrdup(string_data);
}
else {
val->value.str.len = sprintf 
(string_data, "%Ld", (ISC_INT64) (*((ISC_INT64 *)data)));
val->type = IS_STRING;
val->value.str.val = 
estrdup(string_data);
}
/* End of experimental section */
   val->type = IS_STRING;

/* OLD CODE */  
/*val->value.str.len =  
sprintf(string_data, "%Ld.%Ld",

 (ISC_INT64) (*((ISC_INT64 *)data) 
/ (int) pow(10.0, (double) -scale)),

 (ISC_INT64) abs((int) 
(*((ISC_INT64 *)data) % (int) pow(10.0, (double) 
-scale;
val->value.str.val = 
estrdup(string_data);*/
break;
#endif

The code is faster (you'll have in the wrost case of all 
about 18 iterations on a char array), cleaner and work 
always.

Now, I hope you'll put this code in the PHP dists as soon 
as possible, and give a STRONG evidence of this problem in 
your site, possibily warining all PHP-INTERBASE users, 
that, as I know, are a LOT.

P.S. I found the same error in the PERL DBD::Interbase 
module; I will soon track it down and send a remark to the 
perl community.

Thanks in advance, 
Giancarlo Niccolai.







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

Bug #15909 Updated: Session data not updated on page jump

[nospam . ricko]

 ID:   15909
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Session related
 Operating System: Linux Gnu  2.2.12
 PHP Version:  4.1.2
 New Comment:

Just wanted to confirm I also experienced this problem after upgrading
to 4.1.2 for the security fix, so it's not an option to go back to an
older version of PHP.

The suggested $_SESSION[S][X] work around fixed my shopping cart but
this is going to be a huge chore to fix the entire site. 

Is there an ETA on this fix?


Previous Comments:


[2002-03-06 13:11:34] [EMAIL PROTECTED]

Several pages that worked in PHP 4.0.2 no longer work in 4.1.2. The
problem is that values added to a global session variable array just
before jumping to another page are not being stored.

For example, on page courses.php the user selects a course from a list.
The code for the course is stored in a session variable $S[event_code],
and the code pagejumps (by calling a library routine that calls
header()) to page course.php, to display data for that particular
course. The problem is, the value $S[event_code] no longer exists when
we get to the second page (course.php).

I can see the value in $S[event_code] if I var_dump($S)  before the
pagejump in courses.php. If I var_dump($S) just after arriving in page
course.php, I see the other contents of the $S array but not
$S[event_code].

Array $S is global and each page begins with
session_register("S");
The update takes place within a function that declares $S as global.

If I replace
$S[event_code] = $event_code;
with
$_SESSION[S][event_code] = $event_code; 
the value is passed.

PHP options enable_track_vars and register_globals are ON,
session.save_handler is files, session.serialize_handler is php.

Thank you.







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

Bug #15912: Trailing \r\n in last varible when doing POST request with IE

[napolium]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0CVS-2002-03-06
PHP Bug Type: URL related
Bug description:  Trailing \r\n in last varible when doing POST request with IE

I seams like PHP does not care about the Content-length sent by the browser
when decoding POST requests. And IE seams to add a trailing \r\n at the
end of the POST string that is not included in the Content-length.

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

Bug #15902 Updated: File Upload bug when sending many of files in upload multipart/form-data ?

[m]

 ID:   15902
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux Slackware 7.1
 PHP Version:  4.1.2
 New Comment:

Hi i instaled the php4-latest.tar.gz from snaps.php.net and now it
worked perfectly. with 20 and 40 files

but sorry for lack of knowlege, but i was woundering about the
possibility of new serious bugs at dev version, should i stay with this
version ? should i wait for 4.2 ? 

sorry to annoy but is there a way to update only the file upload part
in php 4.1.2 manually copying some files from the dev source ?

thank you for helping and helping me now on

Thanks a lot derick and ppl from php.net

Marcus Vinícius


Previous Comments:


[2002-03-06 13:01:03] [EMAIL PROTECTED]

I'll ask again, can you please try a snapshot from snaps.php.net?

Derick



[2002-03-06 11:44:33] [EMAIL PROTECTED]

I´ll post the code that i´m using

the point is using 20 different files of about 20 k each

use file.php?num=numberoffiles




 New Document 








 $v) { echo "$k => $v"; }
foreach ($HTTP_POST_FILES as $k => $v) { echo "$k ==> $v"; }

?>





=$i;$i++) {
 echo "";
}
?>









[2002-03-06 11:11:48] [EMAIL PROTECTED]

Hello,

the file upload code was rewritten for PHP 4.2.0, can you try a
snapshot from snaps.php.net and see if it works?

regards,
Derick



[2002-03-06 11:09:15] [EMAIL PROTECTED]

Sorry to annoy but i sent yesterday an email to Stefan Esser, and he
told me to open a bug report about the possibility of a bug in file
upload.

I updated my php to 4.1.2 and i´m having such a strange problem with
file upload i was woundering about a bug, because i tried to look at
rfc 2616 http1.1 and 1827, file
upload rfc and i didn´t find anything about it.

I wrote a code, that i can upload in one form unlimited files, at the
beggining i´m using

ini_set("upload_max_filesize","10M");
set_time_limit(0);

since then its all ok

it works all normally when i upload less than +- 20 or 25 files but
when i try 35
for example, the variables from post, that goes before the 35  tags doesn´t come...

i put a debug at the begging

foreach ($HTTP_POST_VARS as $k => $v) { echo "$k => $v"; }
foreach ($HTTP_POST_FILES as $k => $v) { echo "$k ==> $v"; }

when i get 10 or 15 files it returns to me

field1 => value
field2=> value
field3=> value
file1 ==> array
file2 ==> array
file3 ==> array
file4 ==> array
file5 ==> array
.. ==> array
field4 => value
field5 => value

but when i try 30 for example

it returns only

field1 => value
field2=> value
field3=> value
file1 ==> array

very strange isn´t it ?

I don´t know if there is any limitation in post data, but i thought
that if this exists it should return some warning or something, but it
seemed to me be very strange.

Sorry to annoy, or sorry if its not a bug, or limitation but im getting
mad with this :o/ thanx for the oportunity and sorry for poor english

Marcus Vinícius




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

Bug #15911: call to undefined function in eval ()'ed code causes script to die

[sander]

From: [EMAIL PROTECTED]
Operating system: Debian (Sid) Linux
PHP version:  4.0CVS-2002-03-06
PHP Bug Type: Unknown/Other Function
Bug description:  call to undefined function in eval ()'ed code causes script to die

If eval()'ed code contains a parse error, the rest of the php script will
continue. If it contains a call to an undefined function, it will die, and
it won't execute the rest of the script.
That's very inconsistant behaviour


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

Bug #15910: php-3.0.18 configure --with-pgsql=DIRWITH-FOO

[hlehmann]

From: [EMAIL PROTECTED]
Operating system: Sol-8
PHP version:  4.1.2
PHP Bug Type: PostgreSQL related
Bug description:  php-3.0.18  configure --with-pgsql=DIRWITH-FOO

ln -s $PrefixPSQL /usr/local/pgsql
OPTIONS="$OPTIONS --with-pgsql=$PrefixPSQL"
...
./configure $OPTIONS
php-3.0.18 $ make
...
gcc -g -O2 -O2   -I. -I.   -I../apache_1.3.22/src/include
-I../apache_1.3.22/src
/os/unix -c internal_functions.c -o
internal_functions.o
In file included from internal_functions.c:59:
functions/php3_pgsql.h:46: libpq-fe.h: No such file or directory
functions/php3_pgsql.h:47: libpq/libpq-fs.h: No such file or directory
make: *** [internal_functions.o] Error 1
## Var PrefixPOSTGRES existiert nicht (-> PrefixPSQL)
## -IPOSTGREDIR fehlt
$ find / -name libpq-fs.h
/usr/local/pgsql-7.2/include/libpq/libpq-fs.h
/tmp/postgresql-7.2/src/include/libpq/libpq-fs.h
## Files sind aber da.
## Pfad (LD)? fuer postgresql fehlt.
## -> Fehler in configure-script , Makefile anpassen
## ---
## add -I/usr/local/pgsql-7.2/include to Makefile (INCLUDE=)
## Fehler ist weg, aber die erzeugte Lib funktioniert nicht.
## ---
## Ursache:
## - configure --with-pgsql=/usr/local/pgsql-7.2
##   -> generate Makefile mit:
##   INCLUDE = -I$(srcdir) -I.   -I/usr/local/apache/include  
##   ## -I$PrefixPSQL/include fehlt
## - configure --with-pgsql=/usr/local/pgsql
##   -> generate Makefile mit:
##   INCLUDE = -I$(srcdir) -I.   -I/usr/local/apache/include
-I/usr/local/pg
sql/include
##   ## -I$PrefixPSQL/include ist vorhanden
## -> Fehler in configure

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

Bug #15900 Updated: arguments to functions or again ODBC bug.

[adasi]

 ID:   15900
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: ODBC related
 Operating System: Linux
 PHP Version:  4.1.2
 New Comment:

Also:
echo odbc_result($table,5); 
works but
$tname=odbc_result($table,5); echo $tname; 
shows nothing dunno what to do, it's urgent.
unixODBC-2.2.1
FreeTDS-0.53


Previous Comments:


[2002-03-06 10:13:25] [EMAIL PROTECTED]

In second first example i've cut lines with my example database name,
user and password. In second one i forgot to do it. Of course the
reason why it's not working is '$a=$kid;', not the database
name/user/pass definitions.



[2002-03-06 10:09:59] [EMAIL PROTECTED]

This function:
function GetTID($kid)
{
$a=$kid;
$conn = odbc_pconnect("$database", "$username", "$password");
$query = "select * from KontrahIO where KontrId2 = ".$kid;
$table = odbc_do($conn,$query);
$xi=1;
odbc_fetch_row($table);
while (odbc_fetch_row($table)) {
$tid[$xi]=odbc_result($table,9);
$a=$tid[$xi];
$xi++;
}
odbc_close($conn);
return $tid;
}

works but this one:

function GetTID($kid)
{
$database="Hetman";
$username="admin";
$password="pewnienie";
$conn = odbc_pconnect("$database", "$username", "$password");
$query = "select * from KontrahIO where KontrId2 = ".$kid;
$table = odbc_do($conn,$query);
$xi=1;
odbc_fetch_row($table);
while (odbc_fetch_row($table)) {
$tid[$xi]=odbc_result($table,9);
$a=$tid[$xi];
$xi++;
}
odbc_close($conn);
return $tid;
}

no... It's returning nothing






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

Bug #15707 Updated: suggestion to Document about time() and other "Date and Time functions"

[Xuefer]

 ID:  15707
 Updated by:  [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
 Status:  Open
 Bug Type:Feature/Change Request
 PHP Version: 4.1.1
 New Comment:

sorry for my fooly mistype @_@
i've read so many codes when they calc: when->which
hold website--> whole website


Previous Comments:


[2002-02-25 00:11:17] [EMAIL PROTECTED]

why isn't there any suggestion/guide to the web-developers
that we should use unix timestamp for internal processing
and allowing convert in input/output

almost every c/c++ programmer would think,
it's fooly yet funny to operate TIME using STRING format
also in low speed



i've read so many codes when they calc the time_diff
mktime(..substr($time, 0, 4) - substr(..). blah... blah);


i'm using unix timestamp in my hold website, and output in certain
format as I like. it's simple yet enough!
i'm afraid it's only needed by mysql to store string-format
timestamp(mysql timestamp) that we can search by month or year and
others




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

Bug #15881 Updated: a new format char for sprintf kind function

[Xuefer]

 ID:   15881
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: all
 PHP Version:  4.1.2
 New Comment:

notice that it's capital "%S" not "%s"
or any other unused char


Previous Comments:


[2002-03-05 11:23:52] [EMAIL PROTECTED]

i've ask ppl in irc EFnet #php.
none of them like runtime magic quote.
so...

i would like to have the following feature:

-> sprintf("%S", $string);

which is the same function as addslashes($string);

and i can do as the following:

-> mysql_query(sprintf("UPDATE mytable SET abc='%S'", $string));


i think this would make a great change to those php-sql scripts




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

Bug #15873 Updated: special build error with apache using php module after system-compoment changed

[Xuefer]

 ID:   15873
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Apache related
 Operating System: rh linux 7.2
 PHP Version:  4.1.2
 New Comment:

well, i did have uninstalled gd-1.4.8 (i didn't notice the version
before), by "rpm -e gd-1.4.8"

but the version i reinstall is also gd-1.4.8 source
and compile/install to /usr/local/ (rpm version should be /usr/)

i've done "rm -f config.cache"
dunno why "configure" still think that nothing changed
so can't link with gd and give out "undefined reference" error


Previous Comments:


[2002-03-06 06:12:55] [EMAIL PROTECTED]

This might be caused by multiple versions of GD being installed. Check
if the old version is really gone and try again :)



[2002-03-05 08:30:31] [EMAIL PROTECTED]

what i did:
step1:
redhat7.2
with gd/jpeg/... support
build php as apache module
ok, works

step2:
uninstall some of the redhat rpm
download gd/jpeg and build it
reconfig php; make clean; make; make install;
all passed;

step3:
now reconfig apache, rebuild apache
failed! undefined reference to gdImageCreate gdImage
and so on...

i've tried so many times, still get such error.

and by change, i did the following command in apache src-package
directory:
[apache]# rm src/modules/php4/libphp4.module
and:
[php]# make install
[apache]# make

all pass! it works.


in a word, libphp4.module was not reinstalled correctly!




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

Bug #15909: Session data not updated on page jump

[phpbug]

From: [EMAIL PROTECTED]
Operating system: Linux Gnu  2.2.12 
PHP version:  4.1.2
PHP Bug Type: Session related
Bug description:  Session data not updated on page jump

Several pages that worked in PHP 4.0.2 no longer work in 4.1.2. The problem
is that values added to a global session variable array just before
jumping to another page are not being stored.

For example, on page courses.php the user selects a course from a list.
The code for the course is stored in a session variable $S[event_code],
and the code pagejumps (by calling a library routine that calls header())
to page course.php, to display data for that particular course. The
problem is, the value $S[event_code] no longer exists when we get to the
second page (course.php).

I can see the value in $S[event_code] if I var_dump($S)  before the
pagejump in courses.php. If I var_dump($S) just after arriving in page
course.php, I see the other contents of the $S array but not
$S[event_code].

Array $S is global and each page begins with
session_register("S");
The update takes place within a function that declares $S as global.

If I replace
$S[event_code] = $event_code;
with
$_SESSION[S][event_code] = $event_code; 
the value is passed.

PHP options enable_track_vars and register_globals are ON,
session.save_handler is files, session.serialize_handler is php.

Thank you.



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

Bug #15902 Updated: File Upload bug when sending many of files in upload multipart/form-data ?

[derick]

 ID:   15902
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: Linux Slackware 7.1
 PHP Version:  4.1.2
 New Comment:

I'll ask again, can you please try a snapshot from snaps.php.net?

Derick


Previous Comments:


[2002-03-06 11:44:33] [EMAIL PROTECTED]

I´ll post the code that i´m using

the point is using 20 different files of about 20 k each

use file.php?num=numberoffiles




 New Document 








 $v) { echo "$k => $v"; }
foreach ($HTTP_POST_FILES as $k => $v) { echo "$k ==> $v"; }

?>





=$i;$i++) {
 echo "";
}
?>









[2002-03-06 11:11:48] [EMAIL PROTECTED]

Hello,

the file upload code was rewritten for PHP 4.2.0, can you try a
snapshot from snaps.php.net and see if it works?

regards,
Derick



[2002-03-06 11:09:15] [EMAIL PROTECTED]

Sorry to annoy but i sent yesterday an email to Stefan Esser, and he
told me to open a bug report about the possibility of a bug in file
upload.

I updated my php to 4.1.2 and i´m having such a strange problem with
file upload i was woundering about a bug, because i tried to look at
rfc 2616 http1.1 and 1827, file
upload rfc and i didn´t find anything about it.

I wrote a code, that i can upload in one form unlimited files, at the
beggining i´m using

ini_set("upload_max_filesize","10M");
set_time_limit(0);

since then its all ok

it works all normally when i upload less than +- 20 or 25 files but
when i try 35
for example, the variables from post, that goes before the 35  tags doesn´t come...

i put a debug at the begging

foreach ($HTTP_POST_VARS as $k => $v) { echo "$k => $v"; }
foreach ($HTTP_POST_FILES as $k => $v) { echo "$k ==> $v"; }

when i get 10 or 15 files it returns to me

field1 => value
field2=> value
field3=> value
file1 ==> array
file2 ==> array
file3 ==> array
file4 ==> array
file5 ==> array
.. ==> array
field4 => value
field5 => value

but when i try 30 for example

it returns only

field1 => value
field2=> value
field3=> value
file1 ==> array

very strange isn´t it ?

I don´t know if there is any limitation in post data, but i thought
that if this exists it should return some warning or something, but it
seemed to me be very strange.

Sorry to annoy, or sorry if its not a bug, or limitation but im getting
mad with this :o/ thanx for the oportunity and sorry for poor english

Marcus Vinícius




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

Bug #15908: failed to compile with iconv

[winfried]

From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.5-RELEASE
PHP version:  4.1.2
PHP Bug Type: Compile Failure
Bug description:  failed to compile with iconv

I tried to compile latest PHP 4.1.2 on my system.
I need the iconv extension, but I get the following
error in linking:

/bin/sh /usr/ports/www/mod_php4/work/php-4.1.2/libtool --silent
--mode=link cc -I. -I/usr/ports/www/mod_php4/work/php-4.1.2/
-I/usr/ports/www/mod_php4/work/php-4.1.2/main
-I/usr/ports/www/mod_php4/work/php-4.1.2
-I/usr/ports/www/mod_php4/work/php-4.1.2/Zend
-I/usr/local/include/freetype2/freetype -I/usr/local/include/gd
-I/usr/local/include -I/usr/local/include/mysql
-I/usr/local/include/pspell  -I/usr/ports/www/mod_php4/work/php-4.1.2/TSRM
-march=i686 -O6 -I/usr/local/include -I/usr/local/include/pgsql   -o php
-export-dynamic stub.lo libphp4.la 
./.libs/libphp4.a(internal_functions.o)(.data+0x3c): undefined reference
to `iconv_module_entry'
*** Error code 1

I'm making the PHP binary standalone, right from ports. Some info about
the system: iconv-2.0, Sablot-0.81, expat-1.95.2. I had a similar problem
on other system, making an Apache PHP module; with PHP 4.0.6 I had no
problems with that (on FreeBSD 4.4-RELEASE/STABLE).

Here's my configure line:
--with-config-file-path=/usr/local/etc/php.standalone --disable-pear
--enable-discard-path --with-readline=/usr --enable-force-cgi-redirect
--enable-versioning --with-system-regex --disable-debug
--enable-track-vars --without-gd --without-mysql --with-gd=/usr/local
--with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local
--with-png-dir=/usr/local --with-zlib --with-mcrypt=/usr/local
--with-mhash=/usr/local --with-mysql=/usr/local --with-pgsql=/usr/local
--with-xml --with-expat-dir=/usr/local --enable-xslt --with-xslt-sablot
--with-expat-dir=/usr/local --with-iconv=/usr/local
--with-pspell=/usr/local --enable-mbregex --enable-mbstring
--enable-sockets --enable-trans-sid --with-iconv=/usr/local
--prefix=/usr/local i386-portbld-freebsd4.5

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

Bug #15905 Updated: long filenames in fopen() crash PHP.

[derick]

 ID:   15905
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Solaris 2.6
 PHP Version:  4.1.2
 New Comment:

Does it only happen with safe_mode on?

Derick


Previous Comments:


[2002-03-06 12:53:03] [EMAIL PROTECTED]

Can't reproduce this problem with latest CVS on Linux (don't have
solaris test environment).

Can you test with CVS ?



[2002-03-06 12:16:07] [EMAIL PROTECTED]

sorry, gdb output was duplicated during cut'n'paste.



[2002-03-06 12:06:58] [EMAIL PROTECTED]

Just investigated, it happens if the path name is longer than 1980
characters: PHP Works with 1980 characters, crashes with 1981.

Forgot to mention that i use the CGI version of PHP.



[2002-03-06 11:34:02] [EMAIL PROTECTED]

While upgrading PHP from 4.0.3pl1 to 4.1.2 i noticed crashes related to
long file names, espacially when running under safe_mode.

The problem can be reproduced using the following one liner:



Please note that for obvious reasons the filename has been shortened in
the example above, the "sleep" statement has been added for debugging
purposes...

Process trace of PHP:

sigprocmask(SIG_UNBLOCK, 0xEFFFE5B8, 0x) = 0
sigaction(SIGALRM, 0xEFFFE518, 0x)  = 0
resolvepath("",
0xEFFFE078, 1024) Err#78 ENAMETOOLONG
Incurred fault #6, FLTBOUNDS  %pc = 0xEF3A4644
  siginfo: SIGSEGV SEGV_MAPERR addr=0xF000
Received signal #11, SIGSEGV [default]
  siginfo: SIGSEGV SEGV_MAPERR addr=0xF000
*** process killed ***


gdb output:

(gdb) b php_fopen_wrapper
Breakpoint 1 at 0x2f3b8: file fopen_wrappers.c, line 245.
(gdb) cont
Continuing.

Breakpoint 1, php_fopen_wrapper (path=0x1cb060 'x' ..., 
mode=0x1c71e8 "r", options=4, issock=0xefffe660, socketd=0x72, 
opened_path=0x0) at fopen_wrappers.c:245
fopen_wrappers.c:245: No such file or directory.
(gdb) 
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xef3a4644 in strcpy ()
(gdb) bt
#0  0xef3a4644 in strcpy ()
#1  0xef3cbe18 in _realpath ()
#2  0xf8090 in php_checkuid (filename=0x1cb060 'x' ..., 
fopen_mode=0x1c71e8 "r", mode=0) at safe_mode.c:79
#3  0x2fcf8 in php_fopen_url_wrapper (
path=0x78787878 , 
mode=0x78787878 ,
options=2021161080, 
issock=0x78787878, socketd=0x78787878, opened_path=0x78787878)
at fopen_wrappers.c:558
Cannot access memory at address 0x787878b0.
(gdb) (gdb) b php_fopen_wrapper
Breakpoint 1 at 0x2f3b8: file fopen_wrappers.c, line 245.
(gdb) cont
Continuing.

Breakpoint 1, php_fopen_wrapper (path=0x1cb060 'x' ..., 
mode=0x1c71e8 "r", options=4, issock=0xefffe660, socketd=0x72, 
opened_path=0x0) at fopen_wrappers.c:245
fopen_wrappers.c:245: No such file or directory.
(gdb) 
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xef3a4644 in strcpy ()
(gdb) bt
#0  0xef3a4644 in strcpy ()
#1  0xef3cbe18 in _realpath ()
#2  0xf8090 in php_checkuid (filename=0x1cb060 'x' ..., 
fopen_mode=0x1c71e8 "r", mode=0) at safe_mode.c:79
#3  0x2fcf8 in php_fopen_url_wrapper (
path=0x78787878 , 
mode=0x78787878 ,
options=2021161080, 
issock=0x78787878, socketd=0x78787878, opened_path=0x78787878)
at fopen_wrappers.c:558
Cannot access memory at address 0x787878b0.
(gdb) 

Other occurrences with different path names and include path lead to
Bus Errors...

If you need further information, don't hesitate to contact me.

Alex Mayrhofer




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

Bug #15907 Updated: php 4.1.x error message on trying to load 4.0.x dyn. model broken

[hholzgra]

 ID:   15907
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Critical
 Bug Type: Dynamic loading
 Operating System: *
-PHP Version:  4.1.2
+PHP Version:  4.1.0 and above
-Assigned To:  
+Assigned To:  hholzgra


Previous Comments:


[2002-03-06 12:55:10] [EMAIL PROTECTED]

i get:

PHP Warning: 
U\x89\xe51\xc0\xeb^A\x90\xc9\xc3\x89\xf6U\x89\xe5\x83\xec^TS\xe8:
Unable to initialize module
Module compiled with debug=220, thread-safety=170 module API=677665696
PHP compiled with debug=0, thread-safety=0 module API=20010901
These options need to match 


instead of

PHP Warning:  sixcode :
Unable to initialize module
Module compiled with debug=0, thread-safety=0 module API=20001222
PHP compiled with debug=0, thread-safety=0 module API=20010901
These options need to match 

due to the new fields inserted into structure zend_module_entry

dl.c should be clever enought to look for the previous 
positions of the data fields when encountering malformed
values like "debug=220" or "API=677665696"




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

Bug #15907: php 4.1.x error message on trying to load 4.0.x dyn. model broken

[hholzgra]

From: [EMAIL PROTECTED]
Operating system: *
PHP version:  4.1.2
PHP Bug Type: Dynamic loading
Bug description:  php 4.1.x error message on trying to load 4.0.x dyn. model broken

i get:

PHP Warning: 
U\x89\xe51\xc0\xeb^A\x90\xc9\xc3\x89\xf6U\x89\xe5\x83\xec^TS\xe8:
Unable to initialize module
Module compiled with debug=220, thread-safety=170 module API=677665696
PHP compiled with debug=0, thread-safety=0 module API=20010901
These options need to match 


instead of

PHP Warning:  sixcode :
Unable to initialize module
Module compiled with debug=0, thread-safety=0 module API=20001222
PHP compiled with debug=0, thread-safety=0 module API=20010901
These options need to match 

due to the new fields inserted into structure zend_module_entry

dl.c should be clever enought to look for the previous 
positions of the data fields when encountering malformed
values like "debug=220" or "API=677665696"
-- 
Edit bug report at http://bugs.php.net/?id=15907&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15907&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15907&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15907&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15907&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15907&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15907&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15907&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15907&r=submittedtwice

Bug #15905 Updated: long filenames in fopen() crash PHP.

[mfischer]

 ID:   15905
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Solaris 2.6
 PHP Version:  4.1.2
 New Comment:

Can't reproduce this problem with latest CVS on Linux (don't have
solaris test environment).

Can you test with CVS ?


Previous Comments:


[2002-03-06 12:16:07] [EMAIL PROTECTED]

sorry, gdb output was duplicated during cut'n'paste.



[2002-03-06 12:06:58] [EMAIL PROTECTED]

Just investigated, it happens if the path name is longer than 1980
characters: PHP Works with 1980 characters, crashes with 1981.

Forgot to mention that i use the CGI version of PHP.



[2002-03-06 11:34:02] [EMAIL PROTECTED]

While upgrading PHP from 4.0.3pl1 to 4.1.2 i noticed crashes related to
long file names, espacially when running under safe_mode.

The problem can be reproduced using the following one liner:



Please note that for obvious reasons the filename has been shortened in
the example above, the "sleep" statement has been added for debugging
purposes...

Process trace of PHP:

sigprocmask(SIG_UNBLOCK, 0xEFFFE5B8, 0x) = 0
sigaction(SIGALRM, 0xEFFFE518, 0x)  = 0
resolvepath("",
0xEFFFE078, 1024) Err#78 ENAMETOOLONG
Incurred fault #6, FLTBOUNDS  %pc = 0xEF3A4644
  siginfo: SIGSEGV SEGV_MAPERR addr=0xF000
Received signal #11, SIGSEGV [default]
  siginfo: SIGSEGV SEGV_MAPERR addr=0xF000
*** process killed ***


gdb output:

(gdb) b php_fopen_wrapper
Breakpoint 1 at 0x2f3b8: file fopen_wrappers.c, line 245.
(gdb) cont
Continuing.

Breakpoint 1, php_fopen_wrapper (path=0x1cb060 'x' ..., 
mode=0x1c71e8 "r", options=4, issock=0xefffe660, socketd=0x72, 
opened_path=0x0) at fopen_wrappers.c:245
fopen_wrappers.c:245: No such file or directory.
(gdb) 
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xef3a4644 in strcpy ()
(gdb) bt
#0  0xef3a4644 in strcpy ()
#1  0xef3cbe18 in _realpath ()
#2  0xf8090 in php_checkuid (filename=0x1cb060 'x' ..., 
fopen_mode=0x1c71e8 "r", mode=0) at safe_mode.c:79
#3  0x2fcf8 in php_fopen_url_wrapper (
path=0x78787878 , 
mode=0x78787878 ,
options=2021161080, 
issock=0x78787878, socketd=0x78787878, opened_path=0x78787878)
at fopen_wrappers.c:558
Cannot access memory at address 0x787878b0.
(gdb) (gdb) b php_fopen_wrapper
Breakpoint 1 at 0x2f3b8: file fopen_wrappers.c, line 245.
(gdb) cont
Continuing.

Breakpoint 1, php_fopen_wrapper (path=0x1cb060 'x' ..., 
mode=0x1c71e8 "r", options=4, issock=0xefffe660, socketd=0x72, 
opened_path=0x0) at fopen_wrappers.c:245
fopen_wrappers.c:245: No such file or directory.
(gdb) 
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xef3a4644 in strcpy ()
(gdb) bt
#0  0xef3a4644 in strcpy ()
#1  0xef3cbe18 in _realpath ()
#2  0xf8090 in php_checkuid (filename=0x1cb060 'x' ..., 
fopen_mode=0x1c71e8 "r", mode=0) at safe_mode.c:79
#3  0x2fcf8 in php_fopen_url_wrapper (
path=0x78787878 , 
mode=0x78787878 ,
options=2021161080, 
issock=0x78787878, socketd=0x78787878, opened_path=0x78787878)
at fopen_wrappers.c:558
Cannot access memory at address 0x787878b0.
(gdb) 

Other occurrences with different path names and include path lead to
Bus Errors...

If you need further information, don't hesitate to contact me.

Alex Mayrhofer




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

Bug #15903 Updated: Compile failure when SAPDB + freeTDS

[derick]

 ID:   15903
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Linux 2.4.10
 PHP Version:  4.1.2
 New Comment:

This is a conflict between freedtds and the sapdb library, and PHP
can't do anything about this problem.
You should contact the FreeTDS or SapDB guys and ask if they want to
change the name of their constants.

Derick


Previous Comments:


[2002-03-06 11:27:10] [EMAIL PROTECTED]

Compiled PHP 4.1.2 with support for SAPDB with
--with-sapdb=/opt/sapdb/interfaces/odbc  --NO-PROBLEM

Compiled with support for MSSQL (freeTDS) with
--with-sybase=/usr/local/freetds  --NO-PROBLEM

BUT when I try to compile with both of them I get the following
Compile-Error:

make[2]: Entering directory `/root/compile/php-4.1.2/main'
/bin/sh /root/compile/php-4.1.2/libtool --silent --mode=compile gcc 
-I. -I/root/compile/php-4.1.2/main -I/root/compile/php-4.1.2/main
-I/root/compile/php-4.1.2 -I/usr/include/apache
-I/root/compile/php-4.1.2/Zend -I/usr/include/mysql
-I/opt/sapdb/interfaces/odbc/incl -I/usr/local/freetds/include
-I/root/compile/php-4.1.2/ext/xml/expat  -DEAPI_MM -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DHARD_SERVER_LIMIT=2048
-DDYNAMIC_MODULE_LIMIT=128 -DLINUX=22 -DMOD_SSL=208104 -DEAPI
-DUSE_EXPAT -I/root/compile/php-4.1.2/TSRM -g -O2 -prefer-pic  -c
internal_functions.c
In file included from /usr/local/freetds/include/sybfront.h:23,
 from
/root/compile/php-4.1.2/ext/sybase/php_sybase_db.h:67,
 from internal_functions.c:40:
/usr/local/freetds/include/sybdb.h:72: conflicting types for `RETCODE'
/opt/sapdb/interfaces/odbc/incl/sqltypes.h:164: previous declaration of
`RETCODE'
/usr/local/freetds/include/sybdb.h:80: conflicting types for `BOOL'
/opt/sapdb/interfaces/odbc/incl/WINDOWS.H:66: previous declaration of
`BOOL'
/usr/local/freetds/include/sybdb.h:106: redefinition of `BYTE'
/opt/sapdb/interfaces/odbc/incl/WINDOWS.H:74: `BYTE' previously
declared here
make[2]: *** [internal_functions.lo] Error 1
make[2]: Leaving directory `/root/compile/php-4.1.2/main'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/compile/php-4.1.2/main'
make: *** [all-recursive] Error 1





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

Bug #15715 Updated: file upload - empty $userfile

[jan]

 ID:   15715
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Unknown/Other Function
 Operating System: HP-UX 11i
 PHP Version:  4.1.1
 New Comment:

closing this one.


Previous Comments:


[2002-03-06 12:31:04] [EMAIL PROTECTED]

ok with PHP 4.1.2



[2002-03-06 12:28:57] [EMAIL PROTECTED]

Hi, 

After upgrading to PHP 4.1.2, no more problem.



[2002-03-05 15:56:18] [EMAIL PROTECTED]

I experiment the same problem on a Linux platform.
All variables including $_POST, $HTTP_POST_VARS (,and so on ) are
empty.
The problem occurs if the attribute 'enctype="multipart/form-data" ' is
set in the FORM tag even if no file is uploaded in the script.
Everything is OK if the enctype parameter is removed.

-M



[2002-02-25 11:53:59] [EMAIL PROTECTED]

With sample page :


Send this file: 



";
echo "File : " . $_FILES[userfile][name] ."";
echo "Type : " . $_FILES[userfile][type] ."";
echo "Temp : " . $_FILES[userfile][tmp_name] ."";
echo "Size : " . $_FILES[userfile][size] ."";
if (is_uploaded_file($_FILES[userfile][tmp_name]))
echo "Download : Ok";
elseecho "Download : KO";
}

On RedHat 7.2 (PHP 4.1.1, Apache 1.3.23) no problem,
$userfile=none or path to /tmp/x

On HP-UX 11i (PHP 4.0.6, Apache 1.3.19 build by HP) no problem.

On HP-UX 11i (PHP 4.1.1, Apache 1.3.23 build from source) $userfile and
other variables are empty.
(It's work one time on many)
Compile flags :

./configure  --with-oci8  --with-apache=../apache_1.3.23
--with-gd=/opt/gd --with-pdflib=/opt/pdflib
--with-jpeg-dir=/opt/jpeg-6 --with-png-dir=/opt/libpng
--with-tiff-dir=/opt/tiff-3.5 --with-zlib-dir=/opt/zlib
--enable-sigchild --with-mysql=/opt/mysql
--enable-sockets --with-tsrm-pthreads

Thank's for your help.




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

Bug #15715 Updated: file upload - empty $userfile

[remi . collet]

 ID:   15715
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Unknown/Other Function
 Operating System: HP-UX 11i
 PHP Version:  4.1.1
 New Comment:

ok with PHP 4.1.2


Previous Comments:


[2002-03-06 12:28:57] [EMAIL PROTECTED]

Hi, 

After upgrading to PHP 4.1.2, no more problem.



[2002-03-05 15:56:18] [EMAIL PROTECTED]

I experiment the same problem on a Linux platform.
All variables including $_POST, $HTTP_POST_VARS (,and so on ) are
empty.
The problem occurs if the attribute 'enctype="multipart/form-data" ' is
set in the FORM tag even if no file is uploaded in the script.
Everything is OK if the enctype parameter is removed.

-M



[2002-02-25 11:53:59] [EMAIL PROTECTED]

With sample page :


Send this file: 



";
echo "File : " . $_FILES[userfile][name] ."";
echo "Type : " . $_FILES[userfile][type] ."";
echo "Temp : " . $_FILES[userfile][tmp_name] ."";
echo "Size : " . $_FILES[userfile][size] ."";
if (is_uploaded_file($_FILES[userfile][tmp_name]))
echo "Download : Ok";
elseecho "Download : KO";
}

On RedHat 7.2 (PHP 4.1.1, Apache 1.3.23) no problem,
$userfile=none or path to /tmp/x

On HP-UX 11i (PHP 4.0.6, Apache 1.3.19 build by HP) no problem.

On HP-UX 11i (PHP 4.1.1, Apache 1.3.23 build from source) $userfile and
other variables are empty.
(It's work one time on many)
Compile flags :

./configure  --with-oci8  --with-apache=../apache_1.3.23
--with-gd=/opt/gd --with-pdflib=/opt/pdflib
--with-jpeg-dir=/opt/jpeg-6 --with-png-dir=/opt/libpng
--with-tiff-dir=/opt/tiff-3.5 --with-zlib-dir=/opt/zlib
--enable-sigchild --with-mysql=/opt/mysql
--enable-sockets --with-tsrm-pthreads

Thank's for your help.




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

Bug #15715 Updated: file upload - empty $userfile

[remi . collet]

 ID:   15715
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: HP-UX 11i
 PHP Version:  4.1.1
 New Comment:

Hi, 

After upgrading to PHP 4.1.2, no more problem.


Previous Comments:


[2002-03-05 15:56:18] [EMAIL PROTECTED]

I experiment the same problem on a Linux platform.
All variables including $_POST, $HTTP_POST_VARS (,and so on ) are
empty.
The problem occurs if the attribute 'enctype="multipart/form-data" ' is
set in the FORM tag even if no file is uploaded in the script.
Everything is OK if the enctype parameter is removed.

-M



[2002-02-25 11:53:59] [EMAIL PROTECTED]

With sample page :


Send this file: 



";
echo "File : " . $_FILES[userfile][name] ."";
echo "Type : " . $_FILES[userfile][type] ."";
echo "Temp : " . $_FILES[userfile][tmp_name] ."";
echo "Size : " . $_FILES[userfile][size] ."";
if (is_uploaded_file($_FILES[userfile][tmp_name]))
echo "Download : Ok";
elseecho "Download : KO";
}

On RedHat 7.2 (PHP 4.1.1, Apache 1.3.23) no problem,
$userfile=none or path to /tmp/x

On HP-UX 11i (PHP 4.0.6, Apache 1.3.19 build by HP) no problem.

On HP-UX 11i (PHP 4.1.1, Apache 1.3.23 build from source) $userfile and
other variables are empty.
(It's work one time on many)
Compile flags :

./configure  --with-oci8  --with-apache=../apache_1.3.23
--with-gd=/opt/gd --with-pdflib=/opt/pdflib
--with-jpeg-dir=/opt/jpeg-6 --with-png-dir=/opt/libpng
--with-tiff-dir=/opt/tiff-3.5 --with-zlib-dir=/opt/zlib
--enable-sigchild --with-mysql=/opt/mysql
--enable-sockets --with-tsrm-pthreads

Thank's for your help.




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

Bug #15841 Updated: CRLF to separate mail headers is incorrect

[hholzgra]

 ID:   15841
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: *Mail Related
 Operating System: Linux
 PHP Version:  4.1.2
 New Comment:

i still do not see the point, even for unix/sendmail

even /usr/lib/sendmail will transfer the message
using SMTP, and during this step you will have
\r\n line endings anyway, or am i missing something?


Previous Comments:


[2002-03-06 11:04:38] [EMAIL PROTECTED]

The Right Thing(TM), then, is to determine which method (direct or SMTP
injection) is being done. If SMTP, use \r\n. If direct, determine what
the OS' line terminator is (\r\n for Windows, \n for Unix, \r for Mac
(?!)) and use that instead.



[2002-03-04 05:36:24] [EMAIL PROTECTED]

on windows we *do* talk STMP ...



[2002-03-03 16:27:44] [EMAIL PROTECTED]

This is causing mail generated by PHP to be BLOCKED as being
potentially a virus by some anti-virus SMTP servers.

The presence of "\r\n" in headers is typically a sign of a virus trying
to reach Outlook. Some antivirus products now totally block MIME mail
containing "\r\n".

This means all mail generated by PHP programs...



[2002-03-02 20:05:00] [EMAIL PROTECTED]

Last November the mail documentation was changed from saying:
"Multiple extra headers are separated with a newline."
to:
"Multiple extra headers are separated with a carriage return and
newline. Note: You must use \r\n to seperate headers, although some
Unix mail transfer agents may work with just a single newline (\n)."

This change is inaccurate. Line breaks in headers should be the native
line endings for the system on which PHP is running.

The mail() function is not talking to an SMTP server, so RFC2822 does
not apply here. mail() is talking to a command line program on the
local system, and it is reasonable to expect that program to require
system-native line breaks.

Use of CRLF is known to break qmail systems where no conversion of line
breaks occurs on the input data. In this case using CRLF causes all but
the first extra header to appear in the message body (CRLF is
interpreted as two line breaks).

Possibly the best resolution to this problem would be for the mail()
function to convert any line breaks in arg 4 into the system's native
line breaks.





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

Bug #15884 Updated: session_unregister does not work when followed by header("Location: ...")

[jt]

 ID:   15884
 Updated by:   [EMAIL PROTECTED]
-Summary:  session_unregister does not work when followed by
   header("Location: ...")
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  4.1.2
 New Comment:

> You must provide short & complete script.
> It sounds like your bug to me.

Well this issue is very to reproduce so I thought providing a script
wont be necessary. Anyway the following set of scripts will expose the
bug.

Please note that including the session handler will not be necessary if
you are not running user-defined session handlers (php.ini setting)

An explanation on how to use the scripts is below

-
file: include.php


-
file: t1.php


t2
-
file: t2.php

";
?>
t3
-
file: t3.php


t2
-


Observed behaviour:

t1 registers $myvar and displays link to t2. Follow this link
t2 shows value of $myvar and displays link to t3. Follow this link
t3 unregisters $myvar and uses header("Location: ") to redirect you to
t2
t2 shows value of $myvar - it is still "hello"

The behaviour in the last step is incorrect - since $myvar was
unregistred, its value should have been deleted from the session but
obiously is not


When you comment out the line starting with "header" in t3.php and do
the first two steps above and then click the link t3 shows $myvar will
get unregistred properly. This is why the bug has the title
"session_unregister does not work when followed by header("Location:
...")"


btw: The reason for this is not the session-handler I use, php simply
does not call the "pgsql_session_write" function if session_unregister
is followed by a header("Location: ...") statement.


best regards,

Jochen


Previous Comments:


[2002-03-06 03:04:01] [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".


You must provide short & complete script.
It sounds like your bug to me.



[2002-03-05 12:32:08] [EMAIL PROTECTED]

When followed by a 

header("Location: ...");

statement session_unregister does not get properly executed.

Reproduce: Take any script that has a session_unregister in it, put a
header("Location: ...") under this statement, and see if unregistered
var gets deleted from session-storage (it does not)
Now put a session_write_close() in front of the header-statement and
watch it work properly.

If you have trouble reproducing this please don't hesitate to contact
me.

My setup:

User-Defined Session-Handler: pgsql_session_handler latest version

PHP compiled with:
./configure' '--with-mysql=/usr/local/mysql' '--with-pgsql'
'--with-ldap' '--enable-trans-sid' '--with-gd'

Exact same setup worked with php4.0.6, did not work after upgrade to
4.1.2








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

Bug #15905 Updated: long filenames in fopen() crash PHP.

[a . mayrhofer]

 ID:   15905
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Solaris 2.6
 PHP Version:  4.1.2
 New Comment:

sorry, gdb output was duplicated during cut'n'paste.


Previous Comments:


[2002-03-06 12:06:58] [EMAIL PROTECTED]

Just investigated, it happens if the path name is longer than 1980
characters: PHP Works with 1980 characters, crashes with 1981.

Forgot to mention that i use the CGI version of PHP.



[2002-03-06 11:34:02] [EMAIL PROTECTED]

While upgrading PHP from 4.0.3pl1 to 4.1.2 i noticed crashes related to
long file names, espacially when running under safe_mode.

The problem can be reproduced using the following one liner:



Please note that for obvious reasons the filename has been shortened in
the example above, the "sleep" statement has been added for debugging
purposes...

Process trace of PHP:

sigprocmask(SIG_UNBLOCK, 0xEFFFE5B8, 0x) = 0
sigaction(SIGALRM, 0xEFFFE518, 0x)  = 0
resolvepath("",
0xEFFFE078, 1024) Err#78 ENAMETOOLONG
Incurred fault #6, FLTBOUNDS  %pc = 0xEF3A4644
  siginfo: SIGSEGV SEGV_MAPERR addr=0xF000
Received signal #11, SIGSEGV [default]
  siginfo: SIGSEGV SEGV_MAPERR addr=0xF000
*** process killed ***


gdb output:

(gdb) b php_fopen_wrapper
Breakpoint 1 at 0x2f3b8: file fopen_wrappers.c, line 245.
(gdb) cont
Continuing.

Breakpoint 1, php_fopen_wrapper (path=0x1cb060 'x' ..., 
mode=0x1c71e8 "r", options=4, issock=0xefffe660, socketd=0x72, 
opened_path=0x0) at fopen_wrappers.c:245
fopen_wrappers.c:245: No such file or directory.
(gdb) 
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xef3a4644 in strcpy ()
(gdb) bt
#0  0xef3a4644 in strcpy ()
#1  0xef3cbe18 in _realpath ()
#2  0xf8090 in php_checkuid (filename=0x1cb060 'x' ..., 
fopen_mode=0x1c71e8 "r", mode=0) at safe_mode.c:79
#3  0x2fcf8 in php_fopen_url_wrapper (
path=0x78787878 , 
mode=0x78787878 ,
options=2021161080, 
issock=0x78787878, socketd=0x78787878, opened_path=0x78787878)
at fopen_wrappers.c:558
Cannot access memory at address 0x787878b0.
(gdb) (gdb) b php_fopen_wrapper
Breakpoint 1 at 0x2f3b8: file fopen_wrappers.c, line 245.
(gdb) cont
Continuing.

Breakpoint 1, php_fopen_wrapper (path=0x1cb060 'x' ..., 
mode=0x1c71e8 "r", options=4, issock=0xefffe660, socketd=0x72, 
opened_path=0x0) at fopen_wrappers.c:245
fopen_wrappers.c:245: No such file or directory.
(gdb) 
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xef3a4644 in strcpy ()
(gdb) bt
#0  0xef3a4644 in strcpy ()
#1  0xef3cbe18 in _realpath ()
#2  0xf8090 in php_checkuid (filename=0x1cb060 'x' ..., 
fopen_mode=0x1c71e8 "r", mode=0) at safe_mode.c:79
#3  0x2fcf8 in php_fopen_url_wrapper (
path=0x78787878 , 
mode=0x78787878 ,
options=2021161080, 
issock=0x78787878, socketd=0x78787878, opened_path=0x78787878)
at fopen_wrappers.c:558
Cannot access memory at address 0x787878b0.
(gdb) 

Other occurrences with different path names and include path lead to
Bus Errors...

If you need further information, don't hesitate to contact me.

Alex Mayrhofer




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

Bug #15905 Updated: long filenames in fopen() crash PHP.

[a . mayrhofer]

 ID:   15905
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Solaris 2.6
 PHP Version:  4.1.2
 New Comment:

Just investigated, it happens if the path name is longer than 1980
characters: PHP Works with 1980 characters, crashes with 1981.

Forgot to mention that i use the CGI version of PHP.


Previous Comments:


[2002-03-06 11:34:02] [EMAIL PROTECTED]

While upgrading PHP from 4.0.3pl1 to 4.1.2 i noticed crashes related to
long file names, espacially when running under safe_mode.

The problem can be reproduced using the following one liner:



Please note that for obvious reasons the filename has been shortened in
the example above, the "sleep" statement has been added for debugging
purposes...

Process trace of PHP:

sigprocmask(SIG_UNBLOCK, 0xEFFFE5B8, 0x) = 0
sigaction(SIGALRM, 0xEFFFE518, 0x)  = 0
resolvepath("",
0xEFFFE078, 1024) Err#78 ENAMETOOLONG
Incurred fault #6, FLTBOUNDS  %pc = 0xEF3A4644
  siginfo: SIGSEGV SEGV_MAPERR addr=0xF000
Received signal #11, SIGSEGV [default]
  siginfo: SIGSEGV SEGV_MAPERR addr=0xF000
*** process killed ***


gdb output:

(gdb) b php_fopen_wrapper
Breakpoint 1 at 0x2f3b8: file fopen_wrappers.c, line 245.
(gdb) cont
Continuing.

Breakpoint 1, php_fopen_wrapper (path=0x1cb060 'x' ..., 
mode=0x1c71e8 "r", options=4, issock=0xefffe660, socketd=0x72, 
opened_path=0x0) at fopen_wrappers.c:245
fopen_wrappers.c:245: No such file or directory.
(gdb) 
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xef3a4644 in strcpy ()
(gdb) bt
#0  0xef3a4644 in strcpy ()
#1  0xef3cbe18 in _realpath ()
#2  0xf8090 in php_checkuid (filename=0x1cb060 'x' ..., 
fopen_mode=0x1c71e8 "r", mode=0) at safe_mode.c:79
#3  0x2fcf8 in php_fopen_url_wrapper (
path=0x78787878 , 
mode=0x78787878 ,
options=2021161080, 
issock=0x78787878, socketd=0x78787878, opened_path=0x78787878)
at fopen_wrappers.c:558
Cannot access memory at address 0x787878b0.
(gdb) (gdb) b php_fopen_wrapper
Breakpoint 1 at 0x2f3b8: file fopen_wrappers.c, line 245.
(gdb) cont
Continuing.

Breakpoint 1, php_fopen_wrapper (path=0x1cb060 'x' ..., 
mode=0x1c71e8 "r", options=4, issock=0xefffe660, socketd=0x72, 
opened_path=0x0) at fopen_wrappers.c:245
fopen_wrappers.c:245: No such file or directory.
(gdb) 
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xef3a4644 in strcpy ()
(gdb) bt
#0  0xef3a4644 in strcpy ()
#1  0xef3cbe18 in _realpath ()
#2  0xf8090 in php_checkuid (filename=0x1cb060 'x' ..., 
fopen_mode=0x1c71e8 "r", mode=0) at safe_mode.c:79
#3  0x2fcf8 in php_fopen_url_wrapper (
path=0x78787878 , 
mode=0x78787878 ,
options=2021161080, 
issock=0x78787878, socketd=0x78787878, opened_path=0x78787878)
at fopen_wrappers.c:558
Cannot access memory at address 0x787878b0.
(gdb) 

Other occurrences with different path names and include path lead to
Bus Errors...

If you need further information, don't hesitate to contact me.

Alex Mayrhofer




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

Bug #15902 Updated: File Upload bug when sending many of files in upload multipart/form-data ?

[m]

 ID:   15902
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: Linux Slackware 7.1
 PHP Version:  4.1.2
 New Comment:

I´ll post the code that i´m using

the point is using 20 different files of about 20 k each

use file.php?num=numberoffiles




 New Document 








 $v) { echo "$k => $v"; }
foreach ($HTTP_POST_FILES as $k => $v) { echo "$k ==> $v"; }

?>





=$i;$i++) {
 echo "";
}
?>








Previous Comments:


[2002-03-06 11:11:48] [EMAIL PROTECTED]

Hello,

the file upload code was rewritten for PHP 4.2.0, can you try a
snapshot from snaps.php.net and see if it works?

regards,
Derick



[2002-03-06 11:09:15] [EMAIL PROTECTED]

Sorry to annoy but i sent yesterday an email to Stefan Esser, and he
told me to open a bug report about the possibility of a bug in file
upload.

I updated my php to 4.1.2 and i´m having such a strange problem with
file upload i was woundering about a bug, because i tried to look at
rfc 2616 http1.1 and 1827, file
upload rfc and i didn´t find anything about it.

I wrote a code, that i can upload in one form unlimited files, at the
beggining i´m using

ini_set("upload_max_filesize","10M");
set_time_limit(0);

since then its all ok

it works all normally when i upload less than +- 20 or 25 files but
when i try 35
for example, the variables from post, that goes before the 35  tags doesn´t come...

i put a debug at the begging

foreach ($HTTP_POST_VARS as $k => $v) { echo "$k => $v"; }
foreach ($HTTP_POST_FILES as $k => $v) { echo "$k ==> $v"; }

when i get 10 or 15 files it returns to me

field1 => value
field2=> value
field3=> value
file1 ==> array
file2 ==> array
file3 ==> array
file4 ==> array
file5 ==> array
.. ==> array
field4 => value
field5 => value

but when i try 30 for example

it returns only

field1 => value
field2=> value
field3=> value
file1 ==> array

very strange isn´t it ?

I don´t know if there is any limitation in post data, but i thought
that if this exists it should return some warning or something, but it
seemed to me be very strange.

Sorry to annoy, or sorry if its not a bug, or limitation but im getting
mad with this :o/ thanx for the oportunity and sorry for poor english

Marcus Vinícius




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

Bug #15906: pcntl_signal() does not work while waiting with socket_accept()

[christophe . dirac]

From: [EMAIL PROTECTED]
Operating system: SuSE 7.0 Kernel 2.2.17
PHP version:  4.1.1
PHP Bug Type: Unknown/Other Function
Bug description:  pcntl_signal() does not work while waiting with socket_accept()

Configure Command: ./configure --with-imap --with-mysql --enable-sockets
--enable-pcntl

Example:
#! /usr/local/bin/php -q
http://bugs.php.net/?id=15906&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15906&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15906&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15906&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15906&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15906&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15906&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15906&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15906&r=submittedtwice

Bug #15905: long filenames in fopen() crash PHP.

[a . mayrhofer]

From: [EMAIL PROTECTED]
Operating system: Solaris 2.6
PHP version:  4.1.2
PHP Bug Type: Reproducible crash
Bug description:  long filenames in fopen() crash PHP.

While upgrading PHP from 4.0.3pl1 to 4.1.2 i noticed crashes related to
long file names, espacially when running under safe_mode.

The problem can be reproduced using the following one liner:



Please note that for obvious reasons the filename has been shortened in
the example above, the "sleep" statement has been added for debugging
purposes...

Process trace of PHP:

sigprocmask(SIG_UNBLOCK, 0xEFFFE5B8, 0x) = 0
sigaction(SIGALRM, 0xEFFFE518, 0x)  = 0
resolvepath("",
0xEFFFE078, 1024) Err#78 ENAMETOOLONG
Incurred fault #6, FLTBOUNDS  %pc = 0xEF3A4644
  siginfo: SIGSEGV SEGV_MAPERR addr=0xF000
Received signal #11, SIGSEGV [default]
  siginfo: SIGSEGV SEGV_MAPERR addr=0xF000
*** process killed ***


gdb output:

(gdb) b php_fopen_wrapper
Breakpoint 1 at 0x2f3b8: file fopen_wrappers.c, line 245.
(gdb) cont
Continuing.

Breakpoint 1, php_fopen_wrapper (path=0x1cb060 'x' ...,

mode=0x1c71e8 "r", options=4, issock=0xefffe660, socketd=0x72, 
opened_path=0x0) at fopen_wrappers.c:245
fopen_wrappers.c:245: No such file or directory.
(gdb) 
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xef3a4644 in strcpy ()
(gdb) bt
#0  0xef3a4644 in strcpy ()
#1  0xef3cbe18 in _realpath ()
#2  0xf8090 in php_checkuid (filename=0x1cb060 'x' ...,

fopen_mode=0x1c71e8 "r", mode=0) at safe_mode.c:79
#3  0x2fcf8 in php_fopen_url_wrapper (
path=0x78787878 , 
mode=0x78787878 ,
options=2021161080, 
issock=0x78787878, socketd=0x78787878, opened_path=0x78787878)
at fopen_wrappers.c:558
Cannot access memory at address 0x787878b0.
(gdb) (gdb) b php_fopen_wrapper
Breakpoint 1 at 0x2f3b8: file fopen_wrappers.c, line 245.
(gdb) cont
Continuing.

Breakpoint 1, php_fopen_wrapper (path=0x1cb060 'x' ...,

mode=0x1c71e8 "r", options=4, issock=0xefffe660, socketd=0x72, 
opened_path=0x0) at fopen_wrappers.c:245
fopen_wrappers.c:245: No such file or directory.
(gdb) 
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xef3a4644 in strcpy ()
(gdb) bt
#0  0xef3a4644 in strcpy ()
#1  0xef3cbe18 in _realpath ()
#2  0xf8090 in php_checkuid (filename=0x1cb060 'x' ...,

fopen_mode=0x1c71e8 "r", mode=0) at safe_mode.c:79
#3  0x2fcf8 in php_fopen_url_wrapper (
path=0x78787878 , 
mode=0x78787878 ,
options=2021161080, 
issock=0x78787878, socketd=0x78787878, opened_path=0x78787878)
at fopen_wrappers.c:558
Cannot access memory at address 0x787878b0.
(gdb) 

Other occurrences with different path names and include path lead to Bus
Errors...

If you need further information, don't hesitate to contact me.

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

Bug #15904: Return value of eval()

[bs_php]

From: [EMAIL PROTECTED]
Operating system: Win 2k
PHP version:  4.1.1
PHP Bug Type: Documentation problem
Bug description:  Return value of eval() 

The PHP doc says:
  "In PHP 4, eval() returns FALSE unless return() is called"

But I get NULL as return value if return() is not used. I only get FALSE
if an FATAL error occures during the eval(); like a parse error. 


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

Bug #15903: Compile failure when SAPDB + freeTDS

[SM]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4.10
PHP version:  4.1.2
PHP Bug Type: Compile Failure
Bug description:  Compile failure when SAPDB + freeTDS

Compiled PHP 4.1.2 with support for SAPDB with
--with-sapdb=/opt/sapdb/interfaces/odbc  --NO-PROBLEM

Compiled with support for MSSQL (freeTDS) with
--with-sybase=/usr/local/freetds  --NO-PROBLEM

BUT when I try to compile with both of them I get the following
Compile-Error:

make[2]: Entering directory `/root/compile/php-4.1.2/main'
/bin/sh /root/compile/php-4.1.2/libtool --silent --mode=compile gcc  -I.
-I/root/compile/php-4.1.2/main -I/root/compile/php-4.1.2/main
-I/root/compile/php-4.1.2 -I/usr/include/apache
-I/root/compile/php-4.1.2/Zend -I/usr/include/mysql
-I/opt/sapdb/interfaces/odbc/incl -I/usr/local/freetds/include
-I/root/compile/php-4.1.2/ext/xml/expat  -DEAPI_MM -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DHARD_SERVER_LIMIT=2048 -DDYNAMIC_MODULE_LIMIT=128
-DLINUX=22 -DMOD_SSL=208104 -DEAPI -DUSE_EXPAT
-I/root/compile/php-4.1.2/TSRM -g -O2 -prefer-pic  -c
internal_functions.c
In file included from /usr/local/freetds/include/sybfront.h:23,
 from
/root/compile/php-4.1.2/ext/sybase/php_sybase_db.h:67,
 from internal_functions.c:40:
/usr/local/freetds/include/sybdb.h:72: conflicting types for `RETCODE'
/opt/sapdb/interfaces/odbc/incl/sqltypes.h:164: previous declaration of
`RETCODE'
/usr/local/freetds/include/sybdb.h:80: conflicting types for `BOOL'
/opt/sapdb/interfaces/odbc/incl/WINDOWS.H:66: previous declaration of
`BOOL'
/usr/local/freetds/include/sybdb.h:106: redefinition of `BYTE'
/opt/sapdb/interfaces/odbc/incl/WINDOWS.H:74: `BYTE' previously declared
here
make[2]: *** [internal_functions.lo] Error 1
make[2]: Leaving directory `/root/compile/php-4.1.2/main'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/compile/php-4.1.2/main'
make: *** [all-recursive] Error 1

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

Bug #15902 Updated: File Upload bug when sending many of files in upload multipart/form-data ?

[derick]

 ID:   15902
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: Linux Slackware 7.1
 PHP Version:  4.1.2
 New Comment:

Hello,

the file upload code was rewritten for PHP 4.2.0, can you try a
snapshot from snaps.php.net and see if it works?

regards,
Derick


Previous Comments:


[2002-03-06 11:09:15] [EMAIL PROTECTED]

Sorry to annoy but i sent yesterday an email to Stefan Esser, and he
told me to open a bug report about the possibility of a bug in file
upload.

I updated my php to 4.1.2 and i´m having such a strange problem with
file upload i was woundering about a bug, because i tried to look at
rfc 2616 http1.1 and 1827, file
upload rfc and i didn´t find anything about it.

I wrote a code, that i can upload in one form unlimited files, at the
beggining i´m using

ini_set("upload_max_filesize","10M");
set_time_limit(0);

since then its all ok

it works all normally when i upload less than +- 20 or 25 files but
when i try 35
for example, the variables from post, that goes before the 35  tags doesn´t come...

i put a debug at the begging

foreach ($HTTP_POST_VARS as $k => $v) { echo "$k => $v"; }
foreach ($HTTP_POST_FILES as $k => $v) { echo "$k ==> $v"; }

when i get 10 or 15 files it returns to me

field1 => value
field2=> value
field3=> value
file1 ==> array
file2 ==> array
file3 ==> array
file4 ==> array
file5 ==> array
.. ==> array
field4 => value
field5 => value

but when i try 30 for example

it returns only

field1 => value
field2=> value
field3=> value
file1 ==> array

very strange isn´t it ?

I don´t know if there is any limitation in post data, but i thought
that if this exists it should return some warning or something, but it
seemed to me be very strange.

Sorry to annoy, or sorry if its not a bug, or limitation but im getting
mad with this :o/ thanx for the oportunity and sorry for poor english

Marcus Vinícius




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

Bug #15902: File Upload bug when sending many of files in upload multipart/form-data ?

[m]

From: [EMAIL PROTECTED]
Operating system: Linux Slackware 7.1
PHP version:  4.1.2
PHP Bug Type: Scripting Engine problem
Bug description:  File Upload bug when sending many of files in upload 
multipart/form-data ?

Sorry to annoy but i sent yesterday an email to Stefan Esser, and he told
me to open a bug report about the possibility of a bug in file upload.

I updated my php to 4.1.2 and i´m having such a strange problem with file
upload i was woundering about a bug, because i tried to look at rfc 2616
http1.1 and 1827, file
upload rfc and i didn´t find anything about it.

I wrote a code, that i can upload in one form unlimited files, at the
beggining i´m using

ini_set("upload_max_filesize","10M");
set_time_limit(0);

since then its all ok

it works all normally when i upload less than +- 20 or 25 files but when i
try 35
for example, the variables from post, that goes before the 35  tags doesn´t come...

i put a debug at the begging

foreach ($HTTP_POST_VARS as $k => $v) { echo "$k => $v"; }
foreach ($HTTP_POST_FILES as $k => $v) { echo "$k ==> $v"; }

when i get 10 or 15 files it returns to me

field1 => value
field2=> value
field3=> value
file1 ==> array
file2 ==> array
file3 ==> array
file4 ==> array
file5 ==> array
.. ==> array
field4 => value
field5 => value

but when i try 30 for example

it returns only

field1 => value
field2=> value
field3=> value
file1 ==> array

very strange isn´t it ?

I don´t know if there is any limitation in post data, but i thought that
if this exists it should return some warning or something, but it seemed
to me be very strange.

Sorry to annoy, or sorry if its not a bug, or limitation but im getting
mad with this :o/ thanx for the oportunity and sorry for poor english

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

Bug #15841 Updated: CRLF to separate mail headers is incorrect

[pcg-php]

 ID:   15841
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: *Mail Related
 Operating System: Linux
 PHP Version:  4.1.2
 New Comment:

The Right Thing(TM), then, is to determine which method (direct or SMTP
injection) is being done. If SMTP, use \r\n. If direct, determine what
the OS' line terminator is (\r\n for Windows, \n for Unix, \r for Mac
(?!)) and use that instead.


Previous Comments:


[2002-03-04 05:36:24] [EMAIL PROTECTED]

on windows we *do* talk STMP ...



[2002-03-03 16:27:44] [EMAIL PROTECTED]

This is causing mail generated by PHP to be BLOCKED as being
potentially a virus by some anti-virus SMTP servers.

The presence of "\r\n" in headers is typically a sign of a virus trying
to reach Outlook. Some antivirus products now totally block MIME mail
containing "\r\n".

This means all mail generated by PHP programs...



[2002-03-02 20:05:00] [EMAIL PROTECTED]

Last November the mail documentation was changed from saying:
"Multiple extra headers are separated with a newline."
to:
"Multiple extra headers are separated with a carriage return and
newline. Note: You must use \r\n to seperate headers, although some
Unix mail transfer agents may work with just a single newline (\n)."

This change is inaccurate. Line breaks in headers should be the native
line endings for the system on which PHP is running.

The mail() function is not talking to an SMTP server, so RFC2822 does
not apply here. mail() is talking to a command line program on the
local system, and it is reasonable to expect that program to require
system-native line breaks.

Use of CRLF is known to break qmail systems where no conversion of line
breaks occurs on the input data. In this case using CRLF causes all but
the first extra header to appear in the message body (CRLF is
interpreted as two line breaks).

Possibly the best resolution to this problem would be for the mail()
function to convert any line breaks in arg 4 into the system's native
line breaks.





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