#19861 [NEW]: sessions PHP 4.3.0pre1 Released
From: [EMAIL PROTECTED] Operating system: freeBSD 4.5 PHP version: 4.3.0-pre1 PHP Bug Type: Session related Bug description: sessions PHP 4.3.0pre1 Released ? session_start(); $zminna = $have_no_value; session_register(zminna); $rtrtrtr = fdg; echo $masfked; ? Why this printing in the browser 'fdg'// that doesn't. because the $masfked is empty.. this is in PHP 4.3.0pre1 Released Thats your bug and not my.. ^-) . thanks. please fix it.. -- Edit bug report at http://bugs.php.net/?id=19861edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19861r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19861r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19861r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19861r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19861r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19861r=support Expected behavior: http://bugs.php.net/fix.php?id=19861r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19861r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19861r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19861r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19861r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19861r=dst IIS Stability: http://bugs.php.net/fix.php?id=19861r=isapi
#17826 [Fbk-Csd]: PHP 4.2.1 Apache SAPI is not compatible with Apache 2.0.39
ID: 17826 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Apache2 related Operating System: Win32 PHP Version: 4.2.1 Assigned To: edink New Comment: PHP will work with whatever is current Apache version at the time of its release. Newer versions of Apache2 often break backwards compatibility so php4apache2.dll will not work with them. So either use the version of Apache that is supported by that PHP release, or use (almost) always current snapshot from http://snaps.php.net/win32/ Previous Comments: [2002-10-11 07:01:27] [EMAIL PROTECTED] Thank you for all the Help Its working perfect with the php4apache2.dll from the Prerelease PHP Version 4.2.4 from http://snaps.php.net/win32/php4-win32-STABLE-latest.zip But it take alot of time to find this Bugreport. If you would add a little link from the Downloadpage of PHP to this Page, it would help many scared php-newbies like me ;) Thanks for all the help Chojin [2002-10-05 10:58:07] [EMAIL PROTECTED] after having some trouble with this myself on both apache 2.0.42 and 2.0.43 and finding this thread, i used just the php4apache2.dll file from http://snaps.php.net/win32/php4-win32-STABLE-latest.zip with the rest of the files being php 4.2.3 ones, and it works perfectly now. havent seen any bugs so far. hope this helps someone :) [2002-10-04 00:30:50] [EMAIL PROTECTED] Hello. I figured this out. There is no other way than using a 2.0.36 version and apache2filter.dll ! That seems to work perfectly. Only problem is that where from you can find 2.0.36 version of the Apache. Here is location where from I downloaded it: http://apache.kr.net/dist/ I have now PHP 4.2.3, MySQL and Apache 2.0.36 up and running. I have done quite a few tests and I didn't face problems. In httpd.conf you need just following lines: LoadModule php4_module c:/www/bin/php4/experimental/apache2filter.dll DirectoryIndex index.php index.html index.html.var index.htm index.phtml index.php3 default.htm AddType application/x-httpd-php .php .php3 .phtml .php4 That all you need. Apache2filter.dll might be also problematic to find, but I found it from older PHP distributions (4.2.0, see http://ftp.proventum.net/pub/php/win32/) Greetings, Jari Hiltunen, aka OH4BC [2002-10-04 00:02:29] [EMAIL PROTECTED] Sniper, the newest snapshot does not fix the problem here. Apache_2.0.43 doesn't read the php4apache2.dll correctly. Has anyone got this to work yet? [2002-10-03 19:12:10] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip 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/17826 -- Edit this bug report at http://bugs.php.net/?id=17826edit=1
#19861 [Opn-Bgs]: sessions PHP 4.3.0pre1 Released
ID: 19861 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: freeBSD 4.5 PHP Version: 4.3.0-pre1 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Previous Comments: [2002-10-11 06:36:35] [EMAIL PROTECTED] ? session_start(); $zminna = $have_no_value; session_register(zminna); $rtrtrtr = fdg; echo $masfked; ? Why this printing in the browser 'fdg'// that doesn't. because the $masfked is empty.. this is in PHP 4.3.0pre1 Released Thats your bug and not my.. ^-) . thanks. please fix it.. -- Edit this bug report at http://bugs.php.net/?id=19861edit=1
#19866 [NEW]: Translation in french for session_write_close()
From: [EMAIL PROTECTED] Operating system: Suze 7.0/Win95/WinXP PHP version: 4.2.1 PHP Bug Type: *Languages/Translation Bug description: Translation in french for session_write_close() Traduction francaise (Sans accents ni cedilles, je suis en clavier anglais) session_write_close -- Ecrit les donnees de session et ferme la session courante Description void session_write_close ( void) Termine la session courante et sauve les donnees. Les donnees de session sont habituellement sauvees une fois le script termine sans avoir besoin d'appeller explicitement session_write_close(), mais vu que les donnees sont verrouillees afin d'eviter plusieurs ecritures concurentes, UN seul script peut travailler sur une session a la fois. En utilisant les session avec les cadres (frames), vous pourrez remarquer que les cadres se chargent un a un a cause de cette restriction Vous pouvez reduire le temps necessaire au chargement des cadres en appellant cette fonction afin de fermer la session des que tous les changements faits au variables de session ont ete realisees. PS (Nothing to see : Sorry to have put a bug here and a note to the function, but don't know where to put a translation... either here or directly in the function) CYA Min's -- Edit bug report at http://bugs.php.net/?id=19866edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19866r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19866r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19866r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19866r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19866r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19866r=support Expected behavior: http://bugs.php.net/fix.php?id=19866r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19866r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19866r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19866r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19866r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19866r=dst IIS Stability: http://bugs.php.net/fix.php?id=19866r=isapi
#19865 [NEW]: explode bug
From: [EMAIL PROTECTED]
Operating system: RedHat 7.1
PHP version: 4.3.0-pre1
PHP Bug Type: *General Issues
Bug description: explode bug
I have next code:
?
$testline = a.\1.b.\0.d.\1.f.\1.1.\1.d;
var_dump(explode(\1,$testline));
?
In PHP 4.2.3 it work as expected, I see:
array(5) { [0]= string(1) a [1]= string(3) bd [2]= string(1) f
[3]= string(1) 1 [4]= string(1) d }
In PHP 4.3pre1:
array(2) { [0]= string(1) a [1]= string(9) bdf1d }
Same effect if \0 replace to \2.
My config line:
'./configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-pfpro'
'--enable-inline-optimization' '--with-mysql' '--enable-track-vars'
'--disable-debug' '--disable-pic' '--disable-ctype' '--disable-mbstring'
'--disable-xml' '--disable-tokenizer' '--with-zlib' '--enable-sysvshm'
'--enable-sysvsem' '--enable-shmop' '--enable-costaid' '--with-mm'
'--with-imap=/usr/install/imap-2002.RC5' '--with-gdbm' '--with-oci8'
'--enable-sigchild' '--without-gd' '--with-curl' '--with-dom-exslt'
'--with-dom-xslt' '--with-dom'
--
Edit bug report at http://bugs.php.net/?id=19865edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19865r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=19865r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=19865r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19865r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=19865r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19865r=support
Expected behavior: http://bugs.php.net/fix.php?id=19865r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19865r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19865r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=19865r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19865r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=19865r=dst
IIS Stability: http://bugs.php.net/fix.php?id=19865r=isapi
#8029 [Com]: Session loses variables, zero length session file
ID: 8029 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *Session related Operating System: Linux Redhat 6.2 PHP Version: 4.0.3pl1 New Comment: I have also experienced this problem, but only on a Windows 2000 Pro machine running Apache 1.3 and PHP 4.2.3. Session variables would be lost at random and the session file would be emptied. When I moved my application to RedHat 7.2, Apache 2 and PHP 4.2.2, I am yet to experience the problem after a week of development whereas on the Windows machine it would happen every 10 minutes or so. I am sorry I can't be more specific about the problem but it does seem to be random. If it helps my application is a simple web chat that calls the script every 5 seconds and relies on six session variables to identify the user and keep track of their status. Previous Comments: [2002-02-07 10:06:55] [EMAIL PROTECTED] Hello. I would like to ask him to go reopen this bug, because I go by the same problem. Seemingly without some reason, the data of the session disappear. I go ties the directory where the session files are stored and they don't simply exist more. I was already accompanying the moments from the creation of the file ties the hour that the same disappears. The times the process doesn't last more than 1 minute and other more than 10 min. I am using php 4. 1. 1, Apache 1. 3. 20, win98 SE 4. 1. (with all of the available updatings in the windowsupdate.microsoft.com). My lan works in speed of 10/100 Mbit. The file php. ini is one copies of the php. ini-dist, only with alterations in the path of the creation of the session files. The remaining continues original. The path is that d:/php/sessiondata. If possible I would like his help for the solution of this problem. Sorry for my terrible english. [2001-05-13 05:15:18] [EMAIL PROTECTED] Hello, does this still happen with the latest release (4.0.5). If yes, please reopen this report. regards, Derick [2000-12-02 08:58:52] [EMAIL PROTECTED] Well, if it is impossible to reproduce, then I don't see how we can help you. Suspending bug report. [2000-11-29 05:06:56] [EMAIL PROTECTED] We stores some objects and variables into sessions. Sessions are stored on disk in /tmp directory. Sometimes (absloutly radnom situation) problem occures with session. No objects are found in session. The session file goes to zero lenght and no other error is logged or displayed. It's impossible to reproduce this error. -- Edit this bug report at http://bugs.php.net/?id=8029edit=1
#13142 [Com]: strtotime() returns -1 for M d H:i:s Y format
ID: 13142 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Date/time related Operating System: Linux PHP Version: 4.3.0-dev New Comment: I am using PHP 4.2.3 under Windows 2000 where date(D M d H:i:s T Y) produces... Fri Oct 11 09:52:47 Eastern Standard Time 2002 instead of... Fri Oct 11 09:52:47 EDT 2002 and, strtotime() of either format produced above returns -1 Previous Comments: [2002-07-04 13:22:32] [EMAIL PROTECTED] Verified during the Bughunt [2001-09-04 20:15:24] [EMAIL PROTECTED] Uh..reproduced I meant. :) [2001-09-04 20:15:10] [EMAIL PROTECTED] Confirmed with latest CVS. [2001-09-04 16:47:44] [EMAIL PROTECTED] strtotime(Sep 04 16:39:45 2001) returns -1 with PHP 4.0.6 this was working with PHP 4.0.3 -- Edit this bug report at http://bugs.php.net/?id=13142edit=1
#19863 [Opn-Bgs]: Missing table - Wrong contents display
ID: 19863 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: WIN2K PHP Version: 4.2.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Looks like a phpMyAdmin bug, hence not for us to solve ;) If you believe that not to be the case, please provide a shortest possible example (source code) that demonstrates the bug. Previous Comments: [2002-10-11 08:07:37] [EMAIL PROTECTED] Environment(more): mySql 3.23.43, Apache 2.0.40, phpMyAdmin 2.2.2.(italian language). Using this last application, I created a new table with 1 record in it. I tried to change a field's content, but I get the form for a new record input. I deleted the record I couldn't change and inserted a new one with a new value. Asked for the table contents and the deleted record was displayed. Closing and re-running the application I couldn't find the table any more. I tried to create it again, but I got the 'Table already existing' error message. Using the mySQL commands 'show tables' and 'select * from table_name' brought to the expected results(table_name in the list and the new record existing). The same problem happen with different table and database. Final fun (discovered by chance): changing the language from italian to english brings everything to work properly!! Just to be complete(maybe), phpMyAdmin worked ok with php 4.1.2 and Apache 1.3.19 on WIN98ME. Cherio, Piero. -- Edit this bug report at http://bugs.php.net/?id=19863edit=1
#19864 [Opn-Bgs]: getimagesize slow on large file
ID: 19864 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type:GetImageSize related PHP Version: 4.2.3 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Previous Comments: [2002-10-11 08:34:25] [EMAIL PROTECTED] getimagesize very slow on large _local_ file for 4mb file, it take 1sec or more time! i wonder why it's such slow to just read file head info is it trying to buffer the whole file? -- Edit this bug report at http://bugs.php.net/?id=19864edit=1
#19858 [Ctl-Csd]: nl2br incorrect return
ID: 19858 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Closed Bug Type: *General Issues Operating System: RedHat 7.1 PHP Version: 4.3.0-pre1 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-10-11 05:47:01] [EMAIL PROTECTED] I get no output on FreeBSD 4.6. CVS from four weeks ago works as expected. Marking critical. [2002-10-11 05:33:38] [EMAIL PROTECTED] Output each times difference. For example: 1 time: Ý3 2 time: \ [2002-10-11 05:25:54] [EMAIL PROTECTED] can you please also paste the output? [2002-10-11 05:25:17] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2002-10-11 05:22:09] [EMAIL PROTECTED] $e = test; echo nl2br($e); I get very strange output. HOW=--with-apxs=/usr/local/apache/bin/apxs --with-pfpro ./configure $HOW --enable-inline-optimization \ --with-mysql\ --enable-track-vars \ --disable-debug --disable-pic \ --disable-ctype \ --disable-mbstring \ --disable-xml \ --disable-tokenizer \ --with-zlib \ --enable-sysvshm --enable-sysvsem --enable-shmop \ --enable-costaid \ --with-mm \ --with-imap=/usr/install/imap-2002.RC5 \ --with-gdbm \ --with-oci8 --enable-sigchild \ --without-gd \ --with-curl \ --with-dom-exslt --with-dom-xslt --with-dom -- Edit this bug report at http://bugs.php.net/?id=19858edit=1
#19858 [Opn-Ctl]: nl2br incorrect return
ID: 19858 Updated by: [EMAIL PROTECTED] -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: *General Issues Operating System: RedHat 7.1 PHP Version: 4.3.0-pre1 New Comment: I get no output on FreeBSD 4.6. CVS from four weeks ago works as expected. Marking critical. Previous Comments: [2002-10-11 05:33:38] [EMAIL PROTECTED] Output each times difference. For example: 1 time: Ý3 2 time: \ [2002-10-11 05:25:54] [EMAIL PROTECTED] can you please also paste the output? [2002-10-11 05:25:17] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2002-10-11 05:22:09] [EMAIL PROTECTED] $e = test; echo nl2br($e); I get very strange output. HOW=--with-apxs=/usr/local/apache/bin/apxs --with-pfpro ./configure $HOW --enable-inline-optimization \ --with-mysql\ --enable-track-vars \ --disable-debug --disable-pic \ --disable-ctype \ --disable-mbstring \ --disable-xml \ --disable-tokenizer \ --with-zlib \ --enable-sysvshm --enable-sysvsem --enable-shmop \ --enable-costaid \ --with-mm \ --with-imap=/usr/install/imap-2002.RC5 \ --with-gdbm \ --with-oci8 --enable-sigchild \ --without-gd \ --with-curl \ --with-dom-exslt --with-dom-xslt --with-dom -- Edit this bug report at http://bugs.php.net/?id=19858edit=1
#19867 [NEW]: extract function and null values
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.0 PHP Bug Type: Arrays related Bug description: extract function and null values In earlier versions of PHP ... when looping through a set of database data, for example, and extracting on each loop -- the extract function would overwrite the variable with the previous value, even if it was NULL. I just recently switched servers that had a more recent version of PHP. Now extract behaves differently. On the next pass through, the variable is not overwritten if the new value is NULL. This requires the use of unset on each loop for each variable that could have NULL values. I see nothing in the changelog about this, so I'm trying to determine if it's a bug, or was changed on purpose. If it's a change, I'm not sure I understand why, since it would seem to be much more useful to have it overwritten with the NULL value. -- Edit bug report at http://bugs.php.net/?id=19867edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19867r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19867r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19867r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19867r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19867r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19867r=support Expected behavior: http://bugs.php.net/fix.php?id=19867r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19867r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19867r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19867r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19867r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19867r=dst IIS Stability: http://bugs.php.net/fix.php?id=19867r=isapi
#19869 [NEW]: bug in array_rand
From: [EMAIL PROTECTED] Operating system: windows PHP version: 4.2.2 PHP Bug Type: Scripting Engine problem Bug description: bug in array_rand I've found a bug with array_rand in PHP 4.2.2; it works in earlier versions, however when tested in newer PHP versions the output never changes. eg. srand ((double)microtime()*100); $backgrounds = range (1,28); $rand_keys = array_rand ($backgrounds, 3); print $backgrounds[$rand_keys[0]].~.$backgrounds[$rand_keys[1]].~.$backgrounds[$rand_keys[2]]; This would always for me produce the same results for me whatever I try. -- Edit bug report at http://bugs.php.net/?id=19869edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19869r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19869r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19869r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19869r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19869r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19869r=support Expected behavior: http://bugs.php.net/fix.php?id=19869r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19869r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19869r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19869r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19869r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19869r=dst IIS Stability: http://bugs.php.net/fix.php?id=19869r=isapi
#19292 [Ctl]: random error: open_basedir restriction in effect. File is in wrong directory
ID: 19292 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating System: linux PHP Version: 4.2.3 New Comment: I can confirm the message from [EMAIL PROTECTED] Same problem here on several linux boxes that servers a nummer of virtual host. On some vhosts we have these error on every 2nd hit. There is a chance that these kind of error not effected is to the first vhost. I have made a test with the latest 'php4-20021010' with shows the same behavior. Realy weird is that the unkown error messages shows the WRONG settings (open_basedir) for that vhosts. Screenshot: http://sgi.takenet.de/~beh/error.gif They are 2 other things out there that apps that using pear(cache) shows open_basedir restrictions too. But the pear directory is always allowed. The make install prozess from the php latest and php-4.3rc1 shows both tng-web:/usr/src/php-4.3.0pre1 # make install Installing PHP SAPI module [activating module `php4' in /usr/apache/conf/httpd.conf] cp libs/libphp4.so /usr/apache/libexec/libphp4.so chmod 755 /usr/apache/libexec/libphp4.so cp /usr/apache/conf/httpd.conf /usr/apache/conf/httpd.conf.bak cp /usr/apache/conf/httpd.conf.new /usr/apache/conf/httpd.conf rm /usr/apache/conf/httpd.conf.new Installing shared extensions: /usr/lib/php/extensions/no-debug-non-zts-20020429/ Installing PHP CLI binary:/usr/bin/ Installing PEAR environment: /usr/lib/php/ Warning: file_exists() [http://www.php.net/function.file-exists]: SAFE MODE Restriction in effect. The script whose uid is 500 is not allowed to access /root owned by uid 0 in /daten/src/php-4.3.0pre1/pear/PEAR/Config.php on line 282 a lot of more warnings. Screenshot: http://sgi.takenet.de/~beh/error2.gif We are not using any kind of caching software or other 3rd party modules. And yes.. switching back to 4.2.1 solves all the problems without making any changes on configfiles (php.ini , httpd.conf) Previous Comments: [2002-10-10 08:43:37] [EMAIL PROTECTED] Keep this at 'Critical' status. ([EMAIL PROTECTED]: Can you be a bit more specific? And did you test with PHP 4.3.0-dev there?) [2002-10-10 05:05:17] [EMAIL PROTECTED] Same here, yet only on one of four production boxes. Error randomly pops up, and is gone after reloading (seems to be only one apache child at a time is effected). Seems like the error occurs for all functions using file i/o, mainly include() in our case. [2002-10-09 13:13:09] [EMAIL PROTECTED] Could someone please check if this is still a problem in current CVS? [2002-10-05 19:28:45] [EMAIL PROTECTED] Keep it critical. [2002-10-05 10:43:37] [EMAIL PROTECTED] I just checked in a change to the open_basedir check. I don't think it is a fix for your problems, but it could be. Please try using this CVS snapshot on a non-production machine: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Thanks, Brian 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/19292 -- Edit this bug report at http://bugs.php.net/?id=19292edit=1
#19870 [NEW]: Assertion failure in mips_emit_delays at ./config/tc-mips.c line 2231.
From: [EMAIL PROTECTED] Operating system: LInux 4 Cobalt RAQ2 PHP version: 4.2.3 PHP Bug Type: *Compile Issues Bug description: Assertion failure in mips_emit_delays at ./config/tc-mips.c line 2231. hi, After getting latest php from CVS i still get same Attention message after running ./configure. CONFIGURE: './configure' '--with-apxs' '--with-mysql' '--with-gettext' '--with-xml' '--with-imap' '--enable-ftp' CC: gcc CFLAGS: -g -O2 CPPFLAGS:-D_XPG_IV -DCOBALT_RAQ_LED -DLINUX=2 CXX: CXXFLAGS: INCLUDES: -I$(top_builddir)/Zend -I/usr/local/include LDFLAGS: -Wl,-rpath,/usr/local/lib -L/usr/local/lib LIBS: -lcrypt -lpam -lcrypt -lresolv -lm -ldl -lnsl -lcrypt DLIBS: -lc-client SAPI: apache PHP_RPATHS: /usr/local/lib uname -a: Linux piper.remixnetworks.com 2.0.34C52_SK #1 Tue Nov 30 18:14:40 PST 1999 mips unknown gcc -o conftest -g -O2 -D_XPG_IV -DCOBALT_RAQ_LED -DLINUX=2 -Wl,-rpath,/usr/local/lib -L/usr/local/lib conftest.c -lcrypt -lpam -lcrypt -lresolv -lm -ldl -lnsl -lcrypt 15 /tmp/cca09867.s: Assembler messages: /tmp/cca09867.s:72: Internal error! Assertion failure in mips_emit_delays at ./config/tc-mips.c line 2231. Please report this bug. -- Edit bug report at http://bugs.php.net/?id=19870edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19870r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19870r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19870r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19870r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19870r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19870r=support Expected behavior: http://bugs.php.net/fix.php?id=19870r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19870r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19870r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19870r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19870r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19870r=dst IIS Stability: http://bugs.php.net/fix.php?id=19870r=isapi
#19871 [NEW]: Query returning all the same data
From: [EMAIL PROTECTED] Operating system: W2K Terminal Server PHP version: 4.2.3 PHP Bug Type: ODBC related Bug description: Query returning all the same data I am running a Progress Database with a ODBC data source entry. I have a test table with 4 records in it. Each record has three fields. ID, Name and Total. The information in the table is... Index on Name. ID Name Total 1 Horse 21 2 Cow30 3 Eagle 14 2 Cow34 Here is my actual code. $DBName = php; $TableName = PUB.table1; $Query = SELECT * from $TableName; $Link = odbc_connect ($DBName,$User,$Password); $Results = odbc_do($Link, $Query); print odbc_result_all($Results); What I expect to see was four lines of data display as above. What I got was... ID Name Total 2 Cow 30 2 Cow 30 2 Cow 30 2 Cow 30 I have tried 10-15 different ways to access the $Results to no avail. Then I decided to see if it was SQL problem. Using another SQL interface to the Progress Database, I performed the same query and got the expected results. Next I decided to see if it was an ODBC problem. My first approach was to set up a query within a MSExcel spreadsheet. This worked just fine and got the expected results. This told me that the ODBC driver used to access the Progress Database was working. Next I wanted to see if it was an PHP/ODBC command problem. So I set up an MS Access database and created an ODBC entry for it using the Microsoft driver for ODBC/mdb. I got the expected results. In fact the only difference between the php script for MS Access and Progress was the name of the Data Source. I also didn't need to use PUB in front of the table name. I used the exact same code to query and print the results. This leads me to believe that the problem here is the interaction of php and the driver for Progress. The ODBC driver that is shipped with Progress is MERANT 3.60 32-BIT Progress SQL92 v9.1C 3.60.00.00 Again, everything points to a problem between php and the driver for Progress. Using the same driver in both Excel, MS Word works just fine. I would appreciate it if someone would look into this for me. Thanks -- Edit bug report at http://bugs.php.net/?id=19871edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19871r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19871r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19871r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19871r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19871r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19871r=support Expected behavior: http://bugs.php.net/fix.php?id=19871r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19871r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19871r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19871r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19871r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19871r=dst IIS Stability: http://bugs.php.net/fix.php?id=19871r=isapi
