Bug #16525 Updated: Cannot open the file: mk:@MSITStore:......
ID: 16525 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Documentation problem Operating System: Windows PHP Version: 4.1.2 New Comment: 1st class Derick, fixed within the hour... I am new to PHP and I heard the community was active, but hey this is fantastic, keep up the good work! Previous Comments: [2002-04-11 02:12:09] [EMAIL PROTECTED] A new one is currently being uploaded, it should be available in one hour again. Derick [2002-04-11 02:03:51] [EMAIL PROTECTED] I have exactly the same problem. After downloading the eglish CHM documentation file, I run it and get the same message: "Cannot open the file: mk:@MSITStore:c:\php_manual_en.chm" I have tried downloading the file to different computers and still get the same problem. Rich [2002-04-10 03:07:26] [EMAIL PROTECTED] Additional: OS Windows2000 What I do? I copy to c:\ file php_manual_en.chm and double click to on it. More appear popup window, in title whitch word "Help" and in body message "Cannot open the file: mk:@MSITStore:C:\php_manual_en.chm" and one button "Ok". I press button "Ok" and nothing not appear. [2002-04-10 02:26:24] [EMAIL PROTECTED] Please check if it is in a directory with no # or any other URL special character in the name. Goba [2002-04-10 02:00:27] [EMAIL PROTECTED] I just download Windows HTML Help file (Size: 5288Kb Date: 9 Apr 2002) from http://www.php.net/download-docs.php?sizes=1, but I don't can to see it. When I try to see (run) he, appear popup window asked next: Cannot open the file: mk:@MSITStore:.. -- Edit this bug report at http://bugs.php.net/?id=16525&edit=1
Bug #16540 Updated: variables still exist after loading to a new page
ID: 16540
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Variables related
Operating System: win2K
PHP Version: 4.1.2
New Comment:
The variables value stay empty after logout and will remain empty
forever eventhough you try to login again with different value of
username and password
Previous Comments:
[2002-04-11 02:17:58] [EMAIL PROTECTED]
Below is the short script that produce quite stupid logics :)
//*** start here
$header =
"BUGS";
$min = 4;
$log = "";
$log .= "Username";
$log .= "Password ";
$log .= "Keep me loged-in into
this MUMZ unless I logout.";
$log .= "Do
nothing.";
if((isset($HTTP_POST_VARS["mumzu"]) && isset($HTTP_POST_VARS["mumzp"])
&& isset($HTTP_POST_VARS["mumzr"])) ||
(isset($HTTP_COOKIE_VARS["mumzu"]) && isset($HTTP_COOKIE_VARS["mumzp"])
&& isset($HTTP_COOKIE_VARS["mumzr"])))
{
if(!isset($p))
{
$m = 30;
$lifetime = time() + ($m * 60);
setcookie("mumzu", $mumzu, $lifetime);
setcookie("mumzp", $mumzp, $lifetime);
setcookie("mumzr", $mumzr, $lifetime);
echo $header;
echo "this is Restricted areaclick here to logout";
}
else if(isset($p) && $p == "logout")
{
setcookie("mumzu");
setcookie("mumzp");
setcookie("mumzr");
echo $header;
echo "Here is the bug: the 3 variabels mumzu,
mumzp, mumzr suppoused to be disapeared after clicking the link
below.And logically since there is no any existing variables it
suppoused to display login form instead restricted area
again";
echo "you have been loged out click here to
login again";
}
else
{
setcookie("mumzu");
setcookie("mumzp");
setcookie("mumzr");
echo $header;
echo "Bad username or password";
echo $log;
}
}
else
echo $header.$log;
if(isset($mumzu))
echo "username: \"$mumzu\" , pass: \"$mumzp\", cookie mumzp:
".@$HTTP_COOKIE_VARS["mumzp"];
echo "";
//***End of Line
--
Edit this bug report at http://bugs.php.net/?id=16540&edit=1
Bug #15940 Updated: Segmentation fault (11)
ID: 15940 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: Linux PHP Version: 4.1.2 New Comment: It happens here also. I tried with several apache version, but the error is the same. I have to restart apache on hourly basis. With 4.06 it worked for months. Previous Comments: [2002-03-19 10:04:41] [EMAIL PROTECTED] Check out bug-report #14529, talking about propably the same problems there [2002-03-19 06:41:49] [EMAIL PROTECTED] Had the same problems as described in first post in this thread. We tried an older apache, 1.3.20. This doesn't help, same problems occur: the stopping of php-parsing in the middle or end of an echo-command, and the exited on signal 11 message in var/log/messages. Our php 4.1.2 configuration: './configure' '--with-mysql=/usr/local' '--with-postgres=/usr/local/pgsql' '--with-gnu-ld' '--with-libz' '--with-bz2' '--with-gdbm' '--with-ndbm' '--with-gd' '--with-openssl' '--with-mm' '--enable-sysvsem' '--enable-sysvshm' '--with-mhash' '--with-mcrypt' '--with-apache=../apache_1.3.20' We tried an older version of Apache, because this seemed the only difference to another server where no exited-on-signal-11-messages were found in the /var/log/messages-file. Didn't look at the difference in load though, shall ask our administrators about this. [2002-03-13 06:12:16] [EMAIL PROTECTED] I should mention that the problems occurs even if there is no call to Interbase at all. In our case we saw it happen in an index.php file which gets some session values and sets some constants base on the environment. It then creates html/javascript to open a new browser window. This didn't happen as the rendering ended inmidst the javascript code. Only after this is Interbase involved. [2002-03-13 04:03:07] [EMAIL PROTECTED] I found that if you pass the wrong type of object to ibase_free_result or ibase_free_query you cause the Apache child running the PHP script to segfault. So, for example, if I create a query object and then later pass it to ibase_free_result I guarantee that the Apache child segfaults. Maybe an object check should take place inside the ibase_free_result to see that it was actually passed a result rather than a query object. Like one of the other people reporting this bug, the page renders to a point and then (I guess when Apache dies) no more of the document is returned. I spent a week trying to solve this problem and it manifests itself in 4.1.1 and 4.1.2. I'm running Red Hat 7.2 with Apache 1.3.20. PHP was built using a very long set of options - if they are required please e-mail me and I will send them. I'm running PHP as an Apache module without the CGI option. [2002-03-08 08:23:52] [EMAIL PROTECTED] [root@trex dev]# gdb /usr/sbin/httpd GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) 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: /usr/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x40430c7c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x40430c7c in memcpy () from /lib/i686/libc.so.6 #1 0x in __strtol_internal (nptr=0x0, endptr=0x0, base=165, group=128) PHP was compiled with: ./configure --without-mysql --with-imap --with-imap-ssl --with-interbase --with-pgsql --with-kerberos --with-gettext --with-xml --with-apache=../apache_1.3.23/ --enable-track-vars --enable-debug 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/15940 -- Edit this bug report at http://bugs.php.net/?id=15940&edit=1
Bug #16540: variables still exist after loading to a new page
From: [EMAIL PROTECTED]
Operating system: win2K
PHP version: 4.1.2
PHP Bug Type: Variables related
Bug description: variables still exist after loading to a new page
Below is the short script that produce quite stupid logics :)
//*** start here
$header =
"BUGS";
$min = 4;
$log = "";
$log .= "Username";
$log .= "Password ";
$log .= "Keep me loged-in into
this MUMZ unless I logout.";
$log .= "Do
nothing.";
if((isset($HTTP_POST_VARS["mumzu"]) && isset($HTTP_POST_VARS["mumzp"]) &&
isset($HTTP_POST_VARS["mumzr"])) || (isset($HTTP_COOKIE_VARS["mumzu"]) &&
isset($HTTP_COOKIE_VARS["mumzp"]) && isset($HTTP_COOKIE_VARS["mumzr"])))
{
if(!isset($p))
{
$m = 30;
$lifetime = time() + ($m * 60);
setcookie("mumzu", $mumzu, $lifetime);
setcookie("mumzp", $mumzp, $lifetime);
setcookie("mumzr", $mumzr, $lifetime);
echo $header;
echo "this is Restricted areaclick here to logout";
}
else if(isset($p) && $p == "logout")
{
setcookie("mumzu");
setcookie("mumzp");
setcookie("mumzr");
echo $header;
echo "Here is the bug: the 3 variabels mumzu,
mumzp, mumzr suppoused to be disapeared after clicking the link
below.And logically since there is no any existing variables it
suppoused to display login form instead restricted area
again";
echo "you have been loged out click here to
login again";
}
else
{
setcookie("mumzu");
setcookie("mumzp");
setcookie("mumzr");
echo $header;
echo "Bad username or password";
echo $log;
}
}
else
echo $header.$log;
if(isset($mumzu))
echo "username: \"$mumzu\" , pass: \"$mumzp\", cookie mumzp:
".@$HTTP_COOKIE_VARS["mumzp"];
echo "";
//***End of Line
--
Edit bug report at http://bugs.php.net/?id=16540&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16540&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16540&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16540&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16540&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16540&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16540&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16540&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16540&r=submittedtwice
Bug #16525 Updated: Cannot open the file: mk:@MSITStore:......
ID: 16525 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Documentation problem Operating System: Windows PHP Version: 4.1.2 New Comment: A new one is currently being uploaded, it should be available in one hour again. Derick Previous Comments: [2002-04-11 02:03:51] [EMAIL PROTECTED] I have exactly the same problem. After downloading the eglish CHM documentation file, I run it and get the same message: "Cannot open the file: mk:@MSITStore:c:\php_manual_en.chm" I have tried downloading the file to different computers and still get the same problem. Rich [2002-04-10 03:07:26] [EMAIL PROTECTED] Additional: OS Windows2000 What I do? I copy to c:\ file php_manual_en.chm and double click to on it. More appear popup window, in title whitch word "Help" and in body message "Cannot open the file: mk:@MSITStore:C:\php_manual_en.chm" and one button "Ok". I press button "Ok" and nothing not appear. [2002-04-10 02:26:24] [EMAIL PROTECTED] Please check if it is in a directory with no # or any other URL special character in the name. Goba [2002-04-10 02:00:27] [EMAIL PROTECTED] I just download Windows HTML Help file (Size: 5288Kb Date: 9 Apr 2002) from http://www.php.net/download-docs.php?sizes=1, but I don't can to see it. When I try to see (run) he, appear popup window asked next: Cannot open the file: mk:@MSITStore:.. -- Edit this bug report at http://bugs.php.net/?id=16525&edit=1
Bug #16525 Updated: Cannot open the file: mk:@MSITStore:......
ID: 16525 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Documentation problem Operating System: Windows PHP Version: 4.1.2 New Comment: I have exactly the same problem. After downloading the eglish CHM documentation file, I run it and get the same message: "Cannot open the file: mk:@MSITStore:c:\php_manual_en.chm" I have tried downloading the file to different computers and still get the same problem. Rich Previous Comments: [2002-04-10 03:07:26] [EMAIL PROTECTED] Additional: OS Windows2000 What I do? I copy to c:\ file php_manual_en.chm and double click to on it. More appear popup window, in title whitch word "Help" and in body message "Cannot open the file: mk:@MSITStore:C:\php_manual_en.chm" and one button "Ok". I press button "Ok" and nothing not appear. [2002-04-10 02:26:24] [EMAIL PROTECTED] Please check if it is in a directory with no # or any other URL special character in the name. Goba [2002-04-10 02:00:27] [EMAIL PROTECTED] I just download Windows HTML Help file (Size: 5288Kb Date: 9 Apr 2002) from http://www.php.net/download-docs.php?sizes=1, but I don't can to see it. When I try to see (run) he, appear popup window asked next: Cannot open the file: mk:@MSITStore:.. -- Edit this bug report at http://bugs.php.net/?id=16525&edit=1
Bug #12508 Updated: can't return a ntext type field in a select statement
ID: 12508 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.0.6 New Comment: I think this could be duplicate of #10114 or caused by same problem. Actualy Gustav's work around make me free from the error, but the return value was not fetched correctly. NULL is the always result for all fields. And, this workaround could be Ok for ODBC function only. Not succeeded at mssql functions. Previous Comments: [2002-01-10 07:15:46] [EMAIL PROTECTED] I found a good work around. Insert following SQL query after connecting to the MSSQL database: SET TEXTSIZE 10 or to your estimated max size, which should be the same as defined in odbc_longreadlen (), if MSSQL is accessed through ODBC, which I prefer, because the PHP mssql functions don't return my german umlaute correctly. hope this helps gustav graf [2001-08-01 04:44:03] [EMAIL PROTECTED] selecting a ntext type field using mssql_query produces the following error message MS SQL message: ntext data cannot be sent to clients using DB-Library (such as ISQL) or ODBC version 3.7 or earlier. (severity 16) -- Edit this bug report at http://bugs.php.net/?id=12508&edit=1
Bug #13798 Updated: Compilation error with oracle
ID: 13798 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: SYSTEM V 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-03-03 02:53:25] [EMAIL PROTECTED] To properly diagnose this bug, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". can you please try a recent release? [2001-10-23 07:30:38] [EMAIL PROTECTED] I want to install PHP-4.0.6 on my system (SYSTEM V NCR) with apache-1.3.19. I use this command : ./configure --without-mysql --with-oracle --with-apache=../apache_1.3.19 --enable-track-vars This product this debug.log : m -ldl -lnsl -lsocket 1>&5 NCR High Performance C Compiler R3.0c (c) Copyright 1994-98, NCR Corporation (c) Copyright 1987-98, MetaWare Incorporated UX:ld: WARNING: /usr/lib/libresolv.so: warning: attempted multiple inclusion of file UX:ld: WARNING: /usr/lib/libresolv.so: warning: attempted multiple inclusion of file UX:ld: WARNING: /usr/lib/libnsl.so: warning: attempted multiple inclusion of fil e UX:ld: WARNING: /usr/lib/libsocket.so: warning: attempted multiple inclusion of file dynamic linker : ./conftest : error opening libclntsh.so.1.0 And produce this errors in the config.log file : -- configure:1916: checking whether cc accepts -g configure:1948: checking how to run the C preprocessor configure:1969: cc -E conftest.c >/dev/null 2>conftest.out NCR High Performance C Compiler R3.0c (c) Copyright 1994-98, NCR Corporation (c) Copyright 1987-98, MetaWare Incorporated configure: failed program was: #line 1963 "configure" #include "confdefs.h" #include Syntax Error configure:1986: cc -E -traditional-cpp conftest.c >/dev/null 2>conftest.out (cc:) Warning: -a (within -traditional-cpp) is not a recognizable option. (cc:) Warning: -d (within -traditional-cpp) is not a recognizable option. (cc:) Warning: -i (within -traditional-cpp) is not a recognizable option. (cc:) Warning: -i (within -traditional-cpp) is not a recognizable option. (cc:) Warning: -o (within -traditional-cpp) is not a recognizable option. (cc:) Warning: -n (within -traditional-cpp) is not a recognizable option. (cc:) Warning: -a (within -traditional-cpp) is not a recognizable option. (cc:) Warning: -l (within -traditional-cpp) is not a recognizable option. And next : configure:2455: cc -c conftest.c 1>&5 NCR High Performance C Compiler R3.0c (c) Copyright 1994-98, NCR Corporation (c) Copyright 1987-98, MetaWare Incorporated configure:2572: cc -o conftestconftest.c 1>&5 NCR High Performance C Compiler R3.0c (c) Copyright 1994-98, NCR Corporation (c) Copyright 1987-98, MetaWare Incorporated E "/usr/include/pthread.h",L110/C1: Can't open "dce/cma.h": No such file or directory w (#657): (info) How referenced files were included: |File /usr/include/pthread.h from configure. Unable to proceed Aborting(21)... configure: failed program was: #line 2554 "configure" -- When I run make, i have this mistake --- Making all in posix cc -I. -I/app/apache/php-4.0.6/ext/posix -I/app/apache/php-4.0.6/main - I/app/apache/php-4.0.6 -I/app/apache/apache_1.3.19/src/include -I/app/apache/apa che_1.3.19/src/os/unix -I/app/apache/php-4.0.6/Zend -I/app/oracle/product/734/rd bms/public -I/app/oracle/product/734/rdbms/demo -I/app/oracle/product/734/networ k/public -I/app/apache/php-4.0.6/ext/xml/expat/xmltok -I/app/apache/php-4.0.6/ex t/xml/expat/xmlparse -I/app/apache/php-4.0.6/TSRM -DSUPPORT_UTF8 -DXML_BYTE_ORD ER=21 -c posix.c && touch posix.lo NCR High Performance C Compiler R3.0c (c) Copyright 1994-98, NCR Corporation (c) Copyright 1987-98, MetaWare Incorporated w "/app/apache/php-4.0.6/Zend/zend_execute.h",L185/C5(#257):'=' encountered where '==' may have been intended. w "/app/apache/php-4.0.6/Zend/zend_execute.h",L198/C4(#257):'=' encountered where '==' may have been intended. w "/app/apache/php-4.0.6/ext/standard/php_string.h",L125/C5(#257): '=' enco untered where '==' may have been intended. E "posix.
Bug #16523 Updated: $variable = ibase_query fails
ID: 16523 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: InterBase related Operating System: linux (2.4.18, slackware 8) -PHP Version: 4.1.2 +PHP Version: 4.2.0RC2 New Comment: tried just the interbase.c file, didn't compile. tried all of 4.2.0RC2 from the QA website -- installs fine. (the test page will reveal that's what's running.) problem persists. the initial_fail.php script will still abort without sending a response. initial_test.php still works. any good ideas? a test script i could run to see if it's just me, the database server, the install of php, or something else entirely? Previous Comments: [2002-04-10 14:26:18] [EMAIL PROTECTED] i'll try the interbase.c thing, but if it's the change i've seen mentioned elsewhere in the recent bug reports/fixes (something about the "i've been naughty" section, changing what gets freed, etc.) then we've already got it (based on the diff i saw -- the links posted to it on cvs.something wouldn't work, 404.) but i will try it, just in case. is 4.2 stable enough to use? or is -only- the interbase.c the part i want? and yes, i have looked at the documentation. in several languages in fact (amusing that in french, the example stays the same, with translated text around it.) i found a few pages that had correct brackets for optional parameters (php.net's documentation on ibase_* is somewhat lacking in specifics.) i still think the problem is centered around the return value from ibase_query: if i don't try to assign it to a variable, the script does connect, and it does get a value back from the database (so it's not something simple like a username/password problem.) the documentation says that ibase_connect, ibase_trans, ibase_query, etc. pretty much all return "int" but no integer i've ever seen when echoed says "Resource #3" ... also, i have no problem assigning the return value from the two other functions, both of which also return resources (integers, ha!) am i missing anything else? i'll give interbase.c a whirl, and if that doesn't work, i might even upgrade to 4.2 all-around (might as well.) heck, i've got another server being setup, won't hurt it to try stuff out. [2002-04-10 11:52:36] [EMAIL PROTECTED] May you upgrade your interbase.c with that one in RC2 at www.php.net/~derick ? and ... have you already look at http://www.php.net/manual/en/function.ibase-connect.php there is an example showing how to loop in a resultset Daniela [2002-04-10 10:50:38] [EMAIL PROTECTED] sure =) here are links to: #the test, working (no returned value from function being assigned to variable) both in working form and in viewable form: http://www.csmaster.org/art/initial_test.php http://www.csmaster.org/art/initial_test.phps #same script, with the line uncommented (attempt to store the returned value from ibase_query()) http://www.csmaster.org/art/initial_fail.php http://www.csmaster.org/art/initial_fail.phps #still available, server info http://www.csmaster.org/test.php you're welcome to connect to the database as shown, the firebird server should be accessible from the outside (and i just made a copy in case someone gets fancy.) i know there's a lot of junk in those, but we spent a few hours trying various things, which all sorta wound up in the same file, to get it to let us do simple queries. it's my first time using php, but not firebird. [2002-04-10 05:41:42] [EMAIL PROTECTED] I cannot reproduce it. Could you provide a little test script, please? [2002-04-10 01:16:34] [EMAIL PROTECTED] // successful: $stuff = ibase_fetch_row (ibase_query($sql_string)); # we can get $stuff[0], rows are being returned // not successful: $thingie = ibase_query($sql_string); # same statement, same file -- won't work. # if we comment this line out, the one above will work. # if this line does get executed, it fails. we can, for # that matter, grab the returned value and echo it! but # if for the life of us we try to assign it -into- a # variable so we can call ibase_fetch_row multiple times # (kinda handy) the script won't run. // i'm not the sysadmin, but i'll try to get any info that would help out. we're talking to Firebird 1.0 (which supports all of Interbase 6.0's communications protocols) and i've not had any problems with the interbase->firebird conversion in other situations. also tested: ibase_prepare gives us the same problem. if the return value is encapsulated in the call to ibase_execute, the script doesn't crash.
Bug #13993 Updated: eval() parse errors not using error_handler
ID: 13993
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
Operating System: Redhat Linux 7.1
PHP Version: 4.0.6
New Comment:
I have the same problem - would be a very nice feature to be able to
catch errors in eval statements.
Previous Comments:
[2001-11-10 15:00:10] [EMAIL PROTECTED]
Reopening as a feature-request.
[2001-11-10 12:24:47] [EMAIL PROTECTED]
Parse errors are never handled by set_error_handler().
[2001-11-08 15:30:54] [EMAIL PROTECTED]
I'm trying to validate some dynamically generated PHP code using
eval()
set_error_handler('eval_error');
eval($php_code);
restore_error_handler();
problem: if $php_code contains a parse error, the error is not
reported using the eval_error() function, but uses the generic error
handler.
--
Edit this bug report at http://bugs.php.net/?id=13993&edit=1
Bug #16337 Updated: include() does not decode anything in username:password@ pairs
ID: 16337
Updated by: [EMAIL PROTECTED]
-Summary: include() does not decode % correctly
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: HTTP related
Operating System: Unix based
PHP Version: 4.1.0
New Comment:
in case anyone wondered, the HTTP spec I am refering to, is at:
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html
(Section 11.1)
Since RFC 2616 doesn't specify user-pass strings, I assume this older
RFC still applies.
Previous Comments:
[2002-04-10 19:57:48] [EMAIL PROTECTED]
Correction:
PHP's fopen url wrapper doesn't appear to unencode ANY encodings at
all. Since the HTTP spec only excludes ':' from the username (and
nothing at all from the password), this bug makes many
username:password pairs unusable.
[2002-03-28 18:12:28] [EMAIL PROTECTED]
When include() is called with the following syntax:
include("http://username:[EMAIL PROTECTED]/";);
It is the duty of the include call to tokenize the username and
password, and to urldecode each of them. Why? Because things would
break if a username contained 'www.example.com/?var=' or say a
password contained an @. So, it is the duty of the caller to urlencode
these tokens, and the duty of include (or a sub function) to unencode
it after parsing.
However, it has been observed in PHP 4.1.x that '%' characters (or
their equivalent '%25') are not decoded properly. Prior use of this
feature leads us to believe the 4.0.x series of PHP does not have this
problem.
We run websites with hundreds of users. We would appreciate a quick
response, because we would rather not force all users with '%'s in
their passwords to change them. Thank you.
--
Edit this bug report at http://bugs.php.net/?id=16337&edit=1
Bug #16337 Updated: include() does not decode % correctly
ID: 16337
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: HTTP related
Operating System: Unix based
PHP Version: 4.1.0
New Comment:
Correction:
PHP's fopen url wrapper doesn't appear to unencode ANY encodings at
all. Since the HTTP spec only excludes ':' from the username (and
nothing at all from the password), this bug makes many
username:password pairs unusable.
Previous Comments:
[2002-03-28 18:12:28] [EMAIL PROTECTED]
When include() is called with the following syntax:
include("http://username:[EMAIL PROTECTED]/";);
It is the duty of the include call to tokenize the username and
password, and to urldecode each of them. Why? Because things would
break if a username contained 'www.example.com/?var=' or say a
password contained an @. So, it is the duty of the caller to urlencode
these tokens, and the duty of include (or a sub function) to unencode
it after parsing.
However, it has been observed in PHP 4.1.x that '%' characters (or
their equivalent '%25') are not decoded properly. Prior use of this
feature leads us to believe the 4.0.x series of PHP does not have this
problem.
We run websites with hundreds of users. We would appreciate a quick
response, because we would rather not force all users with '%'s in
their passwords to change them. Thank you.
--
Edit this bug report at http://bugs.php.net/?id=16337&edit=1
Bug #16084 Updated: DLLs in the standard distribution using zlib need to be updated
ID: 16084 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: Zlib Related Operating System: Windows (any) PHP Version: 4.0.5 New Comment: Changed status to critical so the people who build these extensions make sure to use the new zlib. Previous Comments: [2002-03-14 17:15:29] [EMAIL PROTECTED] The following DLLs in the standard, supported Win32 binary distribution appear to use ZLib, and need to be recompiled and repackaged, because a serious bug has been found in the deflate algorythm: php_cpdf.dll php_gd.dll php_pdf.dll php_zlib.dll Full information on the bug can be found in the related CERT advisory: http://www.kb.cert.org/vuls/id/368819 The updated zlib can be downloaded from its home page: http://www.gzip.org/zlib/ PS: sorry if this has been reported twice. However, I didn't find this bug in the database -- Edit this bug report at http://bugs.php.net/?id=16084&edit=1
Bug #15799 Updated: Another segfault on iconv
ID: 15799
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: ICONV related
Operating System: Linux
PHP Version: 4.0CVS-2002-02-2
New Comment:
fyi..I can't reproduce this on Linux with latest CVS
and with libiconv 1.3.
Previous Comments:
[2002-03-12 01:19:33] [EMAIL PROTECTED]
Yes true ... weird. Upon taking a closer look it seems the iconv fails
with 'Invalid or incomplete multibyte or wide character' but the error
code is not properly handled in the code in the first and therefore not
recognized. Will take a closer look later (this day ;).
Maybe you can verify if your input data really without errors?
[2002-03-11 17:40:44] [EMAIL PROTECTED]
Ah, you're right, I thought all ob_* functions that return or output
the buffer pass the data through the ob_handler first.
But even if I use it the intended way, the output is not converted.
This is the new script I used:
www.yahoo.com.tw
END;
iconv_set_encoding('input_encoding', 'BIG5');
iconv_set_encoding('internal_encoding', 'UTF-8');
iconv_set_encoding('output_encoding', 'UTF-8');
ob_start('ob_iconv_handler');
echo $text;
header('Content-Type: text/plain; charset=UTF-8');
ob_end_flush();
?>
[2002-03-11 17:10:02] [EMAIL PROTECTED]
I'm closing this because I think your code is bogus. The manual clearly
says "The function ("ob_iconv_handler") will be called when
ob_end_flush() is called, or when the output buffer is flushed to the
browser at the end of the request."
So, if you call ob_get_contents() and ob_end_clean() you do not get any
conversion. If you either call ob_end_flush() or just don't call any
further ob*() functions the conversion works as expected for me.
Feel free to re-open if you think I'm wrong.
[2002-03-11 05:58:19] [EMAIL PROTECTED]
Yep, saw it. Will fix this later (this day).
[2002-03-11 05:18:13] [EMAIL PROTECTED]
I see you already committed the patch to cvs and, yes, php doesn't
segfault anymore, thanks.
But unfortunately the conversion doesn't happen at all. You can try the
same script I posted earlier to reproduce it. Method 1 converts
correctly, method 2 just send the Big5 data asis.
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/15799
--
Edit this bug report at http://bugs.php.net/?id=15799&edit=1
Bug #12919 Updated: Server crashes
ID: 12919 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: IIS related Operating System: NT4 sp6 PHP Version: 4.0.6 New Comment: The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Previous Comments: [2001-08-23 09:13:18] [EMAIL PROTECTED] From: "Maartense, Patrick [JACAT]" <[EMAIL PROTECTED]> Darn I can not give the reply as I have no Pwd for that ID This happens with ISAPI As far as I remember we also had this when not loading the ORACLE api. Ok, marking this one as duplicate, then. There are lots of other bug reports about access violations with IIS, and some of them have more info IIRC. BTW, can someone please fix the bug db so that it rejects posts w/o passwords? [2001-08-23 07:39:25] [EMAIL PROTECTED] CGI or ISAPI? Does it happen with the php_oracle.dll turned off (commented out in php.ini)? [2001-08-23 07:37:09] [EMAIL PROTECTED] After some time the IIS server craches with following description in the LOG The HTTP server encountered an unhandled exception while processing the ISAPI Application ' php4ts!php_execute_script + 0x60'. on the browserscreen following message is visible PHP has encountered an Access Violation at 0388581f Only loaded: extension=php_oracle.dll -- Edit this bug report at http://bugs.php.net/?id=12919&edit=1
Bug #14456 Updated: mcrypt_create_iv: unterminated string & segfault
ID: 14456
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Closed
Bug Type: mcrypt related
Operating System: Linux 2.2.X
PHP Version: 4.1.0
Assigned To: derick
Previous Comments:
[2001-12-12 15:48:48] [EMAIL PROTECTED]
dup of #14236
[2001-12-12 09:15:33] [EMAIL PROTECTED]
Already known
[2001-12-12 09:05:56] [EMAIL PROTECTED]
mcrypt_create_iv(mcrypt_get_iv_size (MCRYPT_DES , MCRYPT_MODE_ECB),
MCRYPT_RAND) produces following error and causes apache to segfault:
Warning - String is not zero-terminated
source: zend_execute_API.c:274
Workaround:
Replace the mcrypt_create_iv call with:
$fp = fopen("/dev/random", "r");
$iv = fread($fp, mcrypt_get_iv_size (MCRYPT_DES ,
MCRYPT_MODE_ECB));
fclose($fp);
Better: Should be fixed.
--
Edit this bug report at http://bugs.php.net/?id=14456&edit=1
Bug #12756 Updated: Downloadable HTML Docs - Filenames should be limited to 31 chars.
ID: 12756 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type:Documentation problem PHP Version: 4.0.6 New Comment: see #10862 for more info. Previous Comments: [2001-10-10 08:43:54] [EMAIL PROTECTED] Duplicate of 10862 [2001-08-15 04:38:48] [EMAIL PROTECTED] Downloadable HTML Docs - Filenames should be limited to 31 chars. Note that when the HTML version of the docs are downloaded, they do not work on a Macintosh, because some of the filenames are over the 31 character limit. This means that when the zip file is extracted that the filenames get cropped, so the links to those pages do not work. For example, this is too long: language.basic-syntax.instruction-separation.php -- Edit this bug report at http://bugs.php.net/?id=12756&edit=1
Bug #13998 Updated: + in commandline disappears
ID: 13998 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Unknown/Other Function Operating System: windows 2000 - apache server PHP Version: 4.0.6 New Comment: see #12219 for explanation. Previous Comments: [2001-11-12 02:46:19] [EMAIL PROTECTED] I'm sorry, but I've read that page and I don't see anything about this problem. Not even in the notes. [2001-11-09 12:13:55] [EMAIL PROTECTED] Or, if you meant that an url like http://localhost/file.php?var=foo+bar resulted in $var being "foo bar", RTM: http://www.php.net/manual/en/language.variables.external.php [2001-11-09 12:10:41] [EMAIL PROTECTED] Dupe of #12219 [2001-11-09 11:46:05] [EMAIL PROTECTED] If I echo the query_string, I get: case=1&file_id=file_35&id=35&name=Grondplan%20T+1.jpg&ftype=drawing but when I ask the following: echo $name; it gives me: Grondplan T 1.jpg the + has disappeared. can anyone help me. -- Edit this bug report at http://bugs.php.net/?id=13998&edit=1
Bug #13990 Updated: Command line Input Problems with '+'
ID: 13990
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Closed
Bug Type: Strings related
Operating System: GNU/Linux Debian SID
PHP Version: 4.1.0RC1
Previous Comments:
[2001-11-09 12:16:37] [EMAIL PROTECTED]
Dupe of #12219
[2001-11-08 10:12:59] [EMAIL PROTECTED]
I use Debian/SIDs standard php4 as of 08/11/2001
Here is the Script to reproduce the Problem:
When I call the script like this:
nsn@nsn:~ > php4 -q test.php a+b
var_dump tells me I gave the Script 2 Parameters (a and b)
Actually I gave it 1 Parameter ('a+b').
I think PHP url-decodes the argvs before interpretion, but when I call
the Script like this:
nsn@nsn:~ > php4 -q test.php a%2bb (with %2b being the url-endoded
String for +) PHP does not url-decode the String properly.
As it seems it is not possible to send a string containing the
character '+' to PHP on the command line.
please excuse my rather bad english
regards
Michael Bayer [[EMAIL PROTECTED]]
--
Edit this bug report at http://bugs.php.net/?id=13990&edit=1
Bug #14170 Updated: #!/path/to/php shows up on every php script
ID: 14170 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: *General Issues Operating System: Linux RH 7.1 PHP Version: 4.0CVS-2001-11-22 Previous Comments: [2001-11-22 15:17:15] [EMAIL PROTECTED] Duplicate of #9041 [2001-11-22 13:00:33] [EMAIL PROTECTED] No, the point is if you run a script as a conventional CGI-script (just like you can run shell scripts through CGI), the line with #!/path/to/php shows up... Normally, if you run PHP as CGI via Apache, some lines in httpd.conf say that *.php should be parsed through /usr/local/bin/php It's not necessary to use that. Alternatively, you could use #!/path/to/php if the server has (plain) CGI enabled. It's usefull i.e. if you have built a dev-version of PHP somewhere and don't want to install it, but just use it for a few scripts to test new functionality. And about magic stuff: the patch which hides #! when running via the command line, has already been commited... isn't that magic too? Workaround: enable output buffering in your php.ini and start your scripts with ob_end_clean();. [2001-11-22 12:23:30] [EMAIL PROTECTED] Err ... whats the point of using this in a CGI? I understand, some kind of portability probably (running it from CMD and CGI) but this is some dirty magic stuff IMHO. Its just a text file which gets processed and when it starts with #! then it starts with #! and therefore the output shall be #!. However, I've an open mind for that :) [2001-11-22 10:54:56] [EMAIL PROTECTED] Sounds like a misconfiguration to me. [2001-11-22 10:50:49] [EMAIL PROTECTED] Nope, this bug only shows up if you run it through CGI. Running from the command-line works fine. 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/14170 -- Edit this bug report at http://bugs.php.net/?id=14170&edit=1
Bug #15002 Updated: apache CRASHES on duplicate cookie and session_var
ID: 15002 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Session related Operating System: win2k PHP Version: 4.1.1 Previous Comments: [2002-01-13 09:58:08] [EMAIL PROTECTED] i take it back :( was a dupe after all. sorry for wasting your time. [2002-01-12 06:30:17] [EMAIL PROTECTED] nope. no dupe! 14453 was regarding a wrong path for the session.save_path setting. this is a different bug =/ [2002-01-12 05:55:02] [EMAIL PROTECTED] Very likely to be a dupe of #14453. If not, reopen this report. [2002-01-11 16:29:31] [EMAIL PROTECTED] the following code will crash apache(1.3.22 with php 4.1.1 running as a module on Win2K Hebrew Enabaled) -- Edit this bug report at http://bugs.php.net/?id=15002&edit=1
Bug #15237 Updated: PHP crashes when save path is invalid
ID: 15237
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Closed
Bug Type: Session related
Operating System: Win2k Prof (RUS) SP1
PHP Version: 4.1.1 (original win binaries)
New Comment:
this should be fixed..please try the php 4.2.0RC2 from
http://www.php.net/~derick/ and reopen if it still crashes.
Previous Comments:
[2002-01-27 21:18:01] [EMAIL PROTECTED]
Dup.
PHP crashes when save path is invalid
[2002-01-27 19:21:17] [EMAIL PROTECTED]
//sorry, here's the line:
//
session_start();
// will cause fault on my system
// if (php.ini{session.save_path}) == INVALID
// In other words when session.save_path directory of php.ini doesn't
exist.
[2002-01-27 05:18:23] [EMAIL PROTECTED]
Can you track down the problem to a few lines of code?
[2002-01-26 17:20:59] [EMAIL PROTECTED]
I've got some PHP script (not written by me) which causes latest PHP
crash on my system:
Win2K Professional (RUS) SP1 5.00.2195
The scripts constists of several files available in archive at
http://www.chat.ru/~olegpro2000/forum.zip
Run
php forum.php
to reproduce crash (php4ts.dll will crash)
Regards, Oleg.
--
Edit this bug report at http://bugs.php.net/?id=15237&edit=1
Bug #16240 Updated: Session variable not passing between pages
ID: 16240 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Session related Operating System: Debian Linux PPC and Win2K PHP Version: 4.1.2 New Comment: Please try the PHP 4.2.0RC2 from http://www.php.net/~derick/ and reopen if this still fails. Previous Comments: [2002-03-24 05:35:19] [EMAIL PROTECTED] status->dupe [2002-03-23 20:29:45] [EMAIL PROTECTED] Please search bug db first. There are sevral bug reports in db already... [2002-03-23 19:17:32] [EMAIL PROTECTED] I'm having problems with the session_start() and session_register functions working properly in version 4.1.2 on Debian for PPC. After visiting a page that initiates sessions, the session variable shows up fine in the /tmp file (can be viewed by 'cat'), but when another page that uses any of the session variables is visisted, the session file in /tmp is empty. I can't seem to find a workaround (even using $_SESS or $HTTP_SESSION_VARS). The same code works fine on PHP 4.0.6. -- Edit this bug report at http://bugs.php.net/?id=16240&edit=1
Bug #16345 Updated: mysql and header() problem prevent saving session vars(?)
ID: 16345
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Closed
Bug Type: Session related
Operating System: Linux (Debian)
PHP Version: 4.1.1
New Comment:
Please try the PHP 4.2.0RC2 from http://www.php.net/~derick/ and reopen
if it still fails.
Previous Comments:
[2002-03-29 11:09:39] [EMAIL PROTECTED]
This is a duplicate of the session bug found here:
http://bugs.php.net/bug.php?id=16102
[2002-03-29 11:01:01] [EMAIL PROTECTED]
foo.php:
bar.php:
bar.php says "Warning: Undefined index: test"
if i use session_register('test') in foo.php, all works properly
i'm using php as module of Apache/1.3.23
--
Edit this bug report at http://bugs.php.net/?id=16345&edit=1
Bug #16273 Updated: $_SESSION won't work when register_globals is OFF!
ID: 16273 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Session related Operating System: Windows 98 SE German PHP Version: 4.1.2 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-03-25 20:15:36] [EMAIL PROTECTED] Two days ago I installed PHP Version 4.1.2 as CGI on a Win98SE platform with Apache 1.3.20 running as server. I used the php.ini-recommended with register_globals turned OFF and made only minor changes concerning directories and error-display. Migrating my old scripts to the new settings I found that the session management with the superglobal $_SESSION would not work: the session file was created in my session directory (session.save_path=c:\tmp) BUT no session variables were stored in it. Here's a pair of scripts to illustrate: session_1.php: session_2.php'; ?> session_2.php: On activating the link to session_2.php, the following errormessage is displayed: Warning: Undefined index: text in session_2.php on line 3 (Using $HTTP_SESSION_VARS['text'] instead of $_SESSION['text'] leads to the same result.) However, turning register_globals ON and using global variables with session_register(), session_unregister() and session_is_registered() works fine. But that's not really the point of php.ini-recommended, is it? ;-)-: After spending many hours checking my setup, reading the manual and several faqs and finally receiving feedback from other users who have the same problem on the german PHP-mailinglist [EMAIL PROTECTED] and not finding it this bug in your list of reported bugs, I decided to report it. I also thought that this is a rather major problem, since register_globals is to be turned off by default in upcoming versions. Please contact me if you need any additional information - this is the first time I am reporting a bug. Thanx 4 your great work, Robert [2002-03-25 19:53:51] [EMAIL PROTECTED] Two days ago I installed PHP Version 4.1.2 as CGI on a Win98SE platform with Apache 1.3.20 running as server. I used the php.ini-recommended with register_globals turned OFF and made only minor changes concerning directories and error-display. Migrating my old scripts to the new settings I found that the session management with the superglobal $_SESSION would not work: the session file was created in my session directory (session.save_path=c:\tmp) BUT no session variables were stored in it. Here's a pair of scripts to illustrate: session_1.php: session_2.php'; ?> session_2.php: On activating the link to session_2.php, the following errormessage is displayed: Warning: Undefined index: text in session_2.php on line 3 (Using $HTTP_SESSION_VARS['text'] instead of $_SESSION['text'] leads to the same result.) However, turning register_globals ON and using global variables with session_register(), session_unregister() and session_is_registered() works fine. But that's not really the point of php.ini-recommended, is it? ;-)-: After spending many hours checking my setup, reading the manual and several faqs and finally receiving feedback from other users who have the same problem on the german PHP-mailinglist [EMAIL PROTECTED] and not finding it this bug in your list of reported bugs, I decided to report it. I also thought that this is a rather major problem, since register_globals is to be turned off by default in upcoming versions. Please contact me if you need any additional information - this is the first time I am reporting a bug. Thanx 4 your great work, Robert -- Edit this bug report at http://bugs.php.net/?id=16273&edit=1
Bug #16088 Updated: ini_set("session.save_handler", "user") causes segmentation fault
ID: 16088
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Closed
Bug Type: Session related
Operating System: Redhat 7.2
PHP Version: 4.1.2
New Comment:
Please try the latest CVS snapshot from http://snaps.php.net/ and
reopen if it sill crashes.
Previous Comments:
[2002-03-14 20:48:19] [EMAIL PROTECTED]
Further experimentations seems to show that the conflict is actually
having session auto start enabled, and having save_handler set to user
[2002-03-14 19:22:35] [EMAIL PROTECTED]
In my php.ini file I have "session.save_handler = files" for
compatibility reasons (so the other sites on my box will run).
I am developing a site that needs to store sessions in a mysql DB. I
have the session handler running fine when the php.ini file says
session.save_handler = user, but when I try to set it at runtime using
ini_set("session.save_handler", "user"), the child process dies:
'child pid 2167 exit signal Segmentation fault (11)'.
--
Edit this bug report at http://bugs.php.net/?id=16088&edit=1
Bug #16082 Updated: libmm 1.1.3 session save handler = crash
ID: 16082 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Session related Operating System: Linux Redhat 7.1 PHP Version: 4.1.2 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-03-14 15:09:22] [EMAIL PROTECTED] I am trying to get php 4.1.2 working with mm support (libmm 1.1.3) to act as my session save handler. I have a 100% reproducable segfault w/ apache 1.3.23. I have been able to reproduce this on Redhat 7.1 and Mandrake 8.1, with 2 different machines. This happens with and w/o the Zend Optimizer. The gdb stack dump here shows that I was running the Optimizer at the time. My php configure line is as follows: ./configure \ --with-mm=/usr/local \ --with-apxs=/usr/local/apache/bin/apxs \ --disable-debug (normally, I have a bunch of other items in the configure line, but I wanted to narrow the crash down to the least amount of variables) The php script is very simple: Here is the gdb output: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 28561)] 0x402ae4f9 in ps_srlzr_decode_php (val=0x81066ec "", vallen=135269900) at session.c:394 394 if (++q >= endptr) goto break_outer_loop; (gdb) bt #0 0x402ae4f9 in ps_srlzr_decode_php (val=0x81066ec "", vallen=135269900) at session.c:394 #1 0x402ae8b1 in php_session_decode (val=0x81066ec "", vallen=135269900) at session.c:457 #2 0x402aeb03 in php_session_initialize () at session.c:524 #3 0x402afbb2 in php_session_start () at session.c:890 #4 0x402b0e55 in zif_session_start (ht=0, return_value=0x8100dec, this_ptr=0x0, return_value_used=0) at session.c:1264 #5 0x443ef70b in zend_assign_to_variable_reference () from /usr/local/Zend/lib/ZendOptimizer.so #6 0x443f9325 in zend_oe () from /usr/local/Zend/lib/ZendOptimizer.so #7 0x402752e4 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #8 0x40282b85 in php_execute_script (primary_file=0xb440) at main.c:1307 #9 0x4027ecf2 in apache_php_module_main (r=0x80f9a74, display_source_mode=0) at sapi_apache.c:90 #10 0x4027f7ce in send_php (r=0x80f9a74, display_source_mode=0, filename=0x0) at mod_php4.c:575 #11 0x4027f822 in send_parsed_php (r=0x80f9a74) at mod_php4.c:590 #12 0x080727b7 in ap_invoke_handler () #13 0x080869ff in process_request_internal () #14 0x08086a60 in ap_process_request () #15 0x0807de6d in child_main () #16 0x0807e0db in make_child () #17 0x0807e18c in startup_children () #18 0x0807e808 in standalone_main () #19 0x0807f067 in main () #20 0x40111627 in __libc_start_main (main=0x807ecc8 , argc=1, ubp_av=0xb884, init=0x804e760 <_init>, fini=0x809c0c0 <_fini>, rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xb87c) at ../sysdeps/generic/libc-start.c:129 -- Edit this bug report at http://bugs.php.net/?id=16082&edit=1
Bug #16055 Updated: Running 4.1.2 as module in Apache 1.3.2 crashes Apache.exe
ID: 16055 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Session related Operating System: Windows XP Pro PHP Version: 4.1.2 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-03-14 04:58:16] [EMAIL PROTECTED] This is very likely to be caused by an incorrect session.save_path. There's already a report about that. Please reopen if that's not the case. [2002-03-13 22:56:55] [EMAIL PROTECTED] This has been a problem in 4.1.0 and 4.1.2. A simple will crash Apache.exe. OS: Windows XP Pro (I suspect this will happen with any version of Windows) Server: Apache 1.3.2 PHP: 4.1.2, running as module [2002-03-13 22:28:31] [EMAIL PROTECTED] This has been a problem in 4.1.0 and 4.1.2. A simple will crash Apache.exe. OS: Windows XP Pro (I suspect this will happen with any version of Windows) Server: Apache 1.3.2 PHP: 4.1.2, running as module -- Edit this bug report at http://bugs.php.net/?id=16055&edit=1
Bug #15921 Updated: Threads crash while saving current session.
ID: 15921
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Closed
Bug Type: Session related
Operating System: Redhat Linux 7.1
PHP Version: 4.1.2
New Comment:
This bug has been fixed in CVS.
Previous Comments:
[2002-03-06 22:15:24] [EMAIL PROTECTED]
Is there a workaround for it?
[2002-03-06 22:08:58] [EMAIL PROTECTED]
Thanks for the report, but It's known issue.
Easy one to fix, but it's not fixed fully yet.
Status = Duplicate
[2002-03-06 21:54:30] [EMAIL PROTECTED]
I have been able to make this happen on a fairly regular basis using a
user defined session handler..
You can grap the tarball of the session handler at
http://64.81.150.105/session.tar
System is a Redhat 7.1.
MySQL Version 3.23.39
Apache Version 1.3.20
PHP version 4.1.2 as a module
configure line: ./configure --with-mysql
--with-apxs=/usr/local/apache/bin/apxs --with-gd
here is the bt:
Starting program: /usr/local/apache/bin/httpd -X
Program received signal SIGSEGV, Segmentation fault.
zend_hash_internal_pointer_reset_ex (ht=0x3, pos=0xb080) at
zend_hash.c:978
978 *pos = ht->pListHead;
(gdb) bt
#0 zend_hash_internal_pointer_reset_ex (ht=0x3, pos=0xb080) at
zend_hash.c:978
#1 0x40267c5f in php_session_save_current_state () at session.c:544
#2 0x4026a1d2 in php_session_flush () at session.c:1381
#3 0x4026a1f7 in zm_deactivate_session (type=1, module_number=3) at
session.c:1393
#4 0x40228cdd in module_registry_cleanup (module=0x80d9178) at
zend_API.c:1165
#5 0x4022a954 in zend_hash_apply (ht=0x4030f460, apply_func=0x40228cb0
) at zend_hash.c:669
#6 0x402258da in zend_deactivate_modules () at zend.c:585
#7 0x402325ff in php_request_shutdown (dummy=0x0) at main.c:723
#8 0x4022fa8c in apache_php_module_main (r=0x80eee4c,
display_source_mode=0) at sapi_apache.c:96
#9 0x4023050e in send_php (r=0x80eee4c, display_source_mode=0,
filename=0x0) at mod_php4.c:575
#10 0x40230562 in send_parsed_php (r=0x80eee4c) at mod_php4.c:590
#11 0x08054633 in ap_invoke_handler () at eval.c:41
#12 0x08068179 in process_request_internal () at eval.c:41
#13 0x080681dc in ap_process_request () at eval.c:41
#14 0x0805f7ae in child_main () at eval.c:41
#15 0x0805f93c in make_child () at eval.c:41
#16 0x0805fa99 in startup_children () at eval.c:41
#17 0x080600d6 in standalone_main () at eval.c:41
#18 0x08060863 in main () at eval.c:41
#19 0x4008fe5e in __libc_start_main (main=0x806051c , argc=2,
ubp_av=0xbb0c, init=0x804ead0 <_init>,
fini=0x809506c <_fini>, rtld_fini=0x4000d3c4 <_dl_fini>,
stack_end=0xbb04) at ../sysdeps/generic/libc-start.c:129
Starting program: /usr/local/apache/bin/httpd -X
Program received signal SIGSEGV, Segmentation fault.
zend_hash_get_current_key_ex (ht=0x80fbdbc, str_index=0xb074,
str_length=0xb078, num_index=0xb07c, duplicate=0,
pos=0xb080) at zend_hash.c:1035
1035if (p->nKeyLength) {
(gdb) bt
#0 zend_hash_get_current_key_ex (ht=0x80fbdbc, str_index=0xb074,
str_length=0xb078, num_index=0xb07c, duplicate=0,
pos=0xb080) at zend_hash.c:1035
#1 0x40267cb7 in php_session_save_current_state () at session.c:545
#2 0x4026a1d2 in php_session_flush () at session.c:1381
#3 0x4026a1f7 in zm_deactivate_session (type=1, module_number=3) at
session.c:1393
#4 0x40228cdd in module_registry_cleanup (module=0x80d8c10) at
zend_API.c:1165
#5 0x4022a954 in zend_hash_apply (ht=0x4030f460, apply_func=0x40228cb0
) at zend_hash.c:669
#6 0x402258da in zend_deactivate_modules () at zend.c:585
#7 0x402325ff in php_request_shutdown (dummy=0x0) at main.c:723
#8 0x4022fa8c in apache_php_module_main (r=0x80ee8fc,
display_source_mode=0) at sapi_apache.c:96
#9 0x4023050e in send_php (r=0x80ee8fc, display_source_mode=0,
filename=0x0) at mod_php4.c:575
#10 0x40230562 in send_parsed_php (r=0x80ee8fc) at mod_php4.c:590
#11 0x08054633 in ap_invoke_handler () at eval.c:41
#12 0x08068179 in process_request_internal () at eval.c:41
#13 0x080681dc in ap_process_request () at eval.c:41
#14 0x0805f7ae in child_main () at eval.c:41
#15 0x0805f93c in make_child () at eval.c:41
#16 0x0805fa99 in startup_children () at eval.c:41
#17 0x080600d6 in standalone_main () at eval.c:41
#18 0x08060863 in main () at eval.c:41
#19 0x4008fe5e in __libc_start_main (main=0x806051c , argc=2,
ubp_av=0xbb0c, init=0x804ead0 <_init>,
fini=0x809506c <_fini>, rtld_fini=0x4000d3c4 <_dl_fini>,
stack_end=0xbb04) at ../sysdeps/generic/libc-start.c:129
--
Edit this bug report at http://bugs.php.ne
Bug #15843 Updated: (crash) save_path problem
ID: 15843 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Session related Operating System: Windows XP PHP Version: 4.1.1 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-03-03 13:30:49] [EMAIL PROTECTED] Hello, I have tracked down the problem. Setting session.save_path = "C:\windows\temp" will not fix the problem. You will have to create own folder under the root c:\ e.g. "c:\mytemp", using the admin rights (root) and the set: session.save_path = "C:\mytemp" -Vildan [2002-03-03 09:21:15] [EMAIL PROTECTED] I am running php 4.1.1 on XP under Apache 1.3. Every time I call session script, php.exe on server crashes. Error msg (in windows): php.exe has encountered a problems and needs to close. szAppName: php.exe szAppVer: 0.0.0.0 szModName: php4ts.dll szModVer: 0.0.0.0 offset:000a956c I have set the session.save_path = "C:\windows\temp" in the php.ini, but the problem persist. php file content that craches php.exe - - Hope that the problem is within my script, and not PHP itself, but anyhow, users running their own scripts should be able to crash PHP. Regards, -Vildan -- Edit this bug report at http://bugs.php.net/?id=15843&edit=1
Bug #8734 Updated: Unable to send large emails, causes a GPF - small email work fine.
ID: 8734 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Duplicate Bug Type: Mail related Operating System: Windows NT 4 PHP Version: 4.0.4pl1 Assigned To: hholzgra New Comment: Was this bug fixed in 4.1.2? -David Previous Comments: [2001-06-22 18:33:07] [EMAIL PROTECTED] see #11165 [2001-01-30 05:03:00] [EMAIL PROTECTED] reclassify [2001-01-16 11:47:11] [EMAIL PROTECTED] I have been able to make the change and recompile the code to use a 1Mb buffer, instead of a 4K buffer and the mail() function works fine now. You need to change the line #define MAIL_BUFFER_SIZE (1024*4)/* 4k buffer */ to #define MAIL_BUFFER_SIZE (1024*1024) /* 1Mb buffer */ in file "sendmail.h" to make this function work. Ideally, the buffer size should be calculated dynamically, but that'll take a bit longer of course ! Can someone try and pop this change into the next release please. TTFN ! Wayne Cope [2001-01-16 08:25:58] [EMAIL PROTECTED] I have checked the source code for the Windows version of the mail() function and have determined that there is a 4K limit to the mail buffer - which is nowhere near enough. The line is: #define MAIL_BUFFER_SIZE (1024*4)/* 4k buffer */ Which can be found in "sendmail.h" under the Win32 compilation. I can't compile the code to check for sure, but it does look like this is the problem. C'ya ! Wayne Cope [2001-01-16 07:40:01] [EMAIL PROTECTED] When sending attached files (test file is only 14K), a GPF is caused by the mail() function. When the file is small (e.g. 1K) the function works fine. I have checked the ini file settings and all seems fine, and have run the same code on version 4.0.4 and it also crashes then too. I am unable to check on any other versions. I would guess it's a similar problem to the other "malloc problem" in this section (bug report: 8360) as it would appear to be a memory issue. Let me know if you need any more info... Wayne Cope. -- Edit this bug report at http://bugs.php.net/?id=8734&edit=1
Bug #15248 Updated: xslt and iconv option cause errors
ID: 15248 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Compile Failure Operating System: Mac OS X 10.1.2 PHP Version: 4.1.1 Assigned To: markonen New Comment: This bug has been fixed in CVS. Previous Comments: [2002-03-10 12:56:12] [EMAIL PROTECTED] This bug has been superceded by bugs 15986 and 15987. Please follow those bugs for information regarding the forthcoming fixes for the issue you've reported. [2002-03-09 13:31:21] [EMAIL PROTECTED] Making this assigned so Marko won't forget to close this when he fixes this. :) [2002-01-28 02:28:26] [EMAIL PROTECTED] guess, you mean issue, which occured because of apple libtool has -twolevel_namespace enabled by default, with can be overriden in prev. PHP build, changing ltconfig. There is another problem, which also have place on PHP 4.0.6 (I don't know whether it true for another versions or not)It's enough to set only one configure otion --enable- xslt and you will get an error. I don't familiar with all this compilation stuff and C, but looks like PHP can not find iconv header or dynlib or static lib and stacks. (I dled and installed libiconv1.7.tar.gz which produce libiconv***.dylib. I also configure libiconv with --enable- -static, but it doesn't help. Any way didn't find a solution to configure PHP with XSLT support. I think that XSLT support is critical for reach content sites driven by PHP... [2002-01-27 21:29:22] [EMAIL PROTECTED] This is a known issue and will be corrected in the CVS within the next couple of days. [2002-01-27 15:02:16] [EMAIL PROTECTED] I need Iconvlib for XSLT suppot in PHP. I build iconvlib without any problems, but when I tried to configure PHP (4.0.6/4.1.0) I got the error messaches checking whether to enable the XSLT Sablotron backend... yes checking libexpat dir for Sablotron XSL support... no checking for iconv_open in -lc... no configure: error: iconv not found Configure options ./configure -with-apxs --with-mysql=/usr/local/mysql -- with-gd=/usr/local --with-jpeg-dir=/usr/local --with-png- dir=/usr/local --with-freetype-dir=/usr/local --with-zlib- dir=/usr --with-xml --enable-xslt --with-xslt-sablot=/usr/ local --with-zlib=/usr --with-pdflib=/usr/lib --enable-wddx --enable-trans-sid --enable-ftp --with-gnu-ld If I run configure without XSLT support I get an error when ran Apache with compiled PHP module [osxserver:/usr/src/php-4.0.6] root# apachectl configtest dyld: /usr/sbin/httpd Undefined symbols: _iconv_module_entry Does it iconv compatibility issues? Or it's bug in PHP sources? -- Edit this bug report at http://bugs.php.net/?id=15248&edit=1
Bug #15107 Updated: Usage of sessions crashes PHP.
ID: 15107
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Closed
Bug Type: Session related
Operating System: Windows 98
PHP Version: 4.1.1
New Comment:
This bug has been fixed in CVS.
Previous Comments:
[2002-01-19 00:51:43] [EMAIL PROTECTED]
it shouldn't crash. There is report for this problem.
Status = Duplicate
[2002-01-18 18:10:32] [EMAIL PROTECTED]
Please help me
The function code that i have given it dosent give any error messages
but It passes all verfication like username and password from the
database but after it call the checkuser function withou giving any
error messages it return's to login menu.
if ( !$ecust_row || $ecust_row[duser]!=$session[login] ||
$ecust_row[dpass]!=$session[password] )
{
print $tt;
//header( "Location: login.php" );
exit;
}
It goes through only this verification not
$session[logged_in] = true;
return $ecust_row;
Tuan
[2002-01-18 15:48:02] [EMAIL PROTECTED]
Sorry, the reason was because the /tmp folder was missing.
[2002-01-18 15:17:59] [EMAIL PROTECTED]
I am using PHP 4.1.1. with apache 1.3.22 on Win98.
This script (or any script that involves sessions) produces the error
message below:
PHP caused an invalid page fault in
module PHP4TS.DLL at 0177:10054373.
Registers:
EAX=0028 CS=0177 EIP=10054373 EFLGS=00010206
EBX=00760320 SS=017f ESP=0063fa48 EBP=100a01c0
ECX=0015 DS=017f ESI=00760320 FS=59d7
EDX=00764f10 ES=017f EDI=101290a0 GS=
Bytes at CS:EIP:
8b 10 8d 4c 24 1c 51 52 e8 e0 51 05 00 8d 44 24
Stack dump:
101290a0 00760320 00760320 0001 0001 00760320 1005430d
00760320
00760320 100544fb 00760320 0078d410 100a01e9 0001 000a 00760320
[2002-01-18 15:13:51] [EMAIL PROTECTED]
This script (or any script that involves sessions) produces the error
message below:
PHP caused an invalid page fault in
module PHP4TS.DLL at 0177:10054373.
Registers:
EAX=0028 CS=0177 EIP=10054373 EFLGS=00010206
EBX=00760320 SS=017f ESP=0063fa48 EBP=100a01c0
ECX=0015 DS=017f ESI=00760320 FS=59d7
EDX=00764f10 ES=017f EDI=101290a0 GS=
Bytes at CS:EIP:
8b 10 8d 4c 24 1c 51 52 e8 e0 51 05 00 8d 44 24
Stack dump:
101290a0 00760320 00760320 0001 0001 00760320 1005430d 00760320
00760320 100544fb 00760320 0078d410 100a01e9 0001 000a 00760320
--
Edit this bug report at http://bugs.php.net/?id=15107&edit=1
Bug #15225 Updated: 4.1.1 fails on OS X 10.1.2
ID: 15225 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Compile Failure Operating System: darwin PHP Version: 4.1.1 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-03-10 12:54:54] [EMAIL PROTECTED] This bug has been superceded by bugs 15986 and 15987. Please follow those bugs for information regarding the forthcoming fixes for the issue you've reported. [2002-01-25 13:16:09] [EMAIL PROTECTED] This appears to be a libtool issue... 4.0.6 compliles without issue on OS X 10.1.2, after making small changes to the ltconfig file. In 4.1.1 there is no ltconfig file, and any attempts to complile fail with the following error: ld: -undefined error must be used when -twolevel_namespace is in effect /usr/bin/libtool: internal link edit command failed This occurred even after setting the following: setenv LDFLAGS -flat_namespace I can get 4.1.1 to compile if I first run configure in the 4.0.6 tree and copy the created libtool file to the 4.1.1 tree and then run make. Thanks for your attention; I found no mention of this error in the bug database. -- Edit this bug report at http://bugs.php.net/?id=15225&edit=1
Bug #15012 Updated: Cannot load libphp4.so - undefined symbol: uncompress
ID: 15012 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Apache related Operating System: Debian GNU/Linux 2.2 PHP Version: 4.1.1 New Comment: This is fixed in CVS and in the PHP 4.2.0 (which will be released soon) Previous Comments: [2002-01-13 20:22:02] [EMAIL PROTECTED] You can ask support question to [EMAIL PROTECTED] We are not going to answer any support questions, since if we do. Bug db will be full of questions. BTW, have your read manual? [2002-01-13 17:37:41] [EMAIL PROTECTED] I tried ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs --with-zlib and when it's compiling, I got the error "Confugure extensions" "checking if the location of ZLIB install directory is defined... no" "checking whether to include ZLIB support... yes" "configure: error: Cannot find libz" so I tried ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs --with-zlib=/usr/local/src/php-4.1.1/ext/zlib and I got the same message :( Can you help me... [2002-01-13 02:40:33] [EMAIL PROTECTED] Adding --with-zlib fix this for you. [2002-01-12 23:12:52] [EMAIL PROTECTED] I already searched but I didn't find an answer [2002-01-12 21:23:49] [EMAIL PROTECTED] Please search bug db before report ;) There is workaround described in report :) 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/15012 -- Edit this bug report at http://bugs.php.net/?id=15012&edit=1
Bug #14895 Updated: Error when trying to load the php4 module
ID: 14895 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: OpenSSL related Operating System: FreeBSD 4.3-RELEASE PHP Version: 4.1.1 New Comment: Reopen if this still happens with latest CVS snapshot and if you're sure you don't have bogus c-client libs or header files in your system. Previous Comments: [2002-02-27 23:57:42] [EMAIL PROTECTED] The answer is: Find and remove any old [lib]c-client.a|so on your system, then install the new uw c-client library or let php find it in your --with-imap directory. David [2002-02-27 23:28:46] [EMAIL PROTECTED] Any answers to this problem yet? #!/bin/bash rm config.cache; export LIBS="-ljpeg -lpng" LDFLAGS="-L/usr/local/ssl/lib -L/usr/X11R6/lib -L/usr/local/lib" \ CFLAGS="$CFLAGS -I/usr/local/include" CPPFLAGS="$CFLAGS" ./configure \ --with-apxs=/usr/local/apache/bin/apxs --enable-track-vars \ --enable-magic-quotes --enable-trans-sid --enable-memory-limit \ --enable-force-cgi-redirect --enable-discard-path --with-openssl \ --enable-sigchild --enable-bcmath --with-bz2 \ --enable-calendar --enable-ftp \ --with-imap=/usr/src/imap-2002.DEV.SNAP-0202261726/ --with-imap-ssl=/usr/local/ssl/lib \ --with-pgsql --enable-trans-sid --with-zlib \ --with-mysql=no \ --enable-sysvshm --x-libraries=/usr/X11R6/lib \ --with-freetype-dir=/usr/local/include/freetype1/ \ --with-jpeg-dir=shared \ --with-png-dir=shared --with-xpm-dir=shared --with-gd-dir=shared --with-gd ... Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/libexec/libphp4.so: undefined symbol: ssl_onceonlyinit imapd is compiled as: make install SSLTYPE=nopwd ssl_onceonlyinit is located in imapd/src/osdep/unix/ssl_unix.c [2002-02-22 02:32:27] [EMAIL PROTECTED] Sorry, this actually WAS imap-ssl related. [2002-01-19 14:33:23] [EMAIL PROTECTED] I've searched the bugdb per your suggestion, Derick. All I found were two old IMAP-SSL related issues when I searched for the function name (ssl_onceonlyinit). I can download a copy of the CVS source if you like and retry my compile to see if it is fixed. Something to note, is on a fresh FreeBSD install (4.4-RELEASE), I installed apache and mod_php from a cvsup'ed ports collection, and I get the same error, so you may start to get more wide spread reports of this error. Let me know. [2002-01-19 13:08:40] [EMAIL PROTECTED] You need to provide a little more information, read bugs.php.net/how-to-report.php Derick The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/14895 -- Edit this bug report at http://bugs.php.net/?id=14895&edit=1
Bug #14903 Updated: php 4.1.1 crashes Apache 1.3.22
ID: 14903 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Session related Operating System: Win2k Server PHP Version: 4.1.1 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-01-07 09:11:40] [EMAIL PROTECTED] Very likely to be a dupe of #14453. If not, reopen this report. [2002-01-07 06:25:37] [EMAIL PROTECTED] Whenever a session_start() is invoked PHP crashes Apache and returns an Error 404. OS: Windows 2000 Server Webserver: Apache 1.3.22 PHP-Version: 4.1.1 running as module PHP-ini: php.ini (php.ini-dist) unmodified Also, 4.0.6 works fine. -- Edit this bug report at http://bugs.php.net/?id=14903&edit=1
Bug #14661 Updated: Sessions Causing Apache (maybe others?) to Crash on Windows (maybe others?)
ID: 14661 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Reproducible crash Operating System: winXP PHP Version: 4.1.0 New Comment: As said in 14453, this is now fixed. Please try the PHP 4.2.0RC2 from http://www.php.net/~derick/ and reopen if it still crashes. (remember to replace php4ts.dll also!) Previous Comments: [2001-12-22 15:06:29] [EMAIL PROTECTED] Probably a dupe of 14453 [2001-12-22 14:41:21] [EMAIL PROTECTED] Any use of session functions on php 4.1.0 and apache 1.3.22 cause an error in php4ts.dll and cause apache to crash. everything else i've found works fine. i'm not sure whether this is true for other servers and operating systems, but i've noticed it here at least. a script as simple as: causes this to occur. please fix! :) -- Edit this bug report at http://bugs.php.net/?id=14661&edit=1
Bug #14858 Updated: Lack of tmp directory causes crash on call to session_start()
ID: 14858 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Session related Operating System: Windows 2000 Pro PHP Version: 4.1.1 New Comment: This should be fixed in PHP 4.2.0 now..try the latest RC from http://www.php.net/~derick/ and reopen if this is not the case. (remember to also replace the php4ts.dll) Previous Comments: [2002-01-11 10:25:08] [EMAIL PROTECTED] This is a dupe of one of the critical bugs... I'm too lazy to find out which one ;) [2002-01-09 22:06:37] [EMAIL PROTECTED] Can be a dup of others, but keep it open for now. [2002-01-04 15:00:14] [EMAIL PROTECTED] If the directory c:/tmp does not exist, PHP, installed as a SAPI module, causes an Apache.exe crash when a session_start() function call is made. Reproducible + predictable. Configuration details: Windows 2000 Service Pack 1 Apache 1.3.22 PHP 4.1.1 - SAPI - No additional modules installed, beyond the included MySQL and ODBC support. Temporary directory = c:/tmp -- Edit this bug report at http://bugs.php.net/?id=14858&edit=1
Bug #15967 Updated: session_start(); crashes php.exe
ID: 15967 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Reproducible crash Operating System: WinXP PHP Version: 4.1.1 New Comment: This should be fixed in PHP 4.2.0..try the latest RC from http://www.php.net/~derick/ and reopen if this still fails. (remember to replace the php4ts.dll also!) Previous Comments: [2002-03-09 06:24:59] [EMAIL PROTECTED] Very likely to be a problem with an incorrect session.save_path. There's alreadd a report for that. If that's not the case, reopen this report. [2002-03-08 21:09:40] [EMAIL PROTECTED] crashes (reproducible) my IIS at WinXP. IE-error reporting tells me: szAppName : php.exe szAppVer : 0.0.0.0 szModName : php4ts.dll szModVer : 0.0.0.0 offset : 000a956c I use the standard installation (install from web) without any other addins. Besides sessions, I have no problems with PHP -- Edit this bug report at http://bugs.php.net/?id=15967&edit=1
Bug #15809 Updated: IMAP undefined symbol: ssl_onceonlyinit
ID: 15809 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Feedback Bug Type: IMAP related Operating System: RedHat 7.2 PHP Version: 4.1.2 New Comment: Does PHP 4.2.0RC2 work any better? (it can be found here: http://www.php.net/~derick/ ) Previous Comments: [2002-03-01 06:51:02] [EMAIL PROTECTED] A couple of days ago someone reported the same thing... so this is a dupe... [2002-03-01 06:20:38] [EMAIL PROTECTED] Hi, If I PHP with --with-imap-ssl=/usr/local/openssl install comes with apache start of the errors: Syntax error on line 240 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/libexec/libphp4.so: undefined symbol: ssl_onceonlyinit /usr/local/apache/bin/apachectl start: httpd could not be started OpenSSL Version is: OpenSSL 0.9.6c Apache Version is : 1.3.23 -- Edit this bug report at http://bugs.php.net/?id=15809&edit=1
Bug #16255 Updated: Upload Size > 32MB
ID: 16255 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Open Bug Type: Scripting Engine problem Operating System: Windows 2000 NT PHP Version: 4.1.2 New Comment: ..so let's keep this one open. Previous Comments: [2002-04-09 15:14:18] [EMAIL PROTECTED] There is already a report for this. Don't know which one though... this bugsystem really sucks :( [2002-04-09 15:04:45] [EMAIL PROTECTED] When I try to upload large files (greater than 25MB) using PHP 4.1.2 (Apache 1.3.20/FreeBSD 4.5) it takes an infinitely long time to complete the transfer. It will time out before the transfer is complete (and I set the time out for twenty minutes). I circumvent this bug-driven limitation by having local users access a samba share on the web server, onto which they can move files that are then able to be 'uploaded' (read: copied to the correct filesystem destination) within my PHP script -- but this is not an optimal solution. I've been waiting for this bug to be resolved for months. I hope there is a fix for it in 4.2. Thanks. -ronnen [2002-04-09 03:18:09] [EMAIL PROTECTED] always the same problem, now new is that i can see in the tmp Dir that the filesize increase but very slow. 32MB needs 15 min. on localhost Transfer. [2002-03-25 07:59:02] [EMAIL PROTECTED] You can try for yourself :) There are PHP 4.2.0RC1 binaries at www.php.net/~derick Derick [2002-03-25 06:35:18] [EMAIL PROTECTED] When i make an Upload with size more than 32MB, the time for this upload is very long (75MB over 45 min in 100MBit Network). The same file ,the same PHP and Apache config on an Linux System need only 1 minute for transfer. Please tell me if this bug is solved in Version 4.2 regards Claude Schmitt -- Edit this bug report at http://bugs.php.net/?id=16255&edit=1
Bug #14557 Updated: Compile Failure (and potential fix)
ID: 14557 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Compile Failure Operating System: MacOS X (10.1.1) PHP Version: 4.1.0 Assigned To: kalowsky New Comment: This bug has been fixed in CVS. The cvs HEAD (which will become 4.3.0 at some point) has this fixed. Previous Comments: [2002-03-10 12:54:23] [EMAIL PROTECTED] This bug has been superceded by bugs 15986 and 15987. Please follow those bugs for information regarding the forthcoming fixes for the issue you've reported. [2002-03-03 02:07:54] [EMAIL PROTECTED] Thank you for the submission of this. have you sent an email to the libtool group yet informing them of your findings as well? It might be useful :) Assigning to myself to keep me working on a proper fix. [2001-12-17 01:07:07] [EMAIL PROTECTED] Oops! One more thing! The full text of the tcsh script I'm using is available at http://leraz.dhs.org:8080/~squasar/ manual_php_compile.txt and a script which outputs a phpinfo() is available at http://leraz.dhs.org:8080/ ~squasar/info.php [2001-12-17 01:04:07] [EMAIL PROTECTED] (Incidently, I want to note that most of the problems with the compile seem to stem from libtool, which evidently has no clue what the heck it's doing.) [2001-12-17 01:01:26] [EMAIL PROTECTED] The compile of PHP 4.1.0 (source tarball) fails miserably out-of-the-box on MacOS X 10.1.1. The CGI version seems mostly alright, but the Apache DSO is a dismal mess. I'm running the latest released Apache (1.3.22). Also, I'm working with the CC shipped by Apple for OS X (this failed even MORE miserably with my compiled version of GCC, which is expected since OS X isn't supported by GCC yet) After some 5 days of wrestling, writing manual compiles, and running make -n and libtool --dry-run to get some idea of what the compilation is doing, I finally got it to work properly via writing a tcsh script that manually compiles the files involved (My configure is "./configure --with- apxs=/usr/sbin/apxs --enable-ftp --enable-mbstring -- enable-mbstr-enc-trans --with-mysql=/usr/local --enable- sockets --with-tsrm-pthreads --enable-ctype --with-zlib -- prefix=/usr --sysconfdir=/etc --localstatedir=/var -- mandir=/usr/share/man"). Instead of filling this text box beyond its buffer with the entire script (which gets a bit long in the tooth, obviously), here's a summary of what options it uses: cc command when compiling normal source files: /usr/bin/cc -dynamic -fPIC -fno-common -traditional-cpp -O2 -I(all the various include dirs) -D(all the various defines) -c (source file).c -o (source file).lo ld command when combining the .lo files in a dir into a .a: /usr/bin/ld -r -o lib(dir name).a (all the objects from the dir) cc command for creating the final libphp4.so: /usr/bin/cc - bundle -bundle_loader /usr/sbin/httpd -flat_namespace - undefined warning -lm -lz -L/usr/local/lib/mysql - lmysqlclient -o libphp4.so (all the .a's compiled above) # for this one, note that the -L and -l for mysql only apply for compiling with a non-bundled libmysql Putting all this together into a tcsh script gave me a successful PHP compile, and adding the appropriate install command (/usr/sbin/apxs -S LIBEXECDIR="/usr/libexec/httpd" -i -a -n php4 libphp4.so) gave me a working Apache + PHP 4.1.0 + MySQL. My humble suggestion is that whoever maintains the autoconf script for PHP use this information to make a normal ./configure work under Darwin. (incidently, `uname -a` == Darwin hostname 5.1 Darwin Kernel Version 5.1: Tue Oct 30 00:06:34 PST 2001; root:xnu/ xnu-201.5.obj~1/RELEASE_PPC Power Macintosh powerpc). Thanks :) -- Edit this bug report at http://bugs.php.net/?id=14557&edit=1
Bug #14394 Updated: Problem with line 1457 "archive_cmds"
ID: 14394 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Compile Failure Operating System: Mac OSX 10.1 PHP Version: 4.1.0 Assigned To: kalowsky New Comment: This bug has been fixed in CVS. cvs HEAD which will become 4.3.0 at some point has the fixes for this. Previous Comments: [2002-03-10 12:53:14] [EMAIL PROTECTED] This bug has been superceded by bugs 15986 and 15987. Please follow those bugs for information regarding the forthcoming fixes for the issue you've reported. [2002-03-03 02:12:57] [EMAIL PROTECTED] assigning to myself [2002-03-03 00:01:51] [EMAIL PROTECTED] this is actually a known bug. It's more a bug with libtool and not really a bug of PHP. This is supposedly fixed in libtool 1.4.2 but it doesn't seem to be really (at least not for me locally). There is a libtool 1.3.5 patch that supposedly fixes this for v1.3 libtools. If you're feeling bold, try applying that patch and seeing how things go. [2001-12-11 22:02:11] [EMAIL PROTECTED] Problem also exists in 4.1 [2001-12-09 11:33:47] [EMAIL PROTECTED] When compiling PHP on MacOSX 10.1 you must update line 1457 of the ltconfig file. Trying to compile the source code from php.net as is results in this error: /usr/bin/ld: -undefined error must be used when - twolevel_namespace is in effect make[1]: *** [libphp4.la] Error 1 make: *** [all-recursive] Error 1 Original source line# 1457 of ltconfig downloaded from php.net: archive_cmds='$CC -bundle -undefined suppress -o $lib $libobjs $deplibs $linkopts' What must be used on line 1457 of ltconfig to successfully compile: archive_cmds='$CC -force_flat_namespace -bundle -undefined suppress -o $lib $libobjs $deplibs $linkopts' It took me a long time to find the answer for this problem. There is an article on the Apple developer pages that gave me the change, but they have the wrong line number listed [maybe the source has been updated] Article that told me how to fix it: http://developer.apple.com/internet/macosx/php.html -- Edit this bug report at http://bugs.php.net/?id=14394&edit=1
Bug #14256 Updated: libphp4.la Won't Compile on OS X v10.1
ID: 14256 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Compile Failure Operating System: Mac OS X PHP Version: 4.1.0 New Comment: This bug has been fixed in CVS. (in the HEAD, which will become 4.3.0 sometime..4.2.0 still has the apxs issue) Previous Comments: [2001-12-15 12:06:34] [EMAIL PROTECTED] Dup of #14483 [2001-11-27 13:13:19] [EMAIL PROTECTED] Mac OS X 10.1 development tools default to a two-level namespace, whereas 10.0 tools defaulted to a flat namespace. A discussion of this problem (and one solution, maybe) is posted on Mark Liyanage's site at http://www.entropy.ch/software/macosx/php/. I used the trick explained here to get around a problem building where I got complaints that the -undefined flag used in the configure script was incorrect for two-level namespace. However, when I try to use the --with-apxs flag with the configure script I still can't compile. I have been trying to build a shared object version of RC3 and I only get a little farther in the process until I get another error about multiply-defined symbols when linking libphp4.la. -- Edit this bug report at http://bugs.php.net/?id=14256&edit=1
Bug #14154 Updated: PHP won't compile on OSX 10.1
ID: 14154 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Compile Failure Operating System: Mac OS X (Darwin) 10.1.1 PHP Version: 4.0.6 New Comment: This bug has been fixed in CVS. Previous Comments: [2001-12-13 07:20:35] [EMAIL PROTECTED] dup of 14483, not closed! [2001-12-13 06:30:14] [EMAIL PROTECTED] No feedback. Closing. [2001-11-21 01:17:56] [EMAIL PROTECTED] And if it not works, please read on how you should report a bug at http://bugs.php.net/how-to-report.php [2001-11-20 18:29:09] [EMAIL PROTECTED] Can you please try the latest RC release and report back if it works ? http://www.php.net/~zeev/php-4.1.0RC3.tar.gz [2001-11-20 18:20:29] [EMAIL PROTECTED] PHP won't compile on OSX 10.1 It reports an error - something with namespace. -- Edit this bug report at http://bugs.php.net/?id=14154&edit=1
Bug #14483 Updated: -twolevel_namespace and multiple definitions errors
ID: 14483 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Compile Failure Operating System: Mac OS X 10.1 PHP Version: 4.2.0-dev New Comment: This is fixed in CVS. Previous Comments: [2002-03-10 12:53:55] [EMAIL PROTECTED] This bug has been superceded by bugs 15986 and 15987. Please follow those bugs for information regarding the forthcoming fixes for the issue you've reported. [2002-02-10 19:17:26] [EMAIL PROTECTED] stephano, does your build process enable the dl() functions to work as well? [2002-02-10 09:18:19] [EMAIL PROTECTED] Thanks for the comments. We hope to have a real fix for this ASAP. [2002-02-10 08:45:13] [EMAIL PROTECTED] Ok, here is how I got PHP-4.1.1 to compile clean on MacOSX 10.1.4 for Apache 1.3.22 with APXS: 1) download 4.0.6 and run ./configure --with-apxs --with-[your stuff here] 2) download 4.1.1 and run ./configure --with-apxs --with-[your stuff here] 3) copy php-4.0.6/libtool to php-4.1.1/libtool 4) open php-4.1.1/libtook, go to line 178 and add the '-flat-namespace' directive to the compiler, so change archive_cmds="\$CC -bundle [...] with archive_cmds="\$CC -flat_namespace -bundle [...] 5) open php-4.1.1/Zend/zend_language_scanner.c, go to line 2725 and comment that line out, so change char *yytext; with /* char *yytext; */ [don't worry, this is already defined in another file so this doesn't appear to break anything] 6) run 'make' 7) run 'make install' 8) run 'apachectl restart' and you are up and running :) [2002-01-30 17:11:42] [EMAIL PROTECTED] For the apache module, I use... ./configure --with-apxs --with-mysql The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/14483 -- Edit this bug report at http://bugs.php.net/?id=14483&edit=1
Bug #13729 Updated: PHP Outputs #! line
ID: 13729
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Closed
Bug Type: *General Issues
Operating System: Any
PHP Version: 4.0.6
New Comment:
the patch was applied to CVS a while ago.
Previous Comments:
[2001-10-18 21:04:39] [EMAIL PROTECTED]
Duplicate of #9041
[2001-10-18 05:00:29] [EMAIL PROTECTED]
When running PHP either as a CGI or through mod_php,
including the #! line causes it to be included in the
output. When running as CGI this trips up the browser, when
running through mod_php it just appears as an additional
part of the display HTML document.
The check is in the source code, but it's ignored. The
patch to fix is:
*** sapi/cgi/cgi_main.c Thu Oct 18 07:01:34 2001
--- sapi/cgi/cgi_main.c.origThu Oct 18 06:19:44 2001
***
*** 699,706
return FAILURE;
}
file_handle.filename = argv0;
! }
! if (file_handle.handle.fp &&
file_handle.handle.fp!=stdin) {
/* #!php support */
c = fgetc(file_handle.handle.fp);
if (c == '#') {
--- 699,705
return FAILURE;
}
file_handle.filename = argv0;
! } else if (file_handle.handle.fp &&
file_handle.handle.fp!=stdin)
{
/* #!php support */
c = fgetc(file_handle.handle.fp);
if (c == '#') {
--
Edit this bug report at http://bugs.php.net/?id=13729&edit=1
Bug #13178 Updated: make install fails on cobalt RAQIII.
ID: 13178 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Apache related Operating System: Linux www.affcu.com 2.2.16C27_II PHP Version: 4.0.6 New Comment: This was fixed in 4.1.0. Forgot to close.. Previous Comments: [2001-11-03 22:19:52] [EMAIL PROTECTED] Duplicate of: #11647 [2001-09-06 12:05:37] [EMAIL PROTECTED] hello, It may be the version of APXS that I am using, but it didn't like the 'apxs -S' flag that make install used. I fixed it by editing the config_vars.mk file and changing this line: INSTALL_IT = $(mkinstalldirs) "$(INSTALL_ROOT)/usr/lib/apache" && /usr/sbin/apxs -S LIBEXECDIR="$(INSTALL_ROOT)/usr/lib/apache" -i -a -n php4 l ibs/libphp4.so to be apxs -S and the install worked. I hope that this info helps other people trying to upgrade their version of php on RAQs. Brian King -- Edit this bug report at http://bugs.php.net/?id=13178&edit=1
Bug #12069 Updated: Another "MySQL: Unable to save result set in" problem... not solved...
ID: 12069
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Bogus
Bug Type: MySQL related
Operating System: RedHat Linux 6.2 - Kernel 2.4.1
PHP Version: 4.0.6
New Comment:
check the FAQ.
Previous Comments:
[2001-10-23 14:17:09] [EMAIL PROTECTED]
Duplicate of 11765.
[2001-07-11 17:20:45] [EMAIL PROTECTED]
Warning: MySQL: Unable to save result set in
/hosting/tarieven.be/www/html/counter.php on line 38
This particular line is :
mysql_query("update counter set count=count+1 where (type='total' and
var='hits')");
I've read all other bug reports on this bug and followed the
suggestions, but none of them works.
I've reinstalled MySQL, recompiled PHP (removed every file, removed the
source, untarred it again, etc.). I've looked at the correct socket in
php.ini, but that doesn't change anything either.
The query works fine, but it still gives the error...
--
Edit this bug report at http://bugs.php.net/?id=12069&edit=1
Bug #12056 Updated: Transparent Session ID doesn't pick up redirects
ID: 12056
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Bogus
Bug Type: Session related
Operating System: Linux 2.2.x
PHP Version: 4.0.6
Previous Comments:
[2001-07-11 12:30:52] [EMAIL PROTECTED]
dup of 6121
[2001-07-11 11:24:35] [EMAIL PROTECTED]
Bug #6121 was assigned in 10/2000 and I have seen no updates to it of
any kind. I just wanted to let you know that the problem still exists
in PHP 4.0.6.
If you use a header("Location:URL") to redirect (as I do often), the
SID is not transparently attached to the URL. This doesn't seem like
it would be too difficult to fix. In the mean time I have written
wrapper functions to handle this problem but it IS quite annoying. =)
--
Edit this bug report at http://bugs.php.net/?id=12056&edit=1
Bug #11900 Updated: PHP_PDF.DLL
ID: 11900 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Bogus Bug Type: PDF related Operating System: win98 PHP Version: 4.0.6 New Comment: This is not PHP problem at all. Previous Comments: [2001-07-05 06:05:34] [EMAIL PROTECTED] Duplicate (And the PDF coordinate system is originated in the lower left, that is normal) Derick [2001-07-05 05:42:23] [EMAIL PROTECTED] Now with php 4.06 installer comes php_pdf.dll - which trial time is ower and sends to parser code Fatal error: PDFlib error: Beta expired - retrieve new version from www.pdflib.com and in php_pdf.dll page X -position is correct but Y-position started from bottom page like X 0 position is left and Y 0 position is bottom, but should be from top -- Edit this bug report at http://bugs.php.net/?id=11900&edit=1
Bug #11690 Updated: apxs does not support -S
ID: 11690 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Apache related Operating System: Cobalt OS 5.0 (RaQ3) PHP Version: 4.0.6 New Comment: this was fixed a while ago. (4.1.0 iirc) Previous Comments: [2001-06-26 10:21:43] [EMAIL PROTECTED] Duplicate of 11647 [2001-06-26 05:24:54] [EMAIL PROTECTED] I currently have PHP4.0.4pl1 running fine on a Cobalt RaQ3 machine, and I attempted to upgrade to version 4.0.6. The configure and make went okay with no errors reported, but 'make install' fails with the following error: --- Making install in . make[1]: Entering directory `/home/sites/home/users/admin/php-4.0.6' /home/sites/home/users/admin/php-4.0.6/build/shtool mkdir -p "/usr/lib/apache" && /usr/sbin/apxs -S LIBEXECDIR="/usr/lib/apache" -i -a -n php4 libs/libphp4.so apxs:Error: Unknown option: S Usage: apxs -g -n apxs -q ... apxs -c [-o ] [-D [=]] [-I ] [-L ] [-l ] [-Wc,] [-Wl,] ... apxs -i [-a] [-A] [-n ] ... make[1]: *** [install-sapi] Error 1 make[1]: Leaving directory `/home/sites/home/users/admin/php-4.0.6' make: *** [install-recursive] Error 1 --- It seems the PHP install is trying to install the DSO module with an option that apxs doesn't support ( -S ). The RaQ3 is running Apache version 1.3.6. Regards, Glen Scott -- Edit this bug report at http://bugs.php.net/?id=11690&edit=1
Bug #16539 Updated: Cannot determine error status
ID: 16539 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Linux -PHP Version: 4.1.0 +PHP Version: 4.1.2 New Comment: same problem with version 4.1.2 Previous Comments: [2002-04-10 18:28:21] [EMAIL PROTECTED] I'd like to have some functionality that helps to determine if a script is terminated normally or due to time out error and/or memory limit exceeded error. There are two global flags, PG(connection_status) and AG(memory_exhausted), which supposedly would indicate such errors. However, they are not set properly. PG(connection_status) remains as PHP_CONNECTION_NORMAL when time out happens. AG(memory_exhausted) is always 0, never changes. I'm writing a new PHP extension and I need to generate an alert when a script is terminated due to errors. The changes I need are very minor, actually I can pinpoint the changes in the PHP source: 1) in Zend/zend_execute_API.c, function zend_timeout(), uncomment the following line: /* is there any point in this? we're terminating the request anyway... PG(connection_status) |= PHP_CONNECTION_TIMEOUT; */ 2) in Zend/zend_alloc.c, _CHECK_MEMORY_LIMIT macro, line AG(memory_exhausted=1; should be put before "zend_error(...)", because zend_error(...) never returns in case of fatal errors. -- Edit this bug report at http://bugs.php.net/?id=16539&edit=1
Bug #10281 Updated: Same as 10187
ID: 10281 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Bogus Bug Type: mcrypt related Operating System: Linux Slack PHP Version: 4.0.4pl1 New Comment: same reason as 10187.. Previous Comments: [2001-04-11 03:11:14] [EMAIL PROTECTED] Duplicate of #10187 [2001-04-11 03:07:04] [EMAIL PROTECTED] This is the same bug croping up in Linux. I couldn't comment on it in bug # 10187 so I reposted the bug. -- Edit this bug report at http://bugs.php.net/?id=10281&edit=1
Bug #16539: Cannot determine error status
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.0 PHP Bug Type: Feature/Change Request Bug description: Cannot determine error status I'd like to have some functionality that helps to determine if a script is terminated normally or due to time out error and/or memory limit exceeded error. There are two global flags, PG(connection_status) and AG(memory_exhausted), which supposedly would indicate such errors. However, they are not set properly. PG(connection_status) remains as PHP_CONNECTION_NORMAL when time out happens. AG(memory_exhausted) is always 0, never changes. I'm writing a new PHP extension and I need to generate an alert when a script is terminated due to errors. The changes I need are very minor, actually I can pinpoint the changes in the PHP source: 1) in Zend/zend_execute_API.c, function zend_timeout(), uncomment the following line: /* is there any point in this? we're terminating the request anyway... PG(connection_status) |= PHP_CONNECTION_TIMEOUT; */ 2) in Zend/zend_alloc.c, _CHECK_MEMORY_LIMIT macro, line AG(memory_exhausted=1; should be put before "zend_error(...)", because zend_error(...) never returns in case of fatal errors. -- Edit bug report at http://bugs.php.net/?id=16539&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16539&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16539&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16539&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16539&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16539&r=support Expected behavior: http://bugs.php.net/fix.php?id=16539&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16539&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16539&r=submittedtwice
Bug #12883 Updated: krb4 support in c-client
ID: 12883 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type: Feature/Change Request Operating System: Solaris (SPARC) 2.6 PHP Version: 4.0CVS-2001-08-21 New Comment: And we're not going to add anything that isn't supported by the c-client library. Previous Comments: [2001-08-22 01:21:32] [EMAIL PROTECTED] Before anybody commits this patch here's a note from IMAP docs/FAQ: -- Q: Can I use Kerberos V4? A: Kerberos V4 is not supported. Kerberos V4 client-only contributed code is available as: ftp://ftp.cac.washington.edu/mail/kerberos4-patches.tar.Z This is a patchkit which must be applied to the IMAP toolkit according to the instructions in the patchkit's README. I can not promise that this code works. -- [2001-08-21 16:46:33] [EMAIL PROTECTED] I realized I should probably submit a patch that worked.. it works with 4.0.6, but not 4.0.7dev. The tests that configure (4.0.7dev) runs to check for SSL support in c-client misidentifies the krb4 c-client as having ssl. I can configure and build 4.0.7dev if I disable the IMAP_CHK_SSL in ext/imap/config.m4 and rerun buildconf. configure: error: This c-client library is build with SSL support. Add --with-imap-ssl<=DIR> to your configure line. Check config.log for details. config.log: configure:25058: gcc -o conftest -g -O2 -D_POSIX_PTHREAD_SEMANTICS -R/usr/ucblib -L/usr/ucblib -R/usr/local/gnu/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2 -L/usr/local/gnu/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2 -R/usr/local/build/imap-2000c/lib -L/usr/local/build/imap-2000c/lib -R/usr/local/krb4/lib -L/usr/local/krb4/lib conftest.c -lcrypt -lpam -lcrypt -lresolv -lresolv -lm -ldl -lnsl -lsocket -lsocket -lgcc -lcrypt -ldes -lkrb -L/usr/local/build/imap-2000c/lib -lc-client 1>&5 Undefined first referenced symbol in file tkt_string /usr/local/build/imap-2000c/lib/libc-client.a(osdep.o) (bunch of these for the krb4 functions). I think it's because it's put an -lcrypt where it doesn't belong and it's conflicting with some of the calls in the krb4 des library. Not sure tho.. So.. here's the patch for 4.0.6.. again, it works as a cgi, but not as an apache server module, and i've no idea why. Trying to figure that part out.. diff -p -N -U 4 -r ext/imap/config.m4 ext/imap.krb4/config.m4 --- ext/imap/config.m4 Mon May 21 20:38:46 2001 +++ ext/imap.krb4/config.m4 Tue Aug 21 16:03:59 2001 @@ -20,8 +20,25 @@ AC_DEFUN(IMAP_LIB_CHK,[ fi done ]) +AC_DEFUN(PHP_IMAP_KRB4_CHK, [ + PHP_ARG_WITH(krb4,for KerberosIV support in IMAP, + [ --with-krb4[=DIR] IMAP: Include KerberosIV support.]) + + if test "$PHP_KRB4" = "yes"; then +test -d /usr/kerberos && PHP_KRB4=/usr/kerberos + fi + + if test "$PHP_KRB4" != "no"; then +AC_DEFINE(HAVE_IMAP_KRB4,1,[ ]) +PHP_ADD_LIBPATH($PHP_KRB4/lib, IMAP_SHARED_LIBADD) +PHP_ADD_LIBRARY(des, 1, IMAP_SHARED_LIBADD) +PHP_ADD_LIBRARY(krb, 1, IMAP_SHARED_LIBADD) + fi +]) + + AC_DEFUN(PHP_IMAP_KRB_CHK, [ PHP_ARG_WITH(kerberos,for Kerberos support in IMAP, [ --with-kerberos[=DIR] IMAP: Include Kerberos support.]) @@ -134,7 +151,8 @@ if test "$PHP_IMAP" != "no"; then PHP_ADD_INCLUDE($IMAP_INC_DIR) PHP_ADD_LIBPATH($IMAP_LIBDIR, IMAP_SHARED_LIBADD) PHP_ADD_LIBRARY_DEFER($IMAP_LIB) +PHP_IMAP_KRB4_CHK PHP_IMAP_KRB_CHK PHP_IMAP_SSL_CHK fi diff -p -N -U 4 -r ext/imap/php_imap.c ext/imap.krb4/php_imap.c --- ext/imap/php_imap.c Tue Aug 21 16:06:23 2001 +++ ext/imap.krb4/php_imap.cTue Aug 21 16:44:31 2001 @@ -449,8 +449,9 @@ PHP_MINIT_FUNCTION(imap) #ifndef PHP_WIN32 mail_link(&mmdfdriver); /* link in the mmdf driver */ mail_link(&newsdriver); /* link in the news driver */ mail_link(&philedriver);/* link in the phile driver */ + auth_link(&auth_krb); /* link in the krb authenticator */ auth_link(&auth_log); /* link in the log authenticator */ auth_link(&auth_md5); /* link in the cram-md5 authenticator */ #ifdef HAVE_IMAP_SSL ssl_onceonlyinit (); [2001-08-21 14:02:12] [EMAIL PROTECTED] the line wrapping might be a little off.. this should allow php_imap.c to support a kerberized (krb4) c-client, with the appropriate configure options. it works with the CGI, but not th
Bug #12972 Updated: is_file & co: no warning on non-existing file
ID: 12972 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type: Feature/Change Request Operating System: Any PHP Version: 4 New Comment: This has been fixed. Previous Comments: [2001-08-29 12:44:48] [EMAIL PROTECTED] IMHO, it would be more logic to comply to the manual in this case, so that the new is_file($f) behaves like the current: file_exists($f) && is_file($f) So nuke the warning on non-existing files. A non-existing file is not a file. Nor a directory, etc etc. The change is easy, but do people agree that this change should happen? (-> feature req) [2001-08-27 11:35:37] [EMAIL PROTECTED] I don't know what your 'last' is, but current CVS doesn't output anything with file_exists(): mfischer@ficken:~$ php -q bool(false) No error outpout. - Markus [2001-08-27 10:53:27] [EMAIL PROTECTED] Actually, the last I checked, you _do_ need to use @file_exists() if you have error reporting all the way up to avoid error output. That surprised me. [2001-08-27 10:48:15] [EMAIL PROTECTED] Wrong. You use file_exists() to first determine if something exists. The name is a bit misleading, you can verify existense of files, directories and links (read: any file type). file_exists() is written to _not_ output any error. Whereas the is_*() functions are for good reason. So, if you don't want to use file_exists(), you need to use @is_*(). This is the expected behaviour. - Markus [2001-08-27 07:19:34] [EMAIL PROTECTED] when using the is_file function and a file is not found an error is sent back to the error log. I expect this simply to return false in this case. I am aware of file_exists, however in the manual: Returns true if the filename exists and is a regular file. Therefore I expect this to also be testing for file existence. I do not expect debugging output leading me to have to use @is_file and possibly miss other crucial error output. -- Edit this bug report at http://bugs.php.net/?id=12972&edit=1
Bug #11393 Updated: __FUNCTION__
ID: 11393 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Feature/Change Request Operating System: any PHP Version: 4.0.5 New Comment: Just added __FUNCTION__ and __CLASS__ constants. These will be available in PHP 4.3.0. --Jani Previous Comments: [2001-08-12 15:17:51] [EMAIL PROTECTED] Duplicate of Bug #9423. [2001-06-11 01:29:28] [EMAIL PROTECTED] __FILE__ and __LINE__ are neat. __FUNCTION__ would help me also. -- Edit this bug report at http://bugs.php.net/?id=11393&edit=1
Bug #9423 Updated: Please create a function that returns name of currently executing function
ID: 9423
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Closed
Bug Type:Feature/Change Request
PHP Version: 4.0.4pl1
New Comment:
Just added __FUNCTION__ and __CLASS__ constants.
These will be available in PHP 4.3.0.
--Jani
Previous Comments:
[2001-08-28 04:15:11] [EMAIL PROTECTED]
Duplicate of 8576.
[2001-02-23 10:54:26] [EMAIL PROTECTED]
Please consider adding a new feature to the next version of PHP.
When creating code that reports errors, it would be very helpful
to have a function which returns the name of the currently
executing function (or class method). You could perhaps
name the function "func_get_name()", which would fit in nicely
with the existing PHP functions "func_get_arg()", "func_get_args()",
and "func_num_args()". Example usage:
function foo() {
if ( some error condition ) {
ErrorHandler("An error occurrend in function " .
func_get_name() );
}
}
If there is another (existing) way to accomplish this, please let me
know.
Thank you for your consideration (and thanks for PHP) -
Jim Ide [EMAIL PROTECTED]
--
Edit this bug report at http://bugs.php.net/?id=9423&edit=1
Bug #8882 Updated: Additional argument in funtion file($a, $b)
ID: 8882
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Closed
Bug Type:Feature/Change Request
PHP Version: 4.0.4pl1
New Comment:
Added in PHP 4.3.0 (current CVS HEAD):
http://www.php.net/manual/en/function.file-get-contents.php
Previous Comments:
[2002-02-09 23:22:05] [EMAIL PROTECTED]
this is a duplicate of #5008. (same problem, slightly different
proposed solution.)
[2001-01-24 07:49:41] [EMAIL PROTECTED]
dear all
very often the following expression is being used in applications using
file manipulation (specially treating XML contents):
$cont = join ("", file ("test.xml"));
... i would like to propose an addtional attribute in the argument list
of the function file().
lets consider that:
$cont = file ("test.xml", FALSE) or $cont = file ("test.xml")
would be equivalent to:
$cont = file ("test.xml")
and on the other hand:
$cont = file ("test.xml", TRUE)
would be equivalent to:
$cont = join ("", file ("test.xml"))
the second argument would therefore represent an attribute, which let
one specify not only to return an ARRAY (attribute=FALSE, default) but
also a STRING (attribute=TRUE). adding this argument would not affect
older or current implementations or usage of the function file().
what do you think about this?
best regards, urs
--
Urs Gehrig <[EMAIL PROTECTED]>
http://www.circle.ch
--
Edit this bug report at http://bugs.php.net/?id=8882&edit=1
Bug #7213 Updated: Read a file into a variable with one call
ID: 7213
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Closed
Bug Type: Feature/Change Request
Operating System: FreeBSD
PHP Version: 4.0.3
New Comment:
Added in PHP 4.3.0 (current CVS HEAD):
http://www.php.net/manual/en/function.file-get-contents.php
Previous Comments:
[2001-08-12 15:17:16] [EMAIL PROTECTED]
Duplicate of Bug #5008.
[2000-10-14 17:57:00] [EMAIL PROTECTED]
It would be really nice if someone could make a function call for
reading an entire file into one variable, so one would have to use
implode("", file("file.txt")); for something as simple as that.
--
Edit this bug report at http://bugs.php.net/?id=7213&edit=1
Bug #11332 Updated: signal handling
ID: 11332 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Unix/POSIX PHP Version: 4.0 Latest CVS (2001-06-07) New Comment: There is the pcntl extension for this: http://www.php.net/manual/en/ref.pcntl.php Previous Comments: [2001-06-07 12:21:00] [EMAIL PROTECTED] It would be wonderful if the cgi sapi would allow me to handle my own signals. Something like void register_signal_function (mixed signal, char function), so I can at least shut the script down cleanly. ;) register_shutdown_function () doesn't "appear" to work quite like that. -- Edit this bug report at http://bugs.php.net/?id=11332&edit=1
Bug #12866 Updated: Speaking of Payment Processing... will PHP ever have a POST() function?
ID: 12866 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Feature/Change Request Operating System: All PHP Version: 4.0.6 New Comment: Isn't Curl enough? Previous Comments: [2001-08-20 16:26:54] [EMAIL PROTECTED] Speaking of Payment Processing... will PHP ever have a POST() function to post encoded form data to a server? Its easy enough to write your own, but for people not confident in all the header mumbo-jumbo, it would be really nice to be able to just: $URL="https://secure.authorize.net/secure/transact.dll";; $Args="id=001&cost=19.96&card_number=44&"; $Post_Results=post($URL,$Args); I think this would make PHP far, far easier to use for real time credit card processing, as well as a host of other useful things. Also, if there was some built in way to do the encryption that those companies always want... or at least a PHP tutorial for it... cause I can never figure out what they want, or how the data has to be encrypted... :P -Brian Tanner -- Edit this bug report at http://bugs.php.net/?id=12866&edit=1
Bug #8576 Updated: implement C style __FUNCTION__ constant
ID: 8576 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: N/A PHP Version: 4.0.4 New Comment: Just added __FUNCTION__ and __CLASS__ constants. These will be available in PHP 4.3.0. --Jani Previous Comments: [2001-01-07 13:18:49] [EMAIL PROTECTED] I would love to see the __FUNCTION__ constant (which should return the name of the function its called from (or perhaps filename if not inside a funct?)). -- Edit this bug report at http://bugs.php.net/?id=8576&edit=1
Bug #16537 Updated: Bad backslash substitution w/ subexpressions
ID: 16537
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: PCRE related
Operating System: Windows (2000)
PHP Version: 4.1.2
New Comment:
'\' and '\\' will both end up as a single '\' in the string which
effectively reads \( to the preg parser which means you escape the '('
and so don't use it's function to capture characters for backreferences
which renders the following ')' illegal since it tries to close a not
opened '('. Therefore, \ -> \ and \\ -> \ so you need \\\ to get \\ in
the string so you don't escape the (. Clear ? :)
Providing input data for such reports is essential.
Previous Comments:
[2002-04-10 16:50:10] [EMAIL PROTECTED]
Actually, this is quite simple.
Take this:
$preg_replace("/.\:\\.*?\\(.*?).gif/i","http://xpto/\\1.img",$string);
Theoretically, this would make a simple find-replace, but PHP throws
out a "unmatched parenthesis" error (Compilation failed: unmatched
parentheses at offset 12 blablabla...). With the only parentheses in
that regexp being the "(.*?)" in the middle, the error is awkward.
After some juggling I eventually found that it seems that in the
"\\(.*?)" part of the expression, the backslash before the parenthesis
gets replaced with an actual parenthesis BEFORE the double-backslash is
replaced with an actual backslash. I tried putting a space before the
parenthesis and no error appeared (obviously, the regexp didn't work
like that :).
--
Edit this bug report at http://bugs.php.net/?id=16537&edit=1
Bug #16538: session data not consistently stored during startup (10-50% failure rate)
From: [EMAIL PROTECTED] Operating system: Solaris 7 PHP version: 4.1.2 PHP Bug Type: Session related Bug description: session data not consistently stored during startup (10-50% failure rate) We use mysql db as the store for session data. In the past one month or so, I have noticed that Apache generated some "Segmentation fault" or "Bus error" messages. I was finally able to single out the cause of these errors: a couple of php pages using session. When a new session is initiated, the session data is not stored in the mysql db at least 1 out of 5 times, which appears to be related to the segfault/bus errors. -- Edit bug report at http://bugs.php.net/?id=16538&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16538&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16538&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16538&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16538&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16538&r=support Expected behavior: http://bugs.php.net/fix.php?id=16538&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16538&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16538&r=submittedtwice
Bug #16537: Bad backslash substitution w/ subexpressions
From: [EMAIL PROTECTED]
Operating system: Windows (2000)
PHP version: 4.1.2
PHP Bug Type: PCRE related
Bug description: Bad backslash substitution w/ subexpressions
Actually, this is quite simple.
Take this:
$preg_replace("/.\:\\.*?\\(.*?).gif/i","http://xpto/\\1.img",$string);
Theoretically, this would make a simple find-replace, but PHP throws out a
"unmatched parenthesis" error (Compilation failed: unmatched parentheses
at offset 12 blablabla...). With the only parentheses in that regexp being
the "(.*?)" in the middle, the error is awkward.
After some juggling I eventually found that it seems that in the "\\(.*?)"
part of the expression, the backslash before the parenthesis gets replaced
with an actual parenthesis BEFORE the double-backslash is replaced with an
actual backslash. I tried putting a space before the parenthesis and no
error appeared (obviously, the regexp didn't work like that :).
--
Edit bug report at http://bugs.php.net/?id=16537&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16537&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16537&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16537&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16537&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16537&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16537&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16537&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16537&r=submittedtwice
Bug #16536: Give me inconsisten results
From: [EMAIL PROTECTED]
Operating system: mac os x
PHP version: 4.1.2
PHP Bug Type: Date/time related
Bug description: Give me inconsisten results
#get the numeric sunday
$today_var = getdate();
$today_sec = mktime(0,0,0,date("m"),date("d"),date("Y"));
$offset = $today_var[wday] * 86400 ;
$first_day = $today_sec - $offset;
$this_week_first_date = date("ymd", $first_day);
$path=$this_week_first_date;
this just won't get me Sunday this week.. 020407
suddenly at midnight on Monday the 8th it went to 06, this has been
running fine for many many weeks now.
Help
--
Edit bug report at http://bugs.php.net/?id=16536&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16536&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16536&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16536&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16536&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16536&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16536&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16536&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16536&r=submittedtwice
Bug #16535 Updated: Line breaks not correctly counted when file has Mac line endings
ID: 16535
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Mac OS X
PHP Version: 4.1.2
New Comment:
Hello,
can you verify if this occurs when you have mixed line endings (other
then only Mac endings) or just always (only Mac line endings).
Derick
Previous Comments:
[2002-04-10 16:27:43] [EMAIL PROTECTED]
Related bug Bug #10631, refiled per that bug since I still see it.
[2002-04-10 16:26:42] [EMAIL PROTECTED]
When a file is saved using Macintosh-style line breaks
('\r') and there is some kind of error in the script (maybe
a parse error, etc.) then the line number that is reported
is always less than the line it occured on. In my script PHP told me
line 84, but it was actually 93.
It's a fairly minor thing, but annoying nonetheless. A
workaround, obviously, is to make sure you save your
scripts with Unix line-breaks ('\n').
--
Edit this bug report at http://bugs.php.net/?id=16535&edit=1
Bug #16535 Updated: Line breaks not correctly counted when file has Mac line endings
ID: 16535
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: Mac OS X
PHP Version: 4.1.2
New Comment:
Related bug Bug #10631, refiled per that bug since I still see it.
Previous Comments:
[2002-04-10 16:26:42] [EMAIL PROTECTED]
When a file is saved using Macintosh-style line breaks
('\r') and there is some kind of error in the script (maybe
a parse error, etc.) then the line number that is reported
is always less than the line it occured on. In my script PHP told me
line 84, but it was actually 93.
It's a fairly minor thing, but annoying nonetheless. A
workaround, obviously, is to make sure you save your
scripts with Unix line-breaks ('\n').
--
Edit this bug report at http://bugs.php.net/?id=16535&edit=1
Bug #16535: Line breaks not correctly counted when file has Mac line endings
From: [EMAIL PROTECTED]
Operating system: Mac OS X
PHP version: 4.1.2
PHP Bug Type: Scripting Engine problem
Bug description: Line breaks not correctly counted when file has Mac line endings
When a file is saved using Macintosh-style line breaks
('\r') and there is some kind of error in the script (maybe
a parse error, etc.) then the line number that is reported
is always less than the line it occured on. In my script PHP told me line
84, but it was actually 93.
It's a fairly minor thing, but annoying nonetheless. A
workaround, obviously, is to make sure you save your
scripts with Unix line-breaks ('\n').
--
Edit bug report at http://bugs.php.net/?id=16535&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16535&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16535&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16535&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16535&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16535&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16535&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16535&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16535&r=submittedtwice
Bug #16524 Updated: PHP script crashes iPlanet
ID: 16524
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: iPlanet related
Operating System: Windows 2000
PHP Version: 4.1.2
New Comment:
Yes. But I had trouble figuring out how to get a back trace based on
the link that was sent...
http://bugs.php.net/bugs-generating-backtrace.php
Previous Comments:
[2002-04-10 14:57:09] [EMAIL PROTECTED]
We asked for a backtrace, not for a dump of your php.ini.
[2002-04-10 10:52:11] [EMAIL PROTECTED]
Here are my current ini settings... No error log is being produced.
[PHP]
;;;
; WARNING ;
;;;
; This is the default settings file for new PHP installations.
; By default, PHP installs itself with a configuration suitable for
; development purposes, and *NOT* for production purposes.
; For several security-oriented considerations that should be taken
; before going online with your site, please consult
php.ini-recommended
; and http://php.net/manual/en/security.php.
;;;
; About this file ;
;;;
; This file controls many aspects of PHP's behavior. In order for PHP
to
; read it, it must be named 'php.ini'. PHP looks for it in the
current
; working directory, in the path designated by the environment
variable
; PHPRC, and in the path that was defined in compile time (in that
order).
; Under Windows, the compile-time path is the Windows directory. The
; path in which the php.ini file is looked for can be overridden using
; the -c argument in command line mode.
;
; The syntax of the file is extremely simple. Whitespace and Lines
; beginning with a semicolon are silently ignored (as you probably
guessed).
; Section headers (e.g. [Foo]) are also silently ignored, even though
; they might mean something in the future.
;
; Directives are specified using the following syntax:
; directive = value
; Directive names are *case sensitive* - foo=bar is different from
FOO=bar.
;
; The value can be a string, a number, a PHP constant (e.g. E_ALL or
M_PI), one
; of the INI constants (On, Off, True, False, Yes, No and None) or an
expression
; (e.g. E_ALL & ~E_NOTICE), or a quoted string ("foo").
;
; Expressions in the INI file are limited to bitwise operators and
parentheses:
; |bitwise OR
; &bitwise AND
; ~bitwise NOT
; !boolean NOT
;
; Boolean flags can be turned on using the values 1, On, True or Yes.
; They can be turned off using the values 0, Off, False or No.
;
; An empty string can be denoted by simply not writing anything after
the equal
; sign, or by using the None keyword:
;
; foo = ; sets foo to an empty string
; foo = none; sets foo to an empty string
; foo = "none" ; sets foo to the string 'none'
;
; If you use constants in your value, and these constants belong to a
; dynamically loaded extension (either a PHP extension or a Zend
extension),
; you may only use these constants *after* the line that loads the
extension.
;
; All the values in the php.ini-dist file correspond to the builtin
; defaults (that is, if no php.ini is used, or if you delete these
lines,
; the builtin defaults will be identical).
; Language Options ;
; Enable the PHP scripting language engine under Apache.
engine = On
; Allow the tags are
recognized.
short_open_tag = On
; Allow ASP-style <% %> tags.
asp_tags = Off
; The number of significant digits displayed in floating point
numbers.
precision= 14
; Enforce year 2000 compliance (will cause problems with non-compliant
browsers)
y2k_compliance = Off
; Output buffering allows you to send header lines (including cookies)
even
; after you send body content, at the price of slowing PHP's output
layer a
; bit. You can enable output buffering during runtime by calling the
output
; buffering functions. You can also enable output buffering for all
files by
; setting this directive to On. If you wish to limit the size of the
buffer
; to a certain size - you can use a maximum number of bytes instead of
'On', as
; a value for this directive (e.g., output_buffering=4096).
output_buffering = Off
; You can redirect all of the output of your scripts to a function.
For
; example, if you set output_handler to "ob_gzhandler", output will be
; transparently compressed for browsers that support gzip or deflate
encoding.
; Setting an output handler automatically turns on output buffering.
output_handler =
; Transparent output compression using the zlib library
; Valid values for this option are 'off', 'on', or a specific buffer
size
; to be used for compression (default is 4KB)
zlib.output_compression = Off
; Implicit flush tells PHP to tell the
Bug #16534: compilation failed on inline function url_scanner.c
From: [EMAIL PROTECTED]
Operating system: Solaris 8
PHP version: 4.1.2
PHP Bug Type: Compile Failure
Bug description: compilation failed on inline function url_scanner.c
The compilation of php in standalone mode failed.
I use Forte C 6 update 2.
Forte can't proceed the inline function on :
static inline void mainloop(url_adapt_state_ex_t *ctx, const char
*newdata, size_t newlen TSRMLS_DC)
{
char *end, *q;
char *xp;
char *start;
int rest;
smart_str_appendl(&ctx->buf, newdata, newlen);
YYCURSOR = ctx->buf.c;
YYLIMIT = ctx->buf.c + ctx->buf.len;
switch (STATE) {
case STATE_PLAIN: goto state_plain;
case STATE_TAG: goto state_tag;
case STATE_NEXT_ARG: goto state_next_arg;
case STATE_ARG: goto state_arg;
case STATE_BEFORE_VAL: goto state_before_val;
case STATE_VAL: goto state_val;
}
So I removed the "inline" definition in this function.
Regards,
Armand
--
Edit bug report at http://bugs.php.net/?id=16534&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16534&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16534&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16534&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16534&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16534&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16534&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16534&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16534&r=submittedtwice
Bug #16524 Updated: PHP script crashes iPlanet
ID: 16524
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: iPlanet related
Operating System: Windows 2000
PHP Version: 4.1.2
New Comment:
We asked for a backtrace, not for a dump of your php.ini.
Previous Comments:
[2002-04-10 10:52:11] [EMAIL PROTECTED]
Here are my current ini settings... No error log is being produced.
[PHP]
;;;
; WARNING ;
;;;
; This is the default settings file for new PHP installations.
; By default, PHP installs itself with a configuration suitable for
; development purposes, and *NOT* for production purposes.
; For several security-oriented considerations that should be taken
; before going online with your site, please consult
php.ini-recommended
; and http://php.net/manual/en/security.php.
;;;
; About this file ;
;;;
; This file controls many aspects of PHP's behavior. In order for PHP
to
; read it, it must be named 'php.ini'. PHP looks for it in the
current
; working directory, in the path designated by the environment
variable
; PHPRC, and in the path that was defined in compile time (in that
order).
; Under Windows, the compile-time path is the Windows directory. The
; path in which the php.ini file is looked for can be overridden using
; the -c argument in command line mode.
;
; The syntax of the file is extremely simple. Whitespace and Lines
; beginning with a semicolon are silently ignored (as you probably
guessed).
; Section headers (e.g. [Foo]) are also silently ignored, even though
; they might mean something in the future.
;
; Directives are specified using the following syntax:
; directive = value
; Directive names are *case sensitive* - foo=bar is different from
FOO=bar.
;
; The value can be a string, a number, a PHP constant (e.g. E_ALL or
M_PI), one
; of the INI constants (On, Off, True, False, Yes, No and None) or an
expression
; (e.g. E_ALL & ~E_NOTICE), or a quoted string ("foo").
;
; Expressions in the INI file are limited to bitwise operators and
parentheses:
; |bitwise OR
; &bitwise AND
; ~bitwise NOT
; !boolean NOT
;
; Boolean flags can be turned on using the values 1, On, True or Yes.
; They can be turned off using the values 0, Off, False or No.
;
; An empty string can be denoted by simply not writing anything after
the equal
; sign, or by using the None keyword:
;
; foo = ; sets foo to an empty string
; foo = none; sets foo to an empty string
; foo = "none" ; sets foo to the string 'none'
;
; If you use constants in your value, and these constants belong to a
; dynamically loaded extension (either a PHP extension or a Zend
extension),
; you may only use these constants *after* the line that loads the
extension.
;
; All the values in the php.ini-dist file correspond to the builtin
; defaults (that is, if no php.ini is used, or if you delete these
lines,
; the builtin defaults will be identical).
; Language Options ;
; Enable the PHP scripting language engine under Apache.
engine = On
; Allow the tags are
recognized.
short_open_tag = On
; Allow ASP-style <% %> tags.
asp_tags = Off
; The number of significant digits displayed in floating point
numbers.
precision= 14
; Enforce year 2000 compliance (will cause problems with non-compliant
browsers)
y2k_compliance = Off
; Output buffering allows you to send header lines (including cookies)
even
; after you send body content, at the price of slowing PHP's output
layer a
; bit. You can enable output buffering during runtime by calling the
output
; buffering functions. You can also enable output buffering for all
files by
; setting this directive to On. If you wish to limit the size of the
buffer
; to a certain size - you can use a maximum number of bytes instead of
'On', as
; a value for this directive (e.g., output_buffering=4096).
output_buffering = Off
; You can redirect all of the output of your scripts to a function.
For
; example, if you set output_handler to "ob_gzhandler", output will be
; transparently compressed for browsers that support gzip or deflate
encoding.
; Setting an output handler automatically turns on output buffering.
output_handler =
; Transparent output compression using the zlib library
; Valid values for this option are 'off', 'on', or a specific buffer
size
; to be used for compression (default is 4KB)
zlib.output_compression = Off
; Implicit flush tells PHP to tell the output layer to flush itself
; automatically after every output block. This is equivalent to
calling the
; PHP function flush() after each and every call to print() or echo()
and each
; and every HTML block. Turning this option on has serious
performance
;
Bug #16523 Updated: $variable = ibase_query fails
ID: 16523 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: InterBase related Operating System: linux (2.4.18, slackware 8) PHP Version: 4.1.2 New Comment: i'll try the interbase.c thing, but if it's the change i've seen mentioned elsewhere in the recent bug reports/fixes (something about the "i've been naughty" section, changing what gets freed, etc.) then we've already got it (based on the diff i saw -- the links posted to it on cvs.something wouldn't work, 404.) but i will try it, just in case. is 4.2 stable enough to use? or is -only- the interbase.c the part i want? and yes, i have looked at the documentation. in several languages in fact (amusing that in french, the example stays the same, with translated text around it.) i found a few pages that had correct brackets for optional parameters (php.net's documentation on ibase_* is somewhat lacking in specifics.) i still think the problem is centered around the return value from ibase_query: if i don't try to assign it to a variable, the script does connect, and it does get a value back from the database (so it's not something simple like a username/password problem.) the documentation says that ibase_connect, ibase_trans, ibase_query, etc. pretty much all return "int" but no integer i've ever seen when echoed says "Resource #3" ... also, i have no problem assigning the return value from the two other functions, both of which also return resources (integers, ha!) am i missing anything else? i'll give interbase.c a whirl, and if that doesn't work, i might even upgrade to 4.2 all-around (might as well.) heck, i've got another server being setup, won't hurt it to try stuff out. Previous Comments: [2002-04-10 11:52:36] [EMAIL PROTECTED] May you upgrade your interbase.c with that one in RC2 at www.php.net/~derick ? and ... have you already look at http://www.php.net/manual/en/function.ibase-connect.php there is an example showing how to loop in a resultset Daniela [2002-04-10 10:50:38] [EMAIL PROTECTED] sure =) here are links to: #the test, working (no returned value from function being assigned to variable) both in working form and in viewable form: http://www.csmaster.org/art/initial_test.php http://www.csmaster.org/art/initial_test.phps #same script, with the line uncommented (attempt to store the returned value from ibase_query()) http://www.csmaster.org/art/initial_fail.php http://www.csmaster.org/art/initial_fail.phps #still available, server info http://www.csmaster.org/test.php you're welcome to connect to the database as shown, the firebird server should be accessible from the outside (and i just made a copy in case someone gets fancy.) i know there's a lot of junk in those, but we spent a few hours trying various things, which all sorta wound up in the same file, to get it to let us do simple queries. it's my first time using php, but not firebird. [2002-04-10 05:41:42] [EMAIL PROTECTED] I cannot reproduce it. Could you provide a little test script, please? [2002-04-10 01:16:34] [EMAIL PROTECTED] // successful: $stuff = ibase_fetch_row (ibase_query($sql_string)); # we can get $stuff[0], rows are being returned // not successful: $thingie = ibase_query($sql_string); # same statement, same file -- won't work. # if we comment this line out, the one above will work. # if this line does get executed, it fails. we can, for # that matter, grab the returned value and echo it! but # if for the life of us we try to assign it -into- a # variable so we can call ibase_fetch_row multiple times # (kinda handy) the script won't run. // i'm not the sysadmin, but i'll try to get any info that would help out. we're talking to Firebird 1.0 (which supports all of Interbase 6.0's communications protocols) and i've not had any problems with the interbase->firebird conversion in other situations. also tested: ibase_prepare gives us the same problem. if the return value is encapsulated in the call to ibase_execute, the script doesn't crash. if we grab it into a variable, and try to use that variable for the ibase_execute call, we don't ever get that far (the assignment kills it.) i've checked for the often-mentioned patch to interbase.c, we have it. http://www.csmaster.org/test.php for info on our server (in case you wanna know) -- Edit this bug report at http://bugs.php.net/?id=16523&edit=1
Bug #16259 Updated: Windows version info in binaries
ID: 16259 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Feature/Change Request Operating System: Windows PHP Version: 4.1.1 Assigned To: jtate New Comment: I've added version resources to php4tsdll, php4isapi, php4ts and php4ts_cli projects. I'm waiting for my patch for configure.in and main/php_version.h to go through before I can commit this change. Previous Comments: [2002-04-10 10:45:44] [EMAIL PROTECTED] I'm on it. It'll be in CVS today. [2002-04-09 20:37:28] [EMAIL PROTECTED] He means version info a in Version Info Resource. (Right click on php.exe, properties, Version tab). Re-opening as this is a valid feature request. Can one of the windows build guys add this into the relevant projects? It will need doing for cgi, cli and isapi DLLs, as well as the php4ts.dll. [2002-04-09 20:26:19] [EMAIL PROTECTED] Oops you are talking about os version. You can use "uname" if you use cygwin. (All unix and Mac OS X have that) Or you can check it with w32api, I suppose. [2002-04-09 20:08:51] [EMAIL PROTECTED] PHP 4.2.0 has PHP_VERSION constant phpversion() is there for long time. Reopen if you are talking about other feature. [2002-04-09 18:07:27] [EMAIL PROTECTED] recategorizing as a change request. 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/16259 -- Edit this bug report at http://bugs.php.net/?id=16259&edit=1
Bug #14637 Updated: Apache 2.0 filter and PHP 4 crash
ID: 14637
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache2 related
Operating System: Solaris 8/x86
PHP Version: 4.1.0
New Comment:
Okay.. here's some more info...
APR_BRIGADE_CONCAT is #define'd in apache's
srclib/apr-util/include/apr_buckets.h as a macro to
APR_RING_CONCAT(&(a)->list, &(b)->list, apr_bucket, link)
APR_RING_CONCAT itself is another macro to APR_RING_SPLICE_BEFORE and
APR_RING_INIT, but that's another story..
Anyways... a "print saveto->list" in gdb reports:
Cannot access memory at address 0x10
This address is always the same. Seems like something is screwing-up
saveto->list?
The wierd part is if I set a breakpoint on util_filter.c:562 and
manually 'continue' each time, then it doesn't crash. As soon as I
remove the breakpoint, it'll SIGSEGV. Almost seems like a race
condition?
Previous Comments:
[2002-04-10 13:23:07] [EMAIL PROTECTED]
I'm having the same problem using CVS snapshots of both Apache 2 and
PHP 4 from today.
Test case: phpinfo(); (can't get much simpler than that).
Solaris 8/Sparc + recommended patches
gcc 2.95.4 prerelease (happens w/ gcc 2.95.3 also)
Side note: This PHP snapshot works fine w/ Apache 1.x, and this Apache
2 snapshot works fine if I pull normal .html files. So it seems to be
in the combo of Apache 2 + PHP 4. CFLAGS were: -O0 -w -g3
Program received signal SIGSEGV, Segmentation fault.
0xea304 in ap_save_brigade (f=0x2dcff8, saveto=0x2dbf24, b=0xffbef080,
p=0x2db5c0) at util_filter.c:562
562 APR_BRIGADE_CONCAT(*saveto, *b);
(gdb) bt
#0 0xea304 in ap_save_brigade (f=0x2dcff8, saveto=0x2dbf24,
b=0xffbef080,
p=0x2db5c0) at util_filter.c:562
#1 0xfe318840 in php_output_filter (f=0x2dcff8, bb=0x2dd100)
at
/export/home/dmarques/php4/sapi/apache2filter/sapi_apache2.c:354
#2 0xea178 in ap_pass_brigade (next=0x2dcff8, bb=0x2dd100)
at util_filter.c:534
#3 0xf821c in default_handler (r=0x2db5f8) at core.c:3247
#4 0xd1738 in ap_run_handler (r=0x2db5f8) at config.c:193
#5 0xd232c in ap_invoke_handler (r=0x2db5f8) at config.c:373
#6 0x86598 in ap_process_request (r=0x2db5f8) at http_request.c:261
#7 0x7e698 in ap_process_http_connection (c=0x2d5650) at
http_core.c:291
#8 0xe5c78 in ap_run_process_connection (c=0x2d5650) at
connection.c:85
#9 0xe622c in ap_process_connection (c=0x2d5650, csd=0x2d5580)
at connection.c:207
#10 0xcecfc in child_main (child_num_arg=0) at prefork.c:671
#11 0xcee50 in make_child (s=0x202328, slot=0) at prefork.c:711
#12 0xcf020 in startup_children (number_to_start=2) at prefork.c:783
#13 0xcf710 in ap_mpm_run (_pconf=0x14f8b0, plog=0x1979d0, s=0x202328)
at prefork.c:999
#14 0xd9854 in main (argc=2, argv=0xffbef7a4) at main.c:622
[2001-12-21 04:24:19] [EMAIL PROTECTED]
Current HEAD of both httpd-2.0 and PHP4. Clean compile.
% uname -a
SunOS scotch.ucf.ics.uci.edu 5.8 Generic_108529-12 i86pc i386 i86pc
'./configure' \
'--with-apxs2=/pkg/apache-2.0-cvs/bin/apxs' \
'--with-pgsql=/pkg/postgresql-7.0.2' \
'--with-ispell=/pkg/ispell-3.1' \
'--with-zlib' \
'--with-ldap=/pkg/openldap-2.0.11' \
'--with-openssl=/pkg/openssl-0.9.6b'
This is for a vhost site that I run, so I'm not really at liberty to
provide the script. I can ask the user if I can pass along the script,
but it isn't mine, so I don't really want to do it without
authorization.
Back trace:
(gdb) bt
#0 0x80f4423 in ap_save_brigade (f=0x86652f8, saveto=0x852e0a4,
b=0xde405b3c,
p=0x8536630) at util_filter.c:416
#1 0xdf597be1 in php_output_filter (f=0x86652f8, bb=0x8665448)
at sapi_apache2.c:350
#2 0x80f433d in ap_pass_brigade (next=0x86652f8, bb=0x8665448)
at util_filter.c:388
#3 0x80fca7e in default_handler (r=0x8536668) at core.c:2824
#4 0x80e62f0 in ap_run_handler (r=0x8536668) at config.c:185
#5 0x80e6a2e in ap_invoke_handler (r=0x8536668) at config.c:360
#6 0x80b0866 in ap_process_request (r=0x8536668) at
http_request.c:292
#7 0x80ab8db in ap_process_http_connection (c=0x8910b68) at
http_core.c:280
#8 0x80f2100 in ap_run_process_connection (c=0x8910b68) at
connection.c:84
#9 0x80f24dc in ap_process_connection (c=0x8910b68) at
connection.c:229
#10 0x80e3264 in process_socket (p=0x8910a48, sock=0x8910a80,
my_child_num=1,
my_thread_num=4) at worker.c:565
#11 0x80e37c1 in worker_thread (thd=0x8257c40, dummy=0x836fe18) at
worker.c:782
#12 0xdfb49900 in dummy_worker (opaque=0x8257c40) at thread.c:122
(gdb) down
#1 0xdf597be1 in php_output_filter (f=0x86652f8, bb=0x8665448)
at sapi_apache2.c:350
350 ap_save_brigade(f, &ctx->bb, &bb, f->r->pool);
(gdb) print *ctx
$29 = {state = 761820026, bb = 0x2e312e33, f = 0x86652f8, post_l
Bug #14637 Updated: Apache 2.0 filter and PHP 4 crash
ID: 14637
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache2 related
Operating System: Solaris 8/x86
PHP Version: 4.1.0
New Comment:
I'm having the same problem using CVS snapshots of both Apache 2 and
PHP 4 from today.
Test case: phpinfo(); (can't get much simpler than that).
Solaris 8/Sparc + recommended patches
gcc 2.95.4 prerelease (happens w/ gcc 2.95.3 also)
Side note: This PHP snapshot works fine w/ Apache 1.x, and this Apache
2 snapshot works fine if I pull normal .html files. So it seems to be
in the combo of Apache 2 + PHP 4. CFLAGS were: -O0 -w -g3
Program received signal SIGSEGV, Segmentation fault.
0xea304 in ap_save_brigade (f=0x2dcff8, saveto=0x2dbf24, b=0xffbef080,
p=0x2db5c0) at util_filter.c:562
562 APR_BRIGADE_CONCAT(*saveto, *b);
(gdb) bt
#0 0xea304 in ap_save_brigade (f=0x2dcff8, saveto=0x2dbf24,
b=0xffbef080,
p=0x2db5c0) at util_filter.c:562
#1 0xfe318840 in php_output_filter (f=0x2dcff8, bb=0x2dd100)
at
/export/home/dmarques/php4/sapi/apache2filter/sapi_apache2.c:354
#2 0xea178 in ap_pass_brigade (next=0x2dcff8, bb=0x2dd100)
at util_filter.c:534
#3 0xf821c in default_handler (r=0x2db5f8) at core.c:3247
#4 0xd1738 in ap_run_handler (r=0x2db5f8) at config.c:193
#5 0xd232c in ap_invoke_handler (r=0x2db5f8) at config.c:373
#6 0x86598 in ap_process_request (r=0x2db5f8) at http_request.c:261
#7 0x7e698 in ap_process_http_connection (c=0x2d5650) at
http_core.c:291
#8 0xe5c78 in ap_run_process_connection (c=0x2d5650) at
connection.c:85
#9 0xe622c in ap_process_connection (c=0x2d5650, csd=0x2d5580)
at connection.c:207
#10 0xcecfc in child_main (child_num_arg=0) at prefork.c:671
#11 0xcee50 in make_child (s=0x202328, slot=0) at prefork.c:711
#12 0xcf020 in startup_children (number_to_start=2) at prefork.c:783
#13 0xcf710 in ap_mpm_run (_pconf=0x14f8b0, plog=0x1979d0, s=0x202328)
at prefork.c:999
#14 0xd9854 in main (argc=2, argv=0xffbef7a4) at main.c:622
Previous Comments:
[2001-12-21 04:24:19] [EMAIL PROTECTED]
Current HEAD of both httpd-2.0 and PHP4. Clean compile.
% uname -a
SunOS scotch.ucf.ics.uci.edu 5.8 Generic_108529-12 i86pc i386 i86pc
'./configure' \
'--with-apxs2=/pkg/apache-2.0-cvs/bin/apxs' \
'--with-pgsql=/pkg/postgresql-7.0.2' \
'--with-ispell=/pkg/ispell-3.1' \
'--with-zlib' \
'--with-ldap=/pkg/openldap-2.0.11' \
'--with-openssl=/pkg/openssl-0.9.6b'
This is for a vhost site that I run, so I'm not really at liberty to
provide the script. I can ask the user if I can pass along the script,
but it isn't mine, so I don't really want to do it without
authorization.
Back trace:
(gdb) bt
#0 0x80f4423 in ap_save_brigade (f=0x86652f8, saveto=0x852e0a4,
b=0xde405b3c,
p=0x8536630) at util_filter.c:416
#1 0xdf597be1 in php_output_filter (f=0x86652f8, bb=0x8665448)
at sapi_apache2.c:350
#2 0x80f433d in ap_pass_brigade (next=0x86652f8, bb=0x8665448)
at util_filter.c:388
#3 0x80fca7e in default_handler (r=0x8536668) at core.c:2824
#4 0x80e62f0 in ap_run_handler (r=0x8536668) at config.c:185
#5 0x80e6a2e in ap_invoke_handler (r=0x8536668) at config.c:360
#6 0x80b0866 in ap_process_request (r=0x8536668) at
http_request.c:292
#7 0x80ab8db in ap_process_http_connection (c=0x8910b68) at
http_core.c:280
#8 0x80f2100 in ap_run_process_connection (c=0x8910b68) at
connection.c:84
#9 0x80f24dc in ap_process_connection (c=0x8910b68) at
connection.c:229
#10 0x80e3264 in process_socket (p=0x8910a48, sock=0x8910a80,
my_child_num=1,
my_thread_num=4) at worker.c:565
#11 0x80e37c1 in worker_thread (thd=0x8257c40, dummy=0x836fe18) at
worker.c:782
#12 0xdfb49900 in dummy_worker (opaque=0x8257c40) at thread.c:122
(gdb) down
#1 0xdf597be1 in php_output_filter (f=0x86652f8, bb=0x8665448)
at sapi_apache2.c:350
350 ap_save_brigade(f, &ctx->bb, &bb, f->r->pool);
(gdb) print *ctx
$29 = {state = 761820026, bb = 0x2e312e33, f = 0x86652f8, post_len = 0,
post_idx = 139649336, post_data = 0x852e0f8 ""}
It looks like the ctx is getting corrupted somehow (or is it initially
non-null?). I don't know enough about PHP4 and SAPI to track this down
further. So, I'll file a bug report...
I see that PHP4 is a little different than the rest of the Apache 2.0
modules in that it attempts to keep a unified context (i.e.
SG(server_context)). This is somewhat different than other modules -
as httpd-2.0 is providing a ctx on a per-request level (in f->ctx).
It's not impossible to do it this way - mod_ssl has a similar
connection-based context. But, it makes it harder to manage.
Email me if you have any questions,
Justin Erenkrantz
[EMAIL PROTECTED]
--
Edit this
Bug #16515 Updated: Files with execute-bit are always php-parsed - I cannot disable this!
ID: 16515 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: Linux 2.4.16 PHP Version: 4.1.2 New Comment: I discussed the problem already with Zeev (@Zend) some weeks ago and he wrote: >I'm not sure what to tell you... It's definitely not a >known bug in PHP, I've never heard it being reported >before ever. So, please can anybody check this behaviour/bug? Please tell me if I can help somehow or test some config-params on my system. Thank you very much. Previous Comments: [2002-04-10 09:05:44] [EMAIL PROTECTED] Reopening on user request. [2002-04-09 11:32:19] [EMAIL PROTECTED] 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 I'm sure this is a configuration issue; ask support on the appropriate mailinglist. [2002-04-09 11:06:13] [EMAIL PROTECTED] Hello! After updating 4.04pl1 to 4.1.1, I encountered the following problem: All .htm and .html-files with the execute-bit set, are PHP parsed! I disabled the xbithack-feature of Apache and phpinfo() tells me correctly, that xbithack is disabled (ok, the xbithack-feature will normally enable SSI-parsing in Apache, but I wanted to be sure that everything is disabled). Then I updated to 4.1.2, but the files are still PHP-parsed. I updated Apache from 1.3.19 to 1.3.22, but the files are still PHP-parsed. I tried everything, but my xbit-files are still PHP-parsed - and I don't want this (sigh!). Is this a bug or a hidden feature? Is there something I can do? Can anybody reproduce the problem? (just set chmod 755 for a .html-file, put some php-code in it and look if it is being PHP-parsed) Help! Thanks for your support. Greetings ... tobias wiersch from germany -- Edit this bug report at http://bugs.php.net/?id=16515&edit=1
Bug #16533 Updated: Apache 2 can't start using PHP as a module
ID: 16533 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Windows 98 PHP Version: 4.1.2 New Comment: Apache 2 support is broken in 4.1.2 and will hopefully work better in 4.2.0. Previous Comments: [2002-04-10 12:14:24] [EMAIL PROTECTED] When I try to use PHP with Apache 2 (last stable version), Apache don't start, telling me that he couldn't load the dll module file. I've checked depencies of that file and found that it requires APACHECORE.DLL that isn't anymore with Apache 2 (as it seems ...) PHP work well as a CGI :) -- Edit this bug report at http://bugs.php.net/?id=16533&edit=1
Bug #16533: Apache 2 can't start using PHP as a module
From: [EMAIL PROTECTED] Operating system: Windows 98 PHP version: 4.1.2 PHP Bug Type: Apache2 related Bug description: Apache 2 can't start using PHP as a module When I try to use PHP with Apache 2 (last stable version), Apache don't start, telling me that he couldn't load the dll module file. I've checked depencies of that file and found that it requires APACHECORE.DLL that isn't anymore with Apache 2 (as it seems ...) PHP work well as a CGI :) -- Edit bug report at http://bugs.php.net/?id=16533&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16533&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16533&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16533&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16533&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16533&r=support Expected behavior: http://bugs.php.net/fix.php?id=16533&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16533&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16533&r=submittedtwice
Bug #16532: locale information (LC_NUMERIC) not used in bcmath functions
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.1.0
PHP Bug Type: BC math related
Bug description: locale information (LC_NUMERIC) not used in bcmath functions
Summary says it all...
Some could argue it is a missing feature, not a bug, but
it would make a life a bit easier for non-english
developers, especially as this library is ofteh used for
monetary stuff...
\n";
// this line outputs "0.00" instead of "0,80":
echo bcadd("0,3","0,5",2);
?>
--
Edit bug report at http://bugs.php.net/?id=16532&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16532&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16532&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16532&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16532&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16532&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16532&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16532&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16532&r=submittedtwice
Bug #16523 Updated: $variable = ibase_query fails
ID: 16523 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: linux (2.4.18, slackware 8) PHP Version: 4.1.2 New Comment: May you upgrade your interbase.c with that one in RC2 at www.php.net/~derick ? and ... have you already look at http://www.php.net/manual/en/function.ibase-connect.php there is an example showing how to loop in a resultset Daniela Previous Comments: [2002-04-10 10:50:38] [EMAIL PROTECTED] sure =) here are links to: #the test, working (no returned value from function being assigned to variable) both in working form and in viewable form: http://www.csmaster.org/art/initial_test.php http://www.csmaster.org/art/initial_test.phps #same script, with the line uncommented (attempt to store the returned value from ibase_query()) http://www.csmaster.org/art/initial_fail.php http://www.csmaster.org/art/initial_fail.phps #still available, server info http://www.csmaster.org/test.php you're welcome to connect to the database as shown, the firebird server should be accessible from the outside (and i just made a copy in case someone gets fancy.) i know there's a lot of junk in those, but we spent a few hours trying various things, which all sorta wound up in the same file, to get it to let us do simple queries. it's my first time using php, but not firebird. [2002-04-10 05:41:42] [EMAIL PROTECTED] I cannot reproduce it. Could you provide a little test script, please? [2002-04-10 01:16:34] [EMAIL PROTECTED] // successful: $stuff = ibase_fetch_row (ibase_query($sql_string)); # we can get $stuff[0], rows are being returned // not successful: $thingie = ibase_query($sql_string); # same statement, same file -- won't work. # if we comment this line out, the one above will work. # if this line does get executed, it fails. we can, for # that matter, grab the returned value and echo it! but # if for the life of us we try to assign it -into- a # variable so we can call ibase_fetch_row multiple times # (kinda handy) the script won't run. // i'm not the sysadmin, but i'll try to get any info that would help out. we're talking to Firebird 1.0 (which supports all of Interbase 6.0's communications protocols) and i've not had any problems with the interbase->firebird conversion in other situations. also tested: ibase_prepare gives us the same problem. if the return value is encapsulated in the call to ibase_execute, the script doesn't crash. if we grab it into a variable, and try to use that variable for the ibase_execute call, we don't ever get that far (the assignment kills it.) i've checked for the often-mentioned patch to interbase.c, we have it. http://www.csmaster.org/test.php for info on our server (in case you wanna know) -- Edit this bug report at http://bugs.php.net/?id=16523&edit=1
Bug #16530 Updated: in PHP 4.1.2, calling mysql_real_escape_string fails
ID: 16530 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 4.1.2 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-04-10 10:31:43] [EMAIL PROTECTED] Documentation problem. It should be stated on the manual page. [2002-04-10 10:30:32] [EMAIL PROTECTED] It is added in 4.3.0 and the version info hasn't been updated on the site yet. Derick [2002-04-10 10:27:53] [EMAIL PROTECTED] In PHP 4.1.2 (not tested on other versions), calling mysql_real_escape_string fails w/ message: "Call to undefined function: mysql_real_escape_string() in ..." -- Edit this bug report at http://bugs.php.net/?id=16530&edit=1
Bug #14688 Updated: session_register() doesn't register
ID: 14688
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Session related
Operating System: linux 2.2
PHP Version: 4.2.0RC2
New Comment:
With register_globals = off I get nothing, i.e. no number, just
newline, with or without session_unregister("counter"). Seems like
$counter does not exist at all.
Previous Comments:
[2002-04-10 08:25:06] [EMAIL PROTECTED]
This is very strange. I have redirect and session works as it shold.
Could you try register_globals=Off to see if it works?
[2002-04-10 05:59:35] [EMAIL PROTECTED]
Using 4.2.0.RC2 this behavior still there, you can check with these
scripts:
## i2.php
## i.php
## i1.php
And then open http://host/i2.php in browser window.
Expected output - 4, but I get 0.
[2002-04-01 15:53:51] [EMAIL PROTECTED]
AFAIK, this is fixed in CVS and PHP 4.2.0RC1.
Please test RC1 from: http://www.php.net/~derick/
and if it doesn't work, latest snapshot from http://snaps.php.net/
[2002-03-12 13:43:33] [EMAIL PROTECTED]
I notice this too under 4.1.2. unset($var) doesn't unregister $var
from the session
FWIW, this is with Linux 2.4.6-pre6, and I'm using the default files
for session storage.
- Colin
[2002-02-02 06:38:08] [EMAIL PROTECTED]
No feedback was provided for this bug, so it is being suspended.
If you are able to provide the information that was requested,
please do so and change the status of the bug back to "Open".
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/14688
--
Edit this bug report at http://bugs.php.net/?id=14688&edit=1
Bug #16523 Updated: $variable = ibase_query fails
ID: 16523 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: InterBase related Operating System: linux (2.4.18, slackware 8) PHP Version: 4.1.2 New Comment: sure =) here are links to: #the test, working (no returned value from function being assigned to variable) both in working form and in viewable form: http://www.csmaster.org/art/initial_test.php http://www.csmaster.org/art/initial_test.phps #same script, with the line uncommented (attempt to store the returned value from ibase_query()) http://www.csmaster.org/art/initial_fail.php http://www.csmaster.org/art/initial_fail.phps #still available, server info http://www.csmaster.org/test.php you're welcome to connect to the database as shown, the firebird server should be accessible from the outside (and i just made a copy in case someone gets fancy.) i know there's a lot of junk in those, but we spent a few hours trying various things, which all sorta wound up in the same file, to get it to let us do simple queries. it's my first time using php, but not firebird. Previous Comments: [2002-04-10 05:41:42] [EMAIL PROTECTED] I cannot reproduce it. Could you provide a little test script, please? [2002-04-10 01:16:34] [EMAIL PROTECTED] // successful: $stuff = ibase_fetch_row (ibase_query($sql_string)); # we can get $stuff[0], rows are being returned // not successful: $thingie = ibase_query($sql_string); # same statement, same file -- won't work. # if we comment this line out, the one above will work. # if this line does get executed, it fails. we can, for # that matter, grab the returned value and echo it! but # if for the life of us we try to assign it -into- a # variable so we can call ibase_fetch_row multiple times # (kinda handy) the script won't run. // i'm not the sysadmin, but i'll try to get any info that would help out. we're talking to Firebird 1.0 (which supports all of Interbase 6.0's communications protocols) and i've not had any problems with the interbase->firebird conversion in other situations. also tested: ibase_prepare gives us the same problem. if the return value is encapsulated in the call to ibase_execute, the script doesn't crash. if we grab it into a variable, and try to use that variable for the ibase_execute call, we don't ever get that far (the assignment kills it.) i've checked for the often-mentioned patch to interbase.c, we have it. http://www.csmaster.org/test.php for info on our server (in case you wanna know) -- Edit this bug report at http://bugs.php.net/?id=16523&edit=1
Bug #16259 Updated: Windows version info in binaries
ID: 16259 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Feature/Change Request Operating System: Windows PHP Version: 4.1.1 -Assigned To: +Assigned To: jtate New Comment: I'm on it. It'll be in CVS today. Previous Comments: [2002-04-09 20:37:28] [EMAIL PROTECTED] He means version info a in Version Info Resource. (Right click on php.exe, properties, Version tab). Re-opening as this is a valid feature request. Can one of the windows build guys add this into the relevant projects? It will need doing for cgi, cli and isapi DLLs, as well as the php4ts.dll. [2002-04-09 20:26:19] [EMAIL PROTECTED] Oops you are talking about os version. You can use "uname" if you use cygwin. (All unix and Mac OS X have that) Or you can check it with w32api, I suppose. [2002-04-09 20:08:51] [EMAIL PROTECTED] PHP 4.2.0 has PHP_VERSION constant phpversion() is there for long time. Reopen if you are talking about other feature. [2002-04-09 18:07:27] [EMAIL PROTECTED] recategorizing as a change request. [2002-03-25 09:01:29] [EMAIL PROTECTED] Hello, I see, that windows binaries of PHP does not include version info. It is useful, if people want discover, what version have on disk, without running php with phpinfo() function. Resource file (php.rc) may be (if not included correctly email me): #include #define XSTRVER4(maj, min, rel, build) #maj "." #min "." #rel "." #build #define XSTRVER3(maj, min, rel) #maj "." #min "." #rel #define STRVER4(maj, min, rel, build) XSTRVER4(maj, min, rel, build) #define STRVER3(maj, min, rel) XSTRVER3(maj, min, rel) VS_VERSION_INFO VERSIONINFO FILEVERSION MAJORVER,MINORVER,RELEASEVER,BUILDNUMBER PRODUCTVERSION MAJORVER,MINORVER,RELEASEVER,0 FILEFLAGSMASK 0 FILEFLAGS 0 FILEOS VOS__WINDOWS32 FILETYPE VFT_DLL FILESUBTYPE VFT2_UNKNOWN BEGIN BLOCK "StringFileInfo" BEGIN BLOCK "040904B0" BEGIN VALUE "CompanyName", "PHP Team" VALUE "FileDescription", "PHP Script interpreter" VALUE "FileVersion", STRVER4(MAJORVER, MINORVER, RELEASEVER, BUILDNUMBER) VALUE "InternalName", "php" VALUE "LegalCopyright", "Copyright © 2002 PHP Team" VALUE "OriginalFilename", "php" VALUE "ProductName", "php" VALUE "ProductVersion", STRVER3(MAJORVER, MINORVER, RELEASEVER) VALUE "URL", "http://www.php.net"; END END BLOCK "VarFileInfo" BEGIN VALUE "Translation", 0x409, 1200 END END --- Under mingw this may be compiled into .o file: windres -DMAJORVER=$(MAJORVERSION) -DMINORVER=$(MINORVERSION) -DRELEASEVER=$(RELEASEVERSION) -DBUILDNUMBER=$(BUILDNUMBER) php.rc php-win32res.o If this .o file is linked into php.exe and all dlls, all this files will have version info. Under MSVC: rc -r /dMAJORVER=1 /dMINORVER=1 /dRELEASEVER=1 /dBUILDNUMBER=1 php.rc create php.res file, which may be linked into php.exe and all dlls for version info. Macros MAJORVER, MINORVER, RELEASEVER and BUILDNUMBER must be specified on command line to resource compiler for include PHP version to resource file. To version info version is created as MAJORVER.MINORVER.RELEASEVER.BUILDNUMBER -- Edit this bug report at http://bugs.php.net/?id=16259&edit=1
Bug #16530 Updated: in PHP 4.1.2, calling mysql_real_escape_string fails
ID: 16530 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open -Bug Type:MySQL related +Bug Type:Documentation problem PHP Version: 4.1.2 New Comment: Documentation problem. It should be stated on the manual page. Previous Comments: [2002-04-10 10:30:32] [EMAIL PROTECTED] It is added in 4.3.0 and the version info hasn't been updated on the site yet. Derick [2002-04-10 10:27:53] [EMAIL PROTECTED] In PHP 4.1.2 (not tested on other versions), calling mysql_real_escape_string fails w/ message: "Call to undefined function: mysql_real_escape_string() in ..." -- Edit this bug report at http://bugs.php.net/?id=16530&edit=1
Bug #16530 Updated: in PHP 4.1.2, calling mysql_real_escape_string fails
ID: 16530 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type:MySQL related PHP Version: 4.1.2 New Comment: It is added in 4.3.0 and the version info hasn't been updated on the site yet. Derick Previous Comments: [2002-04-10 10:27:53] [EMAIL PROTECTED] In PHP 4.1.2 (not tested on other versions), calling mysql_real_escape_string fails w/ message: "Call to undefined function: mysql_real_escape_string() in ..." -- Edit this bug report at http://bugs.php.net/?id=16530&edit=1
Bug #16530: in PHP 4.1.2, calling mysql_real_escape_string fails
From: [EMAIL PROTECTED] Operating system: PHP version: 4.1.2 PHP Bug Type: MySQL related Bug description: in PHP 4.1.2, calling mysql_real_escape_string fails In PHP 4.1.2 (not tested on other versions), calling mysql_real_escape_string fails w/ message: "Call to undefined function: mysql_real_escape_string() in ..." -- Edit bug report at http://bugs.php.net/?id=16530&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16530&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16530&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16530&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16530&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16530&r=support Expected behavior: http://bugs.php.net/fix.php?id=16530&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16530&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16530&r=submittedtwice
Bug #16515 Updated: Files with execute-bit are always php-parsed - I cannot disable this!
ID: 16515 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Apache related Operating System: Linux 2.4.16 PHP Version: 4.1.2 New Comment: Reopening on user request. Previous Comments: [2002-04-09 11:32:19] [EMAIL PROTECTED] 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 I'm sure this is a configuration issue; ask support on the appropriate mailinglist. [2002-04-09 11:06:13] [EMAIL PROTECTED] Hello! After updating 4.04pl1 to 4.1.1, I encountered the following problem: All .htm and .html-files with the execute-bit set, are PHP parsed! I disabled the xbithack-feature of Apache and phpinfo() tells me correctly, that xbithack is disabled (ok, the xbithack-feature will normally enable SSI-parsing in Apache, but I wanted to be sure that everything is disabled). Then I updated to 4.1.2, but the files are still PHP-parsed. I updated Apache from 1.3.19 to 1.3.22, but the files are still PHP-parsed. I tried everything, but my xbit-files are still PHP-parsed - and I don't want this (sigh!). Is this a bug or a hidden feature? Is there something I can do? Can anybody reproduce the problem? (just set chmod 755 for a .html-file, put some php-code in it and look if it is being PHP-parsed) Help! Thanks for your support. Greetings ... tobias wiersch from germany -- Edit this bug report at http://bugs.php.net/?id=16515&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 +Status: Open Bug Type: Session related Operating System: Linux RH 6.2 -PHP Version: 4.0.6RC3 +PHP Version: 4.1.1 Previous Comments: [2002-04-10 03:55:42] [EMAIL PROTECTED] I am having the same problem...I am running apache 1.3.24 win32 in win2k AS...with php 4.1.1 [2002-03-07 14:52:53] [EMAIL PROTECTED] PS apache is running standalone, not xinetd. [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? 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 #14688 Updated: session_register() doesn't register
ID: 14688 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Session related Operating System: linux 2.2 -PHP Version: 4.1.0 +PHP Version: 4.2.0RC2 New Comment: This is very strange. I have redirect and session works as it shold. Could you try register_globals=Off to see if it works? Previous Comments: [2002-04-10 05:59:35] [EMAIL PROTECTED] Using 4.2.0.RC2 this behavior still there, you can check with these scripts: ## i2.php ## i.php ## i1.php And then open http://host/i2.php in browser window. Expected output - 4, but I get 0. [2002-04-01 15:53:51] [EMAIL PROTECTED] AFAIK, this is fixed in CVS and PHP 4.2.0RC1. Please test RC1 from: http://www.php.net/~derick/ and if it doesn't work, latest snapshot from http://snaps.php.net/ [2002-03-12 13:43:33] [EMAIL PROTECTED] I notice this too under 4.1.2. unset($var) doesn't unregister $var from the session FWIW, this is with Linux 2.4.6-pre6, and I'm using the default files for session storage. - Colin [2002-02-02 06:38:08] [EMAIL PROTECTED] No feedback was provided for this bug, so it is being suspended. If you are able to provide the information that was requested, please do so and change the status of the bug back to "Open". [2002-01-11 18:31:26] [EMAIL PROTECTED] Clarification. Which save handler are you using files or user? 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/14688 -- Edit this bug report at http://bugs.php.net/?id=14688&edit=1
Bug #16526 Updated: MySQL pconnect behaviour changed
ID: 16526 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: Linux RH 7.1 PHP Version: 4.1.2 New Comment: Hi Derick, Thanks for the quick response. My hosts file: # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost Previous Comments: [2002-04-10 04:52:21] [EMAIL PROTECTED] This is actually good news, means that I'm not alone. Can you please mail me your /etc/hosts file? Derick [2002-04-10 03:34:16] [EMAIL PROTECTED] Hi, I just upgraded from php 4.0.6 to php-4.2.0RC2, and all of a sudden I get failures when trying to connect to the mySQL server. It now tries to connect as '[EMAIL PROTECTED]' where previously it used 'user@localhost'. Regards, Willo -- Edit this bug report at http://bugs.php.net/?id=16526&edit=1
Bug #14030 Updated: sybase ct_init fails
ID: 14030 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Sybase-ct (ctlib) related Operating System: Solaris 8 PHP Version: 4.0.6 New Comment: On doing installjava -f "myjarfile.jar" -Sservername -Uusername -Ppasswd -Ddatabasename i am getting this error can anybody please let me know y is this error there and how can it be corrected. CTLIB Message: - Layer 6, Origin 8, Severity 5, Number 1, State 0: ct_connect(): directory service layer: internal directory control layer error: There was an error encountered while binding to the directory service. Thanks -bharat Previous Comments: [2002-02-21 04:53:33] [EMAIL PROTECTED] To overcome this problem do one of the follows: -- Install the new libtli.sofile in the $SYBASE/lib directory. Install the new libtli.so in a separate directory and set the environment variable LD_LIBRARY_PATH to this location. [2001-11-20 08:11:51] [EMAIL PROTECTED] The problem is fixed if you set LD_LIBRARY_PATH = $SYBASE/$SYBASE/lib [2001-11-12 08:58:14] [EMAIL PROTECTED] I build apache 1.3.20, Sybase ASE 12 and php 4.0.6 with this configuration: ./configure --with-apache=/usr/local/sorgenti/apache_1.3.14 --with-sybase-ct=/database/sybase/OCS-12_0 when the webserver start this is the error: Open Client Message: Message number: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (131) Message String: ct_init(): network packet layer: internal net library error: Attempt to load protocol driver failed Open Client Message: Message number: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (131) Message String: ct_init(): network packet layer: internal net library error: Attempt to load protocol driver failed [Mon Nov 12 13:49:33 2001] [notice] Apache/1.3.20 (Unix) PHP/4.0.6 configured -- resuming normal operations [Mon Nov 12 13:49:33 2001] [info] Server built: Nov 12 2001 12:56:15 The sybase ct_init function don't work. -- Edit this bug report at http://bugs.php.net/?id=14030&edit=1
Bug #16283 Updated: php fails to compile for apache 2.0.32
ID: 16283 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache2 related Operating System: Linux PHP Version: 4.1.2 New Comment: I tried to compile php 4.1.2 with to apache 2.0.35 (non beta according to httpd.apache.org) It fails because of the reasons described in this bug. Someone ([EMAIL PROTECTED]) told here that had php code fixed... Can you send the diffs? So i can try to compile the beast?? Thank you! Previous Comments: [2002-03-31 21:00:22] [EMAIL PROTECTED] Apache2filter SAPI is _experimental_ and there is no stable Aapche2 neither. PHP 4.1.2 comples with Apache 2.0.28. IIRC. If you are using CVS version of PHP, user CVS version of Apache2. [2002-03-31 20:06:36] [EMAIL PROTECTED] I've changed the AP_FTYPE_RESOURCE for AP_FTYPE_CONTENT and apache2 freeze without debug messages in error.log (config changed fr enable debug messages but nothing ...). Wait for apache or/and php next beta release ?! [2002-03-26 08:47:07] [EMAIL PROTECTED] maybe some one know how to use ap_get_brigade() in php ? i used APR_BLOCK_READ and changed bytelen from pointer to value there is sth in apaches change log about changing from pointer to value so this looks to be correct but what about APR_BLOCK_READ or APR_NONBLOCK_READ example filters in apache 2 use APR_BLOCK_READ so mayby it is correct ? there is no AP_FTYPE_RESOURCE in apaches sources [2002-03-26 08:31:27] [EMAIL PROTECTED] 4.1.2 has apache2filter i fixed it and it compilled and hello world worked i tryed 4.2 it also fails " sapi_apache2.c: In function `php_register_hook': sapi_apache2.c:473: `AP_FTYPE_RESOURCE' undeclared (first use in this function) sapi_apache2.c:473: (Each undeclared identifier is reported only once " but the ap_get_brigade() function is fixed but the php_input_filter() also changed [2002-03-26 07:58:29] [EMAIL PROTECTED] AFAIK, 4.1.2 can't compile at all with Apache 2. Can you try 4.2.0RC1 and see if it works? 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/16283 -- Edit this bug report at http://bugs.php.net/?id=16283&edit=1
Bug #16529: JPEG library reports unrecoverable error
From: [EMAIL PROTECTED] Operating system: Linux, RedHat 6.2 PHP version: 4.1.1 PHP Bug Type: GD related Bug description: JPEG library reports unrecoverable error Since updating from PHP 4.0.6 to 4.1.1 (and 4.1.2) I can no longer use ImageJpeg() properly. Part of the image is drawn but then I get the error; gd-jpeg: JPEG library reports unrecoverable error: Output file write error --- out of disk space? I am not out of disk space, have well over 2G left on both devices. PHP4.0.6 with all the same config options works fine and I have therefore reverted. If a developer would like to see the PHP environment please drop me a line and I'll point you to a URL you can use. rutherford:[~/php-4.0.6] cat php-build.sh #!/bin/sh ./configure --with-apxs \ --with-gd \ --with-mysql=/usr \ --enable-trans-sid \ --with-ttf \ --with-zlib Steve. -- Edit bug report at http://bugs.php.net/?id=16529&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16529&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16529&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16529&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16529&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16529&r=support Expected behavior: http://bugs.php.net/fix.php?id=16529&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16529&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16529&r=submittedtwice
Bug #16002 Updated: imagecreatetruecolor not recognizing create version of GD library
ID: 16002 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: GD related Operating System: Red Hat Linux PHP Version: 4.1.1 New Comment: That's due to a slight error in the GD library detection in PHP. Try PHP4.2RC2 www.php.net/~derick. Also, I recommend applying this patch to the GD 2.0.1 sources if you want to do anything real with it: http://thebrainroom.com/opensource/php/ Previous Comments: [2002-04-10 02:27:23] [EMAIL PROTECTED] I have a dedicated box with full control over it, and I'm having essentially the same problem but with this and other GD functions. I first encountered this problem when I was trying to get ImageFilledArc() to work, but just to check, I tried using ImageCreateTrueColor() and got the same error. I'm thinking that whoever looks at this might want to look beyond just this function and perhaps at something related to version detection? Either way, this problem seems to have it's roots deeper than just this function. My system and problem stats are bascially the same as previous comments. PHP version 4.1.2, GD 2.0.1, Red Hat Linux, a happy configure line with the right GD source, etc. Interestingly, PHPInfo() says I'm using GD version "1.6.2 or higher" whatever that means. I'm more than glad to help out if anyone has any unique ideas they'd like me to try. I'd really love to get those nifty arc and elipse functions working! [2002-03-12 11:56:49] [EMAIL PROTECTED] Duplicated the error on a new dedicated server account that I have. This one is running version 4.1.1. Same error: Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in /www/apache/htdocs/starsguitars/admin/imgfunctions.php on line 39 Here is the configuration './configure' '--with-apxs=/www/apache/bin/apxs' '--with-config-file-path=/usr/local/apache/conf/' '--with-mysql=/usr/local/mysql' '--enable-debug=no' '--enable-track-vars' '--enable-magic-quotes' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr' '--with-png-dir=/usr/lib' '--with-pear' '--with-curl' '--with-zlib-dir=/usr/lib' '--with-ttf' '--enable-gd-native-ttf' '--with-xml' '--with-openssl' [2002-03-12 10:02:47] [EMAIL PROTECTED] Here is an update from my server. Sorry guys that I do not have my own server but this is all I can do to track this down. I am working on getting my own server up locally to test this but haven't had luck yet. Here is the comments from my server host. We have been attempting to correct this problem today by re-compiling PHP and GD, but to no avail at this point. For some unknown reason the GD test programs won't even work because of the gdImageCreateTrueColor problems (yet GD compiles fine). [2002-03-12 09:50:11] [EMAIL PROTECTED] i got the same errors with the precomiled win32 version of php 4.1.2. Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in c:\www\scripts\cddb_appl\crop.php on line 46 Is there a fault in the config file (i.e. should php.ini:extension=php_gd.dll read php_gd2.dll?) or what? [2002-03-11 15:55:29] [EMAIL PROTECTED] I rent my server from a virtual host so I do not have much control over the server. This might not be a bug but a error in them compiling it but it should be reported just in case. I had a script that was working that used imagecreatetruecolor with a older version of PHP, I think it was two versions back. Anyway, my server updated to php 4.1.2 and it 2.01 of GD and after that my script would only return this error. Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in /home/member/public_html/website/admin/imgfunctions.php on line 39 As I said it is a virtual server but phpinfo produced this, './configure' '--with-mysql' '--with-apache=../apache_1.3.23' '--enable-track-vars' '--with-gd=/usr/gd-2.0.1' '--with-jpeg-dir=/usr' '--with-png-dir=/usr/local/lib' '--with-zlib-dir=/usr/local/include' This might not be a bug but an error in my server compiling the latest version of PHP. Please email me at [EMAIL PROTECTED] if an error is obvious that you can see that I can't and I will contact my host and see if that is the problem and then this bug report can be closed. -- Edit this bug report at http://bugs.php.net/?id=16002&edit=1
Bug #16528 Updated: Incompatible behaviour of arrays (and maybe other vars)
ID: 16528 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type: Variables related Operating System: linux PHP Version: 4.1.2 New Comment: This is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2002-04-10 06:21:40] [EMAIL PROTECTED] Can you try 4.2.0RC2 or 3 from www.php.net/~derick? [2002-04-10 06:05:18] [EMAIL PROTECTED] In PHP 4.0 you can write the following: ... $a=''; if ( empty($a['bla']) ) ... There are no errors or warnings, even if all warnings has been put on (as we do). in PHP 4.1 this code complains the missing index 'bla': Warning: Uninitialized string offset: 0 in Workarround: if ( empty($a) and empty($a['bla']) ) which seems not to be very logical. $a['bla'] must be empty, if $a is empty... -- Edit this bug report at http://bugs.php.net/?id=16528&edit=1
