Bug #15905 Updated: long filenames in fopen() crash PHP.
ID: 15905
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Solaris 2.6
PHP Version: 4.1.2
New Comment:
Can't reproduce it on Linux as well. Could be related to some solaris
weirdness. example script works fine if safe_mode is turned off. I'll
test with latest snap shots today.
cheers
axelm
Previous Comments:
[2002-03-06 12:55:49] [EMAIL PROTECTED]
Does it only happen with safe_mode on?
Derick
[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 #15727 Updated: session.gc_maxlifetime doesn't work
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:
yeah,I wanna delete the session files.
u see,if these session files can not be deleted,it will be accumulated
and ocuppy so much disk space.
BTW,I still a question about cookies,why is the time that the cookies
expired not same as the time that parameter of session.cookie_lifetime
set?
for example, I wanna the cookies expired 5 minutes later,what should I
do?I think I should set the parameter,as follow:
session.cookie_lifetime = 300
right?
But, after restart my apache server,I found the cookies maybe expired
after 2 minutes,not 5 minutes as I want.
why?
Previous Comments:
[2002-03-06 22:23:06] [EMAIL PROTECTED]
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.
[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 #14222 Updated: PHP Crashes with weird output often
ID: 14222 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: Windows XP Pro PHP Version: 4.1.1 New Comment: the apache -X seems to work fine! yes! Previous Comments: [2002-03-05 14:17:18] [EMAIL PROTECTED] apache -X dont work (still the same problem) problem has nothing to do with mysql problem (again..): -> on a easy loop with enought data the weird output comes -> the "weird output" is: ->-> moved letters (just moved some pixels down, up, left or right) ->-> replaced letters (with any kind of replacements) ->-> additional letters (i didnt reported missing letters yet, except that the end of the file is different) -> Browser (client) reloading -> Ping seems to make problems (higher ping more problems) some small notes: it depends how much he transfers on every request (i had 0bytes up to the whole document and many steps between them) [2002-03-05 12:17:55] [EMAIL PROTECTED] I HAVE THE SAME PROBLEM! ... humm ... I use : winxp pro/apache 1.3.22/php 4.1.1/mysql 4.01a (run on the same machine) >From my local network it work fine but when I try to see a page of my site from an another location on internet (school for exemple) sometimes it works and sometimes it blinks and crashs. I have this with anything browser (ie5, ie6, opera, galeon etc..). description client-side: the browser load just a part of page (~8000 first bytes) and then it reloads it again and again... description server-side: apache, php and mysql doesn't see any error... But, it all works fine when i use mysql on a another server (on internet) not as localhost its strange, no ? [2002-02-25 11:03:01] [EMAIL PROTECTED] thanks, "apache - X" seems to work !! [2002-02-08 12:20:56] [EMAIL PROTECTED] I also have this problem. Using latest patches with XP Pro, PHP, and Apache. I have not isolated it yet but it has to do with larger amounts of print/echo output being delivered from a php page. Meaning, if my code displays 10 "news" items (slashdot style page) it works, then if I display say 15 it starts to behave irregularly. This has been observed as a localhost access on to the server on the same computer and also accessing the server running from a different computer on the net. When the problem occurs the browser continually reloads this same page and never finishes. (this noticed when accessing the server through ie6 on xp) When accessing the problem page via mozzila from linux station I notice that the page gets just cut off. Anyway I'll try to isolate further. [2002-02-08 04:03:33] [EMAIL PROTECTED] run apache in single process mode eg: apache -X It's probably a bug in the duplicatesocket 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/14222 -- Edit this bug report at http://bugs.php.net/?id=14222&edit=1
Bug #15822 Updated: session variables disappear
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:
To call the session_register() after session_start() for every
session-variable can't be a good solution of course because you have to
get the values for your session-vars at every reload...
Previous Comments:
[2002-03-06 16:04:04] [EMAIL PROTECTED]
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.
[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 #15917 Updated: Virtual host won't work _anymore_ with php-cgi
ID: 15917 Updated by: [EMAIL PROTECTED] -Summary: Virtual host won't work _anymore_ with php-cgi Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: WIndows XP Professional PHP Version: 4.1.1 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Previous Comments: [2002-03-06 18:20:35] [EMAIL PROTECTED] 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 this bug report at http://bugs.php.net/?id=15917&edit=1
Bug #10027 Updated: HTTP_REFERER
ID: 10027 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *Web Server problem Operating System: Linux Redhat 6.2 PHP Version: 4.0.4pl1 New Comment: Both windows2000 & FreeBSD 3.4 found SAME Problem With Apache! How to decode HTTP_WEFERER? Previous Comments: [2001-04-29 11:50:00] [EMAIL PROTECTED] No feedback. closing [2001-03-29 11:11:48] [EMAIL PROTECTED] Works for me just fine with latest CVS. (snapshot can be found at http://snaps.php.net/ ) Which webserver are you using? Apache? --Jani [2001-03-27 11:31:50] [EMAIL PROTECTED] Linking to a phpinfo() page should give a valid HTTP_REFERER value, however, I don't see it. The only thing I see remotely close to that is: HTTP_WEFERER WCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARH -- Edit this bug report at http://bugs.php.net/?id=10027&edit=1
Bug #14971 Updated: unhandled exception processing the ISAPI
ID: 14971 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Operating System: WIN2000 server (SP2) PHP Version: 4.1.1 New Comment: We already had the php4isapi.dll als ISAPI-Filter included, but nevertheless it does not work at all. The crashes are gone for sure, but the new flavour ist that sporadically the connection to an Oracle Database get's lost somehow, somewhere, and all my scripts do not work anymore. The problem occures more often after the server has had a heavy load. Point is: PHP does not crash anymore, but in order to have a working DB connection I have to restart the iisadmin-service. regards, Bernd Previous Comments: [2002-02-06 09:31:55] [EMAIL PROTECTED] I was experiencing this type of crashing over and over myself with win2k SP2. The solution was to add the ISAPI DLL in the ISAPI Filters list as well as the App Mappings. After this ISAPI has been rock solid. This is the same solution as in this bug report: http://bugs.php.net/bug.php?id=15324 . Note: I did not do this at first because the PHP Manual specifically said that I should not do so (http://www.php.net/manual/en/install.iis.php) unless I needed it for HTTP Authentication. Maybe someone should place some errata in the documentation? [2002-01-31 07:41:23] [EMAIL PROTECTED] Hi there, we've got the same problem too. Even on older Versions of PHP it appeares from time to time. 4.1.1 creates the same SysLog-Message on W2k Sp2, but we only use ODBC. Only NET STOP IISADMIN solves the problem, but from time to time you need to reboot the machine. Using the Zend Optimizer or not is not the problem, it is re-creatable without Zend... One thing to mention is, that it only appears on querys that are quite time consuming. regards, Bernd [2002-01-22 10:51:01] [EMAIL PROTECTED] I have the same problem. However, I even unloaded all extensions and the Optimizer thinking that they had to do with it but it still crashes. [2002-01-14 07:12:28] [EMAIL PROTECTED] I have this problem too...But, 6 virtual servers work for me, and, the most surprising, given message appears only on four of six [2002-01-10 11:24:37] [EMAIL PROTECTED] Application use: ODBC, sessions, sockets, gd ext. Extra: Zend Optimizer 1.2.0 (PHP files are encoded with Zend Encoder 1.2.0) I tried PHP ISAPI version (4.1.1) It seems all works fine, but after random time I receive the following error: The HTTP server encountered an unhandled exception while processing the ISAPI Application ' php4ts!zend_strndup + 0x2B + 0x18468B00 and I have to reboot the system because IIS won't work!!! -- Edit this bug report at http://bugs.php.net/?id=14971&edit=1
Bug #14222 Updated: PHP Crashes with weird output often
ID: 14222 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: Windows XP Pro PHP Version: 4.1.1 New Comment: stop! the -X option is for debugging purposes only, as all requests will now be serialized and handled by a single apache process this is *not* what you want in a production environment! the -X option is meant for debugging purposes only, as debugging a apache process farm can become a nightmare ... if the problem does *not* show up with -X then it is most likely related to process coordination or something, which makes it harder to debug ... :( but once again: -X is *not* a solution, it is just one of the means to find the cause Previous Comments: [2002-03-07 04:03:12] [EMAIL PROTECTED] the apache -X seems to work fine! yes! [2002-03-05 14:17:18] [EMAIL PROTECTED] apache -X dont work (still the same problem) problem has nothing to do with mysql problem (again..): -> on a easy loop with enought data the weird output comes -> the "weird output" is: ->-> moved letters (just moved some pixels down, up, left or right) ->-> replaced letters (with any kind of replacements) ->-> additional letters (i didnt reported missing letters yet, except that the end of the file is different) -> Browser (client) reloading -> Ping seems to make problems (higher ping more problems) some small notes: it depends how much he transfers on every request (i had 0bytes up to the whole document and many steps between them) [2002-03-05 12:17:55] [EMAIL PROTECTED] I HAVE THE SAME PROBLEM! ... humm ... I use : winxp pro/apache 1.3.22/php 4.1.1/mysql 4.01a (run on the same machine) >From my local network it work fine but when I try to see a page of my site from an another location on internet (school for exemple) sometimes it works and sometimes it blinks and crashs. I have this with anything browser (ie5, ie6, opera, galeon etc..). description client-side: the browser load just a part of page (~8000 first bytes) and then it reloads it again and again... description server-side: apache, php and mysql doesn't see any error... But, it all works fine when i use mysql on a another server (on internet) not as localhost its strange, no ? [2002-02-25 11:03:01] [EMAIL PROTECTED] thanks, "apache - X" seems to work !! [2002-02-08 12:20:56] [EMAIL PROTECTED] I also have this problem. Using latest patches with XP Pro, PHP, and Apache. I have not isolated it yet but it has to do with larger amounts of print/echo output being delivered from a php page. Meaning, if my code displays 10 "news" items (slashdot style page) it works, then if I display say 15 it starts to behave irregularly. This has been observed as a localhost access on to the server on the same computer and also accessing the server running from a different computer on the net. When the problem occurs the browser continually reloads this same page and never finishes. (this noticed when accessing the server through ie6 on xp) When accessing the problem page via mozzila from linux station I notice that the page gets just cut off. Anyway I'll try to isolate further. 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/14222 -- Edit this bug report at http://bugs.php.net/?id=14222&edit=1
Bug #15841 Updated: CRLF to separate mail headers is incorrect
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: ok 1) blame qmail, it should know better ... 2) lets have SMTP as a default implementation for Unix mail(), too, instead of relying on external programs the "it isn't broken, so don't fix it" argument got even weaker right now ... Previous Comments: [2002-03-06 14:58:38] [EMAIL PROTECTED] 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. [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... 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/15841 -- Edit this bug report at http://bugs.php.net/?id=15841&edit=1
Bug #15927: Crash(?) on Syntax Error
From: [EMAIL PROTECTED] Operating system: Linux 2.4.17/RH 7.2 PHP version: 4.0.6 PHP Bug Type: Scripting Engine problem Bug description: Crash(?) on Syntax Error One bracket too much! This makes PHP issue just 5 Bytes to the browser, regardless of any code following or preceeding this line. I think it doesn't even execute the code because there doesn't appear anything in the logs, too. -- Edit bug report at http://bugs.php.net/?id=15927&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15927&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15927&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15927&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15927&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15927&r=support Expected behavior: http://bugs.php.net/fix.php?id=15927&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15927&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15927&r=submittedtwice
Bug #15927 Updated: Crash(?) on Syntax Error
ID: 15927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux 2.4.17/RH 7.2 PHP Version: 4.0.6 New Comment: If there is a parse error, the script doesn't execute. Not a bug > bogus Previous Comments: [2002-03-07 05:21:42] [EMAIL PROTECTED] One bracket too much! This makes PHP issue just 5 Bytes to the browser, regardless of any code following or preceeding this line. I think it doesn't even execute the code because there doesn't appear anything in the logs, too. -- Edit this bug report at http://bugs.php.net/?id=15927&edit=1
Bug #15927 Updated: Crash(?) on Syntax Error
ID: 15927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux 2.4.17/RH 7.2 PHP Version: 4.0.6 New Comment: This just gives a parser error for me (tested with 4.0.6 and current cvs). Previous Comments: [2002-03-07 05:24:51] [EMAIL PROTECTED] If there is a parse error, the script doesn't execute. Not a bug > bogus [2002-03-07 05:21:42] [EMAIL PROTECTED] One bracket too much! This makes PHP issue just 5 Bytes to the browser, regardless of any code following or preceeding this line. I think it doesn't even execute the code because there doesn't appear anything in the logs, too. -- Edit this bug report at http://bugs.php.net/?id=15927&edit=1
Bug #3474 Updated: overflow(?) problem at string.c
ID: 3474 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.0 Latest CVS (13/02/2000) New Comment: buffer overflow Previous Comments: [2000-02-13 16:01:51] [EMAIL PROTECTED] should be fixed in CVS [2000-02-13 15:42:09] [EMAIL PROTECTED] I see the following in error_log: [Sun Feb 13 16:37:34 2000] Script: '/home/httpd/html/zend/search/indexer.php' --- /home/php/php4/ext/standard/string.c(2189) : Block 0x0837E748 status: Beginning: OK (allocated on /home/php/php4/ext/standard/string.c:2152, 4 bytes) End: Overflown (magic=0x2A8FCC00 instead of 0x2A8FCC84) 1 byte(s) overflown --- [Sun Feb 13 16:37:34 2000] Script: '/home/httpd/html/zend/search/indexer.php' --- /home/php/php4/ext/standard/string.c(2189) : Block 0x0837F380 status: Beginning: OK (allocated on /home/php/php4/ext/standard/string.c:2152, 4 bytes) End: Overflown (magic=0x2A8FCC00 instead of 0x2A8FCC84) 1 byte(s) overflown --- -- Edit this bug report at http://bugs.php.net/?id=3474&edit=1
Bug #15927 Updated: Crash(?) on Syntax Error
ID: 15927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux 2.4.17/RH 7.2 PHP Version: 4.0.6 New Comment: Okay, perhaps I should stressen that there is no error mesage whatsoever. In my case, it took me several hours to find this little one. It's very annoying that PHP doesn't issue a syntax error message. Previous Comments: [2002-03-07 05:25:05] [EMAIL PROTECTED] This just gives a parser error for me (tested with 4.0.6 and current cvs). [2002-03-07 05:24:51] [EMAIL PROTECTED] If there is a parse error, the script doesn't execute. Not a bug > bogus [2002-03-07 05:21:42] [EMAIL PROTECTED] One bracket too much! This makes PHP issue just 5 Bytes to the browser, regardless of any code following or preceeding this line. I think it doesn't even execute the code because there doesn't appear anything in the logs, too. -- Edit this bug report at http://bugs.php.net/?id=15927&edit=1
Bug #15905 Updated: long filenames in fopen() crash PHP.
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:
Happens still with latest CVS snapshot (20020307), please see gdb
debugging session below:
(gdb) run crash.php
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /src/webstuff/php4-20020307/php crash.php
warning: Unable to find dynamic linker breakpoint function.
warning: GDB will be unable to debug shared library initializers
warning: and track explicitly loaded dynamic code.
Breakpoint 1, php_checkuid (filename=0x1d2180 'x' ...,
fopen_mode=0x1c9278 "r", mode=4) at safe_mode.c:50
50 long uid=0L, gid=0L, duid=0L, dgid=0L;
(gdb) step
55 if (!filename) {
(gdb)
59 if (fopen_mode) {
(gdb)
60 if (fopen_mode[0] == 'r') {
(gdb)
71 if (!strncasecmp(filename,"http://";, 7) ||
!strncasecmp(filename,"ftp://";, 6)) {
(gdb) print filename
$7 = 0x1d2180 'x' ...
(gdb)
$8 = 0x1d2180 'x' ...
(gdb)
$9 = 0x1d2180 'x' ...
(gdb) step
78 if (mode != CHECKUID_ALLOW_ONLY_DIR) {
(gdb)
79 VCWD_REALPATH(filename, path);
(gdb)
80 ret = VCWD_STAT(path, &sb);
(gdb)
81 if (ret < 0) {
(gdb)
82 if (mode == CHECKUID_DISALLOW_FILE_NOT_EXISTS) {(gdb)
83 php_error(E_WARNING, "Unable to access %s",
filename);
(gdb) print filename
$10 = 0x1d2180 'x' ...
(gdb)
$11 = 0x1d2180 'x' ...
(gdb) step
zend_error (type=2, format=) at zend.c:642
642 switch (type) {
(gdb)
657 if (zend_is_compiling(TSRMLS_C)) {
(gdb)
zend_is_compiling () at zend_compile.c:147
147 return CG(in_compilation);
(gdb)
zend_is_executing () at zend_execute_API.c:263
263 return EG(in_execution);
(gdb)
zend_error (type=2, format=) at zend.c:661
661 error_filename =
zend_get_executed_filename(TSRMLS_C);
(gdb) print error_filename
$12 =
(gdb) step
zend_get_executed_filename () at zend_execute_API.c:243
243 if (EG(active_op_array)) {
(gdb) print active_op_array
No symbol "active_op_array" in current context.
(gdb) step
244 return EG(active_op_array)->filename;
(gdb) print active_op_array
No symbol "active_op_array" in current context.
(gdb) print EG(active_op_array)->filename
No symbol "EG" in current context.
(gdb) step
zend_error (type=2, format=) at zend.c:662
662 error_lineno =
zend_get_executed_lineno(TSRMLS_C);
(gdb) print error_filename
$13 =
(gdb)
$14 =
(gdb) step
zend_get_executed_lineno () at zend_execute_API.c:253
253 if (EG(opline_ptr)) {
(gdb) print opline_ptr
No symbol "opline_ptr" in current context.
(gdb) step
254 return active_opline->lineno;
(gdb) print filename
No symbol "filename" in current context.
(gdb) step
Program received signal SIGSEGV, Segmentation fault.
zend_get_executed_lineno () at zend_execute_API.c:254
254 return active_opline->lineno;
(gdb) bt
#0 zend_get_executed_lineno () at zend_execute_API.c:254
#1 0xec1bc in zend_error (type=2, format=) at zend.c:662
#2 0xf5d30 in php_checkuid (filename=0x1d2180 'x' ...,
fopen_mode=0xefffe118 'x' ..., mode=0) at
safe_mode.c:83
#3 0x31de4 in php_fopen_url_wrapper (path=, mode=,
options=2021161080, issock=, socketd=,
opened_path=) at fopen_wrappers.c:582
Cannot access memory at address 0x787878b0.
(gdb)
Previous Comments:
[2002-03-07 03:27:46] [EMAIL PROTECTED]
Can't reproduce it on Linux as well. Could be related to some solaris
weirdness. example script works fine if safe_mode is turned off. I'll
test with latest snap shots today.
cheers
axelm
[2002-03-06 12:55:49] [EMAIL PROTECTED]
Does it only happen with safe_mode on?
Derick
[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 t
Bug #15927 Updated: Crash(?) on Syntax Error
ID: 15927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux 2.4.17/RH 7.2 PHP Version: 4.0.6 New Comment: ... and your php.ini error_reporting settings are? Previous Comments: [2002-03-07 05:35:45] [EMAIL PROTECTED] Okay, perhaps I should stressen that there is no error mesage whatsoever. In my case, it took me several hours to find this little one. It's very annoying that PHP doesn't issue a syntax error message. [2002-03-07 05:25:05] [EMAIL PROTECTED] This just gives a parser error for me (tested with 4.0.6 and current cvs). [2002-03-07 05:24:51] [EMAIL PROTECTED] If there is a parse error, the script doesn't execute. Not a bug > bogus [2002-03-07 05:21:42] [EMAIL PROTECTED] One bracket too much! This makes PHP issue just 5 Bytes to the browser, regardless of any code following or preceeding this line. I think it doesn't even execute the code because there doesn't appear anything in the logs, too. -- Edit this bug report at http://bugs.php.net/?id=15927&edit=1
Bug #15928: move_uploaded_file() is unsafe running in safe-mode
From: [EMAIL PROTECTED] Operating system: AIX PHP version: 4.1.2 PHP Bug Type: PHP options/info functions Bug description: move_uploaded_file() is unsafe running in safe-mode Security issue in move_uploaded_file() while in safe-mode We have different web-sites running on our server. Each of them may prepare a directory in which files may be written using php-upload and move_uploaded_file(). Our webserver runs with safe-mode-restriction. The documentations says, as mentioned, that this is not unsafe. Note: move_uploaded_file() is not affected by the normal safe-mode UID-restrictions. This is not unsafe because move_uploaded_file() only operates on files uploaded via PHP. In fact, it is. If I know a directory of another website which allows to upload files via php, I'll be able to write a file to this location, offering an upload-script on my website. I could on this way put offending files in someone elses website, who probably protectet his php-upload-script with .htaccess. I would suggest that move_uploaded_file() should be modified that way, that files may only be moved to directories whose owner is the same as the upload-script while safe-mode restriction applies. This approach would guarantee that nobody else as the people who offers an upload-script will be able to put files in the owners webspace. After such a modification move_uploaded_file() will be really safe. At present, it's not. It allows to skip safe-mode-restriction. Kind regards and thanks for any feedback Roberto -- Edit bug report at http://bugs.php.net/?id=15928&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15928&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15928&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15928&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15928&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15928&r=support Expected behavior: http://bugs.php.net/fix.php?id=15928&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15928&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15928&r=submittedtwice
Bug #10027 Updated: HTTP_REFERER
ID: 10027 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *Web Server problem Operating System: Linux Redhat 6.2 PHP Version: 4.0.4pl1 New Comment: HTTP_WEFERER has nothing todo with PHP its some data your browser gives out to the world. Previous Comments: [2002-03-07 04:19:22] [EMAIL PROTECTED] Both windows2000 & FreeBSD 3.4 found SAME Problem With Apache! How to decode HTTP_WEFERER? [2001-04-29 11:50:00] [EMAIL PROTECTED] No feedback. closing [2001-03-29 11:11:48] [EMAIL PROTECTED] Works for me just fine with latest CVS. (snapshot can be found at http://snaps.php.net/ ) Which webserver are you using? Apache? --Jani [2001-03-27 11:31:50] [EMAIL PROTECTED] Linking to a phpinfo() page should give a valid HTTP_REFERER value, however, I don't see it. The only thing I see remotely close to that is: HTTP_WEFERER WCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARH -- Edit this bug report at http://bugs.php.net/?id=10027&edit=1
Bug #4296 Updated: OCIBindByName core dumps
ID: 4296 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Oracle related Operating System: Linux PHP Version: 4.0 Release Candidate 1 New Comment: Linux +Apache + php 4.0.8 + Oracle 8.1.5.0.2 My oracle table has a LONG field (str_out). The statement to obtain filed works as long as strlen(str_out) < 32067, otherwise i get error from oracle. I suppose that Oracle not work with fields LONG greater then 32067. Previous Comments: [2000-08-18 13:06:43] [EMAIL PROTECTED] Closed due to missing user feedback. [2000-07-27 18:10:51] [EMAIL PROTECTED] Did you get your trace? ALso please try latest version of php (4.0.1pl2) and see if the problem still is there. [2000-05-02 17:29:20] [EMAIL PROTECTED] Linux + Oracle 8.1.5.0.2 The following block works: $query = "INSERT INTO messages VALUES ($num, :msg_body)"; $msg_body = stripslashes($msg_body); $stmt = OCIParse($cnx, $query); OCIBindByName($stmt, ":msg_body", &$msg_body, -1); OCIExecute($stmt); Replacting the 4th line by: OCIBindByName($stmt, ":msg_body", &$msg_body, -1, OCI_B_CLOB); My oracle table has a CLOB field (for msg_body). This first statement works as long as strlen($msg_body) < 32067. I suppose I need the second one to fix my length problem but then Apache core dumps. Trying to get a trace ... -- Edit this bug report at http://bugs.php.net/?id=4296&edit=1
Bug #15927 Updated: Crash(?) on Syntax Error
ID: 15927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux 2.4.17/RH 7.2 PHP Version: 4.0.6 New Comment: Thank you, you pointed me to the reason for my problem: In the .htaccess file I found: php_value display_errors true must be: php_flag display_errors on That means: Due to this syntactically wrong statement in the htaccess-file PHP overides the default and sets this flag to "false". I think this is not the desired behaviour, isn't it? Previous Comments: [2002-03-07 05:57:04] [EMAIL PROTECTED] ... and your php.ini error_reporting settings are? [2002-03-07 05:35:45] [EMAIL PROTECTED] Okay, perhaps I should stressen that there is no error mesage whatsoever. In my case, it took me several hours to find this little one. It's very annoying that PHP doesn't issue a syntax error message. [2002-03-07 05:25:05] [EMAIL PROTECTED] This just gives a parser error for me (tested with 4.0.6 and current cvs). [2002-03-07 05:24:51] [EMAIL PROTECTED] If there is a parse error, the script doesn't execute. Not a bug > bogus [2002-03-07 05:21:42] [EMAIL PROTECTED] One bracket too much! This makes PHP issue just 5 Bytes to the browser, regardless of any code following or preceeding this line. I think it doesn't even execute the code because there doesn't appear anything in the logs, too. -- Edit this bug report at http://bugs.php.net/?id=15927&edit=1
Bug #15727 Updated: session.gc_maxlifetime doesn't work
ID: 15727
Updated by: [EMAIL PROTECTED]
-Summary: session.gc_maxlifetime doesn't work
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Bogus
Bug Type: Session related
Operating System: Linux
PHP Version: 4.0CVS-2002-02-2
New Comment:
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
Previous Comments:
[2002-03-07 03:42:36] [EMAIL PROTECTED]
yeah,I wanna delete the session files.
u see,if these session files can not be deleted,it will be accumulated
and ocuppy so much disk space.
BTW,I still a question about cookies,why is the time that the cookies
expired not same as the time that parameter of session.cookie_lifetime
set?
for example, I wanna the cookies expired 5 minutes later,what should I
do?I think I should set the parameter,as follow:
session.cookie_lifetime = 300
right?
But, after restart my apache server,I found the cookies maybe expired
after 2 minutes,not 5 minutes as I want.
why?
[2002-03-06 22:23:06] [EMAIL PROTECTED]
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.
[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 #15927 Updated: Crash(?) on Syntax Error
ID: 15927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux 2.4.17/RH 7.2 PHP Version: 4.0.6 New Comment: "php_value display_errors true" is perfectly valid, just that (string)"true" is converted to (int)"true" which is zero Previous Comments: [2002-03-07 06:27:03] [EMAIL PROTECTED] Thank you, you pointed me to the reason for my problem: In the .htaccess file I found: php_value display_errors true must be: php_flag display_errors on That means: Due to this syntactically wrong statement in the htaccess-file PHP overides the default and sets this flag to "false". I think this is not the desired behaviour, isn't it? [2002-03-07 05:57:04] [EMAIL PROTECTED] ... and your php.ini error_reporting settings are? [2002-03-07 05:35:45] [EMAIL PROTECTED] Okay, perhaps I should stressen that there is no error mesage whatsoever. In my case, it took me several hours to find this little one. It's very annoying that PHP doesn't issue a syntax error message. [2002-03-07 05:25:05] [EMAIL PROTECTED] This just gives a parser error for me (tested with 4.0.6 and current cvs). [2002-03-07 05:24:51] [EMAIL PROTECTED] If there is a parse error, the script doesn't execute. Not a bug > bogus 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/15927 -- Edit this bug report at http://bugs.php.net/?id=15927&edit=1
Bug #15912 Updated: Trailing \r\n in last varible when doing POST request with IE
ID: 15912 Updated by: [EMAIL PROTECTED] -Summary: Trailing \r\n in last varible when doing POST request with IE Reported By: [EMAIL PROTECTED] Status: Open Bug Type: URL related Operating System: Linux -PHP Version: 4.0CVS-2002-03-06 +PHP Version: 4.0CVS-2002-03-0 New Comment: 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. Exmaple code: "; echo "b=".urlencode($_POST["b"]).""; ?> a: b: Posting "foo" in a and "bar" i b results in this output in IE: a=foo b=bar%0D%0A and in Mozilla: a=foo b=bar Previous Comments: [2002-03-06 14:37:38] [EMAIL PROTECTED] 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 this bug report at http://bugs.php.net/?id=15912&edit=1
Bug #15929: Online Manual Inconplete
From: [EMAIL PROTECTED] Operating system: Linux Ted Hat 7.2 PHP version: 4.1.2 PHP Bug Type: Documentation problem Bug description: Online Manual Inconplete Please note that in the installation instructions there is what is described as a "complete" list of configuration options but so far we have spotted that --with-xml --enable-xslt --with-xslt-sablot are missing and are only mentioned on the relavent function pages. Thanks -- Edit bug report at http://bugs.php.net/?id=15929&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15929&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15929&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15929&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15929&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15929&r=support Expected behavior: http://bugs.php.net/fix.php?id=15929&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15929&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15929&r=submittedtwice
Bug #15930: gzencode can't have a level
From: [EMAIL PROTECTED] Operating system: windows 200 PHP version: 4.1.1 PHP Bug Type: Zlib Related Bug description: gzencode can't have a level "; $gzdata = gzencode($data,9); echo strlen($gzdata),":bad always 10"; ?> -- Edit bug report at http://bugs.php.net/?id=15930&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15930&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15930&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15930&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15930&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15930&r=support Expected behavior: http://bugs.php.net/fix.php?id=15930&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15930&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15930&r=submittedtwice
Bug #15931: openssl linking error:undefined reference to `OPENSSL_add_all_algorithms_noconf
From: [EMAIL PROTECTED] Operating system: Linux 2.4.18-ac1 PHP version: 4.0CVS-2002-03-07 PHP Bug Type: Compile Failure Bug description: openssl linking error:undefined reference to `OPENSSL_add_all_algorithms_noconf # openssl version OpenSSL 0.9.8-dev 24 Sep 2000 # gcc --version 2.96 /bin/sh /usr/src/php4/libtool --silent --mode=link gcc -I. -I/usr/src/php4/sapi/cli -I/usr/src/php4/main -I/usr/src/php4 -I/usr/src/apache_1.3.23//src/include -I/usr/src/apache_1.3.23//src/os/unix -I/usr/src/php4/Zend -I/usr/src/openssl/include -I/usr/include/libxml2 -I/usr/include/freetype -I/usr/include/mysql -I/data/virtual/include -I/usr/src/php4/ext/xml/expat -I/usr/src/php4/TSRM -fPIC -O3 -m486 -o php -export-dynamic libphp4cli.la ./.libs/libphp4cli.a(openssl.o): In function `zm_startup_openssl': openssl.o(.text+0xa16): undefined reference to `OPENSSL_add_all_algorithms_noconf' collect2: ld returned 1 exit status make[2]: *** [php] Error 1 make[2]: Leaving directory `/usr/src/php4/sapi/cli' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/php4/sapi/cli' make: *** [all-recursive] Error 1 -- Edit bug report at http://bugs.php.net/?id=15931&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15931&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15931&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15931&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15931&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15931&r=support Expected behavior: http://bugs.php.net/fix.php?id=15931&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15931&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15931&r=submittedtwice
Bug #10930 Updated: Can't connect to mysql after running some code that crashes IIS 5
ID: 10930
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.0.5
New Comment:
I have experienced the same bug with PHP 4.1.1 (Win32 install build)
and Windows 2000 server. It is really an IIS bug not a PHP bug. The
crux of it is ...
header("Location: $PHP_SELF");
This sends a 'virtual' URI not an absolute URI. (see the http://www.php.net/manual/en/function.header.php";>PHP manual for
header function). Why this should crash IIS is unclear since surely
it should cope with a rogue CGI program.
If an absolute URI is sent in the header it does not crash IIS.
This would cause problems on Windows boxes running a number of PHP
websites for end users. Sloppy header coding can cause all the websites
to be unavailable until admin restarts IIS.
Phorum 3.3.2a (www.phorum.org) uses the Location header with a virtual
URI in the admin screens.
Previous Comments:
[2001-05-17 12:08:03] [EMAIL PROTECTED]
After running the code below, PHP 4.0.5 is no longer able to connecto
to mysql. I have tested this at 2 different locations, and the result
is the same every time. Also after visiting the website with this code
in it, inetinfo.exe (IIS) crashes.
PHP was installed with php405-installer.exe. The problem occurs on
Windows 2000 Professional SP1 & SP2. Windows 2000 server has not been
tested. Below is the code that should be pasted into a webpage, and
then visited with any browser. I accidentally caused inetinfo.exe to
die with this:
.
This was found on accident...thanks to my crappy coding. :)
Date: 05-14-2001
Kills: Inetinfo.exe on Win2k
*/
session_start();
session_register('username');
session_register('password');
header("Location: $PHP_SELF");
if ($formusername) {
mysql_connect("$mysql_host","$mysql_user","$mysql_pass");
mysql_select_db("$mysql_db");
$auth_sql = mysql_query("SELECT * FROM $mysql_user_table WHERE
username =
'$formusername' AND password = '$formpassword'");
$user_exists = mysql_num_rows($auth_sql);
if ($user_exists == "1") {
$username = $formusername;
$password = $formpassword;
}
else {
$login_error = "Error:Wrongusername/password";
session_unregister('username');
session_unregister('password');
}
}
else {
mysql_connect("$mysql_host","$mysql_user","$mysql_pass");
mysql_select_db("$mysql_db");
$auth_sql = mysql_query("SELECT * FROM $mysql_user_table WHERE
username =
'$username' AND password = '$password'");
$user_exists = mysql_num_rows($auth_sql);
if ($user_exists == "1") {
// blah blah blah!
}
else {
$login_error = "Error:Wrongusername/password";
session_unregister('username');
session_unregister('password');
}
}
if ($login == "no") {
session_destroy();
session_unregister('username');
session_unregister('password');
header("Location: $PHP_SELF");
}
?>
--
Edit this bug report at http://bugs.php.net/?id=10930&edit=1
Bug #15932: file_exists generates a verbose warning in addition to return code.
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.1.2
PHP Bug Type: Filesystem function related
Bug description: file_exists generates a verbose warning in addition to return code.
Upon upgrading to PHP 4.1.2, all calls which use the file_exists() function
to verify files within a non-existent sub-directory, are generating a stat
warning (which was not the case in 4.0.6).
Example code:
if (file_exists($dir.'/filename.ext')) {
FOO;
}
If $dir doesn't exist, the following warning is generated:
Warning: stat failed for dir/filename.exe (errno=20 - Not a directory) in
script.php on line n.
This is easily silenced by calling @file_exists instead, but it doesn't
seem like the desired behavior.
--
Edit bug report at http://bugs.php.net/?id=15932&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15932&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15932&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15932&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15932&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15932&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15932&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15932&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15932&r=submittedtwice
Bug #14939 Updated: Warning: gzinflate: buffer error in /usr/local/apache/elca_rmg/class.FTemplateE
ID: 14939
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Zlib Related
Operating System: Apache
PHP Version: 4.1.1
New Comment:
Does this script work if you don't provide a compression level?
-- robin
Previous Comments:
[2002-01-08 21:04:16] [EMAIL PROTECTED]
Receive the following error with only 15 consecutive characters
entered.
Warning: gzinflate: buffer error in
/usr/local/apache/elca_rmg/class.FTemplateExt.php on line 153
What follows is the code updating the SQL files:
$gzsize = strlen($description) + 4; // added 4 more than req'd
$gzcompress = gzdeflate ($description,6);
$gzcompress = addslashes($gzcompress); //Reqd for SQL updates
$query = "UPDATE htmlcontent SET record_nbr = \"$record_nbr\",
gzcompress = \"$gzcompress\", gzsize = $gzsize WHERE record_nbr =
\"$record_nbr\"";
}
general_update($errno,$errmsg,$rowsaffected, $result, $s_synod_id,
$query); // UPDATE the record
***
Next I attempt to read the record back and unzip gzcompress
Note that $description consists of 20 'a' characters. Any repetitive
char will do and only 15 to 20 are req'd
***
$query = "SELECT * FROM htmlcontent WHERE record_nbr =
\"$record_nbr\"";
general_read($errno, $errmsg,$numrows, $result_html, $s_synod_id,
$query);
if ($numrows > 0) {
if ($row_html = mysql_fetch_array ($result_html)) {
$content = stripslashes($row_html["gzcompress"]);
if (strlen($content) > 0) {
**Error occurs on the following instruction*
$new = gzinflate($content,$row_html["gzsize"]);
--
Edit this bug report at http://bugs.php.net/?id=14939&edit=1
Bug #15833 Updated: PHP 4.1.x results in huge memory usage during runtime under Solaris 8
ID: 15833 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Performance problem Operating System: Solaris 8 PHP Version: 4.1.2 New Comment: We had the same problem with php 4.1.2 under slackware 8 with 2.4.17 smp. PHP did not follow memory limit at all. PHP 4.0.6 + security patch works ok. Previous Comments: [2002-03-02 11:13:43] [EMAIL PROTECTED] Compiling PHP 4.1.1 (patched) or PHP 4.1.2 under Solaris 8 on a Sun NetraX1 as external CGI results in a huge memory usage, even if only the phpinfo function wa called. The executable used around 73 MB memory. Compiling it the same way under Solaris 2.6/7 works perfectly ... Compiling it under Linux the same way works perfectly too. Here the configure line: ./configure --prefix=/usr/local/php-4.1.2 --enable-force-cgi-redirect --with-gdb m --with-gd=/usr/local/gd-2.0.1 --with-mysql=/usr/local/mysql-3.23.37 --with-ttf =/usr/local/freetype-2.0.6 --enable-gd-native-ttf --with-jpeg-dir=/usr/local/con verter --with-xpm-dir --with-freetype-dir=/usr/local/freetype-2.0.6 --with-png-d ir=/usr/local/libpng-1.2.1 --with-gettext=/usr/local/gnu --with-zlib-dir=/lib -- enable-ftp --enable-shared --with-dom=/usr/local/libxml2-2.4.9 --enable-trans-si d --with-config-file-path=/usr/local/php-4.1.2 --with-tiff-dir=/usr/local/tiff-v 3.5.6-beta --with-pdflib=/usr/local/pdflib-4.0.1 --with-imap=/usr/local --with-m crypt=/usr/local/libmcrypt-2.4.10 --with-expat-dir=/usr/local/expat-1.95.2 --wit h-sablot=/usr/local/Sablot-0.65 --with-openssl=/usr/local/openssl-0.9.6a --with- bz2 --with-t1lib=/usr/local/T1-1.1.1 --with-mm --with-zip=/usr/local/zziplib-0.1 0.27 --enable-inline-optimization --enable-sysvsem --enable-sysvshm --with-ndbm Kind regards, Frank PowerWeb -- Edit this bug report at http://bugs.php.net/?id=15833&edit=1
Bug #15912 Updated: Trailing \r\n in last varible when doing POST request with IE
ID: 15912 Updated by: [EMAIL PROTECTED] -Summary: Trailing \r\n in last varible when doing POST request with IE Reported By: [EMAIL PROTECTED] Status: Open Bug Type: HTTP related Operating System: Linux PHP Version: 4.0CVS-2002-03-0 New Comment: PHP 4.1.2 seams to handle it correctly Previous Comments: [2002-03-07 09:36:02] [EMAIL PROTECTED] Changed category to HTTP related [2002-03-07 07:00:37] [EMAIL PROTECTED] 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. Exmaple code: "; echo "b=".urlencode($_POST["b"]).""; ?> a: b: Posting "foo" in a and "bar" i b results in this output in IE: a=foo b=bar%0D%0A and in Mozilla: a=foo b=bar [2002-03-06 14:37:38] [EMAIL PROTECTED] 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 this bug report at http://bugs.php.net/?id=15912&edit=1
Bug #15912 Updated: Trailing \r\n in last varible when doing POST request with IE
ID: 15912 Updated by: [EMAIL PROTECTED] -Summary: Trailing \r\n in last varible when doing POST request with IE Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: URL related +Bug Type: HTTP related Operating System: Linux PHP Version: 4.0CVS-2002-03-0 New Comment: Changed category to HTTP related Previous Comments: [2002-03-07 07:00:37] [EMAIL PROTECTED] 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. Exmaple code: "; echo "b=".urlencode($_POST["b"]).""; ?> a: b: Posting "foo" in a and "bar" i b results in this output in IE: a=foo b=bar%0D%0A and in Mozilla: a=foo b=bar [2002-03-06 14:37:38] [EMAIL PROTECTED] 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 this bug report at http://bugs.php.net/?id=15912&edit=1
Bug #15933: PHP 4.* binary does not connect to mysql from a cron job
From: [EMAIL PROTECTED] Operating system: Sco Unixware 7.1 PHP version: 4.1.0 PHP Bug Type: MySQL related Bug description: PHP 4.* binary does not connect to mysql from a cron job I have a few PHP scripts that execute from a php binary from a cron job. Since changing to version 4 they fail to connect to the database with a :- "Can't connect to local MySQL server through socket '/tmp/mysql.sock'" error, or :- "Can't connect to MySQL server on ''" if I don't use the local socket method of connecting. I've tried these versions of php and a few different versions of mysql all with the above same results php-4.0.3pl1 php-4.0.6 php-4.1.0 I've reverted the binary to version php-3.0.18 and it all works fine As the scripts are quite simple I only need mysql with the php binary, my configuration for the binaries is :- ./configure --enable-track-vars --with-mysql=/usr/local/mysql -- Edit bug report at http://bugs.php.net/?id=15933&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15933&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15933&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15933&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15933&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15933&r=support Expected behavior: http://bugs.php.net/fix.php?id=15933&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15933&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15933&r=submittedtwice
Bug #15933 Updated: PHP 4.* binary does not connect to mysql from a cron job
ID: 15933 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MySQL related Operating System: Sco Unixware 7.1 PHP Version: 4.1.0 New Comment: I forgot to mention that the scripts connect fine from the command line and only failed to connect from cron. Previous Comments: [2002-03-07 09:50:07] [EMAIL PROTECTED] I have a few PHP scripts that execute from a php binary from a cron job. Since changing to version 4 they fail to connect to the database with a :- "Can't connect to local MySQL server through socket '/tmp/mysql.sock'" error, or :- "Can't connect to MySQL server on ''" if I don't use the local socket method of connecting. I've tried these versions of php and a few different versions of mysql all with the above same results php-4.0.3pl1 php-4.0.6 php-4.1.0 I've reverted the binary to version php-3.0.18 and it all works fine As the scripts are quite simple I only need mysql with the php binary, my configuration for the binaries is :- ./configure --enable-track-vars --with-mysql=/usr/local/mysql -- Edit this bug report at http://bugs.php.net/?id=15933&edit=1
Bug #15918 Updated: DomAttribute missing "type" property
ID: 15918 Updated by: [EMAIL PROTECTED] -Summary: DomAttribute missing "type" property Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: DOM XML related Operating System: Linux PHP Version: 4.1.2 -Assigned To: +Assigned To: jtate New Comment: This should be a quick fix. Previous Comments: [2002-03-06 19:37:26] [EMAIL PROTECTED] 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 this bug report at http://bugs.php.net/?id=15918&edit=1
Bug #15934: parameter seperator for url rewriting not w3c compliant
From: [EMAIL PROTECTED] Operating system: Linux Debian 2.2 PHP version: 4.1.2 PHP Bug Type: Session related Bug description: parameter seperator for url rewriting not w3c compliant When enabling url rewriting with sessions, the paramter seperator used for seperating the SID= from other parameteres in the uri is not w3c compliant. PHP uses & (&) for seperating the SID= from other paramters in an URI, w3c states (and they are so right) that this character is used for entities like &. It could let to some hard to find errors in future browsers when they parse it like so. I suggest php uses the ; for parameter seperation as the standards from w3c state. -- Edit bug report at http://bugs.php.net/?id=15934&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15934&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15934&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15934&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15934&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15934&r=support Expected behavior: http://bugs.php.net/fix.php?id=15934&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15934&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15934&r=submittedtwice
Bug #15933 Updated: PHP 4.* binary does not connect to mysql from a cron job
ID: 15933 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: Sco Unixware 7.1 PHP Version: 4.1.0 New Comment: Did you check that the necessary environment variables were set? Cron doesn't read your profile before launching the executable. Check to see that php from within cron can read the php.ini file. Previous Comments: [2002-03-07 10:07:17] [EMAIL PROTECTED] I forgot to mention that the scripts connect fine from the command line and only failed to connect from cron. [2002-03-07 09:50:07] [EMAIL PROTECTED] I have a few PHP scripts that execute from a php binary from a cron job. Since changing to version 4 they fail to connect to the database with a :- "Can't connect to local MySQL server through socket '/tmp/mysql.sock'" error, or :- "Can't connect to MySQL server on ''" if I don't use the local socket method of connecting. I've tried these versions of php and a few different versions of mysql all with the above same results php-4.0.3pl1 php-4.0.6 php-4.1.0 I've reverted the binary to version php-3.0.18 and it all works fine As the scripts are quite simple I only need mysql with the php binary, my configuration for the binaries is :- ./configure --enable-track-vars --with-mysql=/usr/local/mysql -- Edit this bug report at http://bugs.php.net/?id=15933&edit=1
Bug #15833 Updated: PHP 4.1.x results in huge memory usage during runtime under Solaris 8
ID: 15833 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Performance problem Operating System: Solaris 8 PHP Version: 4.1.2 New Comment: PHP uses about 6-8 MB after taking the --with-mm option out. Seems to be a problem of PHP or libmm. Frank PowerWeb Previous Comments: [2002-03-07 08:18:58] [EMAIL PROTECTED] We had the same problem with php 4.1.2 under slackware 8 with 2.4.17 smp. PHP did not follow memory limit at all. PHP 4.0.6 + security patch works ok. [2002-03-02 11:13:43] [EMAIL PROTECTED] Compiling PHP 4.1.1 (patched) or PHP 4.1.2 under Solaris 8 on a Sun NetraX1 as external CGI results in a huge memory usage, even if only the phpinfo function wa called. The executable used around 73 MB memory. Compiling it the same way under Solaris 2.6/7 works perfectly ... Compiling it under Linux the same way works perfectly too. Here the configure line: ./configure --prefix=/usr/local/php-4.1.2 --enable-force-cgi-redirect --with-gdb m --with-gd=/usr/local/gd-2.0.1 --with-mysql=/usr/local/mysql-3.23.37 --with-ttf =/usr/local/freetype-2.0.6 --enable-gd-native-ttf --with-jpeg-dir=/usr/local/con verter --with-xpm-dir --with-freetype-dir=/usr/local/freetype-2.0.6 --with-png-d ir=/usr/local/libpng-1.2.1 --with-gettext=/usr/local/gnu --with-zlib-dir=/lib -- enable-ftp --enable-shared --with-dom=/usr/local/libxml2-2.4.9 --enable-trans-si d --with-config-file-path=/usr/local/php-4.1.2 --with-tiff-dir=/usr/local/tiff-v 3.5.6-beta --with-pdflib=/usr/local/pdflib-4.0.1 --with-imap=/usr/local --with-m crypt=/usr/local/libmcrypt-2.4.10 --with-expat-dir=/usr/local/expat-1.95.2 --wit h-sablot=/usr/local/Sablot-0.65 --with-openssl=/usr/local/openssl-0.9.6a --with- bz2 --with-t1lib=/usr/local/T1-1.1.1 --with-mm --with-zip=/usr/local/zziplib-0.1 0.27 --enable-inline-optimization --enable-sysvsem --enable-sysvshm --with-ndbm Kind regards, Frank PowerWeb -- Edit this bug report at http://bugs.php.net/?id=15833&edit=1
Bug #15908 Updated: failed to compile with iconv
ID: 15908 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: FreeBSD 4.5-RELEASE PHP Version: 4.1.2 New Comment: I tried the patch specified in: http://bugs.php.net/bug.php?id=14423 but it fails at: Making all in main cc -I. -I/usr/ports/www/mod_php4/work/php-4.1.2/main -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 -c internal_functions.c && touch internal_functions.lo internal_functions.c:69: `iconv_module_entry' undeclared here (not in a function) internal_functions.c:69: initializer element is not constant internal_functions.c:69: (near initialization for `php_builtin_extensions[15]') *** Error code 1 Previous Comments: [2002-03-06 12:58:42] [EMAIL PROTECTED] 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 this bug report at http://bugs.php.net/?id=15908&edit=1
Bug #15918 Updated: DomAttribute missing "type" property
ID: 15918 Updated by: [EMAIL PROTECTED] -Summary: DomAttribute missing "type" property Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: DOM XML related Operating System: Linux PHP Version: 4.1.2 Assigned To: jtate New Comment: Let me allow myself to be less ambiguous on the last comment I made. It would be nice if every class also consistently had a property for the name (no need for function I guess, since it would not be in the way of the current design to make a function to return every property). The reason I say this is because often times, in the case of classes such as DomText, the name is actually just "#text" and DomDocument is "#document". There is a chart on the w3c page for the nodeNames that correspond to the different classes and without this property consistent for every php DOM class, I have to use a huge switch statement to run through the different types of nodes and figure out what the name would be. Just seems like a trivial fix that would make the classes more complete. Thanks! Previous Comments: [2002-03-07 10:15:06] [EMAIL PROTECTED] This should be a quick fix. [2002-03-06 19:37:26] [EMAIL PROTECTED] 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 this bug report at http://bugs.php.net/?id=15918&edit=1
Bug #11116 Updated: File upload sometimes work, sometimes fails
ID: 6 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: HTTP related Operating System: win NT 4 PHP Version: 4.0.5 New Comment: I have got the same problem... I'm using php4.1.0 as a module of apache... with file size all it is OK, but sometimes upload fails, sometimes do not... more often fails than not... Previous Comments: [2001-11-18 10:05:28] [EMAIL PROTECTED] No feedback. Closing. [2001-10-28 16:44:43] [EMAIL PROTECTED] You're setting the maximum filesize to be 4096 bytes. That might be the reason for the uploads to fail? Not many normal files are that small. --Jani [2001-06-01 04:33:14] [EMAIL PROTECTED] It seems that binary files always fail and others sometimes fail. I thought it could be wise to add the submit form I use. ... [2001-05-31 22:53:09] [EMAIL PROTECTED] Is there any pattern of files you can't upload? like, are they always binary files that fail? --Jani [2001-05-29 03:26:55] [EMAIL PROTECTED] Tried php 4.0.5 => same problem. I can *sometimes* upload files, *sometimes* i can't!? 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/6 -- Edit this bug report at http://bugs.php.net/?id=6&edit=1
Bug #15918 Updated: DomAttribute missing "type" property
ID: 15918 Updated by: [EMAIL PROTECTED] -Summary: DomAttribute missing "type" property Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: DOM XML related Operating System: Linux PHP Version: 4.1.2 Assigned To: jtate New Comment: I've added type nodes to DomAttributes. (I also added them to CDATA nodes too). I'll take a look at the name stuff, but it will require a little more time to look into. I'll get the type nodes into the 4.2.0 release tree so that it'll be in the next release. Previous Comments: [2002-03-07 11:19:05] [EMAIL PROTECTED] Let me allow myself to be less ambiguous on the last comment I made. It would be nice if every class also consistently had a property for the name (no need for function I guess, since it would not be in the way of the current design to make a function to return every property). The reason I say this is because often times, in the case of classes such as DomText, the name is actually just "#text" and DomDocument is "#document". There is a chart on the w3c page for the nodeNames that correspond to the different classes and without this property consistent for every php DOM class, I have to use a huge switch statement to run through the different types of nodes and figure out what the name would be. Just seems like a trivial fix that would make the classes more complete. Thanks! [2002-03-07 10:15:06] [EMAIL PROTECTED] This should be a quick fix. [2002-03-06 19:37:26] [EMAIL PROTECTED] 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 this bug report at http://bugs.php.net/?id=15918&edit=1
Bug #15804 Updated: PHPSESSID in querystring causes XHTML validator to fail
ID: 15804 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: Apache/1.3.23 (Unix) PHP Version: 4.1.2 New Comment: More over, the real problem is that the seperation character for URI params is ; not & Previous Comments: [2002-03-01 02:32:39] [EMAIL PROTECTED] >From php.ini-recommended: ; The separator used in PHP generated URLs to separate arguments. ; Default is "&". ;arg_separator.output = "&" regards, Derick [2002-03-01 02:26:58] [EMAIL PROTECTED] PHP is compiled with --enable-trans-sid. When I turn on sessions on, (with session_start()) and try to validate my previously valid XHTML page, the validator throws errors on every link. [quote from W3C XHTML 1.0 Transitional validator]: Error: reference not terminated by refc delimiter [end quote] It's referring to the fact that there is a "&" in the code when it is not part of an entity. Without using sessions, I can use & in a URL and the page will validate. I guess the actual bug is that it's inserting a & instead of an & which is invalid XHTML. -- Edit this bug report at http://bugs.php.net/?id=15804&edit=1
Bug #15934 Updated: parameter seperator for url rewriting not w3c compliant
ID: 15934 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Linux Debian 2.2 PHP Version: 4.1.2 New Comment: It seems this 'bug' is 'answered' somewhat in bug #15804. see there for info and my comment. This bug can be migrated to 'bogus' therefore Previous Comments: [2002-03-07 10:30:04] [EMAIL PROTECTED] When enabling url rewriting with sessions, the paramter seperator used for seperating the SID= from other parameteres in the uri is not w3c compliant. PHP uses & (&) for seperating the SID= from other paramters in an URI, w3c states (and they are so right) that this character is used for entities like &. It could let to some hard to find errors in future browsers when they parse it like so. I suggest php uses the ; for parameter seperation as the standards from w3c state. -- Edit this bug report at http://bugs.php.net/?id=15934&edit=1
Bug #15934 Updated: parameter seperator for url rewriting not w3c compliant
ID: 15934 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: Linux Debian 2.2 PHP Version: 4.1.2 New Comment: See last comment, this bug is handled somewhat in bug #15804 which is marked as bogus. Previous Comments: [2002-03-07 11:59:08] [EMAIL PROTECTED] It seems this 'bug' is 'answered' somewhat in bug #15804. see there for info and my comment. This bug can be migrated to 'bogus' therefore [2002-03-07 10:30:04] [EMAIL PROTECTED] When enabling url rewriting with sessions, the paramter seperator used for seperating the SID= from other parameteres in the uri is not w3c compliant. PHP uses & (&) for seperating the SID= from other paramters in an URI, w3c states (and they are so right) that this character is used for entities like &. It could let to some hard to find errors in future browsers when they parse it like so. I suggest php uses the ; for parameter seperation as the standards from w3c state. -- Edit this bug report at http://bugs.php.net/?id=15934&edit=1
Bug #15177 Updated: Informix Shared Module will not compile
ID: 15177 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: *Compile Issues Operating System: RH Linux 7.2 PHP Version: 4.1.1 New Comment: This might possibly be related to bug number 15803 as this is the last time (php-4.0.4pl1) I was able to compile Informix with IBM DB2 support at the same time as well... Previous Comments: [2002-03-03 05:34:47] [EMAIL PROTECTED] Marking as Critical for release 4.2.0 [2002-03-03 05:30:06] [EMAIL PROTECTED] The last version where compile with-informix worked was php4-4.0.4pl1 None after that work, I've tryed them all, including snapshots [2002-01-23 00:45:02] [EMAIL PROTECTED] Same problem as with 4.1.0. Informix will compile statically in PHP, but will not compile as a shared module. I get the same error as in 4.1.0: /bin/sh /php/php-4.1.1/libtool --silent --mode=compile gcc -I. -I/php/php-4.1.1/ext/informix -I/php/php-4.1.1/main -I/php/php-4.1.1 -I/usr/include/apache -I/php/php-4.1.1/Zend -I/opt/informix/incl/esql -I/php/php-4.1.1/ext/xml/expat -DLINUX=22 -DEAPI -DEAPI_MM -DEAPI_MM_CORE_PATH=/var/run/httpd.mm -I/php/php-4.1.1/TSRM -g -O2 -prefer-pic -c ifx.c && touch ifx.slo /bin/sh /php/php-4.1.1/libtool --silent --mode=link gcc -I. -I/php/php-4.1.1/ext/informix -I/php/php-4.1.1/main -I/php/php-4.1.1 -I/usr/include/apache -I/php/php-4.1.1/Zend -I/opt/informix/incl/esql -I/php/php-4.1.1/ext/xml/expat -DLINUX=22 -DEAPI -DEAPI_MM -DEAPI_MM_CORE_PATH=/var/run/httpd.mm -I/php/php-4.1.1/TSRM -g -O2 -prefer-pic -o informix.la -avoid-version -module -rpath /php/php-4.1.1/modules ifx.lo -Rext/informix -Lext/informix -R/opt/informix/lib/esql -L/opt/informix/lib/esql -R/opt/informix/lib -L/opt/informix/lib -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx libtool: link: only absolute run-paths are allowed make[3]: *** [informix.la] Error 1 make[3]: Leaving directory `/php/php-4.1.1/ext/informix' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/php/php-4.1.1/ext/informix' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/php/php-4.1.1/ext' make: *** [all-recursive] Error 1 Configure was input as [root@elliott php-4.1.1]# ./configure --with-apxs=/usr/sbin/apxs --without-mysql --enable-shared --with-informix=shared Any ideas? Zack -- Edit this bug report at http://bugs.php.net/?id=15177&edit=1
Bug #14141 Updated: Fatal error: fatal flex scanner internal error--end of buffer missed in ...
ID: 14141 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: iPlanet related Operating System: SunOS 5.6 PHP Version: 4.0.6 New Comment: I do not admit... (Hope this is the same error, even it has not exactly the same "words" in it) Fatal error: input in flex scanner failed in /home/worldtalk/public_html/info.php3 on line 1 This error I get, when I simply autorefresh a page (at 30 secs) - The error appears randomly... (perhaps more often if the server load is high) => I read, that it could have something to do with FastCGI compatibility... mfg, Stefan Koenig Previous Comments: [2001-11-20 05:25:55] [EMAIL PROTECTED] Hello, I am developing a website and when refreshing a screen or simply accessing to a page I have the following error: Fatal error: fatal flex scanner internal error--end of buffer missed in /www/docs/index.php on line 1 This can occurs at any page and giving me any line number. I read a lot about things like that and I think that it is due to the include I use. I think that it is due to the fact that the file included is not entirely read and t gives an error. In fact, in my pages I use several includes that contains my functions library and my page header and footer. This easily reproductible when I acces very fast the same page (eg: fast clics). Can somebody confirm that I found the right cause of this error ? Most important, Is there any solution to avoid those kind of problems ? Thank you in advance, Regards, Fontana Renato -- Edit this bug report at http://bugs.php.net/?id=14141&edit=1
Bug #15935: phpinfo routine mixing SCRIPT_URI and SCRIPT_URL
From: [EMAIL PROTECTED] Operating system: Irix 6.5.14 PHP version: 4.1.2 PHP Bug Type: Apache related Bug description: phpinfo routine mixing SCRIPT_URI and SCRIPT_URL Just noticed that phpinfo is reporting the SCRIPT_URI in the form: http://www.ex.ac.uk/test.php and the SCRIPT_URL in the form: /test.php Aren't these the wrong way round?? REQUEST_URI is of the form: /test.php Sorry to be so pedantic. Bill Edmunds -- Edit bug report at http://bugs.php.net/?id=15935&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15935&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15935&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15935&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15935&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15935&r=support Expected behavior: http://bugs.php.net/fix.php?id=15935&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15935&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15935&r=submittedtwice
Bug #13094 Updated: Upload very slow
ID: 13094 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Performance problem Operating System: Windows 2000 PHP Version: 4.0.6 Assigned To: sniper New Comment: When is this release (4.2.x) due? Previous Comments: [2002-03-02 10:50:50] [EMAIL PROTECTED] No, only for 4.2.x Derick [2002-03-02 10:47:11] [EMAIL PROTECTED] Has this problem been solved in the update for 4.1.2? [2001-10-28 12:34:17] [EMAIL PROTECTED] This should be fixed in CVS now. You can try the latest development build from http://www.php4win.com/ but make sure it's dated after 27th of October 2001. Also, there are some minor leaks still in the new code. If you encounter such leaks, please send the shortest possible code + html with which you can reproduce the leak to [EMAIL PROTECTED] (or me) so we can get rid of these leaks. The fix will be in PHP 4.2.0. --Jani [2001-10-28 12:10:12] [EMAIL PROTECTED] Fixed in CVS by Jani, will be fixed in 4.2.0 [2001-09-02 16:52:23] [EMAIL PROTECTED] Work in progress... 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/13094 -- Edit this bug report at http://bugs.php.net/?id=13094&edit=1
Bug #13094 Updated: Upload very slow
ID: 13094 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Performance problem Operating System: Windows 2000 PHP Version: 4.0.6 Assigned To: sniper New Comment: In about two months. Derick Previous Comments: [2002-03-07 13:11:46] [EMAIL PROTECTED] When is this release (4.2.x) due? [2002-03-02 10:50:50] [EMAIL PROTECTED] No, only for 4.2.x Derick [2002-03-02 10:47:11] [EMAIL PROTECTED] Has this problem been solved in the update for 4.1.2? [2001-10-28 12:34:17] [EMAIL PROTECTED] This should be fixed in CVS now. You can try the latest development build from http://www.php4win.com/ but make sure it's dated after 27th of October 2001. Also, there are some minor leaks still in the new code. If you encounter such leaks, please send the shortest possible code + html with which you can reproduce the leak to [EMAIL PROTECTED] (or me) so we can get rid of these leaks. The fix will be in PHP 4.2.0. --Jani [2001-10-28 12:10:12] [EMAIL PROTECTED] Fixed in CVS by Jani, will be fixed in 4.2.0 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/13094 -- Edit this bug report at http://bugs.php.net/?id=13094&edit=1
Bug #13718 Updated: form elements with same name problem
ID: 13718 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Feature/Change Request Operating System: All PHP Version: 4.0.6 New Comment: this is a duplicate of #10502. Previous Comments: [2002-03-06 09:10:49] [EMAIL PROTECTED] You have this feature as a "possible" in the PHP To-Do list, so I think this report ought to be reclassified from Bogus. At least then we could vote on it so you could see what the level of support for it is. Cheers! [2001-10-24 18:58:56] [EMAIL PROTECTED] I'm sorry to keep bringing this issue to light, but this actually would mimic that of your existing functionality. If you name an element in a form with a [] that does not garuntee that the variable on the other end will be an array. If there is only one element posted with that name followed by [] it will end up as a standard variable. So, I again make the plea: If you have more than one element with the same name with or without a [] it will come out an array. If you have one element with or without a [] it will come out the other end as a single variable. It is possible that you actually intended for the single element with [] to come out as an array, if that is the case, I guess you should consider this a bug report for the functionality of trailing [] in forms. [2001-10-18 11:38:37] [EMAIL PROTECTED] Oh, I'm sorry, I missunderstood you. I understand what you are getting at, ambiguity can be a problem. I guess I'll just deal with using the suggestion of indexing on a string in javascript. Thank you for all your help. [2001-10-18 11:33:49] [EMAIL PROTECTED] no, i didn't ;) i just tried to describe what would happen *if* we would follow your suggestion and that it is a not so good idea after all (although we definetly should have a look at the [] syntax regarding standard conformance) [2001-10-18 10:57:57] [EMAIL PROTECTED] wow, I just noticed that you are suggesting that php actually generate an array! I posted two example html files, that clearly show that you are wrong. PHP always treats them as a single variable, no matter how many are actually set. 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/13718 -- Edit this bug report at http://bugs.php.net/?id=13718&edit=1
Bug #13035 Updated: 404 on a .php results in SERVER ERROR when using php as a cgi
ID: 13035 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: Linux 2.4.6 PHP Version: 4.0.6 New Comment: Yes with PHP 4.1.2 the problem occures still for me. Previous Comments: [2002-01-17 19:32:26] [EMAIL PROTECTED] I dont know. I dont have 4.1.1 compiled as a CGI anywhere, won't have time to do it and test it until next week probably. [2002-01-12 14:46:54] [EMAIL PROTECTED] Is still still valid with latest apache and php? [2001-08-29 12:12:13] [EMAIL PROTECTED] If PHP is used as a CGI program via: Action php-script /cgi-bin/php AddHandler php-script .php .php3 any .php page which is not found results in 500 SERVER ERROR in the browser instead of 404 NOT FOUND. The php binary is returning nothing in its response to this situation. To wit: The Apache error_log reports "Premature end of script headers" The script_log (enabled with Apache's ScriptLog directive) reports: %% [Wed Aug 29 12:09:58 2001] GET /cgi-bin/php/nothere.php HTTP/1.0 %% 500 /usr/local/httpd/cgi-bin/php %request Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Charset: iso-8859-1,*,utf-8 Accept-Encoding: gzip Accept-Language: en Connection: Keep-Alive Host: localhost User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.6 i686) %response ### php was compiled with "'./configure' '--with-mysql=/usr' '--with-gd' '--with-imagick' '--enable-discard-path' '--enable-force-cgi-redirect'" -- Edit this bug report at http://bugs.php.net/?id=13035&edit=1
Bug #15912 Updated: Trailing \r\n in last varible when doing POST request with IE
ID: 15912 Updated by: [EMAIL PROTECTED] -Summary: Trailing \r\n in last varible when doing POST request with IE Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: HTTP related Operating System: Linux PHP Version: 4.0CVS-2002-03-0 New Comment: In what version it didn't work? Previous Comments: [2002-03-07 09:40:47] [EMAIL PROTECTED] PHP 4.1.2 seams to handle it correctly [2002-03-07 09:36:02] [EMAIL PROTECTED] Changed category to HTTP related [2002-03-07 07:00:37] [EMAIL PROTECTED] 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. Exmaple code: "; echo "b=".urlencode($_POST["b"]).""; ?> a: b: Posting "foo" in a and "bar" i b results in this output in IE: a=foo b=bar%0D%0A and in Mozilla: a=foo b=bar [2002-03-06 14:37:38] [EMAIL PROTECTED] 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 this bug report at http://bugs.php.net/?id=15912&edit=1
Bug #15918 Updated: DomAttribute missing "type" property
ID: 15918 Updated by: [EMAIL PROTECTED] -Summary: DomAttribute missing "type" property Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: DOM XML related Operating System: Linux PHP Version: 4.1.2 Assigned To: jtate New Comment: I'm closing this bug. It's been committed both to HEAD and PHP_4_2_0. I will open a feature request for setting nodeNames for each node. Please send me the link to the page you refer to on the w3c page. Previous Comments: [2002-03-07 11:37:30] [EMAIL PROTECTED] I've added type nodes to DomAttributes. (I also added them to CDATA nodes too). I'll take a look at the name stuff, but it will require a little more time to look into. I'll get the type nodes into the 4.2.0 release tree so that it'll be in the next release. [2002-03-07 11:19:05] [EMAIL PROTECTED] Let me allow myself to be less ambiguous on the last comment I made. It would be nice if every class also consistently had a property for the name (no need for function I guess, since it would not be in the way of the current design to make a function to return every property). The reason I say this is because often times, in the case of classes such as DomText, the name is actually just "#text" and DomDocument is "#document". There is a chart on the w3c page for the nodeNames that correspond to the different classes and without this property consistent for every php DOM class, I have to use a huge switch statement to run through the different types of nodes and figure out what the name would be. Just seems like a trivial fix that would make the classes more complete. Thanks! [2002-03-07 10:15:06] [EMAIL PROTECTED] This should be a quick fix. [2002-03-06 19:37:26] [EMAIL PROTECTED] 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 this bug report at http://bugs.php.net/?id=15918&edit=1
Bug #15908 Updated: failed to compile with iconv
ID: 15908 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: FreeBSD 4.5-RELEASE PHP Version: 4.1.2 New Comment: Could you please try the latest CVS snapshot from http://snaps.php.net/ ? Previous Comments: [2002-03-07 11:01:41] [EMAIL PROTECTED] I tried the patch specified in: http://bugs.php.net/bug.php?id=14423 but it fails at: Making all in main cc -I. -I/usr/ports/www/mod_php4/work/php-4.1.2/main -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 -c internal_functions.c && touch internal_functions.lo internal_functions.c:69: `iconv_module_entry' undeclared here (not in a function) internal_functions.c:69: initializer element is not constant internal_functions.c:69: (near initialization for `php_builtin_extensions[15]') *** Error code 1 [2002-03-06 12:58:42] [EMAIL PROTECTED] 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 this bug report at http://bugs.php.net/?id=15908&edit=1
Bug #15177 Updated: Informix Shared Module will not compile
ID: 15177 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical -Bug Type: *Compile Issues +Bug Type: Compile Failure Operating System: RH Linux 7.2 PHP Version: 4.1.1 Previous Comments: [2002-03-07 12:12:10] [EMAIL PROTECTED] This might possibly be related to bug number 15803 as this is the last time (php-4.0.4pl1) I was able to compile Informix with IBM DB2 support at the same time as well... [2002-03-03 05:34:47] [EMAIL PROTECTED] Marking as Critical for release 4.2.0 [2002-03-03 05:30:06] [EMAIL PROTECTED] The last version where compile with-informix worked was php4-4.0.4pl1 None after that work, I've tryed them all, including snapshots [2002-01-23 00:45:02] [EMAIL PROTECTED] Same problem as with 4.1.0. Informix will compile statically in PHP, but will not compile as a shared module. I get the same error as in 4.1.0: /bin/sh /php/php-4.1.1/libtool --silent --mode=compile gcc -I. -I/php/php-4.1.1/ext/informix -I/php/php-4.1.1/main -I/php/php-4.1.1 -I/usr/include/apache -I/php/php-4.1.1/Zend -I/opt/informix/incl/esql -I/php/php-4.1.1/ext/xml/expat -DLINUX=22 -DEAPI -DEAPI_MM -DEAPI_MM_CORE_PATH=/var/run/httpd.mm -I/php/php-4.1.1/TSRM -g -O2 -prefer-pic -c ifx.c && touch ifx.slo /bin/sh /php/php-4.1.1/libtool --silent --mode=link gcc -I. -I/php/php-4.1.1/ext/informix -I/php/php-4.1.1/main -I/php/php-4.1.1 -I/usr/include/apache -I/php/php-4.1.1/Zend -I/opt/informix/incl/esql -I/php/php-4.1.1/ext/xml/expat -DLINUX=22 -DEAPI -DEAPI_MM -DEAPI_MM_CORE_PATH=/var/run/httpd.mm -I/php/php-4.1.1/TSRM -g -O2 -prefer-pic -o informix.la -avoid-version -module -rpath /php/php-4.1.1/modules ifx.lo -Rext/informix -Lext/informix -R/opt/informix/lib/esql -L/opt/informix/lib/esql -R/opt/informix/lib -L/opt/informix/lib -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx libtool: link: only absolute run-paths are allowed make[3]: *** [informix.la] Error 1 make[3]: Leaving directory `/php/php-4.1.1/ext/informix' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/php/php-4.1.1/ext/informix' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/php/php-4.1.1/ext' make: *** [all-recursive] Error 1 Configure was input as [root@elliott php-4.1.1]# ./configure --with-apxs=/usr/sbin/apxs --without-mysql --enable-shared --with-informix=shared Any ideas? Zack -- Edit this bug report at http://bugs.php.net/?id=15177&edit=1
Bug #15930 Updated: gzencode can't have a level
ID: 15930 Updated by: [EMAIL PROTECTED] -Summary: gzencode can't have a level Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed -Bug Type: Zlib Related +Bug Type: Documentation problem Operating System: windows 200 PHP Version: 4.1.1 -Assigned To: +Assigned To: sr New Comment: That's an error in the documentation. The optional second parameter doesn't set the compression level, it does set the compression mode, i.e. you can use FORCE_GZIP or FORCE_DEFLATE in order to use gzip/deflate compression. The compression level is always the default Z_DEFAULT_COMPRESSION. If nobody objects (does anybody use this parameter?) I'll fix the documentation ... Previous Comments: [2002-03-07 07:37:05] [EMAIL PROTECTED] "; $gzdata = gzencode($data,9); echo strlen($gzdata),":bad always 10"; ?> -- Edit this bug report at http://bugs.php.net/?id=15930&edit=1
Bug #15930 Updated: gzencode can't have a level
ID: 15930 Updated by: [EMAIL PROTECTED] -Summary: gzencode can't have a level Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Documentation problem -Operating System: windows 200 +Operating System: windows 2000 PHP Version: 4.1.1 Assigned To: sr New Comment: YES, I use it. before I use gzopen($fic,"wb9"); with a temporary file the compression was better than gzencode. For passing information from serveur to client, the size of data is very important. I prefer spending 20 ms for much compression than 30 sec more for download. but if it is possible to change the Z_DEFAULT_COMPRESSION, it's ok I always use the same (maxi) compression. Previous Comments: [2002-03-07 10:50:54] [EMAIL PROTECTED] That's an error in the documentation. The optional second parameter doesn't set the compression level, it does set the compression mode, i.e. you can use FORCE_GZIP or FORCE_DEFLATE in order to use gzip/deflate compression. The compression level is always the default Z_DEFAULT_COMPRESSION. If nobody objects (does anybody use this parameter?) I'll fix the documentation ... [2002-03-07 07:37:05] [EMAIL PROTECTED] "; $gzdata = gzencode($data,9); echo strlen($gzdata),":bad always 10"; ?> -- Edit this bug report at http://bugs.php.net/?id=15930&edit=1
Bug #15930 Updated: gzencode can't have a level
ID: 15930 Updated by: [EMAIL PROTECTED] -Summary: gzencode can't have a level Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Documentation problem Operating System: windows 2000 PHP Version: 4.1.1 Assigned To: sr New Comment: Z_DEFAULT_COMPRESSION is a constant of the zlib include file, so you could change it only with a recompile of php. As a workaround maybe you can use gzdeflate() or gzcompress(), there the second parameter is the compression level. But then you have to manually add the gzip headers (and maybe the CRC) if you need them. Previous Comments: [2002-03-07 11:41:43] [EMAIL PROTECTED] YES, I use it. before I use gzopen($fic,"wb9"); with a temporary file the compression was better than gzencode. For passing information from serveur to client, the size of data is very important. I prefer spending 20 ms for much compression than 30 sec more for download. but if it is possible to change the Z_DEFAULT_COMPRESSION, it's ok I always use the same (maxi) compression. [2002-03-07 10:50:54] [EMAIL PROTECTED] That's an error in the documentation. The optional second parameter doesn't set the compression level, it does set the compression mode, i.e. you can use FORCE_GZIP or FORCE_DEFLATE in order to use gzip/deflate compression. The compression level is always the default Z_DEFAULT_COMPRESSION. If nobody objects (does anybody use this parameter?) I'll fix the documentation ... [2002-03-07 07:37:05] [EMAIL PROTECTED] "; $gzdata = gzencode($data,9); echo strlen($gzdata),":bad always 10"; ?> -- Edit this bug report at http://bugs.php.net/?id=15930&edit=1
Bug #15930 Updated: gzencode can't have a level
ID: 15930 Updated by: [EMAIL PROTECTED] -Summary: gzencode can't have a level Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Documentation problem Operating System: windows 2000 PHP Version: 4.1.1 Assigned To: sr New Comment: Well, I prefer the fonctionnality in documentation or something like : gzencode($data[,$level[,$mode]]) It would be much easy to use, than make a gzip by hand with header,crc, ... in "User Contributed Notes" two another persons report this problem. We can perhaps ask them. Previous Comments: [2002-03-07 12:42:03] [EMAIL PROTECTED] Z_DEFAULT_COMPRESSION is a constant of the zlib include file, so you could change it only with a recompile of php. As a workaround maybe you can use gzdeflate() or gzcompress(), there the second parameter is the compression level. But then you have to manually add the gzip headers (and maybe the CRC) if you need them. [2002-03-07 11:41:43] [EMAIL PROTECTED] YES, I use it. before I use gzopen($fic,"wb9"); with a temporary file the compression was better than gzencode. For passing information from serveur to client, the size of data is very important. I prefer spending 20 ms for much compression than 30 sec more for download. but if it is possible to change the Z_DEFAULT_COMPRESSION, it's ok I always use the same (maxi) compression. [2002-03-07 10:50:54] [EMAIL PROTECTED] That's an error in the documentation. The optional second parameter doesn't set the compression level, it does set the compression mode, i.e. you can use FORCE_GZIP or FORCE_DEFLATE in order to use gzip/deflate compression. The compression level is always the default Z_DEFAULT_COMPRESSION. If nobody objects (does anybody use this parameter?) I'll fix the documentation ... [2002-03-07 07:37:05] [EMAIL PROTECTED] "; $gzdata = gzencode($data,9); echo strlen($gzdata),":bad always 10"; ?> -- Edit this bug report at http://bugs.php.net/?id=15930&edit=1
Bug #15936: mistakes in oracle 8 ocifetchinto funtion documentation
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.0.6 PHP Bug Type: Documentation problem Bug description: mistakes in oracle 8 ocifetchinto funtion documentation Please notice that in the french chm php manual, the documentation of the optional parameter of oracle 8 fonction ocifetchinto is erroneous: constants name should be all characters in uppercase (OCI_ASSOC instead of oci_ASSOC etc...). I have checked other functions documentation and it's the same on ociexecute with oci_COMMIT_ON_SUCCESS instead of OCI_COMMIT_ON_SUCCESS So I suppose this might be a mistake in all the oracle 8 (OCI) xml file wich you use to generate chm help files sorry for my bad english best regards Benjamin Leblanc PS : Sample of oracle 8 module documentation - ocifetchinto: - L'option mode vous permet de modifier le comportement par défaut de la fonction. Vous pouvez passer plusieurs modes simplement en les additionnant (i.e. oci_ASSOC+oci_RETURN_NULLS). Les modes valides sont : oci_ASSOC Retourne un tableau associatif. oci_NUM Retourne un tableau à index numérique (DEFAULT, valeur par défaut) oci_RETURN_NULLS Retourne les colonnes vides. oci_RETURN_LOBS Retourne la valeur des objets LOB plutôt que leur descripteur. -- Edit bug report at http://bugs.php.net/?id=15936&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15936&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15936&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15936&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15936&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15936&r=support Expected behavior: http://bugs.php.net/fix.php?id=15936&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15936&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15936&r=submittedtwice
Bug #15937: Call-time pass-by-reference has been deprecated
From: [EMAIL PROTECTED] Operating system: SuSE Linux 6.0 PHP version: 4.0.5 PHP Bug Type: Documentation problem Bug description: Call-time pass-by-reference has been deprecated Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of strlen(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in line 653 To what shall I modify the declartion of strlen? It's not documented anywhere... -- Edit bug report at http://bugs.php.net/?id=15937&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15937&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15937&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15937&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15937&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15937&r=support Expected behavior: http://bugs.php.net/fix.php?id=15937&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15937&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15937&r=submittedtwice
Bug #15937 Updated: Call-time pass-by-reference has been deprecated
ID: 15937 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: SuSE Linux 6.0 PHP Version: 4.0.5 New Comment: there's nothing wrong with strlen(). why do you pass it the argument by reference? strlen() doesn't modify it, so it's completely useless. this PR is bogus. Previous Comments: [2002-03-07 13:22:23] [EMAIL PROTECTED] Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of strlen(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in line 653 To what shall I modify the declartion of strlen? It's not documented anywhere... -- Edit this bug report at http://bugs.php.net/?id=15937&edit=1
Bug #15937 Updated: Call-time pass-by-reference has been deprecated
ID: 15937 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Documentation problem Operating System: SuSE Linux 6.0 PHP Version: 4.0.5 New Comment: reopened this bug. the reason for me to use the call-by-reference is performance... Previous Comments: [2002-03-07 13:31:19] [EMAIL PROTECTED] there's nothing wrong with strlen(). why do you pass it the argument by reference? strlen() doesn't modify it, so it's completely useless. this PR is bogus. [2002-03-07 13:22:23] [EMAIL PROTECTED] Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of strlen(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in line 653 To what shall I modify the declartion of strlen? It's not documented anywhere... -- Edit this bug report at http://bugs.php.net/?id=15937&edit=1
Bug #15937 Updated: Call-time pass-by-reference has been deprecated
ID: 15937 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: SuSE Linux 6.0 PHP Version: 4.0.5 New Comment: Performance is of no concern here. If a function doesn't modify a var, it wont copy it. As strlen() doesn't modify the value, it is not copied, and no performance is lost. Making this bogus again. Previous Comments: [2002-03-07 14:05:02] [EMAIL PROTECTED] reopened this bug. the reason for me to use the call-by-reference is performance... [2002-03-07 13:31:19] [EMAIL PROTECTED] there's nothing wrong with strlen(). why do you pass it the argument by reference? strlen() doesn't modify it, so it's completely useless. this PR is bogus. [2002-03-07 13:22:23] [EMAIL PROTECTED] Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of strlen(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in line 653 To what shall I modify the declartion of strlen? It's not documented anywhere... -- Edit this bug report at http://bugs.php.net/?id=15937&edit=1
Bug #15937 Updated: Call-time pass-by-reference has been deprecated
ID: 15937 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Documentation problem Operating System: SuSE Linux 6.0 PHP Version: 4.0.5 New Comment: Sebastian, please make a performance comparison. If a by-reference is faster, so make a note in the docs and mark this error as deleted. Previous Comments: [2002-03-07 14:07:15] [EMAIL PROTECTED] Performance is of no concern here. If a function doesn't modify a var, it wont copy it. As strlen() doesn't modify the value, it is not copied, and no performance is lost. Making this bogus again. [2002-03-07 14:05:02] [EMAIL PROTECTED] reopened this bug. the reason for me to use the call-by-reference is performance... [2002-03-07 13:31:19] [EMAIL PROTECTED] there's nothing wrong with strlen(). why do you pass it the argument by reference? strlen() doesn't modify it, so it's completely useless. this PR is bogus. [2002-03-07 13:22:23] [EMAIL PROTECTED] Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of strlen(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in line 653 To what shall I modify the declartion of strlen? It's not documented anywhere... -- Edit this bug report at http://bugs.php.net/?id=15937&edit=1
Bug #15938: DOMXML: Implement nodeName
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.1.2 PHP Bug Type: Feature/Change Request Bug description: DOMXML: Implement nodeName The standard DOM implementation at the w3c web page: http://www.w3.org/TR/1999/CR-DOM-Level-2-19991210/core.html#ID-1950641247 lists that each DOM node has a nodeName and nodeValue property along with an attributes list. This needs to be reflected in the PHP DOMXML implementation so as to make iterating through the DOM object easier, and not require large switch statements to, as the w3c paper puts it, "[cast] down to the specific derived interface" to retrieve data. It is partially implemented with the name and tag_name attributes, but it is incomplete and inconsistant. This will require quite a bit of rewrite to implement, but it is worthwhile. I'll work on this, but I'm filing this so that it doesn't get forgotten. -- Edit bug report at http://bugs.php.net/?id=15938&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15938&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15938&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15938&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15938&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15938&r=support Expected behavior: http://bugs.php.net/fix.php?id=15938&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15938&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15938&r=submittedtwice
Bug #15938 Updated: DOMXML: Implement nodeName
ID: 15938 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: All PHP Version: 4.1.2 -Assigned To: +Assigned To: jtate New Comment: Assigning it to me. Previous Comments: [2002-03-07 14:45:05] [EMAIL PROTECTED] The standard DOM implementation at the w3c web page: http://www.w3.org/TR/1999/CR-DOM-Level-2-19991210/core.html#ID-1950641247 lists that each DOM node has a nodeName and nodeValue property along with an attributes list. This needs to be reflected in the PHP DOMXML implementation so as to make iterating through the DOM object easier, and not require large switch statements to, as the w3c paper puts it, "[cast] down to the specific derived interface" to retrieve data. It is partially implemented with the name and tag_name attributes, but it is incomplete and inconsistant. This will require quite a bit of rewrite to implement, but it is worthwhile. I'll work on this, but I'm filing this so that it doesn't get forgotten. -- Edit this bug report at http://bugs.php.net/?id=15938&edit=1
Bug #8545 Updated: Session variables not carried forward in Netscape Client
ID: 8545 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Session related Operating System: Linux RH 6.2 PHP Version: 4.0.6RC3 New Comment: I get these results with RH7.0,Apache 1.3.22,PHP 4.1.1 (php.ini display_errors=on, register_globals= off) Netscape 4.75 (cookies,javascript on OR off) on my development workstation: (first.php) Use of undefined constant test - assumed 'test' in /var/www/hoecoop/html/auth/first.php on line 3 Click here to goto next page Warning: Undefined variable: test in /var/www/hoecoop/html/auth/second.php on line 3 Click here to goto first page Help !!! Previous Comments: [2002-03-04 00:00:02] [EMAIL PROTECTED] 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". [2002-02-03 19:58:19] [EMAIL PROTECTED] To reporter: Is this bug still in PHP 4.1.1? [2002-01-06 22:13:19] [EMAIL PROTECTED] Is this bug outstanding? To reporter: please update PHP Version. (i.e. Try with 4.2.0-dev) [2001-06-14 23:12:11] [EMAIL PROTECTED] Seems like the session_start() doesn set the cookie when Apache is run in Inetd mode. Reproduced with PHP 4.0.6RC3 [2001-02-28 04:03:15] [EMAIL PROTECTED] hi, observation is same even with the latest one. rgds Bhaskar 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/8545 -- Edit this bug report at http://bugs.php.net/?id=8545&edit=1
Bug #15939: implement the function remove_attribute
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.1.2 PHP Bug Type: DOM XML related Bug description: implement the function remove_attribute Of all the functions missing, this seems to be the most critical. There is currently no way to take an attribute out of the xml document. -- Edit bug report at http://bugs.php.net/?id=15939&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15939&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15939&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15939&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15939&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15939&r=support Expected behavior: http://bugs.php.net/fix.php?id=15939&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15939&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15939&r=submittedtwice
Bug #8545 Updated: Session variables not carried forward in Netscape Client
ID: 8545 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Session related Operating System: Linux RH 6.2 PHP Version: 4.0.6RC3 New Comment: PS apache is running standalone, not xinetd. Previous Comments: [2002-03-07 14:49:43] [EMAIL PROTECTED] I get these results with RH7.0,Apache 1.3.22,PHP 4.1.1 (php.ini display_errors=on, register_globals= off) Netscape 4.75 (cookies,javascript on OR off) on my development workstation: (first.php) Use of undefined constant test - assumed 'test' in /var/www/hoecoop/html/auth/first.php on line 3 Click here to goto next page Warning: Undefined variable: test in /var/www/hoecoop/html/auth/second.php on line 3 Click here to goto first page Help !!! [2002-03-04 00:00:02] [EMAIL PROTECTED] 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". [2002-02-03 19:58:19] [EMAIL PROTECTED] To reporter: Is this bug still in PHP 4.1.1? [2002-01-06 22:13:19] [EMAIL PROTECTED] Is this bug outstanding? To reporter: please update PHP Version. (i.e. Try with 4.2.0-dev) [2001-06-14 23:12:11] [EMAIL PROTECTED] Seems like the session_start() doesn set the cookie when Apache is run in Inetd mode. Reproduced with PHP 4.0.6RC3 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/8545 -- Edit this bug report at http://bugs.php.net/?id=8545&edit=1
Bug #15905 Updated: long filenames in fopen() crash PHP.
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:
What is the value of 'active_opline' in the function
'zend_executed_lineno' ? Seems to be fucked up somehow (or the if
expression above results in a wrong condition?).
Does it also happen with current CVS?
Previous Comments:
[2002-03-07 05:53:08] [EMAIL PROTECTED]
Happens still with latest CVS snapshot (20020307), please see gdb
debugging session below:
(gdb) run crash.php
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /src/webstuff/php4-20020307/php crash.php
warning: Unable to find dynamic linker breakpoint function.
warning: GDB will be unable to debug shared library initializers
warning: and track explicitly loaded dynamic code.
Breakpoint 1, php_checkuid (filename=0x1d2180 'x' ...,
fopen_mode=0x1c9278 "r", mode=4) at safe_mode.c:50
50 long uid=0L, gid=0L, duid=0L, dgid=0L;
(gdb) step
55 if (!filename) {
(gdb)
59 if (fopen_mode) {
(gdb)
60 if (fopen_mode[0] == 'r') {
(gdb)
71 if (!strncasecmp(filename,"http://";, 7) ||
!strncasecmp(filename,"ftp://";, 6)) {
(gdb) print filename
$7 = 0x1d2180 'x' ...
(gdb)
$8 = 0x1d2180 'x' ...
(gdb)
$9 = 0x1d2180 'x' ...
(gdb) step
78 if (mode != CHECKUID_ALLOW_ONLY_DIR) {
(gdb)
79 VCWD_REALPATH(filename, path);
(gdb)
80 ret = VCWD_STAT(path, &sb);
(gdb)
81 if (ret < 0) {
(gdb)
82 if (mode == CHECKUID_DISALLOW_FILE_NOT_EXISTS) {(gdb)
83 php_error(E_WARNING, "Unable to access %s",
filename);
(gdb) print filename
$10 = 0x1d2180 'x' ...
(gdb)
$11 = 0x1d2180 'x' ...
(gdb) step
zend_error (type=2, format=) at zend.c:642
642 switch (type) {
(gdb)
657 if (zend_is_compiling(TSRMLS_C)) {
(gdb)
zend_is_compiling () at zend_compile.c:147
147 return CG(in_compilation);
(gdb)
zend_is_executing () at zend_execute_API.c:263
263 return EG(in_execution);
(gdb)
zend_error (type=2, format=) at zend.c:661
661 error_filename =
zend_get_executed_filename(TSRMLS_C);
(gdb) print error_filename
$12 =
(gdb) step
zend_get_executed_filename () at zend_execute_API.c:243
243 if (EG(active_op_array)) {
(gdb) print active_op_array
No symbol "active_op_array" in current context.
(gdb) step
244 return EG(active_op_array)->filename;
(gdb) print active_op_array
No symbol "active_op_array" in current context.
(gdb) print EG(active_op_array)->filename
No symbol "EG" in current context.
(gdb) step
zend_error (type=2, format=) at zend.c:662
662 error_lineno =
zend_get_executed_lineno(TSRMLS_C);
(gdb) print error_filename
$13 =
(gdb)
$14 =
(gdb) step
zend_get_executed_lineno () at zend_execute_API.c:253
253 if (EG(opline_ptr)) {
(gdb) print opline_ptr
No symbol "opline_ptr" in current context.
(gdb) step
254 return active_opline->lineno;
(gdb) print filename
No symbol "filename" in current context.
(gdb) step
Program received signal SIGSEGV, Segmentation fault.
zend_get_executed_lineno () at zend_execute_API.c:254
254 return active_opline->lineno;
(gdb) bt
#0 zend_get_executed_lineno () at zend_execute_API.c:254
#1 0xec1bc in zend_error (type=2, format=) at zend.c:662
#2 0xf5d30 in php_checkuid (filename=0x1d2180 'x' ...,
fopen_mode=0xefffe118 'x' ..., mode=0) at
safe_mode.c:83
#3 0x31de4 in php_fopen_url_wrapper (path=, mode=,
options=2021161080, issock=, socketd=,
opened_path=) at fopen_wrappers.c:582
Cannot access memory at address 0x787878b0.
(gdb)
[2002-03-07 03:27:46] [EMAIL PROTECTED]
Can't reproduce it on Linux as well. Could be related to some solaris
weirdness. example script works fine if safe_mode is turned off. I'll
test with latest snap shots today.
cheers
axelm
[2002-03-06 12:55:49] [EMAIL PROTECTED]
Does it only happen with safe_mode on?
Derick
[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
Bug #15940: Segmentation fault (11)
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.2 PHP Bug Type: Apache related Bug description: Segmentation fault (11) There seems to be a bug in PHP 4.1.2. Being not an expert in this kind of stuff I can only report the symptoms. We are running the site for quite a time without any problems (4.0.6 compiled with configure --with-apache=../apache_1.3.23 --enable-track-vars --with-interbase=/opt/interbase --enable-trans-id). After upgrading to 4.1.2 the output of PHP did occasionally - not always - create only parts of the expected output. The apache error log showed "child pid 8354 exit signal Segmentation fault (11)" for about every 20 sec. The site has quite a high load with about 80 kByte/s at the time of watching this. Switching back to 4.0.6 made the problem disappear. On a other server with almost exactly the same config the problem does not occur. The only difference between the two is that the load is lower (between 1 and 4 kBytes/s) and that Interbase is not used by any PHP script on the server but support is compiled in and interbase is running. -- Edit bug report at http://bugs.php.net/?id=15940&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15940&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15940&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15940&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15940&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15940&r=support Expected behavior: http://bugs.php.net/fix.php?id=15940&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15940&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15940&r=submittedtwice
Bug #15941: feature request for str_replace_first
From: [EMAIL PROTECTED]
Operating system: all
PHP version: 4.1.2
PHP Bug Type: Feature/Change Request
Bug description: feature request for str_replace_first
function str_replace_first($search, $replace, $subject)
{
$retval = $subject;
$pos = strpos($subject,$search);
if ($pos !== false) {
$retval =
substr_replace($subject,$replace,$pos,strlen($search));
}
return $retval;
}
the above function would be useful in the str_functions, would probably be
faster in c.. and i bet some people use something similar atleast once in
their life :D
--
Edit bug report at http://bugs.php.net/?id=15941&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15941&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15941&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15941&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15941&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15941&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15941&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15941&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15941&r=submittedtwice
Bug #13595 Updated: Solution for "PHP Fatal error: Unable to start session mm module in Unknown on
ID: 13595
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Session related
Operating System: Debian Sid
PHP Version: 4.0.6
New Comment:
Yes, I had the save path explicitly set to '/dev/null' in php.ini since
I first installed version 4.0.5; I haven't been using sessions, so I
wouldn't have noticed if sessions were not working. However, after the
upgrade, I sure noticed something was wrong, since apache wouldn't
start.
As for why it was setup that way... I have the server setup so each
virtual host uses its own 'tmp' directory, and as I recall, I didn't
want PHP to store anything in '/tmp'.
Previous Comments:
[2002-03-07 00:30:14] [EMAIL PROTECTED]
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.
[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?
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 #15918 Updated: DomAttribute missing "type" property
ID: 15918 Updated by: [EMAIL PROTECTED] -Summary: DomAttribute missing "type" property Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: DOM XML related Operating System: Linux PHP Version: 4.1.2 Assigned To: jtate New Comment: It appears that the logic for the nodeName has already been implemented...(search in the C code for #comment or #cdata-section and you will arrive at the switch statement). So all the code is there, it just seems like mode DOM Classes don't have this function "attached" for whatever reason. If you just attach this function domxml_node_name then it should be done. Also, it seems only logical to attach the function domxml_node_type to all of the DOM Classes (just a thought)...the page on W3C for nodeNames is: http://www.w3.org/TR/2002/WD-DOM-Level-3-Core-20020114/core.html#ID-1950641247 just cruise down a little bit from that anchor and you will see the table (first one you come to). But like I said, I am certain the functions are already prepared in the php C code. Previous Comments: [2002-03-07 14:32:23] [EMAIL PROTECTED] I'm closing this bug. It's been committed both to HEAD and PHP_4_2_0. I will open a feature request for setting nodeNames for each node. Please send me the link to the page you refer to on the w3c page. [2002-03-07 11:37:30] [EMAIL PROTECTED] I've added type nodes to DomAttributes. (I also added them to CDATA nodes too). I'll take a look at the name stuff, but it will require a little more time to look into. I'll get the type nodes into the 4.2.0 release tree so that it'll be in the next release. [2002-03-07 11:19:05] [EMAIL PROTECTED] Let me allow myself to be less ambiguous on the last comment I made. It would be nice if every class also consistently had a property for the name (no need for function I guess, since it would not be in the way of the current design to make a function to return every property). The reason I say this is because often times, in the case of classes such as DomText, the name is actually just "#text" and DomDocument is "#document". There is a chart on the w3c page for the nodeNames that correspond to the different classes and without this property consistent for every php DOM class, I have to use a huge switch statement to run through the different types of nodes and figure out what the name would be. Just seems like a trivial fix that would make the classes more complete. Thanks! [2002-03-07 10:15:06] [EMAIL PROTECTED] This should be a quick fix. [2002-03-06 19:37:26] [EMAIL PROTECTED] 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 this bug report at http://bugs.php.net/?id=15918&edit=1
Bug #15942: undefined symbol: xsltParseStylesheet*
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.2 PHP Bug Type: XSLT related Bug description: undefined symbol: xsltParseStylesheet* php: relocation error: /usr/lib/php4/domxml.so: undefined symbol: xsltParseStylesheet* I downloaded the snapshot and did the following ./configure --with-dom=shared --with-dom-xslt --with-dom-exslt (I had libxslt and libxslt-devel 1.0.12 and the corresponding libxml2) Then I copied the domxml.so to my extensions and tried to use one of the domxml_xslt_stylesheet_* functions and received the above error. I had previously build the module just after the libxslt functions were added (around CVS version 1.102) and it worked fine. In addition to this error, the following lines from the C file cause the module not to load when left in the source code. Line 1236: xmlSetGenericErrorFunc(xmlGenericErrorContext, (xmlGenericErrorFunc)domxml_error); if HAVE_DOMXSLT xsltSetGenericErrorFunc(xsltGenericErrorContext, (xmlGenericErrorFunc)domxml_error); -- Edit bug report at http://bugs.php.net/?id=15942&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15942&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15942&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15942&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15942&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15942&r=support Expected behavior: http://bugs.php.net/fix.php?id=15942&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15942&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15942&r=submittedtwice
Bug #15942 Updated: undefined symbol: xsltParseStylesheet*
ID: 15942 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: XSLT related Operating System: Linux PHP Version: 4.1.2 New Comment: Important to note here that all the other domxml functions worked, it was just the xslt functions that had trouble. Of course when the module couldn't load, nothing worked. Previous Comments: [2002-03-07 16:30:50] [EMAIL PROTECTED] php: relocation error: /usr/lib/php4/domxml.so: undefined symbol: xsltParseStylesheet* I downloaded the snapshot and did the following ./configure --with-dom=shared --with-dom-xslt --with-dom-exslt (I had libxslt and libxslt-devel 1.0.12 and the corresponding libxml2) Then I copied the domxml.so to my extensions and tried to use one of the domxml_xslt_stylesheet_* functions and received the above error. I had previously build the module just after the libxslt functions were added (around CVS version 1.102) and it worked fine. In addition to this error, the following lines from the C file cause the module not to load when left in the source code. Line 1236: xmlSetGenericErrorFunc(xmlGenericErrorContext, (xmlGenericErrorFunc)domxml_error); if HAVE_DOMXSLT xsltSetGenericErrorFunc(xsltGenericErrorContext, (xmlGenericErrorFunc)domxml_error); -- Edit this bug report at http://bugs.php.net/?id=15942&edit=1
Bug #15703 Updated: Segmentation fault with apache2 php pages not served
ID: 15703 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: Red Hat Linux 7.1 PHP Version: 4.1.1 New Comment: This time I compiled php with --enable-debug option to generate backtrace.A new file cgisock (0 size) is automatically created after this compile. I think problem is related to swf functions(swf.c). gdb results are at the end: ---APACHE 2--- ./configure --prefix=/wwwroot --enable-auth-anon --enable-auth-db --enable-auth-dbm --enable-auth-digest --enable-file-cache --enable-echo --enable-cache --enable-mem-cache --enable-example --enable-ext-filter --enable-case-filter --enable-case-filter-in --enable-mime-magic --enable-cern-meta --enable-expires --enable-usertrack --enable-unique-id --enable-ssl --enable-optional-hook-export --enable-optional-hook-import --enable-optional-fn-import --enable-optional-fn-export --enable-http --enable-dav --enable-cgi --enable-info --enable-cgid --enable-dav-fs --enable-vhost-alias --enable-speling --enable-actions --enable-rewrite --enable-so --PHP 4.1.1-- ./configure --prefix=/wwwroot/php --with-apxs2=/wwwroot/bin/apxs --with-mod_charset --with-config-file-path=/wwwroot/php/ --with-openssl --with-zlib --enable-bcmath --with-bz2 --enable-calendar --with-cpdflib --with-png-dir --with-jpeg-dir --with-tiff-dir --enable-ctype --with-curl --with-db3 --with-dom --enable-exif --enable-filepro --enable-ftp --with-gd --enable-gd-native-ttf --with-xpm-dir --with-freetype-dir=/usr --with-ttf --with-t1lib --with-gettext --with-gmp --with-hyperwave --with-iconv --with-imap --with-kerberos --with-imap-ssl --with-ircg --with-ldap --enable-mbstring --enable-mbstr-enc-trans --with-mcal=/usr/src/libmcal --with-mhash --with-mnogosearch=/usr/local/mnogosearch --with-mysql --with-pgsql --with-pspell --with-qtdom --enable-trans-sid --enable-shmop --with-snmp -enable-ucd-snmp-hack --enable-sockets --with-regex=php --with-swf --enable-wddx --with-expat-dir=/usr/local --enable-xslt --with-xslt-sablot --with-yaz=/usr/local/lib --enable-yp --with-zip --with-pdflib --enable-versioning --with-tsrm-st --with-tsrm-pthreads --enable-track-vars --enable-overload --with-mcrypt --with-java=/usr/java/j2sdk1.4.0 --enable-sysvsem --enable-sysvshm --enable-debug After making and installing both apache and php when I started apache and tried to access http://localhost. It worked and apache test page was displayed. Then I tried to access a php file with only phpinfo() function. Netscape displayed a message the document contained no date. Follwing was added to apache error_log: --- [Fri Mar 08 02:12:54 2002] [notice] Digest: generating secret for digest authentication ... [Fri Mar 08 02:12:54 2002] [notice] Digest: done [Fri Mar 08 02:12:55 2002] [notice] Apache/2.0.28 (Unix) mod_ssl/3.0a0 OpenSSL/0.9.6 DAV/2 configured -- resuming normal operations [Fri Mar 08 02:13:16 2002] [error] Optional hook test said: GET / HTTP/1.0 [Fri Mar 08 02:13:16 2002] [error] Optional function test said: GET / HTTP/1.0 [Fri Mar 08 02:13:16 2002] [error] Optional hook test said: GET /apache_pb.gif HTTP/1.0 [Fri Mar 08 02:13:16 2002] [error] Optional function test said: GET /apache_pb.gif HTTP/1.0 [Fri Mar 08 02:14:47 2002] [notice] child pid 4472 exit signal Segmentation fault (11) I stoped apache removed all logs files and tried /wwwroot/bin/httpd -X after running 'ulimit -c unlimited' and then accessed a php file with phpinfo() and lynx displayed unable to access start document...unkonwn network error and exited. /wwwroot/bin/httpd -X produced: Segmentation fault and exited. No core file is produced under /wwwroot/bin (/wwwroot is apache 2.0 install directory). /wwwroot/bin has write permission for everyone. Then I tried the second option like this and was successful: --- gdb /wwwroot/bin/httpd GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run -X Starting program: /wwwroot/bin/httpd -X [New Thread 1024 (LWP 763)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 763)] 0x405e52c1 in zm_activate_swf (type=1, module_number=8, tsrm_ls=0x81e7210) at swf.c:173 173 SWFG(use_
Bug #15912 Updated: Trailing \r\n in last varible when doing POST request with IE
ID: 15912 Updated by: [EMAIL PROTECTED] -Summary: Trailing \r\n in last varible when doing POST request with IE Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: HTTP related Operating System: Linux PHP Version: 4.0CVS-2002-03-0 New Comment: The CVS version from yesterday (2002-03-06) Previous Comments: [2002-03-07 14:29:04] [EMAIL PROTECTED] In what version it didn't work? [2002-03-07 09:40:47] [EMAIL PROTECTED] PHP 4.1.2 seams to handle it correctly [2002-03-07 09:36:02] [EMAIL PROTECTED] Changed category to HTTP related [2002-03-07 07:00:37] [EMAIL PROTECTED] 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. Exmaple code: "; echo "b=".urlencode($_POST["b"]).""; ?> a: b: Posting "foo" in a and "bar" i b results in this output in IE: a=foo b=bar%0D%0A and in Mozilla: a=foo b=bar [2002-03-06 14:37:38] [EMAIL PROTECTED] 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 this bug report at http://bugs.php.net/?id=15912&edit=1
Bug #14939 Updated: Warning: gzinflate: buffer error in /usr/local/apache/elca_rmg/class.FTemplateE
ID: 14939
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Zlib Related
Operating System: Apache
PHP Version: 4.1.1
-Assigned To:
+Assigned To: sr
New Comment:
Does the attached patch help?
--- /home/sr/cvs/php/php4/ext/zlib/zlib.c Thu Mar 7 16:38:26
2002
+++ ext/zlib/zlib.c Thu Mar 7 23:15:48 2002
@@ -967,7 +967,7 @@
if(! s2) { if(s1) efree(s1); RETURN_FALSE; }
stream.next_in = (Bytef*) Z_STRVAL_PP(data);
- stream.avail_in = (uInt) Z_STRLEN_PP(data);
+ stream.avail_in = (uInt) Z_STRLEN_PP(data) + 1; /*
there is room for \0 */
stream.next_out = s2;
stream.avail_out = (uInt) length;
(If there are broken line breaks and you can't apply it, change the
line stream.avail_in = (uInt) Z_STRLEN_PP(data) to ...(data)+1 in the
gzinflate function).
Please report if it works (and if it doesn't break other things). This
seems to be a rather strange thing in the zlib library ...
Previous Comments:
[2002-03-07 08:06:33] [EMAIL PROTECTED]
Does this script work if you don't provide a compression level?
-- robin
[2002-01-08 21:04:16] [EMAIL PROTECTED]
Receive the following error with only 15 consecutive characters
entered.
Warning: gzinflate: buffer error in
/usr/local/apache/elca_rmg/class.FTemplateExt.php on line 153
What follows is the code updating the SQL files:
$gzsize = strlen($description) + 4; // added 4 more than req'd
$gzcompress = gzdeflate ($description,6);
$gzcompress = addslashes($gzcompress); //Reqd for SQL updates
$query = "UPDATE htmlcontent SET record_nbr = \"$record_nbr\",
gzcompress = \"$gzcompress\", gzsize = $gzsize WHERE record_nbr =
\"$record_nbr\"";
}
general_update($errno,$errmsg,$rowsaffected, $result, $s_synod_id,
$query); // UPDATE the record
***
Next I attempt to read the record back and unzip gzcompress
Note that $description consists of 20 'a' characters. Any repetitive
char will do and only 15 to 20 are req'd
***
$query = "SELECT * FROM htmlcontent WHERE record_nbr =
\"$record_nbr\"";
general_read($errno, $errmsg,$numrows, $result_html, $s_synod_id,
$query);
if ($numrows > 0) {
if ($row_html = mysql_fetch_array ($result_html)) {
$content = stripslashes($row_html["gzcompress"]);
if (strlen($content) > 0) {
**Error occurs on the following instruction*
$new = gzinflate($content,$row_html["gzsize"]);
--
Edit this bug report at http://bugs.php.net/?id=14939&edit=1
Bug #15925 Updated: ext/gd/config.m4 broken in HEAD
ID: 15925 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Closed 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 New Comment: This bug has been fixed in CVS. I applied reverse patch for PHP 4.1.2. gd2/freetype2 detection related issue is solved by this fix. But, GD/Freetype related issue Rasmus mentioned is still existing and need to befixed. 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 #14522 Updated: Crash with using $node->unlink();
ID: 14522
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: DOM XML related
Operating System: SuSe 7.3
PHP Version: CVS Download
New Comment:
beware: the bug is marked as closed, but a fix has not been applied to
cvs yet.
Previous Comments:
[2002-02-19 15:16:27] [EMAIL PROTECTED]
The patch from [EMAIL PROTECTED] worked on my Server.
Hope it will be soon in the CVS Version
[2002-02-19 13:43:50] [EMAIL PROTECTED]
This patch against latest CVS should fix it:
(basically it makes domxml not free a node on unlink and
rather wait for request shutdown to free a node).
btw, this patch also enables a domxml user to re-add a
previously unlink()ed node, which is impossible with
the current code.
regards,
-lukas
Index: ext/domxml/php_domxml.c
===
RCS file: /repository/php4/ext/domxml/php_domxml.c,v
retrieving revision 1.116
diff -u -r1.116 php_domxml.c
--- ext/domxml/php_domxml.c 4 Feb 2002 21:07:39 - 1.116
+++ ext/domxml/php_domxml.c 19 Feb 2002 18:38:57 -
@@ -1801,8 +1801,6 @@
DOMXML_PARAM_NONE(nodep, id, le_domxmlnodep);
xmlUnlinkNode(nodep);
- xmlFreeNode(nodep);
- zval_dtor(id); /* This is not enough
because the children won't be deleted */
}
/* }}} */
[2002-02-19 12:23:38] [EMAIL PROTECTED]
Nothing happening about the bug? Un Downloading regularly the newest
CVS Version but doesnt help
[2002-02-12 16:22:20] [EMAIL PROTECTED]
We have also reproduced this error on both RedHat 7.2 and FreeBSD 4.4
both running PHP 4.1.1. It completely takes down FREEBSD as apache
continues to log seg faults until the drive is full. We had the same
results with 4.0.6 prior to the upgrade as well.
[2002-01-07 12:16:47] [EMAIL PROTECTED]
Sorry i havent been at home the second part of December.
Here a sample code:
bla");
$xmlnode=$xmlstruc->root();
$xmlchilds=$xmlnode->children();
if(!is_array($xmlchilds)) $xmlchilds=array($xmlchilds);
foreach ( $xmlchilds as $workingchild) {
$workingchild->unlink();}
echo $xmlstruc->dumpmem();
?>
martin
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/14522
--
Edit this bug report at http://bugs.php.net/?id=14522&edit=1
Bug #15703 Updated: Segmentation fault with apache2 php pages not served
ID: 15703
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Apache2 related
Operating System: Red Hat Linux 7.1
PHP Version: 4.1.1
New Comment:
Hmm .. have you compiled php with thread support?
It seems the swf module is missing an ZEND_INIT_MODULE_GLOBALS() call
in PHP_MINIT_FUNCTION().
Can you test this patch (against current CVS) ?
diff -u -r1.44 swf.c
--- swf.c 11 Dec 2001 15:30:38 - 1.44
+++ swf.c 7 Mar 2002 22:59:37 -
@@ -138,10 +138,19 @@
}
/* }}} */
+/* {{{ php_swf_init_globals
+ */
+static void php_swf_init_globals(zend_swf_globals *swf_globals) {
+ swf_globals->use_file = 0;
+ swf_globals->tmpfile_name = NULL;
+}
+
/* {{{ PHP_MINIT_FUNCTION
*/
PHP_MINIT_FUNCTION(swf)
{
+ ZEND_INIT_MODULE_GLOBALS(swf, php_swf_init_globals, NULL);
+
REGISTER_LONG_CONSTANT("MOD_COLOR", MOD_COLOR, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("MOD_MATRIX", MOD_MATRIX, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("TYPE_PUSHBUTTON", TYPE_PUSHBUTTON,
CONST_CS | CONST_PERSISTENT);
Previous Comments:
[2002-03-07 17:04:24] [EMAIL PROTECTED]
This time I compiled php with --enable-debug option to generate
backtrace.A
new file cgisock (0 size) is automatically created after this compile.
I think
problem is related to swf functions(swf.c). gdb results are at the
end:
---APACHE
2---
./configure --prefix=/wwwroot --enable-auth-anon --enable-auth-db
--enable-auth-dbm --enable-auth-digest --enable-file-cache
--enable-echo
--enable-cache --enable-mem-cache --enable-example --enable-ext-filter
--enable-case-filter --enable-case-filter-in --enable-mime-magic
--enable-cern-meta --enable-expires --enable-usertrack
--enable-unique-id
--enable-ssl --enable-optional-hook-export
--enable-optional-hook-import
--enable-optional-fn-import --enable-optional-fn-export --enable-http
--enable-dav --enable-cgi --enable-info --enable-cgid --enable-dav-fs
--enable-vhost-alias --enable-speling --enable-actions --enable-rewrite
--enable-so
--PHP
4.1.1--
./configure --prefix=/wwwroot/php --with-apxs2=/wwwroot/bin/apxs
--with-mod_charset --with-config-file-path=/wwwroot/php/ --with-openssl
--with-zlib --enable-bcmath --with-bz2 --enable-calendar --with-cpdflib
--with-png-dir --with-jpeg-dir --with-tiff-dir --enable-ctype
--with-curl
--with-db3 --with-dom --enable-exif --enable-filepro --enable-ftp
--with-gd --enable-gd-native-ttf --with-xpm-dir
--with-freetype-dir=/usr
--with-ttf --with-t1lib --with-gettext --with-gmp --with-hyperwave
--with-iconv --with-imap --with-kerberos --with-imap-ssl --with-ircg
--with-ldap --enable-mbstring --enable-mbstr-enc-trans
--with-mcal=/usr/src/libmcal --with-mhash
--with-mnogosearch=/usr/local/mnogosearch --with-mysql --with-pgsql
--with-pspell --with-qtdom --enable-trans-sid --enable-shmop
--with-snmp
-enable-ucd-snmp-hack --enable-sockets --with-regex=php --with-swf
--enable-wddx --with-expat-dir=/usr/local --enable-xslt
--with-xslt-sablot
--with-yaz=/usr/local/lib --enable-yp --with-zip --with-pdflib
--enable-versioning --with-tsrm-st --with-tsrm-pthreads
--enable-track-vars --enable-overload --with-mcrypt
--with-java=/usr/java/j2sdk1.4.0 --enable-sysvsem --enable-sysvshm
--enable-debug
After making and installing both apache and php when I started apache
and
tried to access http://localhost. It worked and apache test page was
displayed.
Then I tried to access a php file with only phpinfo() function.
Netscape displayed a message the document contained no date. Follwing
was added to apache error_log:
---
[Fri Mar 08 02:12:54 2002] [notice] Digest: generating secret for
digest authentication ...
[Fri Mar 08 02:12:54 2002] [notice] Digest: done
[Fri Mar 08 02:12:55 2002] [notice] Apache/2.0.28 (Unix) mod_ssl/3.0a0
OpenSSL/0.9.6 DAV/2 configured -- resuming normal operations
[Fri Mar 08 02:13:16 2002] [error] Optional hook test said: GET /
HTTP/1.0
[Fri Mar 08 02:13:16 2002] [error] Optional function test said: GET /
HTTP/1.0
[Fri Mar 08 02:13:16 2002] [error] Optional hook test said: GET
/apache_pb.gif HTTP/1.0
[Fri Mar 08 02:13:16 2002] [error] Optional function test said: GET
/apache_pb.gif HTTP/1.0
[Fri Mar 08 02:14:47 2002] [notice] child pid 4472 exit signal
Segmentation fault (11)
I stoped apache removed all logs files and tried /wwwroot/bin/httpd -X
after running 'ulimit -c unlimited' and
then accessed a php file with phpinfo() and lynx displayed una
Bug #14522 Updated: Crash with using $node->unlink();
ID: 14522 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: DOM XML related Operating System: SuSe 7.3 PHP Version: CVS Download New Comment: I've commented out the offending lines in the source. You can pull it from CVS at any time. I'll also see if we can get it into the 4.2.0 release. Thanks for bringing it up again. Previous Comments: [2002-03-07 17:59:06] [EMAIL PROTECTED] beware: the bug is marked as closed, but a fix has not been applied to cvs yet. [2002-02-19 15:16:27] [EMAIL PROTECTED] The patch from [EMAIL PROTECTED] worked on my Server. Hope it will be soon in the CVS Version [2002-02-19 13:43:50] [EMAIL PROTECTED] This patch against latest CVS should fix it: (basically it makes domxml not free a node on unlink and rather wait for request shutdown to free a node). btw, this patch also enables a domxml user to re-add a previously unlink()ed node, which is impossible with the current code. regards, -lukas Index: ext/domxml/php_domxml.c === RCS file: /repository/php4/ext/domxml/php_domxml.c,v retrieving revision 1.116 diff -u -r1.116 php_domxml.c --- ext/domxml/php_domxml.c 4 Feb 2002 21:07:39 - 1.116 +++ ext/domxml/php_domxml.c 19 Feb 2002 18:38:57 - @@ -1801,8 +1801,6 @@ DOMXML_PARAM_NONE(nodep, id, le_domxmlnodep); xmlUnlinkNode(nodep); - xmlFreeNode(nodep); - zval_dtor(id); /* This is not enough because the children won't be deleted */ } /* }}} */ [2002-02-19 12:23:38] [EMAIL PROTECTED] Nothing happening about the bug? Un Downloading regularly the newest CVS Version but doesnt help [2002-02-12 16:22:20] [EMAIL PROTECTED] We have also reproduced this error on both RedHat 7.2 and FreeBSD 4.4 both running PHP 4.1.1. It completely takes down FREEBSD as apache continues to log seg faults until the drive is full. We had the same results with 4.0.6 prior to the upgrade as well. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/14522 -- Edit this bug report at http://bugs.php.net/?id=14522&edit=1
Bug #15736 Updated: Security Exploit
ID: 15736 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Unknown/Other Function Operating System: All UNIX PHP Version: 4.1.1 New Comment: PHP 4.1.2's existance should be reported on the Front Page, perhaps simply stating "offering a number of important security fixes" ? Other people like me have to write things like this: http://www.youngit.org.nz/xmb/viewthread.php?tid=89#pid642 Previous Comments: [2002-02-28 23:06:50] [EMAIL PROTECTED] What is the command to install this PHP 4.0.6 patch? Solarix 8x86 doesn't have a "patch -u" option... I also tried: patch -p1 rfc1867.c.diff-4.0.6.PHPpatch patch -c rfc1867.c.diff-4.0.6.PHPpatch patch -irfc1867.c.diff-4.0.6.PHPpatch # ls -laF -rw-r--r-- 1 bin bin 6802 Feb 28 18:21 rfc1867.c.diff-4.0.6.PHPpatch -rw-r--r-- 1 bin bin 310 Feb 28 19:44 rfc1867.h -rw-r--r-- 1 bin bin 310 Sep 9 2000 rfc1867.h.prePHPpatch Help! Thanks guys. [2002-02-28 18:18:05] [EMAIL PROTECTED] I was wrong, the exploit is fixed. Rasmus fixed just one segfault. [2002-02-28 12:46:48] [EMAIL PROTECTED] Shouldn't the patch on the downloads page also include this patch by Rasmus? http://cvs.php.net/diff.php/php4/main/rfc1867.c?r1=1.71.2.2&r2=1.71.2.3&ty=u [2002-02-28 02:27:52] [EMAIL PROTECTED] ..and I take this back, it's fixed in CVS but not in any release. [2002-02-28 02:11:04] [EMAIL PROTECTED] This bug has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/15736 -- Edit this bug report at http://bugs.php.net/?id=15736&edit=1
Bug #15943: Viewing .phps Crashes with php.ini-recommended
From: [EMAIL PROTECTED] Operating system: FreeBSD PHP version: 4.1.2 PHP Bug Type: Unknown/Other Function Bug description: Viewing .phps Crashes with php.ini-recommended I've installed 4.1.2 and everything works fine with the latest Apache release on the latest FreeBSD release. However, when I try to view a .phps page, the connection to the browser closes abruptly. I was using the supplied php.ini-recommended, and after playing around for a while, saw that using php.ini-dist cleared the problem up. I've looked at both php.ini's supplied with the source, but can't see any difference that would effect this. How can using php.ini-recommended (doesn't work) versus php.ini-dist (works) make a difference, and how can this be straightened out? Thank you, Hans -- Edit bug report at http://bugs.php.net/?id=15943&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15943&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15943&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15943&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15943&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15943&r=support Expected behavior: http://bugs.php.net/fix.php?id=15943&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15943&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15943&r=submittedtwice
Bug #15944: imap_sort Error
From: [EMAIL PROTECTED] Operating system: Windows XP PHP version: 4.1.1 PHP Bug Type: IMAP related Bug description: imap_sort Error // if u run it on Windows. U will see the error message "ERROR PHP.EXE" and "Gate ERROR"!! /* My System Windows XP, IIS 5.1, Expoler 6.0, PHP 4.1.1 */ -- Edit bug report at http://bugs.php.net/?id=15944&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15944&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15944&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15944&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15944&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15944&r=support Expected behavior: http://bugs.php.net/fix.php?id=15944&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15944&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15944&r=submittedtwice
Bug #15943 Updated: Viewing .phps Crashes with php.ini-recommended
ID: 15943 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type: Unknown/Other Function Operating System: FreeBSD PHP Version: 4.1.2 New Comment: This is known issue but I don't know if this is reported. I think phps feature should be removed. (Thoes who know issues understand why :) Use show_source() instead. Previous Comments: [2002-03-07 21:00:26] [EMAIL PROTECTED] I've installed 4.1.2 and everything works fine with the latest Apache release on the latest FreeBSD release. However, when I try to view a .phps page, the connection to the browser closes abruptly. I was using the supplied php.ini-recommended, and after playing around for a while, saw that using php.ini-dist cleared the problem up. I've looked at both php.ini's supplied with the source, but can't see any difference that would effect this. How can using php.ini-recommended (doesn't work) versus php.ini-dist (works) make a difference, and how can this be straightened out? Thank you, Hans -- Edit this bug report at http://bugs.php.net/?id=15943&edit=1
Bug #15943 Updated: Viewing .phps Crashes with php.ini-recommended
ID: 15943 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Unknown/Other Function Operating System: FreeBSD PHP Version: 4.1.2 New Comment: I could some more details? For one, why it should be removed, and two what in the php.ini file breaks the .phps functionality? Using .phps is very useful.. I would think only having show_source() would be clunky, as you'd need another script to just display others. Previous Comments: [2002-03-07 21:36:31] [EMAIL PROTECTED] This is known issue but I don't know if this is reported. I think phps feature should be removed. (Thoes who know issues understand why :) Use show_source() instead. [2002-03-07 21:00:26] [EMAIL PROTECTED] I've installed 4.1.2 and everything works fine with the latest Apache release on the latest FreeBSD release. However, when I try to view a .phps page, the connection to the browser closes abruptly. I was using the supplied php.ini-recommended, and after playing around for a while, saw that using php.ini-dist cleared the problem up. I've looked at both php.ini's supplied with the source, but can't see any difference that would effect this. How can using php.ini-recommended (doesn't work) versus php.ini-dist (works) make a difference, and how can this be straightened out? Thank you, Hans -- Edit this bug report at http://bugs.php.net/?id=15943&edit=1
Bug #15945: While starting Apache I get an undefined symbol error.
mysql_field_count From: [EMAIL PROTECTED] X-PHP-Bug: 15945 Message-ID: <[EMAIL PROTECTED]> From: [EMAIL PROTECTED] Operating system: RedHat 7.2 PHP version: 4.1.2 PHP Bug Type: MySQL related Bug description: While starting Apache I get an undefined symbol error. mysql_field_count While starting Apache I get an undefined symbol error. mysql_field_count Running RedHat 7.2 Installed MySQL 3.23.49a from binary into /usr/local/mysql from mysql-3.23.49a-pc-linux-gnu-i686. MySQL runs correctly. php-4.1.2.tar.gz untarred into php-4.1.2 build was ./configure "--with-mysql=/usr/local/mysql and --with-apxs=/usr/sbin/apxs" ran correctly (without error) make ran without error make install ran without error Apache won't start, reporting "undefined symbol" /etc/rc.d/init.d/httpd start Starting httpd: Syntax error on line 261 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/libphp4.so into server: /etc/httpd/modules/libphp4.so: undefined symbol: mysql_field_count [FAILED] -- Edit bug report at http://bugs.php.net/?id=15945&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15945&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15945&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15945&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15945&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15945&r=support Expected behavior: http://bugs.php.net/fix.php?id=15945&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15945&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15945&r=submittedtwice
Bug #15946: Math output errors
From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version: 4.1.1
PHP Bug Type: Output Control
Bug description: Math output errors
I wrote a script which output Pascal's triangle and then showed the numbers
which were divisible by a certain number in a different colour. At first,
this works fine. Then after the 20th row or so, the % operator starts
outputting incorrect numbers. For example, 37 % 4 returns 1. 24 % 4
returns 3. When those numbers are checked on their own, it works fine.
In the loops though, it starts giving incorrect information after 20 rows.
You can see this at www.alkaline2.com/triangle.php
CODE
\n";
if (!$hidenum) print "\n";
for ($i = 0; $i <= $r; $i++)
{
$num = factorial($r)/(factorial($r - $i) * factorial($i));
if ($divisor > 0 && $num % $divisor == 0)
{
$bgcolor='#ff';
}
else
{
$bgcolor='#44';
}
if (!$hidenum) print "$num\n";
$check = $num % $divisor;
if ($hidenum && $divisor > 0 && $num % $divisor == 0) print "\n";
if ($hidenum && $divisor > 0 && $num % $divisor != 0) print "\n";
if ($hidenum && $divisor == 0) print "\n";
}
print "";
}
function factorial($x)
{
$total = 1;
for ($i = $x; $i > 1; $i--)
$total = $total * $i;
return $total;
}
?>
--
Edit bug report at http://bugs.php.net/?id=15946&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15946&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15946&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15946&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15946&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15946&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15946&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15946&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15946&r=submittedtwice
Bug #15419 Updated: ibase_close problem
ID: 15419 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: InterBase related Operating System: linux red hat PHP Version: 4.1.1 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-14 06:52:06] [EMAIL PROTECTED] We experienced this same bug. I tested it in RH 7.2 with IB 6. We run the same script from command line and got: Segmentation fault when I comment ibase_close($db) out the script works fine. [2002-02-07 03:17:27] [EMAIL PROTECTED] Can look up in your apache log if you get a segfault or some similar crash, and if so can you please provide a backtrace (http://bugs.php.net/?id=15419&edit=1) ? [2002-02-07 02:55:13] [EMAIL PROTECTED] './configure' '--prefix=/usr/local/php4.1.1/' '--enable-track-vars' '--enable-trans-sid' '--with-mysql' '--disable-debug' '--with-apxs=/usr/local/apache-local/bin/apxs' '--enable-shmop' '--enable-xml' '--enable-sockets' '--with-gd' '--with-interbase=/opt/interbase/' Any command after ibase_close doesn't execute and apache returns 404 return code -- Edit this bug report at http://bugs.php.net/?id=15419&edit=1
Bug #13116 Updated: setcookie would not work when expire is set
ID: 13116
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: HTTP related
Operating System: FreeBSD 4.3
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-07 23:05:03] [EMAIL PROTECTED]
Your code works for me, but I don't have a FreeBSD box to test on nor an
Internet Explorer browser.
However, let's not assume yet that this is a FreeBSD problem, since that
really seems unlikely with such a basic thing. The much more probable
case is that it is an IE bug, as IE has historically had problems with
adhering to HTTP standards specifically with cookies.
If your problem (as you say) is like the other bug you link to, then it
sounds like the problem lies in the browser not returning the cookie
rather than the cookie not being set.
To help investigate this, please check as many of the following things
as you know how:
1) HTTP response your PHP page generates
2) subsequent HTTP request from the browser (meaning, a request after
the cookie has been set)
3) Time (in GMT) on the browser
4) Time (in GMT) on the server
5) URL being used to access the page
6) Domain being used to set the cookie
If the problem doesn't reveal itself after inspecting these things, use
the header function as you did but with all hardcoded values to make
sure you're setting the cookie you think you are and that the date is
sufficiently far in the future to rule out any time synchronization
problems.
Thanks for your help!
Chris
[2001-09-03 16:47:38] [EMAIL PROTECTED]
Another user experience the same problem like mine
http://www.php.net/bugs.php?id=11492&edit=1
It looks like they are all using FreeBSD
[2001-09-03 16:33:11] [EMAIL PROTECTED]
I pretty much get the same error as this link
http://www.php.net/bugs.php?id=11478&edit=1
Over a couple hundreds of users, all of them works fine with IE 5.0+
However, some of the user can not login due to the cookie is not set.
Whenever I do
setcookie("username",$user,time()+3600,"/",".domain.com");
Some of the users using IE would not get the cookie.
But when i just change it to
setcookie("username",$user,"","/",".domain.com");
It works. But not setting expire time will not write the cookie to
harddisk, it just stored into memory, which is not what I want.
So, I tried to use the header function and see if that helps.
$time = mktime()+ $config[cookieTTL];
$date = gmdate("l, d-M-Y H:i:s", ($time));
header("Set-Cookie: $cookiename=$tmpstring; expires=$date GMT;
path=/;");
IE still do not pick up the cookie.
Here is a little function I use to store cookie
function putCookie($config,$cookiename, $varname, $data, $send="") {
// function to store cookie, use serialize() to bypass the limit of
using 20 cookies per domain.
// And make it easier to add new cookie later.
//keep this array always static so that when we get out of this
function, it still keep the variable.
static $tmpArray;
$tmpArray[$varname] = $data;
if ($send != "") {
$tmpstring = serialize($tmpArray);
$tmpstring = base64_encode($tmpstring);
$time = mktime()+ $config[cookieTTL];
$date = gmdate("l, d-M-Y H:i:s", ($time));
setCookie($cookiename, $tmpstring, "", $config[cookie_path],
$config[CookieURL]); // now we clean the static array after we send the
cookie
unset($tmpstring);
$tmpArray = "";
unset($tmpArray);
}
}
--
Edit this bug report at http://bugs.php.net/?id=13116&edit=1
Bug #15427 Updated: Online and offline documentation completely different!
ID: 15427 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Documentation problem Operating System: WindowsXP PHP Version: 4.1.1 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-07 10:32:25] [EMAIL PROTECTED] As you can see include is not a function. It is a control structre. Why do you consider it an error to be not included in the function index, as you found it in the control structures section, and not under "Function reference", where the functions are documented? Also what method do you used for searching in the offline and online versions? What format you use of our various offline format possibilities? [2002-02-07 09:12:32] [EMAIL PROTECTED] online and offline versions are generated from the same xml source and at the same time, so you should not see any difference in the content (although the design may be different) where do you download from? mybe there's an old file hidden somewhere we are not aware of? [2002-02-07 08:30:26] [EMAIL PROTECTED] Hello, 1. Searching for the 'include'-function in the english offline documentation in the index file:///c%7C/.../php_manual_en/index.functions.html: it's not present. 2. Searching in the online documentation (costing telephone ticks): it's present under 'control structures': http://www.php.net/manual/en/function.include.php with valuable information on how to use the include function. 3. Searching in the offline documentation under 'control structures': I get a completely worthless page with differences for the include function between PHP3 and 4, not about how to use the include function. We need good offline documentation! When will the online and offline documentation be the same so we can download it??? -- Edit this bug report at http://bugs.php.net/?id=15427&edit=1
Bug #15947: It's code wrong or document wrong about fgets
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 4.1.2
PHP Bug Type: Filesystem function related
Bug description: It's code wrong or document wrong about fgets
On fgets() document is write
string fgets ( int fp [, int length])
bug is you just write php code like
$string = fget($fp);
it will print out some warn info about "Wrong parameter count".
when I check the source code on fgets(), it writed
if (ARG_COUNT(ht) != 2 || zend_get_parameters_ex(2, &arg1, &arg2) ==
FAILURE) {
WRONG_PARAM_COUNT;
}
I think it must not ARG_COUNT(ht) != 2
--
Edit bug report at http://bugs.php.net/?id=15947&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15947&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15947&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15947&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15947&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15947&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15947&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15947&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15947&r=submittedtwice
Bug #15948: Basic Subtraction Error
From: [EMAIL PROTECTED] Operating system: Red Hat Linux 7.1 PHP version: 4.0.6 PHP Bug Type: *Math Functions Bug description: Basic Subtraction Error This was submitted by one of our head developers. We're using PHP/MySQL to build our customer relationship software, and this scares me. --- The numbers should add to 0. When I echo the result I get the below: -5.6843418860808E-14. -- Edit bug report at http://bugs.php.net/?id=15948&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15948&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15948&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15948&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15948&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15948&r=support Expected behavior: http://bugs.php.net/fix.php?id=15948&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15948&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15948&r=submittedtwice
Bug #15925 Updated: ext/gd/config.m4 broken in HEAD
ID: 15925 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +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 New Comment: Ok, but this bug was for Rasmus' bug :)... so opening again. Derick Previous Comments: [2002-03-07 17:35:46] [EMAIL PROTECTED] This bug has been fixed in CVS. I applied reverse patch for PHP 4.1.2. gd2/freetype2 detection related issue is solved by this fix. But, GD/Freetype related issue Rasmus mentioned is still existing and need to befixed. [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 #14522 Updated: Crash with using $node->unlink();
ID: 14522 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Feedback Bug Type: DOM XML related Operating System: SuSe 7.3 PHP Version: CVS Download New Comment: The script posted here does not crash for me with the latest CVS (27-03-2002). Can you try a snapshot from snaps.php.net? Derick Previous Comments: [2002-03-07 18:53:46] [EMAIL PROTECTED] I've commented out the offending lines in the source. You can pull it from CVS at any time. I'll also see if we can get it into the 4.2.0 release. Thanks for bringing it up again. [2002-03-07 17:59:06] [EMAIL PROTECTED] beware: the bug is marked as closed, but a fix has not been applied to cvs yet. [2002-02-19 15:16:27] [EMAIL PROTECTED] The patch from [EMAIL PROTECTED] worked on my Server. Hope it will be soon in the CVS Version [2002-02-19 13:43:50] [EMAIL PROTECTED] This patch against latest CVS should fix it: (basically it makes domxml not free a node on unlink and rather wait for request shutdown to free a node). btw, this patch also enables a domxml user to re-add a previously unlink()ed node, which is impossible with the current code. regards, -lukas Index: ext/domxml/php_domxml.c === RCS file: /repository/php4/ext/domxml/php_domxml.c,v retrieving revision 1.116 diff -u -r1.116 php_domxml.c --- ext/domxml/php_domxml.c 4 Feb 2002 21:07:39 - 1.116 +++ ext/domxml/php_domxml.c 19 Feb 2002 18:38:57 - @@ -1801,8 +1801,6 @@ DOMXML_PARAM_NONE(nodep, id, le_domxmlnodep); xmlUnlinkNode(nodep); - xmlFreeNode(nodep); - zval_dtor(id); /* This is not enough because the children won't be deleted */ } /* }}} */ [2002-02-19 12:23:38] [EMAIL PROTECTED] Nothing happening about the bug? Un Downloading regularly the newest CVS Version but doesnt help 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/14522 -- Edit this bug report at http://bugs.php.net/?id=14522&edit=1
Bug #15948 Updated: Basic Subtraction Error
ID: 15948 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Math Functions Operating System: Red Hat Linux 7.1 PHP Version: 4.0.6 New Comment: This is actually not a bug, but a normal thing with floatingpoint numbers. If you want to do precise calculating, use cents, or decrease the precision in php.ini from 14 to something like 10. Derick Previous Comments: [2002-03-08 02:06:01] [EMAIL PROTECTED] This was submitted by one of our head developers. We're using PHP/MySQL to build our customer relationship software, and this scares me. --- The numbers should add to 0. When I echo the result I get the below: -5.6843418860808E-14. -- Edit this bug report at http://bugs.php.net/?id=15948&edit=1
