Bug #15792 Updated: sapi_apache2.c:247
ID: 15792
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Apache2 related
Operating System: GNU/Linux
PHP Version: 4.1.2
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-20 15:02:22] [EMAIL PROTECTED]
reclassified
[2002-03-20 15:00:40] [EMAIL PROTECTED]
Try latest CVS snapshot from http://snaps.php.net/ as this
should be fixed there.
[2002-03-20 14:54:00] [EMAIL PROTECTED]
I just want to say I got this same error and I have
Mandrake 8.1.
[root@irc-server php-4.1.2]# ./configure
--with-apxs2=/www/bin/apxs --without-mysql --quiet
That's my configure line. It works without any errors.
Hope this bug is fixed soon. Thanks in advance. :)
[2002-03-11 01:47:02] [EMAIL PROTECTED]
Having the same problem with apache 2.0.32, PHP 4.1.2, Linux kernal
2.2.18, gcc 2.91.66, make 3.77, zlib 1.1.3, mysql 3.23.47, posgresql
7.2.
/etc/ld.so.cache has all the various shared libraries listed (and then
some).
Apache, zlib, mysql, postresql all load and operate fine (with limited
testing)
PHP however:
'./configure' \
'--with-zlib' \
'--with-zlib-dir=/usr/local/zlib' \
'--with-apxs2=/usr/local/apache2/bin/apxs' \
'--with-pgsql=shared,/usr/local/pgsql' \
'--with-mysql=shared,/usr/local/mysql' \
'--enable-force-cgi-redirect' \
'--enable-debug' \
configures fine.
make results in
sapi_apache2.c: In function `php_apache_sapi_register_variables':
sapi_apache2.c:148: warning: initialization discards `const' from
pointer target
type
sapi_apache2.c: In function `php_input_filter':
sapi_apache2.c:248: incompatible type for argument 4 of
`ap_get_brigade'
sapi_apache2.c:248: too few arguments to function `ap_get_brigade'
sapi_apache2.c: In function `php_register_hook':
sapi_apache2.c:409: warning: passing arg 2 of `ap_register_input_filter'
from in
compatible pointer type
make[3]: *** [sapi_apache2.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
make then ends.
The make compile line that results in this error is
make[3]: Entering directory `/usr/local/php-4.1.2/sapi/apache2filter'
/bin/sh /usr/local/php-4.1.2/libtool --mode=compile
/usr/local/php-4.1.2/meta_ccld -I.
-I/usr/local/php-4.1.2/sapi/apache2filter -I/usr/local/php-4.1.2/main
-I/usr/local/php-4.1.2 -I/usr/local/apache2/include
-I/usr/local/php-4.1.2/Zend -I/usr/local/mysql/include
-I/usr/local/php-4.1.2/ext/xml/expat -D_REENTRANT
-I/usr/local/php-4.1.2/TSRM -g -O2 -pthread -Wall -DZTS -prefer-pic -c
sapi_apache2.c
/usr/local/php-4.1.2/meta_ccld -I.
-I/usr/local/php-4.1.2/sapi/apache2filter -I/usr/local/php-4.1.2/main
-I/usr/local/php-4.1.2 -I/usr/local/apache2/include
-I/usr/local/php-4.1.2/Zend -I/usr/local/mysql/include
-I/usr/local/php-4.1.2/ext/xml/expat -D_REENTRANT
-I/usr/local/php-4.1.2/TSRM -g -O2 -pthread -Wall -DZTS -c
sapi_apache2.c -fPIC -DPIC -o sapi_apache2.lo
I've found some old notes on earlier releases of PHP 4 with Apache 2
that this bug exists and has been worked around slightly by changing a
line in
PHPROOT/sapi/apache2filter/sapi_apache2.c
from
if ((rv = ap_get_brigade(f->next, bb, mode, readbytes)) !=APR_SUCCESS)
{
return rv;
to
if ((rv = ap_get_brigade(f->next, bb, mode)) !=APR_SUCCESS) {
return rv;
I tried this with no success. Not having worked on any of this code in
the past, I am facing a daunting task trying to debug this. If anyone
has any insight, I would greatly appreciate it. Otherwise, I am going
to go back to Apache 1.3.23 and PHP 3.0.18.
Thanks in advance
Richard
http://www.haimann.com
[2002-03-09 12:30:32] [EMAIL PROTECTED]
I get the same thing exactly. I am using apache-2.0.23, and my compiler
is gcc-3.0.3. This might have a bearing.
Richard.
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/15792
--
Edit this bug report at http://bugs.php.net/?id=15792&edit=1
Bug #12451 Updated: compilation halts on libmysql extension
ID: 12451 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: MySQL related Operating System: Linux 2.4.7 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-30 19:14:46] [EMAIL PROTECTED] This still occurs in php4-200203301500. [2002-03-20 19:05:39] [EMAIL PROTECTED] Could you please try the very latest snapshot: http://snaps.php.net/php4-200203201500.tar.gz --Jani [2002-03-20 16:50:28] [EMAIL PROTECTED] ./configure --with-apache=../apache_1.3.20/ --enable-track-vars --with-kerberos --with-imap-ssl --with-imap --with-mysql --with-gettext=../gettext-0.10.40/ --with-xml --with-gd --enable-ftp gcc -I/home/www/src/php4-200203201200/ext/mysql/libmysql -I/home/www/src/php4-200203201200/ext/mysql -I/home/www/src/php4-200203201200/ext/mysql -DPHP_ATOM_INC -I/home/www/src/php4-200203201200/include -I/home/www/src/php4-200203201200/main -I/home/www/src/php4-200203201200 -I/home/www/src/apache_1.3.20/src/include -I/home/www/src/apache_1.3.20/src/os/unix -I/home/www/src/php4-200203201200/Zend -I/usr/include/imap -I/home/www/src/php4-200203201200/ext/xml/expat -I/home/www/src/php4-200203201200/TSRM -g -O2 -c /home/www/src/php4-200203201200/ext/mysql/libmysql/libmysql.c -o ext/mysql/libmysql/libmysql.o && echo > ext/mysql/libmysql/libmysql.lo In file included from /home/www/src/php4-200203201200/ext/mysql/libmysql/libmysql.c:5: /home/www/src/php4-200203201200/ext/mysql/libmysql/global.h:136:22: operator 'EOL' has no left operand In file included from /home/www/src/php4-200203201200/ext/mysql/libmysql/libmysql.c:5: /home/www/src/php4-200203201200/ext/mysql/libmysql/global.h:498:22: operator 'EOL' has no left operand In file included from /home/www/src/php4-200203201200/ext/mysql/libmysql/libmysql.c:12: /home/www/src/php4-200203201200/ext/mysql/libmysql/m_string.h:205:36: operator '==' has no right operand make: *** [ext/mysql/libmysql/libmysql.lo] Error 1 [root@mario php4-200203201200]# [2002-03-20 16:47:11] [EMAIL PROTECTED] This bug is openned again... In PHP 4.1.2 with manualy recompiled (rpm --rebuild) Mysql libraries [2002-03-01 15:07:01] [EMAIL PROTECTED] I have this error to on my Cobalt Raq 4 :( 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/12451 -- Edit this bug report at http://bugs.php.net/?id=12451&edit=1
Bug #14348 Updated: Major PHP memory corruption? (with testcase)
ID: 14348 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Apache related Operating System: Windows XP Professional PHP Version: 4.0.6 New Comment: Im using winxp with php 4.2 rc4 and apache 2.0.35 and im getting the same problem, tried the flush command in the ini but no joy, does no one know how to fix this, its a nightmare, mine mainly does the reloading over and over in IE presumably because its receiving corrupted data so reloads Previous Comments: [2002-04-18 09:25:01] [EMAIL PROTECTED] Please try PHP 4.2.0RC4 from http://www.php.net/~derick/ [2002-04-17 04:07:14] [EMAIL PROTECTED] I have got same probleme with Apache/1.3.22 (Win32) PHP/4.1.1 (AppServ 1.5 package) when asking "big" pages like PhpNuke or OsCommerce [2001-12-05 08:25:29] [EMAIL PROTECTED] I've just tried that - the same problems occur, unfortunately :-( [2001-12-05 07:12:58] [EMAIL PROTECTED] Just a suggestion: can you try if this also is true for RC3 from http://phpuk.org/~james/php-4.1.0RC3-win32.zip ? [2001-12-05 06:57:05] [EMAIL PROTECTED] Right. This is basically bug 14222 in another guise - I can't see how to add comments to that bug. In bug #14222 it shows the type of corruption I've *sometimes* had reports of seeing with Apache 1.3.20-1.3.22, PHP 4.0.6 on both NT4SP6 and W2KSP2. Mainly corruption like what was linked to in http://tugs.imp.ch/index.html.2 but sometimes like this: http://tugs.imp.ch/index.html.3 And then yesterday I upgraded to Windows XP, and initially I was getting corruption in parts of a large PHP page. I rebooted, and started getting (for the first time) the symptom where the page would just keep reloading and reloading and reloading. I have a testcase now which causes the problem most of the time on IE6 and IE5.5 - continual reloading - since the page of this testcase is made up of HTML comments, I can see various numbers of the point at which HTML loading failed before restarting - e.g. \n"); } print "Finished\n"; ?> On Mozilla (recent nightly build), it behaves differently - the page cuts off at a random point (you can see this by doing View Source), but does not continually reload. Intrigued by the difference, I did a wget of the script to see what was actually coming from the webserver. I got the result of test.php?count=50 It got to iteration 1547, then it went ]XT[<80>^@^@^@^@]test[^@<90>^^<81>] --> and then restarted the count at iteration 214! (note: the square brackets delimit the reversed colour characters in the 'less' filereader - showing null characters and high-eighth-bit characters) It continued up along until iteration 439, then went and jumped to iteration 1764. Then at iteration 2409, it printed and continued on from iteration 896... etc. Then we get to 3056, and it goes
Bug #13400 Updated: ftp functions are sometimes REALLY slow
ID: 13400 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: FTP related Operating System: Red Hat Linux 7.1 PHP Version: 4.0.6 New Comment: I have met this problem on redhat7.2 with proftpd1.2.4, I find that starting proftpd with argument " -d 3" can solve this problem. Previous Comments: [2001-09-22 15:24:41] [EMAIL PROTECTED] I lately installed ProFTPD. This is on of the fastest FTP daemons I know. I've made a site which heavily uses FTP connections to a computer in the same subnet (100Mbit connection between the two). It's really strange. Sometimes the ftp functions (especially ftp_nlist and ftp_rawlist) work fine, sometimes it takes like 5 minutes before the call to the function ends with an empty array as a result... this is really annoying. I've searched user submitted notes about this problem, but couldn't find anything. I don't know if this is a known issue, or maybe it's just a configuration problem on one of the two involved Linux PC's. What I do know is when I restart httpd, the slowdown is always over immediately. I DO close every ftp connection I make! Please help... -- Edit this bug report at http://bugs.php.net/?id=13400&edit=1
Bug #16717 Updated: simply not working - zero bytes
ID: 16717 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: windows PHP Version: 4.1.2 New Comment: I do not ask for help, I think I do everything as written in book. And I know people in lists having the same problem. As I said, the session files in the e:\temp directory all have zero length, thus I can not register any variable, everytime I use them, PHP behaves as they are new (i.e. forgets the past value assigned to them.) Previous Comments: [2002-04-20 18:22:14] [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 [2002-04-20 18:13:53] [EMAIL PROTECTED] I'm using PHP 4.1.2 with Win2k Adv. Server with IIS. As I was trying to write a new script with sessions, I saw that even the simplest examples in the manual does not work. The count variable is never incremented for example. I use $_SESSION, and in php.ini I closed register globals, and set session directory to e:\temp. I got session files created in that directory but they are always with zero length, whether I use cookies or URL rewriting. If I don't say session_start() I got no cookies nor rewrited URLs at all. -- Edit this bug report at http://bugs.php.net/?id=16717&edit=1
Bug #15632 Updated: MSSQL querys cause major problems
ID: 15632 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.1.1 New Comment: After some hasling with the configuration, I have found a solution (for both mod_php and CGI) in setting the mssql.compatability_mode option to 'Off': mssql.compatability_mode = Off I also noticed this bugreport, with the same solution: http://bugs.php.net/bug.php?id=15890 Previous Comments: [2002-04-20 19:06:29] [EMAIL PROTECTED] I experience the same problem using Apache 1.3.20 on Windows 2000. The bug shows with mod_php and PHP as CGI (both 4.1.2). SQL Server 2000 (Dev. Ed.) is installed on the same machine. Connecting to the server and selecting a database is no problem, but any call to mssql_query() causes PHP to crash. I find no messages in the errorlog (except for a 'Premature end of script headers' with the CGI version). Interesting is the fact that mssql_query() behaves as expected (no errors) only if the query returns 0 rows. [2002-02-20 17:09:38] [EMAIL PROTECTED] Additonal info: This occurs under apache as well, but I get an internal script error. The problem occurs when a call to mssql_query matches at least one row. If a query does not match anything, PHP does not crash. But if it does, it crashes. [2002-02-20 14:16:09] [EMAIL PROTECTED] Reopened. [2002-02-20 13:45:03] [EMAIL PROTECTED] Hrmm, can't seem to reopen. The status box only shows 'Bogus' [2002-02-20 13:43:28] [EMAIL PROTECTED] Sorry. With the above configuration, calls to at least mssql_query(); result in a PHP timeout. PHP apparently continues to run, or at least the webserver thinks it is, and the users browser does not display a new page until PHP times out. Behavior is weird, and an example is perhaps weird. http://bugs.php.net/15632 -- Edit this bug report at http://bugs.php.net/?id=15632&edit=1
Bug #15632 Updated: MSSQL querys cause major problems
ID: 15632 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.1.1 New Comment: I experience the same problem using Apache 1.3.20 on Windows 2000. The bug shows with mod_php and PHP as CGI (both 4.1.2). SQL Server 2000 (Dev. Ed.) is installed on the same machine. Connecting to the server and selecting a database is no problem, but any call to mssql_query() causes PHP to crash. I find no messages in the errorlog (except for a 'Premature end of script headers' with the CGI version). Interesting is the fact that mssql_query() behaves as expected (no errors) only if the query returns 0 rows. Previous Comments: [2002-02-20 17:09:38] [EMAIL PROTECTED] Additonal info: This occurs under apache as well, but I get an internal script error. The problem occurs when a call to mssql_query matches at least one row. If a query does not match anything, PHP does not crash. But if it does, it crashes. [2002-02-20 14:16:09] [EMAIL PROTECTED] Reopened. [2002-02-20 13:45:03] [EMAIL PROTECTED] Hrmm, can't seem to reopen. The status box only shows 'Bogus' [2002-02-20 13:43:28] [EMAIL PROTECTED] Sorry. With the above configuration, calls to at least mssql_query(); result in a PHP timeout. PHP apparently continues to run, or at least the webserver thinks it is, and the users browser does not display a new page until PHP times out. Behavior is weird, and an example is perhaps weird. http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". 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/15632 -- Edit this bug report at http://bugs.php.net/?id=15632&edit=1
Bug #16717 Updated: simply not working - zero bytes
ID: 16717 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: windows PHP Version: 4.1.2 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-04-20 18:13:53] [EMAIL PROTECTED] I'm using PHP 4.1.2 with Win2k Adv. Server with IIS. As I was trying to write a new script with sessions, I saw that even the simplest examples in the manual does not work. The count variable is never incremented for example. I use $_SESSION, and in php.ini I closed register globals, and set session directory to e:\temp. I got session files created in that directory but they are always with zero length, whether I use cookies or URL rewriting. If I don't say session_start() I got no cookies nor rewrited URLs at all. -- Edit this bug report at http://bugs.php.net/?id=16717&edit=1
Bug #16717: simply not working - zero bytes
From: [EMAIL PROTECTED] Operating system: windows PHP version: 4.1.2 PHP Bug Type: Session related Bug description: simply not working - zero bytes I'm using PHP 4.1.2 with Win2k Adv. Server with IIS. As I was trying to write a new script with sessions, I saw that even the simplest examples in the manual does not work. The count variable is never incremented for example. I use $_SESSION, and in php.ini I closed register globals, and set session directory to e:\temp. I got session files created in that directory but they are always with zero length, whether I use cookies or URL rewriting. If I don't say session_start() I got no cookies nor rewrited URLs at all. -- Edit bug report at http://bugs.php.net/?id=16717&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16717&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16717&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16717&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16717&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16717&r=support Expected behavior: http://bugs.php.net/fix.php?id=16717&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16717&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16717&r=submittedtwice
Bug #15800 Updated: german characters cannot be stored
ID: 15800
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: WDDX related
Operating System: Win2000
PHP Version: 4.1.1
New Comment:
Using PHP 4.1.2 and can confirme the error.
It's very inconsisten!
At first I wasn't using setlocale() and all seamed fine. But after I
called setlocale() the wddx serialize failed all the time!
Multiple calls of setlocale() produce 2 different results that
alternate. After every Apache restart the results changes sort of
randomly! If setlocale() is commented out, the the last result remains
(even after apache is restarted).
It seams as if setlocale() is writting something wrong to the apache
conf.
Don't know if a reboot would help, but if not my wddx serializetion
would stay broken :(
I recommend not to us it!!!
Following code was used to test :
";
echo htmlspecialchars($ser) . "\n";
var_dump($des);
echo "";
?>
Previous Comments:
[2002-02-28 19:25:21] [EMAIL PROTECTED]
Summary:
german characters cannot be stored
by wddx_serialize_vars
To make it easier for you to reproduce
the bug i write a little step-by-step
summary:
1) Setting the correct local zone
setlocale("LC_ALL","german");
2) Writing some test-data with german characters
ÄÖÜäüö
3) Pushing the test-data into wddx_serialize_vars
on a Win2000 Server. Results on Win2000:
ÄÜä
Results on Linux (correct values):
ÄÖÜäöü
4) Reading the values back (from the saved wddx package)
Ä Üä
It seams like that only some locale characters (ÄÜä) are recognized on
an Win2000 Server. With the same script
and the same data, there are no problems on an Linux
Server.
Happy Debugging :-)
Thomas
--
Edit this bug report at http://bugs.php.net/?id=15800&edit=1
Bug #16704 Updated: Screwed up handles while connection multiple DBs
ID: 16704
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: OCI8 related
Operating System: Windows 2000
PHP Version: 4.1.2
New Comment:
Can't comment on "if it's gone".
Do you mean that in all connection you establish you use the same
username/passwort/host (or sid) in your context?
Previous Comments:
[2002-04-20 16:57:15] [EMAIL PROTECTED]
Hi, thanx for your fast reply!
The true version is 4.0.6. I selected 4.1.2 as there was no better
choice.
I have an aitional Note: Exactly the same problem existed for Informix
AND Mysql:
http://bugs.php.net/bug.php?id=15628
The mysql one cane be found also here.
I browsed through all OCI8 related bugs but I couldn't find this bug,
so I considered it is still existing in 4.1.2.
Antoher problem: I also tried to read the changelogs but why the hell
are there no changelogs in new releases??
updating of 4.0.2rcx is really risky as it is aproduction environment.
Do you think this problem is really gone?
[2002-04-19 21:08:12] [EMAIL PROTECTED]
Which version is it now? In the Report field you write 4.1.2, but in
the body you write 4.0.6
In the latter case, please test a newer version first (even 4.2.0rc4
from php.net/~derick if possible).
[2002-04-19 15:10:19] [EMAIL PROTECTED]
I would like to report a problem and ask for help with php 4.0.6 and
Oracle 8 Support.
When you try to use more than one connection, the last connection
created is the one that receives every statement.
I found a workaround but I'm not quite sure if it really works
everytime (not enough testing yet):
You could do the following for each connections and somehow they are
available
after that:
for ($i=1; $i <= 2; $i++)
{
$oci_connection_new = OCILogon ($oracle_user, $oracle_pass,
$oracle_inst);
}
I reviewed $oci_connection_new and figured out thata it changes the
recource id after the loop
Thomas
--
Edit this bug report at http://bugs.php.net/?id=16704&edit=1
Bug #16716: WDDX's and are ignored.
From: [EMAIL PROTECTED] Operating system: Win 2k PHP version: 4.2.0 PHP Bug Type: WDDX related Bug description: WDDX's and are ignored. WDDX seams to be an unpopular standard and kind of dead. I had trouble finding usable docs about it. Is there a substitute? If so, is there PHP function for it? I don't think that following has a high priority but it would be good if you at least could have a look at following problem. It's not mentioned which version of WDDX PHP is using, but the current implementation ignores some tags that have been in WDDX since V0.9 (1998). - PHP just ignore(!) the -tag. Couldn't you at least transform it to a string instead of just dumping it? - Also is not supported. I get a funny result. For a WDDX DTD V=0.9 (1998) See: http://www.macromedia.com/v1/documents/objects/whitepapers/wddx_dtd.txt The PHP sample: 1998-06-12T04:32:12 John Doe Jane Doe 34 31 EOD; $des = wddx_deserialize($wddx); echo ""; var_dump($des); echo ""; ?> -- Edit bug report at http://bugs.php.net/?id=16716&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16716&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16716&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16716&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16716&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16716&r=support Expected behavior: http://bugs.php.net/fix.php?id=16716&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16716&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16716&r=submittedtwice
Bug #16704 Updated: Screwed up handles while connection multiple DBs
ID: 16704
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: OCI8 related
Operating System: Windows 2000
PHP Version: 4.1.2
New Comment:
Hi, thanx for your fast reply!
The true version is 4.0.6. I selected 4.1.2 as there was no better
choice.
I have an aitional Note: Exactly the same problem existed for Informix
AND Mysql:
http://bugs.php.net/bug.php?id=15628
The mysql one cane be found also here.
I browsed through all OCI8 related bugs but I couldn't find this bug,
so I considered it is still existing in 4.1.2.
Antoher problem: I also tried to read the changelogs but why the hell
are there no changelogs in new releases??
updating of 4.0.2rcx is really risky as it is aproduction environment.
Do you think this problem is really gone?
Previous Comments:
[2002-04-19 21:08:12] [EMAIL PROTECTED]
Which version is it now? In the Report field you write 4.1.2, but in
the body you write 4.0.6
In the latter case, please test a newer version first (even 4.2.0rc4
from php.net/~derick if possible).
[2002-04-19 15:10:19] [EMAIL PROTECTED]
I would like to report a problem and ask for help with php 4.0.6 and
Oracle 8 Support.
When you try to use more than one connection, the last connection
created is the one that receives every statement.
I found a workaround but I'm not quite sure if it really works
everytime (not enough testing yet):
You could do the following for each connections and somehow they are
available
after that:
for ($i=1; $i <= 2; $i++)
{
$oci_connection_new = OCILogon ($oracle_user, $oracle_pass,
$oracle_inst);
}
I reviewed $oci_connection_new and figured out thata it changes the
recource id after the loop
Thomas
--
Edit this bug report at http://bugs.php.net/?id=16704&edit=1
Bug #16715: array_unique results in only one entry in the array
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.1.2 PHP Bug Type: Arrays related Bug description: array_unique results in only one entry in the array The following code should demonstrate that unusual behavior (becaue I'm still not convinced that this is a bug) $input = array ( array (1,1), array (1,2), array(1,2), array(1,1) ); $result = array_unique ($input); print_r($result); The result is : Array ( [0] => Array ( [0] => 1 [1] => 1 ) ) This was not what I was expecting. I was expecting the following result : Array ( [0] => Array ( [0] => 1 [1] => 1 ) [1] => Array ( [0] => 1 [1] => 2 ) ) This is the result You get if You use PHP Version 4.0.4pl1 and before for example. So it is up to You, if You call this a bug or if I just have missused the function array_unique because I was not using a one dimensional array. Hopefully that helps You and me. Cheers Thomas -- Edit bug report at http://bugs.php.net/?id=16715&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16715&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16715&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16715&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16715&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16715&r=support Expected behavior: http://bugs.php.net/fix.php?id=16715&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16715&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16715&r=submittedtwice
Bug #16714: explode()-function is not working correctly with Carriage Returns
From: [EMAIL PROTECTED] Operating system: Windows XP Pro PHP version: 4.2.0 PHP Bug Type: Scripting Engine problem Bug description: explode()-function is not working correctly with Carriage Returns Hello, I just installed PHP4.2.0 RC4 on my System using IIS 5.1 with all patches. I installed PHP as ISAPI module, I ran before PHP 4.1.2 as CGI where the following worked correctly: A propgram running in background saves every 10 secons the actual traffic into a file "jetzt.log", each line is separeted with a carraige return and a line feed "\r\n" - like any other textfile under windows. For example it looks as the following: 34.865 9.763 0 Tage 1 Stunden 9 Minuten 41 Sekunden 16 And here is my script: \r\n"; echo "Upstream: ".$haufen[1]."\r\n"; echo "Uptime: ".$haufen[2]."\r\n"; echo "CPU Usage: ".$haufen[3]."%"; ?> In PHP 4.1.2 the content of jetzt.log was seperated into the array $haufen and the script printed it fine out. Since PHP 4.2.0 all content of jetzt.log is written into $haufen[0], including carriage returns and line feeds. It is the same when I only use "\r" as seperator; when I use "\n", the content is correctly seperated but at the end of each line there is stil a carriage return. I found a comparable problem at http://bugs.php.net/bug.php?id=3428 Best regards Mark Aslan Kuschel -- Edit bug report at http://bugs.php.net/?id=16714&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16714&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16714&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16714&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16714&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16714&r=support Expected behavior: http://bugs.php.net/fix.php?id=16714&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16714&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16714&r=submittedtwice
Bug #16203 Updated: Cannot configure with ming
ID: 16203
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Ming related
Operating System: FreeBSD 4.3-STABLE
PHP Version: 4.2.0RC4
New Comment:
Was the configure line same as before? (ie. same as in your
first note)
It looks like for some reason, the -lfreetype is not added
to the LIBS. Could you send me the whole config.log, please?
Previous Comments:
[2002-04-20 12:30:47] [EMAIL PROTECTED]
Here's what config.log says :
configure:37687: checking for Ming_useSWFVersion in -lming
configure:37714: gcc -o conftest -g -O2
-L/usr/home//local/lib
-R/usr/local/ssl/lib -L/usr/local/ssl/lib -R/usr/local/lib
-L/usr/local/lib -R/usr/home//src/curl-7.9/lib
-L/usr/home//src/curl-7.9/lib -R/usr/home//local/lib
-L/usr/home//local/lib -R/lib -L/lib conftest.c -lming -lgd -lpng
-lz -ljpeg -lz -lm -lz -lxml2 -lcurl -lcrypto -lssl -lcurl -lz -lcrypt
-lssl -lcrypto -lm -lcrypt >&5
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Init_FreeType'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Load_Glyph'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Done_Face'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Get_Kerning'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Get_Char_Index'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Get_Glyph'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Glyph_To_Bitmap'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Set_Char_Size'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Done_Glyph'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Glyph_Get_CBox'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_New_Face'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Glyph_Transform'
configure:37717: $? = 1
configure: failed program was:
#line 37695 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
#ifdef __cplusplus
extern "C"
#endif
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char Ming_useSWFVersion ();
int
main ()
{
Ming_useSWFVersion ();
;
return 0;
}
configure:37734: result: no
configure:37748: error: Ming library 0.2a or greater required.
[2002-04-19 11:32:00] [EMAIL PROTECTED]
What does config.log has to say about this?
[2002-04-19 11:14:04] [EMAIL PROTECTED]
Just tested with 4.2.0 RC4 and the bug is still there.
[2002-03-27 22:01:08] [EMAIL PROTECTED]
tested with php4-200203271800 and erro exists again.
configure:37658: checking for Ming_useSWFVersion in -lming
configure:37685: gcc -o conftest -g -O2 -DMOD_SSL=208106 -DEAPI
-DEAPI_MM -DUSE_EXPAT
-L/usr/lib
-R/usr/local/ssl/lib -L/usr/local/ssl/lib -R/usr/local/lib
-L/usr/local/lib -R/usr/X11R6/lib -L/usr/X11R6/lib conftest.$
/usr/local/lib/libc-client4.so: undefined reference to `mm_expunged'
/usr/local/lib/libc-client4.so: undefined reference to `mm_diskerror'
/usr/local/lib/libc-client4.so: undefined reference to `mm_lsub'
/usr/local/lib/libc-client4.so: undefined reference to `mm_flags'
/usr/local/lib/libc-client4.so: undefined reference to `mm_fatal'
/usr/local/lib/libc-client4.so: undefined reference to `mm_nocritical'
/usr/local/lib/libc-client4.so: undefined reference to `mm_notify'
/usr/local/lib/libc-client4.so: undefined reference to `mm_searched'
/usr/local/lib/libc-client4.so: undefined reference to `mm_status'
/usr/local/lib/libc-client4.so: undefined reference to `mm_login'
/usr/local/lib/libc-client4.so: undefined reference to `mm_list'
/usr/local/lib/libc-client4.so: undefined reference to `mm_critical'
/usr/local/lib/libc-client4.so: undefined reference to `mm_exists'
/usr/local/lib/libc-client4.so: undefined reference to `mm_log'
/usr/local/lib/libc-client4.so: undefined reference to `mm_dlog'
configure:37688: $? = 1
configure: failed program was:
#line 37666 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
#ifdef __cplusplus
extern "C"
#endif
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char Ming_useSWFVersion ();
int
main ()
{
Ming_useSWFVersion ();
;
return 0;
}
configure:37705: result: no
configure:37719: error: Ming library 0.2a or greater required.
[2002-03-27 10
Bug #16712 Updated: pointers and globals don't work together
ID: 16712
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Class/Object related
Operating System: Linux RedHat 7.2
PHP Version: 4.1.2
New Comment:
First, there are NO pointers in PHP, these are called references,
please stick to this term.
Second, yes, variables in a function imported from the global namespace
are in fact references to the global variables. So if working with
references on references in this context does not work.
For objects, you should be out of trouble in PHP5/ZE2 as they aren't
copied anymore so you don't need a reference to them.
Previous Comments:
[2002-04-20 10:43:56] [EMAIL PROTECTED]
The assignment does work while staying local btw... so an echo $b->v;
within ta() would display 1 as it should.
I'm not sure about the exact implementation of PHP, but i think globals
ARE pointers, right ? That would explain it (though i'm not happy with
it).
If so the line
global $b;
would do the same as
$b(local) =& $b(global);
and thus a reassignment of $b to another point would seperate him from
$b(global).
Still i would like to re-reference my $b(global) in a local function.
Is there maybe a workaround or is it an impossibility ?
[2002-04-20 10:31:48] [EMAIL PROTECTED]
While using classes, pointers and globals I noticed data not being
migrated to the globalsphere due to pointerassignments.
[Example]
class test {
var $v=0;
function set($i) { $this->v = $i; }
}
$a = new test();
$b =& new test();
$c =& $b;
function ta() {
global $a,$b,$c;
$a->set(1);
$b =& $a;
$c->set(2);
}
ta();
echo "$a->v,$b->v,$c->v";
[/example]
This should display 1,1,2 since $b has been set to $a, but this
pointer-assigment isn't emigrated to the global $b.
I have done many expirements with it to see if i could further specify
the bug... at first i thought it was destroying non-globals that got
pointed too at the end of the functioncall and thus (accidently)
destroying the pointers in the process, but then if i would point $a to
$b and export them both, neither should be destroyed, so the reference
should stay intact... it isn't.
So the only thing that remains is that function-local
pointer-assigments not seem to affect my global var.
--
Edit this bug report at http://bugs.php.net/?id=16712&edit=1
Bug #16203 Updated: Cannot configure with ming
ID: 16203
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Ming related
Operating System: FreeBSD 4.3-STABLE
PHP Version: 4.2.0RC4
New Comment:
Here's what config.log says :
configure:37687: checking for Ming_useSWFVersion in -lming
configure:37714: gcc -o conftest -g -O2
-L/usr/home//local/lib
-R/usr/local/ssl/lib -L/usr/local/ssl/lib -R/usr/local/lib
-L/usr/local/lib -R/usr/home//src/curl-7.9/lib
-L/usr/home//src/curl-7.9/lib -R/usr/home//local/lib
-L/usr/home//local/lib -R/lib -L/lib conftest.c -lming -lgd -lpng
-lz -ljpeg -lz -lm -lz -lxml2 -lcurl -lcrypto -lssl -lcurl -lz -lcrypt
-lssl -lcrypto -lm -lcrypt >&5
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Init_FreeType'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Load_Glyph'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Done_Face'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Get_Kerning'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Get_Char_Index'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Get_Glyph'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Glyph_To_Bitmap'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Set_Char_Size'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Done_Glyph'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Glyph_Get_CBox'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_New_Face'
/usr/home//local/lib/libgd.so: undefined reference to
`FT_Glyph_Transform'
configure:37717: $? = 1
configure: failed program was:
#line 37695 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
#ifdef __cplusplus
extern "C"
#endif
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char Ming_useSWFVersion ();
int
main ()
{
Ming_useSWFVersion ();
;
return 0;
}
configure:37734: result: no
configure:37748: error: Ming library 0.2a or greater required.
Previous Comments:
[2002-04-19 11:32:00] [EMAIL PROTECTED]
What does config.log has to say about this?
[2002-04-19 11:14:04] [EMAIL PROTECTED]
Just tested with 4.2.0 RC4 and the bug is still there.
[2002-03-27 22:01:08] [EMAIL PROTECTED]
tested with php4-200203271800 and erro exists again.
configure:37658: checking for Ming_useSWFVersion in -lming
configure:37685: gcc -o conftest -g -O2 -DMOD_SSL=208106 -DEAPI
-DEAPI_MM -DUSE_EXPAT
-L/usr/lib
-R/usr/local/ssl/lib -L/usr/local/ssl/lib -R/usr/local/lib
-L/usr/local/lib -R/usr/X11R6/lib -L/usr/X11R6/lib conftest.$
/usr/local/lib/libc-client4.so: undefined reference to `mm_expunged'
/usr/local/lib/libc-client4.so: undefined reference to `mm_diskerror'
/usr/local/lib/libc-client4.so: undefined reference to `mm_lsub'
/usr/local/lib/libc-client4.so: undefined reference to `mm_flags'
/usr/local/lib/libc-client4.so: undefined reference to `mm_fatal'
/usr/local/lib/libc-client4.so: undefined reference to `mm_nocritical'
/usr/local/lib/libc-client4.so: undefined reference to `mm_notify'
/usr/local/lib/libc-client4.so: undefined reference to `mm_searched'
/usr/local/lib/libc-client4.so: undefined reference to `mm_status'
/usr/local/lib/libc-client4.so: undefined reference to `mm_login'
/usr/local/lib/libc-client4.so: undefined reference to `mm_list'
/usr/local/lib/libc-client4.so: undefined reference to `mm_critical'
/usr/local/lib/libc-client4.so: undefined reference to `mm_exists'
/usr/local/lib/libc-client4.so: undefined reference to `mm_log'
/usr/local/lib/libc-client4.so: undefined reference to `mm_dlog'
configure:37688: $? = 1
configure: failed program was:
#line 37666 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
#ifdef __cplusplus
extern "C"
#endif
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char Ming_useSWFVersion ();
int
main ()
{
Ming_useSWFVersion ();
;
return 0;
}
configure:37705: result: no
configure:37719: error: Ming library 0.2a or greater required.
[2002-03-27 10:32:48] [EMAIL PROTECTED]
This should be fixed in CVS. (HEAD)
Can you please verify it and let me know and I'll merge
the fix to PHP 4.2.0 branch too.
--Jani
[2002-03-26 20:48:08] [EMAIL PROTECTED]
I'm using FreeBSD-4.5. Problem st
Bug #16635 Updated: dio_read() leaks memory
ID: 16635 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Unknown/Other Function Operating System: x86/Linux PHP Version: 4.2.0 Assigned To: sterling New Comment: Cannot reproduce - this shouldn't happen. Previous Comments: [2002-04-18 19:12:30] [EMAIL PROTECTED] Assigned to Sterling who is the maintainer of this extension.. [2002-04-16 11:11:28] [EMAIL PROTECTED] I am using the RC4 of php4.2.0 with Apache/1.3.24 (Unix). Every time dio_read() is called in a script, the htttpd process uses more and more memory. ex.: $o = dio_read($fp,10); would let httpd grow by ca. x times of 10. unset($o) will not get the memory back. the httpd process would keep its size until the script terminates. Needing to call dio_read repeatidly makes it even worse. And using 1024 bytes blocks only slows the process of growing down. -- Edit this bug report at http://bugs.php.net/?id=16635&edit=1
Bug #16708 Updated: fgets handling of non-unix EOL markers
ID: 16708 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed -Bug Type: Feature/Change Request +Bug Type: Filesystem function related Operating System: Solaris 2.x PHP Version: 4.1.2 New Comment: This is actually a bug. There is also similar bug #16521 Previous Comments: [2002-04-20 11:05:47] [EMAIL PROTECTED] I forgot to change the status when I posted my last comment. [2002-04-20 11:00:34] [EMAIL PROTECTED] On Solaris, fgets doesn't recognize EOL other than LF. This code is used in the following examples... This file was created on macintosh using Simpletext and scp'd to a sun: cat dog hat dad mom boy you wow sun When you look at it w/ "od -a" on solaris (octaldump, with the "show named characters" flag), it looks like: 000 c a t ht d o g ht h a t cr d a d ht 020 m o m ht b o y cr y o u ht w o w ht 040 s u n ht 044 And the above php code creates this output: Array ( [0] => Array ( [0] => cat [1] => dog [2] => hat dad [3] => mom [4] => boy you [5] => wow [6] => sun [7] => ) ) od of the same file created with vi on solaris looks like: 000 c a t ht d o g ht h a t nl d a d ht 020 m o m ht b o y nl y o u ht w o w ht 040 s u n nl 044 and the output from the php code looks like: Array ( [0] => Array ( [0] => cat [1] => dog [2] => hat ) [1] => Array ( [0] => dad [1] => mom [2] => boy ) [2] => Array ( [0] => you [1] => wow [2] => sun ) ) For a file created on a PC, I imagine the resulting data would look right, but the last element of every array would contain an unseen CR. The different platforms use of different eol markers. This is widely acknowledged. Look at the last few users comments in the documentation for fgets, http://www.php.net/manual/en/function.fgets.php: "...Note that fgets() does not cope with MAC newlines (i.e. a single CR character, or "\r")..." "...If you are doing cross platform development where your PHP programs need to run on windows, unix and macs, or even are reading from files that were developed on various platforms, do not (I repeat DO NOT) use fgets(). This is because fgets(), as mentioned before, does not deal with carriage returns and line feeds for all systems..." [2002-04-20 05:37:32] [EMAIL PROTECTED] It works fine on windows and on mac. If it still doesn't work, provide the relevant code and reopen the report. -Tal [2002-04-19 18:12:45] [EMAIL PROTECTED] Currently, fgets() only recognizes \n (LF) as the end of line marker. It would be useful if it would also recognize CR/LF (pc) and CR (mac). -- Edit this bug report at http://bugs.php.net/?id=16708&edit=1
Bug #16713 Updated: Large upload produce "Unable to allocate xxx bytes" error in Apache
ID: 16713 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: Windows 98 PHP Version: 4.1.2 New Comment: This is fixed in PHP 4.2.0. (release is on Monday, 22th April). You can try the release candidate from here: http://www.php.net/~derick/ Previous Comments: [2002-04-20 11:33:27] [EMAIL PROTECTED] I use the default installation of PHPTriad (PHP 4.1.2 run as a CGI module on Apache 1.3.X). I increased the following variables on php.ini in an attempt to make large uploads work: upload_max_filesize: 32M post_max_size: 32M memory_limit: 64M max_execution_time: 3000 I use a standard upload form (with MAX_FILE_SIZE correctly set) and the .php file where the data are posted is a simple "print_r($_FILES)" to test if it works. However, everytime I upload a file over 5Mb, I get a "500 internal server error" after a relatively short time. The larger the file is, the longer it takes for the error to appear so I assume the problems occurs once PHP is called. Looking at the Apache log, I see the following: Premature end of script headers: c:/apache/php/php.exe FATAL: erealloc(): Unable to allocate 5872001 bytes So it means the large file makes the Apache session crash. I've been trying to make this work for over two weeks but files over 5Mb never work. Thanks -- Edit this bug report at http://bugs.php.net/?id=16713&edit=1
Bug #16713: Large upload produce "Unable to allocate xxx bytes" error in Apache
From: [EMAIL PROTECTED] Operating system: Windows 98 PHP version: 4.1.2 PHP Bug Type: Scripting Engine problem Bug description: Large upload produce "Unable to allocate xxx bytes" error in Apache I use the default installation of PHPTriad (PHP 4.1.2 run as a CGI module on Apache 1.3.X). I increased the following variables on php.ini in an attempt to make large uploads work: upload_max_filesize: 32M post_max_size: 32M memory_limit: 64M max_execution_time: 3000 I use a standard upload form (with MAX_FILE_SIZE correctly set) and the .php file where the data are posted is a simple "print_r($_FILES)" to test if it works. However, everytime I upload a file over 5Mb, I get a "500 internal server error" after a relatively short time. The larger the file is, the longer it takes for the error to appear so I assume the problems occurs once PHP is called. Looking at the Apache log, I see the following: Premature end of script headers: c:/apache/php/php.exe FATAL: erealloc(): Unable to allocate 5872001 bytes So it means the large file makes the Apache session crash. I've been trying to make this work for over two weeks but files over 5Mb never work. Thanks -- Edit bug report at http://bugs.php.net/?id=16713&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16713&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16713&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16713&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16713&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16713&r=support Expected behavior: http://bugs.php.net/fix.php?id=16713&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16713&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16713&r=submittedtwice
Bug #16670 Updated: php 4.1.0, cyrus-imapd.2.0.16, c-client compile-error
ID: 16670 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: linux / redhat 7.2 -PHP Version: 4.1.2 +PHP Version: 4.2.0 New Comment: I think the documentation needs to be updated as the imap-2001a found here: ftp://ftp.cac.washington.edu/imap/imap.tar.Z Has some changes to which header files are needed. Here is my make line for the imap stuff: # make slx SSLTYPE=unix SSLDIR=/www/openssl-0.9.6c/ssl/ SSLINCLUDE=/www/openssl-0.9.6c/include/ SSLLIB=/www/openssl-0.9.6c/lib/ And this is how I installed the files: # cp c-client/c-client.a /www/imap-2001a/lib/libc-client.a # cp c-client/*.h /www/imap-2001a/include/ And this is how I configured PHP: # ./configure --with-imap=/www/imap-2001a/ --with-imap-ssl=/www/openssl-0.9.6c/ And it configured, compiled and worked just fine. I also tried the 'make lnp...' target and that worked also without any problems. Please try with these yourself. Just remember to change the paths to be correct in your system. I will update the online documentation now. --Jani Previous Comments: [2002-04-20 07:30:00] [EMAIL PROTECTED] Hallo, at the first, thanks a lot for all your help's. How did you install the c-client? From RPM? NO, i need no kereberos, that was the id to installed the source-files and compiled. I have test the make-run with the folloes options make lrh (ha ha ===> need kereberos) with make lnp SSLTYPE=unix compiling php- error with make slx SSLTYPE=unix PASSWDTYPE=pam compiling php-error in this Night i have test with php-4.2.0RC4 (without kerberos) the configure was very good then come the first error the c-client was not complete Is crazzy, i have copy all the files in user/local/lib and include was stay in php-manual Then i have write a message to c-client-mailinglist In this FAQ stay this my compile from c-client this run was very ok. I have no id was the make file doing. i think the makefile can not control was is imap-c-client and was is cyrus. Pleas help Thanks a lot for help Best reagards [2002-04-19 22:15:40] [EMAIL PROTECTED] How did you install the c-client? From RPM? Compiled it yourself from sources? iirc, RH rpms have kerberos support buildin their c-client rpms and thus, you NEED to have the kerberos stuff installed too. This includes the -dev packages too. [2002-04-19 20:31:32] [EMAIL PROTECTED] hallo, i have compiled php-4.2.0RC4 on a new machine with suse 7.3 i think imap-ssl is ok. but now is the follow error configure:36521: result: no configure:36535: error: Sorry, I was not able to diagnose which libmcrypt version you have installed. i have installed libmcrypt-2.4.20 and mcrypt-2.5.10 with the php-configure script option --with-mcrypt=/usr/local/include the prefix from mcrypt and libcrypt is /usr/local i have no id but in the php config.log is this message cannot find -lgssapi_krb5 but on my suse i have no libgssapi_krb5 Thanks a lot for help Best reagards Achim [2002-04-19 10:25:05] [EMAIL PROTECTED] And what did happen with 4.2.0RC4 ??? And have you always done a clean configure / make between those different configures? [2002-04-19 07:39:21] [EMAIL PROTECTED] Hallo, Yes i have try RC4. I have first compile without all options, was all ok. At the second i have compile with mysql-support, was all ok. The next step i have compile with many options but without imap and imap-ssl, cyrus was enable, all was ok. (sorry a little problem was with DOM-support, my library was maby to old). in the next step i have compiled with mysql, openssl, cyrus, imap and imap-ssl, bull-shit . Ok. i think the problem is only the c-client. the biggest crazy step was the follow. i have compiled php4.0.6 with imap and imap-ssl, the configure say in this moment (was very good) yoer imap support nothing ssl please remove or --without-imap-ssl or so. i have then configure run und after this compile with cyrus, and imap but without imap-ssl, was very good. Please look the next, that's crazy !! I have the compiled php4.1.2 with mysql, openssl, cyrus and imap " *** but *** " without imap-ssl. the configure comes with an error and say your c-client is compiled with ssl pleas youse imap-ssl Thanks a lot for your help and a nice day Best reagards Achim The remainder of the comments for this report are too lon
Bug #16708 Updated: fgets handling of non-unix EOL markers
ID: 16708 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: Solaris 2.x PHP Version: 4.1.2 New Comment: I forgot to change the status when I posted my last comment. Previous Comments: [2002-04-20 11:00:34] [EMAIL PROTECTED] On Solaris, fgets doesn't recognize EOL other than LF. This code is used in the following examples... This file was created on macintosh using Simpletext and scp'd to a sun: cat dog hat dad mom boy you wow sun When you look at it w/ "od -a" on solaris (octaldump, with the "show named characters" flag), it looks like: 000 c a t ht d o g ht h a t cr d a d ht 020 m o m ht b o y cr y o u ht w o w ht 040 s u n ht 044 And the above php code creates this output: Array ( [0] => Array ( [0] => cat [1] => dog [2] => hat dad [3] => mom [4] => boy you [5] => wow [6] => sun [7] => ) ) od of the same file created with vi on solaris looks like: 000 c a t ht d o g ht h a t nl d a d ht 020 m o m ht b o y nl y o u ht w o w ht 040 s u n nl 044 and the output from the php code looks like: Array ( [0] => Array ( [0] => cat [1] => dog [2] => hat ) [1] => Array ( [0] => dad [1] => mom [2] => boy ) [2] => Array ( [0] => you [1] => wow [2] => sun ) ) For a file created on a PC, I imagine the resulting data would look right, but the last element of every array would contain an unseen CR. The different platforms use of different eol markers. This is widely acknowledged. Look at the last few users comments in the documentation for fgets, http://www.php.net/manual/en/function.fgets.php: "...Note that fgets() does not cope with MAC newlines (i.e. a single CR character, or "\r")..." "...If you are doing cross platform development where your PHP programs need to run on windows, unix and macs, or even are reading from files that were developed on various platforms, do not (I repeat DO NOT) use fgets(). This is because fgets(), as mentioned before, does not deal with carriage returns and line feeds for all systems..." [2002-04-20 05:37:32] [EMAIL PROTECTED] It works fine on windows and on mac. If it still doesn't work, provide the relevant code and reopen the report. -Tal [2002-04-19 18:12:45] [EMAIL PROTECTED] Currently, fgets() only recognizes \n (LF) as the end of line marker. It would be useful if it would also recognize CR/LF (pc) and CR (mac). -- Edit this bug report at http://bugs.php.net/?id=16708&edit=1
Bug #16708 Updated: fgets handling of non-unix EOL markers
ID: 16708 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Feature/Change Request Operating System: Solaris 2.x PHP Version: 4.1.2 New Comment: On Solaris, fgets doesn't recognize EOL other than LF. This code is used in the following examples... This file was created on macintosh using Simpletext and scp'd to a sun: cat dog hat dad mom boy you wow sun When you look at it w/ "od -a" on solaris (octaldump, with the "show named characters" flag), it looks like: 000 c a t ht d o g ht h a t cr d a d ht 020 m o m ht b o y cr y o u ht w o w ht 040 s u n ht 044 And the above php code creates this output: Array ( [0] => Array ( [0] => cat [1] => dog [2] => hat dad [3] => mom [4] => boy you [5] => wow [6] => sun [7] => ) ) od of the same file created with vi on solaris looks like: 000 c a t ht d o g ht h a t nl d a d ht 020 m o m ht b o y nl y o u ht w o w ht 040 s u n nl 044 and the output from the php code looks like: Array ( [0] => Array ( [0] => cat [1] => dog [2] => hat ) [1] => Array ( [0] => dad [1] => mom [2] => boy ) [2] => Array ( [0] => you [1] => wow [2] => sun ) ) For a file created on a PC, I imagine the resulting data would look right, but the last element of every array would contain an unseen CR. The different platforms use of different eol markers. This is widely acknowledged. Look at the last few users comments in the documentation for fgets, http://www.php.net/manual/en/function.fgets.php: "...Note that fgets() does not cope with MAC newlines (i.e. a single CR character, or "\r")..." "...If you are doing cross platform development where your PHP programs need to run on windows, unix and macs, or even are reading from files that were developed on various platforms, do not (I repeat DO NOT) use fgets(). This is because fgets(), as mentioned before, does not deal with carriage returns and line feeds for all systems..." Previous Comments: [2002-04-20 05:37:32] [EMAIL PROTECTED] It works fine on windows and on mac. If it still doesn't work, provide the relevant code and reopen the report. -Tal [2002-04-19 18:12:45] [EMAIL PROTECTED] Currently, fgets() only recognizes \n (LF) as the end of line marker. It would be useful if it would also recognize CR/LF (pc) and CR (mac). -- Edit this bug report at http://bugs.php.net/?id=16708&edit=1
Bug #16712 Updated: pointers and globals don't work together
ID: 16712
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Class/Object related
Operating System: Linux RedHat 7.2
PHP Version: 4.1.2
New Comment:
The assignment does work while staying local btw... so an echo $b->v;
within ta() would display 1 as it should.
I'm not sure about the exact implementation of PHP, but i think globals
ARE pointers, right ? That would explain it (though i'm not happy with
it).
If so the line
global $b;
would do the same as
$b(local) =& $b(global);
and thus a reassignment of $b to another point would seperate him from
$b(global).
Still i would like to re-reference my $b(global) in a local function.
Is there maybe a workaround or is it an impossibility ?
Previous Comments:
[2002-04-20 10:31:48] [EMAIL PROTECTED]
While using classes, pointers and globals I noticed data not being
migrated to the globalsphere due to pointerassignments.
[Example]
class test {
var $v=0;
function set($i) { $this->v = $i; }
}
$a = new test();
$b =& new test();
$c =& $b;
function ta() {
global $a,$b,$c;
$a->set(1);
$b =& $a;
$c->set(2);
}
ta();
echo "$a->v,$b->v,$c->v";
[/example]
This should display 1,1,2 since $b has been set to $a, but this
pointer-assigment isn't emigrated to the global $b.
I have done many expirements with it to see if i could further specify
the bug... at first i thought it was destroying non-globals that got
pointed too at the end of the functioncall and thus (accidently)
destroying the pointers in the process, but then if i would point $a to
$b and export them both, neither should be destroyed, so the reference
should stay intact... it isn't.
So the only thing that remains is that function-local
pointer-assigments not seem to affect my global var.
--
Edit this bug report at http://bugs.php.net/?id=16712&edit=1
Bug #16712: pointers and globals don't work together
From: [EMAIL PROTECTED]
Operating system: Linux RedHat 7.2
PHP version: 4.1.2
PHP Bug Type: Class/Object related
Bug description: pointers and globals don't work together
While using classes, pointers and globals I noticed data not being migrated
to the globalsphere due to pointerassignments.
[Example]
class test {
var $v=0;
function set($i) { $this->v = $i; }
}
$a = new test();
$b =& new test();
$c =& $b;
function ta() {
global $a,$b,$c;
$a->set(1);
$b =& $a;
$c->set(2);
}
ta();
echo "$a->v,$b->v,$c->v";
[/example]
This should display 1,1,2 since $b has been set to $a, but this
pointer-assigment isn't emigrated to the global $b.
I have done many expirements with it to see if i could further specify the
bug... at first i thought it was destroying non-globals that got pointed
too at the end of the functioncall and thus (accidently) destroying the
pointers in the process, but then if i would point $a to $b and export
them both, neither should be destroyed, so the reference should stay
intact... it isn't.
So the only thing that remains is that function-local pointer-assigments
not seem to affect my global var.
--
Edit bug report at http://bugs.php.net/?id=16712&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16712&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16712&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16712&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16712&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16712&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16712&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16712&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16712&r=submittedtwice
Bug #16577 Updated: PHP4 doesn't get any enviroment variables
ID: 16577 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: Linux PHP Version: 4.0CVS-2002-04-12 New Comment: Typo: --with-gsql should be --with-pgsql of course. Previous Comments: [2002-04-20 09:12:13] [EMAIL PROTECTED] Just installed PHP4.2.0RC4 as APXS with Apache2(.0.35) on My Mandrake 8.0 system. Compiles just fine, works good, but like others mentioned, I do not see the Apache specific environment variables in phpinfo() (f.e: PATH_TRANSLATED is unavailable). Apache 2 configure options: ./configure --prefix=/usr/local/apache2 --enable-so PHP4.2.0.RC4 configure options: ./configure --with-mysql=/usr --with--gsql --enable-xml --enable-wddx --enable-ftp --enable-sysvsem --enable-sysvshm --with-apxs2=/usr/local/apache2/bin/apxs --with-ttf=/usr/include --with-jpeg-dir=/usr --with-tiff-dir=/usr --with-zlib-dir=/usr --with-freetype-dir=/usr/local/src/freetype-2.0.4 --with-png-dir=/usr/local/src/libpng-1.2.0/ --with-gd=/usr/local/src/gd-2.0.1/ --enable-gd-native-tt --enable-gd-imgstrttf --enable-track-vars What am I doing wrong, or is it a bug? Regards, Arjan Haverkamp [EMAIL PROTECTED] [2002-04-12 20:22:27] [EMAIL PROTECTED] Works fine here with PHP 4.2.0RC3 and Apache 2.0.35. --Jani p.s. Try RC3 from http://www.php.net/~derick/ [2002-04-12 19:07:33] [EMAIL PROTECTED] i want to use apache2 and i wouldn't rewrite all my php scripts [2002-04-12 18:53:51] [EMAIL PROTECTED] setting register_globals is set to on and it doesn't work and it also doesn't work with php4.1.2 with apache2filter from cvs and apache2 [2002-04-12 18:12:30] [EMAIL PROTECTED] In PHP 4.2.0 and above, register_globals defaults to OFF in php.ini. Please try setting it 'on' or use the new super globals: $_ENV[], $_GET, $_SERVER..etc. If this is not the case, reopen this bug 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/16577 -- Edit this bug report at http://bugs.php.net/?id=16577&edit=1
Bug #16577 Updated: PHP4 doesn't get any enviroment variables
ID: 16577 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: Linux PHP Version: 4.0CVS-2002-04-12 New Comment: Just installed PHP4.2.0RC4 as APXS with Apache2(.0.35) on My Mandrake 8.0 system. Compiles just fine, works good, but like others mentioned, I do not see the Apache specific environment variables in phpinfo() (f.e: PATH_TRANSLATED is unavailable). Apache 2 configure options: ./configure --prefix=/usr/local/apache2 --enable-so PHP4.2.0.RC4 configure options: ./configure --with-mysql=/usr --with--gsql --enable-xml --enable-wddx --enable-ftp --enable-sysvsem --enable-sysvshm --with-apxs2=/usr/local/apache2/bin/apxs --with-ttf=/usr/include --with-jpeg-dir=/usr --with-tiff-dir=/usr --with-zlib-dir=/usr --with-freetype-dir=/usr/local/src/freetype-2.0.4 --with-png-dir=/usr/local/src/libpng-1.2.0/ --with-gd=/usr/local/src/gd-2.0.1/ --enable-gd-native-tt --enable-gd-imgstrttf --enable-track-vars What am I doing wrong, or is it a bug? Regards, Arjan Haverkamp [EMAIL PROTECTED] Previous Comments: [2002-04-12 20:22:27] [EMAIL PROTECTED] Works fine here with PHP 4.2.0RC3 and Apache 2.0.35. --Jani p.s. Try RC3 from http://www.php.net/~derick/ [2002-04-12 19:07:33] [EMAIL PROTECTED] i want to use apache2 and i wouldn't rewrite all my php scripts [2002-04-12 18:53:51] [EMAIL PROTECTED] setting register_globals is set to on and it doesn't work and it also doesn't work with php4.1.2 with apache2filter from cvs and apache2 [2002-04-12 18:12:30] [EMAIL PROTECTED] In PHP 4.2.0 and above, register_globals defaults to OFF in php.ini. Please try setting it 'on' or use the new super globals: $_ENV[], $_GET, $_SERVER..etc. If this is not the case, reopen this bug report. [2002-04-12 18:09:07] [EMAIL PROTECTED] me and some other friends of mine have tested the latest apache2 + and newest php4 versions an got the same problem. php doesn't get any enviroment variables for example REMOTE_ADDR oder some variables like www.foo.org?test=foo -- Edit this bug report at http://bugs.php.net/?id=16577&edit=1
Bug #16681 Updated: Request new words() function returning no of words in string
ID: 16681
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows XP Home Edition
PHP Version: 4.1.2
New Comment:
I notice this example in the ereg section:
ereg ("([[:alnum:]]+) ([[:alnum:]]+) ([[:alnum:]]+)", $string,$regs);
/* Places three space separated words
into $regs[1], $regs[2] and $regs[3]. */
which could become something like the following with the proposed
word() function:
$regs[1] = word($string, 1);
$regs[2] = word($string, 2);
$regs[3] = word($string, 3);
Even for hardened regular expression fans, I'm sure you would agree
which would be nicer to encounter in somebody elses uncommented code.
And I know which I'd rather place my money on as working correctly.
Hugh
Previous Comments:
[2002-04-19 04:59:54] [EMAIL PROTECTED]
This does not warrant new functions. What you are trying to do should
be done with arrays:
/**/
$countries = array("England", "Spain", "France", "Italy");
print "There are " . count($countries) . " countries competing";
print "The " . count($countries) . " are:";
for ($i=0; $ihttp://bugs.php.net/16681
--
Edit this bug report at http://bugs.php.net/?id=16681&edit=1
Bug #16583 Updated: php 4.2.0RC3 always crashes apache 2.0.35 server at start
ID: 16583
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache2 related
Operating System: PLD Linux
PHP Version: 4.2.0RC4
New Comment:
Building w/ optimizations off (CFLAGS="-g -Wall") won't
help either.
Previous Comments:
[2002-04-20 08:27:12] [EMAIL PROTECTED]
100% reproducible, crashes on loadmodule.
$ gcc -v
gcc version 2.95.3 20010315 (release)
$ uname -r
2.4.19-pre7-ac2
configured as
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--with-apxs2=/var/lib/httpd/bin/apxs \
--with-zlib \
--without-mysql \
--with-pgsql=/var/lib/pgsql \
i386-slackware-linux
[2002-04-19 12:11:07] [EMAIL PROTECTED]
%configure \
--with-apxs2=%{_sbindir}/apxs` \
--with-config-file-path=%{_sysconfdir} \
--with-exec-dir=%{_bindir} \
--enable-bcmath=shared \
--enable-calendar=shared \
--enable-dba=shared \
--enable-exif=shared \
--enable-ftp=shared \
--enable-gd-native-ttf \
--enable-magic-quotes \
--enable-posix=shared \
--enable-session \
--enable-shared \
--enable-shmop=shared \
--enable-sysvsem=shared \
--enable-sysvshm=shared \
--enable-track-vars \
--enable-trans-sid \
--enable-safe-mode \
--enable-sockets=shared \
--enable-yp=shared \
--enable-ucd-snmp-hack \
--enable-xml=shared \
--with-expat-dir=/usr \
--with-bz2=shared \
--with-ctype=shared \
--with-curl=shared \
--without-db2 \
--with-db3 \
--with-dbase=shared \
--with-iconv=shared \
--with-dom=shared \
--with-dom-xslt=shared \
--with-filepro=shared \
--with-freetype-dir=shared \
--with-gettext=shared \
--with-gd=shared \
--with-gdbm \
--with-gmp=shared \
--with-hyperwave \
--with-imap=shared --with-imap-ssl \
--with-jpeg-dir=%{_includedir} \
--with-ldap=shared \
--with-mcrypt=shared \
--with-mysql=shared,%{_prefix} \
--with-mysql-sock=/var/lib/mysql/mysql.sock \
--with-mhash=shared \
--with-ming=shared \
--without-mm \
--with-openssl \
--with-pear=%{peardir} \
--with-pcre-regex=shared \
--with-pdflib=shared \
--with-pgsql=shared,%{_prefix} \
--with-png-dir=%{_includedir} \
--without-recode=shared \
--with-regex=php \
--with-sablot=/usr/lib \
--with-snmp=shared \
--with-t1lib=shared \
--with-unixODBC=shared \
--with-zlib=shared \
--with-zlib-dir=shared \
--without-xmlrpc \
--disable-cli
whole spec file is here:
http://cvs.pld.org.pl/SPECS/php.spec?rev=1.120.2.17
src.rpm is here:
ftp://ftp.pld.org.pl/dists/nest/test/SRPMS/php-4.2.0RC4-1.src.rpm
while building I was using rpm --debug, so in such case
rpm sets CFLAGS="-g -O0"
buildlog is here:
ftp://buildlogs.pld.org.pl/nest/i686/OK/_r_DEVEL_php.bz2
(the only difference between this buildlog and mine is that I was
compiling with CFLAGS="-g -O0)
[2002-04-19 12:08:16] [EMAIL PROTECTED]
%configure \
--with-apxs2=%{_sbindir}/apxs` \
%else
`[ $i = apxs ] && echo --with-apxs=%{_sbindir}/apxs` \
%endif
--with-config-file-path=%{_sysconfdir} \
--with-exec-dir=%{_bindir} \
--%{!?debug:dis}%{?debug:en}able-debug \
--enable-bcmath=shared \
--enable-calendar=shared \
--enable-dba=shared \
--enable-exif=shared \
--enable-ftp=shared \
--enable-gd-native-ttf \
--enable-magic-quotes \
--enable-posix=shared \
--enable-session \
--enable-shared \
--enable-shmop=shared \
--enable-sysvsem=shared \
--enable-sysvshm=shared \
--enable-track-vars \
--enable-trans-sid \
--enable-safe-mode \
--enable-sockets=shared \
--enable-yp=shared \
--enable-ucd-snmp-hack \
--enable-xml=shared \
--with-expat-dir=/usr \
%{?_with_xslt:--enable-xslt=shared} \
--with-bz2=shared \
%{?_with_libcpdf:--with-cpdflib=shared} \
--with-ctype=shared \
--with-curl=shared \
--without-db2 \
--with-db3 \
--with-dbase=shared \
--with-iconv=shared \
--with-dom=shared \
--with-dom-xslt=shared \
--with-filepro=shared \
--with-freetype-dir=shared \
--with-gett
Bug #16583 Updated: php 4.2.0RC3 always crashes apache 2.0.35 server at start
ID: 16583
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache2 related
Operating System: PLD Linux
PHP Version: 4.2.0RC4
New Comment:
100% reproducible, crashes on loadmodule.
$ gcc -v
gcc version 2.95.3 20010315 (release)
$ uname -r
2.4.19-pre7-ac2
configured as
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--with-apxs2=/var/lib/httpd/bin/apxs \
--with-zlib \
--without-mysql \
--with-pgsql=/var/lib/pgsql \
i386-slackware-linux
Previous Comments:
[2002-04-19 12:11:07] [EMAIL PROTECTED]
%configure \
--with-apxs2=%{_sbindir}/apxs` \
--with-config-file-path=%{_sysconfdir} \
--with-exec-dir=%{_bindir} \
--enable-bcmath=shared \
--enable-calendar=shared \
--enable-dba=shared \
--enable-exif=shared \
--enable-ftp=shared \
--enable-gd-native-ttf \
--enable-magic-quotes \
--enable-posix=shared \
--enable-session \
--enable-shared \
--enable-shmop=shared \
--enable-sysvsem=shared \
--enable-sysvshm=shared \
--enable-track-vars \
--enable-trans-sid \
--enable-safe-mode \
--enable-sockets=shared \
--enable-yp=shared \
--enable-ucd-snmp-hack \
--enable-xml=shared \
--with-expat-dir=/usr \
--with-bz2=shared \
--with-ctype=shared \
--with-curl=shared \
--without-db2 \
--with-db3 \
--with-dbase=shared \
--with-iconv=shared \
--with-dom=shared \
--with-dom-xslt=shared \
--with-filepro=shared \
--with-freetype-dir=shared \
--with-gettext=shared \
--with-gd=shared \
--with-gdbm \
--with-gmp=shared \
--with-hyperwave \
--with-imap=shared --with-imap-ssl \
--with-jpeg-dir=%{_includedir} \
--with-ldap=shared \
--with-mcrypt=shared \
--with-mysql=shared,%{_prefix} \
--with-mysql-sock=/var/lib/mysql/mysql.sock \
--with-mhash=shared \
--with-ming=shared \
--without-mm \
--with-openssl \
--with-pear=%{peardir} \
--with-pcre-regex=shared \
--with-pdflib=shared \
--with-pgsql=shared,%{_prefix} \
--with-png-dir=%{_includedir} \
--without-recode=shared \
--with-regex=php \
--with-sablot=/usr/lib \
--with-snmp=shared \
--with-t1lib=shared \
--with-unixODBC=shared \
--with-zlib=shared \
--with-zlib-dir=shared \
--without-xmlrpc \
--disable-cli
whole spec file is here:
http://cvs.pld.org.pl/SPECS/php.spec?rev=1.120.2.17
src.rpm is here:
ftp://ftp.pld.org.pl/dists/nest/test/SRPMS/php-4.2.0RC4-1.src.rpm
while building I was using rpm --debug, so in such case
rpm sets CFLAGS="-g -O0"
buildlog is here:
ftp://buildlogs.pld.org.pl/nest/i686/OK/_r_DEVEL_php.bz2
(the only difference between this buildlog and mine is that I was
compiling with CFLAGS="-g -O0)
[2002-04-19 12:08:16] [EMAIL PROTECTED]
%configure \
--with-apxs2=%{_sbindir}/apxs` \
%else
`[ $i = apxs ] && echo --with-apxs=%{_sbindir}/apxs` \
%endif
--with-config-file-path=%{_sysconfdir} \
--with-exec-dir=%{_bindir} \
--%{!?debug:dis}%{?debug:en}able-debug \
--enable-bcmath=shared \
--enable-calendar=shared \
--enable-dba=shared \
--enable-exif=shared \
--enable-ftp=shared \
--enable-gd-native-ttf \
--enable-magic-quotes \
--enable-posix=shared \
--enable-session \
--enable-shared \
--enable-shmop=shared \
--enable-sysvsem=shared \
--enable-sysvshm=shared \
--enable-track-vars \
--enable-trans-sid \
--enable-safe-mode \
--enable-sockets=shared \
--enable-yp=shared \
--enable-ucd-snmp-hack \
--enable-xml=shared \
--with-expat-dir=/usr \
%{?_with_xslt:--enable-xslt=shared} \
--with-bz2=shared \
%{?_with_libcpdf:--with-cpdflib=shared} \
--with-ctype=shared \
--with-curl=shared \
--without-db2 \
--with-db3 \
--with-dbase=shared \
--with-iconv=shared \
--with-dom=shared \
--with-dom-xslt=shared \
--with-filepro=shared \
--with-freetype-dir=shared \
--with-gettext=shared \
--with-gd=shared \
--with-gdbm \
--with-gmp=shared \
--with-hyperwave \
%{!?_without_imap:--with-imap=shared --with-imap-ssl} \
Bug #16670 Updated: php 4.1.0, cyrus-imapd.2.0.16, c-client compile-error
ID: 16670 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: linux / redhat 7.2 PHP Version: 4.1.2 New Comment: Hallo, at the first, thanks a lot for all your help's. How did you install the c-client? From RPM? NO, i need no kereberos, that was the id to installed the source-files and compiled. I have test the make-run with the folloes options make lrh (ha ha ===> need kereberos) with make lnp SSLTYPE=unix compiling php- error with make slx SSLTYPE=unix PASSWDTYPE=pam compiling php-error in this Night i have test with php-4.2.0RC4 (without kerberos) the configure was very good then come the first error the c-client was not complete Is crazzy, i have copy all the files in user/local/lib and include was stay in php-manual Then i have write a message to c-client-mailinglist In this FAQ stay this my compile from c-client this run was very ok. I have no id was the make file doing. i think the makefile can not control was is imap-c-client and was is cyrus. Pleas help Thanks a lot for help Best reagards Previous Comments: [2002-04-19 22:15:40] [EMAIL PROTECTED] How did you install the c-client? From RPM? Compiled it yourself from sources? iirc, RH rpms have kerberos support buildin their c-client rpms and thus, you NEED to have the kerberos stuff installed too. This includes the -dev packages too. [2002-04-19 20:31:32] [EMAIL PROTECTED] hallo, i have compiled php-4.2.0RC4 on a new machine with suse 7.3 i think imap-ssl is ok. but now is the follow error configure:36521: result: no configure:36535: error: Sorry, I was not able to diagnose which libmcrypt version you have installed. i have installed libmcrypt-2.4.20 and mcrypt-2.5.10 with the php-configure script option --with-mcrypt=/usr/local/include the prefix from mcrypt and libcrypt is /usr/local i have no id but in the php config.log is this message cannot find -lgssapi_krb5 but on my suse i have no libgssapi_krb5 Thanks a lot for help Best reagards Achim [2002-04-19 10:25:05] [EMAIL PROTECTED] And what did happen with 4.2.0RC4 ??? And have you always done a clean configure / make between those different configures? [2002-04-19 07:39:21] [EMAIL PROTECTED] Hallo, Yes i have try RC4. I have first compile without all options, was all ok. At the second i have compile with mysql-support, was all ok. The next step i have compile with many options but without imap and imap-ssl, cyrus was enable, all was ok. (sorry a little problem was with DOM-support, my library was maby to old). in the next step i have compiled with mysql, openssl, cyrus, imap and imap-ssl, bull-shit . Ok. i think the problem is only the c-client. the biggest crazy step was the follow. i have compiled php4.0.6 with imap and imap-ssl, the configure say in this moment (was very good) yoer imap support nothing ssl please remove or --without-imap-ssl or so. i have then configure run und after this compile with cyrus, and imap but without imap-ssl, was very good. Please look the next, that's crazy !! I have the compiled php4.1.2 with mysql, openssl, cyrus and imap " *** but *** " without imap-ssl. the configure comes with an error and say your c-client is compiled with ssl pleas youse imap-ssl Thanks a lot for your help and a nice day Best reagards Achim [2002-04-18 16:32:31] [EMAIL PROTECTED] Did you or did you not try the RC4? 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/16670 -- Edit this bug report at http://bugs.php.net/?id=16670&edit=1
Bug #16710 Updated: pg_exec to pg_query alias not mentioned in the NEWS file
ID: 16710 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: every system PHP Version: 4.2.0 New Comment: FYI: The manual page about pg_query() now mentiones that pg_exec() is still available. Previous Comments: [2002-04-20 06:23:03] [EMAIL PROTECTED] Reopened. Yasou, please enter a proper NEWS entry as there's no reference about this in the NEWS file (and light this up that the old function is still available, you see people get confused about this) . . . [2002-04-20 05:31:47] [EMAIL PROTECTED] We decided to use pg_query() because it's more consistent with other database extensions (like mysql, which uses mysql_query()) The old function names still work and won't be removed soon. [2002-04-20 05:27:44] [EMAIL PROTECTED] Reclassified. -Tal [2002-04-20 05:17:34] [EMAIL PROTECTED] I have just finished writing a book about PHP and PostgreSQL. After we have finished layouting the stuff we have seen that pg_exec has changed to pg_query for ABSOLUTELY NO USEFUL reason. In addition to that my company has written > 1000k of PHP/PostgreSQL code in the past and we have to port ALL applications to the new name. This will be chaotic and I cannot see a reason for the change. Was there no way of leaving the old name? We will never ever use PHP in the future again because what we have to face is a microsoft like change destroying all books and all applications on the market. This IS a bug for all serious companies and developers and I hope that those who are responsible for the mess will read this message. Best regards, Hans-Jürgen Schönig (a former PHP programmer and author) -- Edit this bug report at http://bugs.php.net/?id=16710&edit=1
Bug #16711 Updated: pg_query doc page doesn't mentioned that pg_exec is STILL available
ID: 16711 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 4.2.0 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-04-20 06:26:08] [EMAIL PROTECTED] See summary and http://bugs.php.net/bug.php?id=16710 -- Edit this bug report at http://bugs.php.net/?id=16711&edit=1
Bug #16711: pg_query doc page doesn't mentioned that pg_exec is STILL available
From: [EMAIL PROTECTED] Operating system: PHP version: 4.2.0 PHP Bug Type: Documentation problem Bug description: pg_query doc page doesn't mentioned that pg_exec is STILL available See summary and http://bugs.php.net/bug.php?id=16710 -- Edit bug report at http://bugs.php.net/?id=16711&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16711&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16711&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16711&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16711&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16711&r=support Expected behavior: http://bugs.php.net/fix.php?id=16711&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16711&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16711&r=submittedtwice
Bug #16710 Updated: pg_exec to pg_query alias not mentioned in the NEWS file
ID: 16710 Updated by: [EMAIL PROTECTED] -Summary: pg_exec to pg_query Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: every system PHP Version: 4.2.0 New Comment: Reopened. Yasou, please enter a proper NEWS entry as there's no reference about this in the NEWS file (and light this up that the old function is still available, you see people get confused about this) . . . Previous Comments: [2002-04-20 05:31:47] [EMAIL PROTECTED] We decided to use pg_query() because it's more consistent with other database extensions (like mysql, which uses mysql_query()) The old function names still work and won't be removed soon. [2002-04-20 05:27:44] [EMAIL PROTECTED] Reclassified. -Tal [2002-04-20 05:17:34] [EMAIL PROTECTED] I have just finished writing a book about PHP and PostgreSQL. After we have finished layouting the stuff we have seen that pg_exec has changed to pg_query for ABSOLUTELY NO USEFUL reason. In addition to that my company has written > 1000k of PHP/PostgreSQL code in the past and we have to port ALL applications to the new name. This will be chaotic and I cannot see a reason for the change. Was there no way of leaving the old name? We will never ever use PHP in the future again because what we have to face is a microsoft like change destroying all books and all applications on the market. This IS a bug for all serious companies and developers and I hope that those who are responsible for the mess will read this message. Best regards, Hans-Jürgen Schönig (a former PHP programmer and author) -- Edit this bug report at http://bugs.php.net/?id=16710&edit=1
Bug #16689 Updated: bzread has no reliable way of detecting eof
ID: 16689
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Bzip2 Related
Operating System: win32
PHP Version: 4.1.2
New Comment:
Can you try a CVS snapshot?
Try: http://php-bin-snaps.sourceforge.net/
I've double checked the code: in the CVS version,
bzread will return a zero-length string when there is
no more data, fread will return false.
If you are still seeing a 4K long string of zeroes,
then that is a bug in the win32 bz2 library.
Previous Comments:
[2002-04-19 23:32:40] [EMAIL PROTECTED]
this does not work on win32. bzread gives back a string of \0 as long
as the bzread requested...
and in php "\0\0\0" != false
i'm going to reopen and mark it as a win32 bug until there is
confirmation.. good luck.
[2002-04-18 18:41:09] [EMAIL PROTECTED]
Err, scratch that last comment; the only way to detect eof
for bzip streams is to keep reading it.
feof will always return false for bz2.
Your bzread or fread call should return false when no more data can be
read.
while(($string = bzread($bzfile, 4096)) !== false) {
...
}
should do what you want.
[2002-04-18 18:35:27] [EMAIL PROTECTED]
Try a recent CVS snapshot; you can now use feof on bz handles.
Reopen this report if it doesn't work for you :-)
[2002-04-18 17:29:05] [EMAIL PROTECTED]
obviously feof will not work on a Bz file handle (though it would be
nice if it did)
the only way i could find it detect the end in a loop (where you would
be slurping in the whole file) is:
// open the file ... $bzfile
$data="";
$string=bzread($bzfile,4096);
while ($string!=str_repeat("\0",4096)) {
$data.=$string;
$string=bzread($bzfile,4096);
}
a better mechanism for eof detection is needed
--
Edit this bug report at http://bugs.php.net/?id=16689&edit=1
Bug #14261 Updated: fsockopen w/ udp responds incorrectly
ID: 14261 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Bogus Bug Type: Sockets related Operating System: RedHat 7.1 PHP Version: 4.0.6, 4.1.0RC3 New Comment: I can reproduce this, but I believe it is expected behaviour: UDP is a connectionless protocol, so you don't find out if you have "connected" until you start reading/writing data to the socket. I'm marking this as bogus, since that is the way UDP works. Previous Comments: [2002-04-20 00:00:04] [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-03-18 15:20:11] [EMAIL PROTECTED] If you var_dump($test), what does it show? [2001-11-28 14:20:05] [EMAIL PROTECTED] #!/usr/local/bin/php -q Responds "UP" when it should timeout and respond "DOWN". - Tried 4.1.0 RC3 on several x86 machines, same problem. [2001-11-28 01:27:02] [EMAIL PROTECTED] There were some fixes related to this. Could you possibly try the latest 4.1.0 RC from www.php.net/~zeev/php-4.1.0RC3.tar.gz ? If it's fixed there, you can use the soon-to-be-released 4.1.0 version. Derick [2001-11-27 22:28:31] [EMAIL PROTECTED] #!/usr/local/bin/php -q Responds "UP" when it should timeout and respond "DOWN". -- Edit this bug report at http://bugs.php.net/?id=14261&edit=1
Bug #16708 Updated: fgets handling of non-unix EOL markers
ID: 16708 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Solaris 2.x PHP Version: 4.1.2 New Comment: It works fine on windows and on mac. If it still doesn't work, provide the relevant code and reopen the report. -Tal Previous Comments: [2002-04-19 18:12:45] [EMAIL PROTECTED] Currently, fgets() only recognizes \n (LF) as the end of line marker. It would be useful if it would also recognize CR/LF (pc) and CR (mac). -- Edit this bug report at http://bugs.php.net/?id=16708&edit=1
Bug #16710 Updated: pg_exec to pg_query
ID: 16710 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: every system PHP Version: 4.2.0 New Comment: We decided to use pg_query() because it's more consistent with other database extensions (like mysql, which uses mysql_query()) The old function names still work and won't be removed soon. Previous Comments: [2002-04-20 05:27:44] [EMAIL PROTECTED] Reclassified. -Tal [2002-04-20 05:17:34] [EMAIL PROTECTED] I have just finished writing a book about PHP and PostgreSQL. After we have finished layouting the stuff we have seen that pg_exec has changed to pg_query for ABSOLUTELY NO USEFUL reason. In addition to that my company has written > 1000k of PHP/PostgreSQL code in the past and we have to port ALL applications to the new name. This will be chaotic and I cannot see a reason for the change. Was there no way of leaving the old name? We will never ever use PHP in the future again because what we have to face is a microsoft like change destroying all books and all applications on the market. This IS a bug for all serious companies and developers and I hope that those who are responsible for the mess will read this message. Best regards, Hans-Jürgen Schönig (a former PHP programmer and author) -- Edit this bug report at http://bugs.php.net/?id=16710&edit=1
Bug #16710 Updated: pg_exec to pg_query
ID: 16710 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: PostgreSQL related +Bug Type: Feature/Change Request Operating System: every system PHP Version: 4.2.0 New Comment: Reclassified. -Tal Previous Comments: [2002-04-20 05:17:34] [EMAIL PROTECTED] I have just finished writing a book about PHP and PostgreSQL. After we have finished layouting the stuff we have seen that pg_exec has changed to pg_query for ABSOLUTELY NO USEFUL reason. In addition to that my company has written > 1000k of PHP/PostgreSQL code in the past and we have to port ALL applications to the new name. This will be chaotic and I cannot see a reason for the change. Was there no way of leaving the old name? We will never ever use PHP in the future again because what we have to face is a microsoft like change destroying all books and all applications on the market. This IS a bug for all serious companies and developers and I hope that those who are responsible for the mess will read this message. Best regards, Hans-Jürgen Schönig (a former PHP programmer and author) -- Edit this bug report at http://bugs.php.net/?id=16710&edit=1
Bug #16710: pg_exec to pg_query
From: [EMAIL PROTECTED] Operating system: every system PHP version: 4.2.0 PHP Bug Type: PostgreSQL related Bug description: pg_exec to pg_query I have just finished writing a book about PHP and PostgreSQL. After we have finished layouting the stuff we have seen that pg_exec has changed to pg_query for ABSOLUTELY NO USEFUL reason. In addition to that my company has written > 1000k of PHP/PostgreSQL code in the past and we have to port ALL applications to the new name. This will be chaotic and I cannot see a reason for the change. Was there no way of leaving the old name? We will never ever use PHP in the future again because what we have to face is a microsoft like change destroying all books and all applications on the market. This IS a bug for all serious companies and developers and I hope that those who are responsible for the mess will read this message. Best regards, Hans-Jürgen Schönig (a former PHP programmer and author) -- Edit bug report at http://bugs.php.net/?id=16710&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16710&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16710&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16710&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16710&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16710&r=support Expected behavior: http://bugs.php.net/fix.php?id=16710&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16710&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16710&r=submittedtwice
Bug #16701 Updated: error in tranmitting post variables
ID: 16701 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Feedback Bug Type: Variables related Operating System: Windows XP PHP Version: 4.1.2 New Comment: With which browser did you test it? It might be a bug in IE. Could you also provide the code (or the relevant part of it)? -Tal Previous Comments: [2002-04-19 13:01:01] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". [2002-04-19 12:57:08] [EMAIL PROTECTED] Having a form with just a single and you submit the data, it misses the last character of the variable, like: if you submitted the value: foo, then you only get: fo on you on your action url. I've degraded to php 4.0.6 which solved the problem, so it must be something with php 4.1.2. It does not occur when using a get instead of a post, but this is not always a viable solution. If I add one more input boxes (text) to the form, then it works just fine... -- Edit this bug report at http://bugs.php.net/?id=16701&edit=1
Bug #16687 Updated: Constants not being interpreted in "variable variables"
ID: 16687 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Red Hat Linux 7.1 PHP Version: 4.2.0 New Comment: Superglobals are named autoglobals or "auto global"s in many cases. Because you need not use "global" to make it global... I personaly think that superglobal is a better name for them (as used by Rasmus first AFAIK), so I use this name. -- Goba Previous Comments: [2002-04-19 21:01:49] [EMAIL PROTECTED] By design ? hehe Ok, I *think* it was not 'by design', I think this just turned out to be the way it is after it has been implemented. I don't think while writing the code and was kept in mind 'no, we do not want them not to be accessible in functions with variable variables'. Ok, so much. Versions of PHP has already been released, so we should document it. Btw, goba, using the search on php.net I couldn't find a single page refering to the super globals ... ? (I haven't yet browser through the manual index as I tend to find that annyoing) [2002-04-19 15:17:41] [EMAIL PROTECTED] I have already reported this problem, but nothing happened. Superglobals seemed to be accessible with variable variables in the global scope, but not in any local scope (inside a function). Derick told me, that it is by design, but IMHO this is incosistent, and quite ugly :(( -- Goba [2002-04-19 14:53:51] [EMAIL PROTECTED] Reclassified. It should be documented that due the special way super globals are treated the cannot be used with variable variables. [2002-04-19 12:40:50] [EMAIL PROTECTED] True true. Derick (or someone else) mind briefly explaining why this is/has to be different? [2002-04-19 11:11:00] [EMAIL PROTECTED] But then why does it work under certain circumstances and not others? Regardless whether intended or not, this is inconsistent behaviour. I also think that having these differences between regular variables and the "superglobals" shouldn't be necessary. If I can't use them in the same contexts as regular variables, then I would personally prefer the $HTTP_*_VARS instead, because you can. I have found my approach to abstracting this difference ($HTTP_*_VARS vs. $_*) between PHP versions to be really beneficial to my scripts. I can abstract them both down to one name, and use a single reference to the appropriate one instead of sticking if statements every time I need to know which one to use. Sorry to keep buggin' ya, but I think this may be a fair enough argument for change. 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/16687 -- Edit this bug report at http://bugs.php.net/?id=16687&edit=1
Bug #16263 Updated: session.start() create new empty session file and not resume existing session
ID: 16263 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Session related Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: YES!!! After long hours, the "global $HTTP_SESSION_VARS;" worked 4 me (PHP 4.1.2, WinXP, Apache 1.3.24, mod_php4). Today's my birthday!!! Thanks for so beautyful birthday gift!!! (it curious that the tip was post just a few hours ago). Previous Comments: [2002-04-20 00:42:06] [EMAIL PROTECTED] This advice might be worth millions for some, after a sleepless night and endless code comparisons, i found out that adding global $HTTP_SESSION_VARS; right after the session_start(); solves the problem, even when using $_SESSION for your coding which is supposed to be global anyways, so till a formal fix comes up i hope this will help you too.. session_start(); global $HTTP_SESSION_VARS; $_SESSION["HELLO"]="WORLD"; etc. [2002-04-17 04:33:30] [EMAIL PROTECTED] I did exchange all dll's, didn't help with the problem. Sometimes it takes a little while to "loose" the session data, somethimes it happens quickly... [2002-04-15 20:27:19] [EMAIL PROTECTED] once again, whenever you update/downgrade PHP remember to replace ALL the dlls and other binaries in your systems with the ones found in the release packages. [2002-04-15 15:21:23] [EMAIL PROTECTED] Problem still exists in PHP 4.2.0 rc4. [2002-04-15 14:44:20] [EMAIL PROTECTED] I use Apache 1.3.23 and PHP 4.1.0 as an ISAPI module on Windows2000 SP2 with NTFS. I tried 4.1.2 when it came out and today - 15/4/2002 - 4.2.0 RC4. I keep have to downgrade back to 4.1.0 because my complete session-based website ceased to work when using ANY PHP version greater than 4.1.0 (however never tried 4.1.1). It heavily relies on URL transmitted sessions so without cookies. I set register_globals to OFF en use $_SESSION etc throughout the app. I'm really curious when sessions will work again, since I'd like to benefit from the solved security issues of 4.1.x in >= 4.1.2. 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/16263 -- Edit this bug report at http://bugs.php.net/?id=16263&edit=1
