#19594 [Csd]: dba extension segfaults with the db2 driver
ID: 19594 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: DBM/DBA related Operating System: Slackware Linux PHP Version: 4CVS-2002-09-25 New Comment: I know that it should work, but I like to test the different drivers, just for QA on DBA (I maintain it). I'll add the db2 blessing to the DBA class before the next release. Plus, there always seem to be slight differences in how dba drivers work, for which the class compensates (e.g. no dba_replace in gdbm). Hmm, maybe that should be a separate bug report ;) I suppose adding a dba_sync() before closing should be something that the DBA class does with a db2 database (having read the user notes on the PHP manual pages about it not writing to disk unless this is so). Thanks for the help. Previous Comments: [2002-09-28 22:45:16] [EMAIL PROTECTED] It works fine with db 2.7.7 (I have that installed). btw. the PEAR DBA class should work with other dbm libs too...like gdbm and ndbm..(there are quite a few..) [2002-09-28 21:24:43] [EMAIL PROTECTED] I can't get a different copy of db2 installed, so I still don't know if dba works with something other than that installed with slack-current. The Sleepcat db2 installation process boggled my mind. So, if anyone can confirm that it works at all, I'll leave it at that. This was just for testing the DBA class in PEAR, not that I would use db2 personally :P [2002-09-26 22:13:30] [EMAIL PROTECTED] The version is 2.4.14, the default supplied with Slackware. I'm installing 2.7.7 now and will let Pat know if he needs to make an upgrade. [2002-09-26 09:50:28] [EMAIL PROTECTED] I can not reproduce this with latest CVS HEAD using your script. I think it's a problem in your db2 library. What version is it? [2002-09-25 10:15:29] [EMAIL PROTECTED] Here it is. It looks like a string is not allocated correctly. #0 0x081ebb90 in memp_register () #1 0x40040c6b in db_open () from /lib/libdb.so.3 #2 0x0807aa0c in dba_open_db2 (info=0x82ea510) at /home/busterb/cvs/php4/php4/ext/dba/dba_db2.c:74 #3 0x0807a4f8 in php_dba_open (ht=3, return_value=0x82ea4b4, this_ptr=0x0, return_value_used=0, persistent=0) at /home/busterb/cvs/php4/php4/ext/dba/dba.c:346 #4 0x08079e0e in zif_dba_open (ht=3356467, return_value=0x333733, this_ptr=0x333733, return_value_used=3356467) at /home/busterb/cvs/php4/php4/ext/dba/dba.c:386 #5 0x081a6dcf in execute (op_array=0x82e9fbc) at /home/busterb/cvs/php4/php4/Zend/zend_execute.c:1602 #6 0x0818f45c in zend_eval_string (str=0xbfffd55c "", retval_ptr=0x0, string_name=0x333733 ) at /home/busterb/cvs/php4/php4/Zend/zend_execute_API.c:630 #7 0x081ac68d in main (argc=3, argv=0xbfffd764) at /home/busterb/cvs/php4/php4/sapi/cli/php_cli.c:737 #8 0x4033317d in __libc_start_main () from /lib/libc.so.6 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/19594 -- Edit this bug report at http://bugs.php.net/?id=19594&edit=1
#11993 [Opn->Csd]: mysql_close closes incorrect db handler
ID: 11993 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: MySQL related Operating System: Debian 2.19 PHP Version: 4.1.0 Assigned To: zak New Comment: Zak, I already tested it. Please change the status after you detected some possible errors, not before. Georg Previous Comments: [2002-09-19 23:09:18] [EMAIL PROTECTED] I need to check out how this behaves in the current CVS [2002-07-10 05:18:52] [EMAIL PROTECTED] If you want to have always a new link, specify the optional parameter new_link, which is implemented since version 4.2.0. See also: http://www.php.net/manual/en/function.mysql-connect.php [2001-12-31 19:15:55] [EMAIL PROTECTED] doh. [2001-12-31 18:56:34] [EMAIL PROTECTED] I will take a look at this. [2001-12-13 11:13:44] [EMAIL PROTECTED] sorry, i can not try with php4.1.0RC3. I tried out with the latest php4.1.0, and no changes, the problem still exists. ati 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/11993 -- Edit this bug report at http://bugs.php.net/?id=11993&edit=1
#19653 [Opn->Bgs]: sql 2000
ID: 19653 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus -Bug Type: *Database Functions +Bug Type: MSSQL related Operating System: windowx xp professional 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-09-28 16:56:10] [EMAIL PROTECTED] microsoft sql 2000 will not work in php 4.2.3, the driver mssql.dll can't open the database -- Edit this bug report at http://bugs.php.net/?id=19653&edit=1
#19650 [Opn->Fbk]: 4.2.3 (!) "include" operator mistake
ID: 19650 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 4.2.3 New Comment: 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 Previous Comments: [2002-09-28 11:23:53] [EMAIL PROTECTED] I'm trying to write here again (maybe previous thread is down?). You said before this bug in NOT actual in 4.2.3, but code STILL DOES NOT work in 4.2.3. So, PHP v4.2.0 (and later) on Windows: include "/home/some/site.php"; - DOES NOT work (try to believe)! We have to use instead: include "z:/home/some/site.php"; # bad... Bad?.. BAD!!! Previous PHP v4.1.0: include "/home/some/site.php"; - works correct. I think that since 4.2.0 pathes like "/some/where" does not treated as absolute. For example, if we add "z:" to "include_path", include "/home/some/site.php" become workable - it is only the prove. It is VERY loathsome bug, because it makes Windows scripts incompatible with Unix and with previous PHP versions. Again, new version (4.2.3) has THE SAME bug: Z:\!distrib\php-4.2.3-Win32>php.exe ^Z Warning: Failed opening '/test.php' for inclusion (include_path='.;c:\php4\pear') in - on line 2 If I use "include 'z:/test.php'", it works. Please help (our clients are very angry!) P.S. DocumentRoot "/home/site/www" ... GET http://site/test.php - DOES NOT work too. It seems to me mod_php uses the same "include" function while starting the script. -- Edit this bug report at http://bugs.php.net/?id=19650&edit=1
#18523 [Fbk->Opn]: httpd Memory consumption with new PHP
ID: 18523 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Apache related Operating System: BSDI 4.1 PHP Version: 4.2.2 New Comment: su# ls libs/ libphp4.a libphp4.la su# ls .libs/ libphp4.a libphp4.la libphp4.lai Previous Comments: [2002-09-28 22:47:48] [EMAIL PROTECTED] Is there anything in .libs/ or libs/ directory? [2002-09-27 01:42:25] [EMAIL PROTECTED] Did not work; didn't generate the .so su# make install Installing PHP SAPI module [activating module `php4' in /usr/local/web/apache/conf/httpd.conf] cp libs/libphp4.so /usr/local/web/apache/libexec/libphp4.so cp: libs/libphp4.so: No such file or directory apxs:Break: Command failed with rc=1 *** Error code 1 [2002-09-26 19:51:45] [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 [2002-09-08 03:36:42] [EMAIL PROTECTED] Ok No, it isn't. Same issue of wanting a shared libc-client library. I tried the snapshot, and it didn't complain about that, but failed during the make install. (I forget where, I'll try another snapshot in a couple days) [2002-09-07 07:16:11] [EMAIL PROTECTED] > Is this fixed in 4.2.3? I don't know :) Try 4.2.3 and report result back. 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/18523 -- Edit this bug report at http://bugs.php.net/?id=18523&edit=1
#18523 [Opn->Fbk]: httpd Memory consumption with new PHP
ID: 18523 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache related Operating System: BSDI 4.1 PHP Version: 4.2.2 New Comment: Is there anything in .libs/ or libs/ directory? Previous Comments: [2002-09-27 01:42:25] [EMAIL PROTECTED] Did not work; didn't generate the .so su# make install Installing PHP SAPI module [activating module `php4' in /usr/local/web/apache/conf/httpd.conf] cp libs/libphp4.so /usr/local/web/apache/libexec/libphp4.so cp: libs/libphp4.so: No such file or directory apxs:Break: Command failed with rc=1 *** Error code 1 [2002-09-26 19:51:45] [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 [2002-09-08 03:36:42] [EMAIL PROTECTED] Ok No, it isn't. Same issue of wanting a shared libc-client library. I tried the snapshot, and it didn't complain about that, but failed during the make install. (I forget where, I'll try another snapshot in a couple days) [2002-09-07 07:16:11] [EMAIL PROTECTED] > Is this fixed in 4.2.3? I don't know :) Try 4.2.3 and report result back. [2002-09-07 01:10:58] [EMAIL PROTECTED] Is this fixed in 4.2.3? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18523 -- Edit this bug report at http://bugs.php.net/?id=18523&edit=1
#19594 [Opn->Csd]: dba extension segfaults with the db2 driver
ID: 19594 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: DBM/DBA related Operating System: Slackware Linux PHP Version: 4CVS-2002-09-25 New Comment: It works fine with db 2.7.7 (I have that installed). btw. the PEAR DBA class should work with other dbm libs too...like gdbm and ndbm..(there are quite a few..) Previous Comments: [2002-09-28 21:24:43] [EMAIL PROTECTED] I can't get a different copy of db2 installed, so I still don't know if dba works with something other than that installed with slack-current. The Sleepcat db2 installation process boggled my mind. So, if anyone can confirm that it works at all, I'll leave it at that. This was just for testing the DBA class in PEAR, not that I would use db2 personally :P [2002-09-26 22:13:30] [EMAIL PROTECTED] The version is 2.4.14, the default supplied with Slackware. I'm installing 2.7.7 now and will let Pat know if he needs to make an upgrade. [2002-09-26 09:50:28] [EMAIL PROTECTED] I can not reproduce this with latest CVS HEAD using your script. I think it's a problem in your db2 library. What version is it? [2002-09-25 10:15:29] [EMAIL PROTECTED] Here it is. It looks like a string is not allocated correctly. #0 0x081ebb90 in memp_register () #1 0x40040c6b in db_open () from /lib/libdb.so.3 #2 0x0807aa0c in dba_open_db2 (info=0x82ea510) at /home/busterb/cvs/php4/php4/ext/dba/dba_db2.c:74 #3 0x0807a4f8 in php_dba_open (ht=3, return_value=0x82ea4b4, this_ptr=0x0, return_value_used=0, persistent=0) at /home/busterb/cvs/php4/php4/ext/dba/dba.c:346 #4 0x08079e0e in zif_dba_open (ht=3356467, return_value=0x333733, this_ptr=0x333733, return_value_used=3356467) at /home/busterb/cvs/php4/php4/ext/dba/dba.c:386 #5 0x081a6dcf in execute (op_array=0x82e9fbc) at /home/busterb/cvs/php4/php4/Zend/zend_execute.c:1602 #6 0x0818f45c in zend_eval_string (str=0xbfffd55c "", retval_ptr=0x0, string_name=0x333733 ) at /home/busterb/cvs/php4/php4/Zend/zend_execute_API.c:630 #7 0x081ac68d in main (argc=3, argv=0xbfffd764) at /home/busterb/cvs/php4/php4/sapi/cli/php_cli.c:737 #8 0x4033317d in __libc_start_main () from /lib/libc.so.6 [2002-09-25 09:42:42] [EMAIL PROTECTED] Please recompile PHP with --enable-debug and post a new backtrace. 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/19594 -- Edit this bug report at http://bugs.php.net/?id=19594&edit=1
#19594 [Opn]: dba extension segfaults with the db2 driver
ID: 19594
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: DBM/DBA related
Operating System: Slackware Linux
PHP Version: 4CVS-2002-09-25
New Comment:
I can't get a different copy of db2 installed, so I still don't know if
dba works with something other than that installed with slack-current.
The Sleepcat db2 installation process boggled my mind.
So, if anyone can confirm that it works at all, I'll leave it at that.
This was just for testing the DBA class in PEAR, not that I would use
db2 personally :P
Previous Comments:
[2002-09-26 22:13:30] [EMAIL PROTECTED]
The version is 2.4.14, the default supplied with
Slackware.
I'm installing 2.7.7 now and will let Pat know if he needs
to make an upgrade.
[2002-09-26 09:50:28] [EMAIL PROTECTED]
I can not reproduce this with latest CVS HEAD using your script. I
think it's a problem in your db2 library.
What version is it?
[2002-09-25 10:15:29] [EMAIL PROTECTED]
Here it is. It looks like a string is not allocated
correctly.
#0 0x081ebb90 in memp_register ()
#1 0x40040c6b in db_open () from /lib/libdb.so.3
#2 0x0807aa0c in dba_open_db2 (info=0x82ea510) at
/home/busterb/cvs/php4/php4/ext/dba/dba_db2.c:74
#3 0x0807a4f8 in php_dba_open (ht=3,
return_value=0x82ea4b4, this_ptr=0x0, return_value_used=0,
persistent=0) at
/home/busterb/cvs/php4/php4/ext/dba/dba.c:346
#4 0x08079e0e in zif_dba_open (ht=3356467,
return_value=0x333733, this_ptr=0x333733,
return_value_used=3356467) at
/home/busterb/cvs/php4/php4/ext/dba/dba.c:386
#5 0x081a6dcf in execute (op_array=0x82e9fbc)
at
/home/busterb/cvs/php4/php4/Zend/zend_execute.c:1602
#6 0x0818f45c in zend_eval_string (str=0xbfffd55c "",
retval_ptr=0x0,
string_name=0x333733 )
at
/home/busterb/cvs/php4/php4/Zend/zend_execute_API.c:630
#7 0x081ac68d in main (argc=3, argv=0xbfffd764)
at /home/busterb/cvs/php4/php4/sapi/cli/php_cli.c:737
#8 0x4033317d in __libc_start_main () from /lib/libc.so.6
[2002-09-25 09:42:42] [EMAIL PROTECTED]
Please recompile PHP with --enable-debug and post a new backtrace.
[2002-09-25 09:28:42] [EMAIL PROTECTED]
Creating a new db2 database causes a segfault with
dba_open()
$ php -v
PHP 4.3.0-dev (cli), Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend
Technologies
$ php -r "dba_open ("file_test", "n", "db2");"
Segmentation fault
This is the backtrace:
#0 0x081ad050 in memp_register ()
#1 0x40031c6b in db_open () from /lib/libdb.so.3
#2 0x0807567a in dba_open_db2 ()
#3 0x080752b0 in php_dba_open ()
#4 0x08074d3e in zif_dba_open ()
#5 0x0816928c in execute ()
#6 0x0815cd0b in zend_execute_scripts ()
#7 0x081374a9 in php_execute_script ()
#8 0x0816dc6b in main ()
#9 0x4028917d in __libc_start_main () from /lib/libc.so.6
--
Edit this bug report at http://bugs.php.net/?id=19594&edit=1
#12360 [Csd]: fsockopen timeout doesn't work
ID: 12360 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Sockets related Operating System: RedHat 6.2 PHP Version: 4.0.6 New Comment: [EMAIL PROTECTED]: 4.1.2 is too old; can you try a non-stable snapshot from http://snaps.php.net/win32/. Despite the term non-stable, it should be quite stable and will form the base of PHP 4.3 which we are branching for QA and the release process shortly. Previous Comments: [2002-09-28 16:18:59] [EMAIL PROTECTED] It's now year 2002 and I'm using php 4.1.2 and neither is the timeout parameter to the fsockopen function working properly, nor is the socket_set_timeout function i've written a small monitoring program that kills php processes that has been working too long (i use the php scripts by running them in the console).. and the interesting thing is that when i run the same script in several instances, they seem to hang in pairs (but NOT always). Perhaps they try to use the same outgoing port? and this is not something rare, i've been logging the kills and it happens once (two kills) every 10-15 minutes, once killed they are restarted by a loop in a batch file. i'm using windows xp with php 4.1.2 and apache (but as i said, i'm simply running the scripts without apache in the console, "php script.php"..) i remember having this problem when run in linux.. i've seen many similar bugreports but nothing seem to have been done to adress the problem.. keep up the good work, Osman Darcan [2001-08-10 16:16:06] [EMAIL PROTECTED] I put that include in CVS, and it will be in 4.0.7 if there are no problems with it. I did limited testing, but don't know this helped. alindeman: _please_ test this... If this isn't fixed, please reopen. [2001-08-06 18:16:02] [EMAIL PROTECTED] [EMAIL PROTECTED]: > I have not looked into this a lot so I might be mistaken, but it > seems that the problem is that fcntl.h is not defined in main/network.c > > If I add the following lines to main/network.c it seems that timeout > works again: > > #ifndef _FCNTL_H > #include > #endif > > I'm running Debian 2.2r3 with PHP 4.0.6 > > Regards, > Michael [2001-07-25 09:34:30] [EMAIL PROTECTED] I have reproduced this error. When requesting an valid address, but a port that the server does not listen on, the script hangs. (*Andy*) [2001-07-25 09:30:06] [EMAIL PROTECTED] or at least it doesn't time out until after a very long time 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/12360 -- Edit this bug report at http://bugs.php.net/?id=12360&edit=1
#19654 [NEW]: function to call class methods
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.2.3 PHP Bug Type: Feature/Change Request Bug description: function to call class methods We have $$objname->$methodname() for dinamic method calls, and even call_user_func(array(&$$objname, $methodname), but we have no $classname::$methodname() or call_class_method($classname, $methodname) or anything like this. It would be nice to call class methods dinamicaly, as many times classes are used for namespace resons, and there is no need to have instances of them. -- Edit bug report at http://bugs.php.net/?id=19654&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19654&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19654&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19654&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19654&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19654&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19654&r=support Expected behavior: http://bugs.php.net/fix.php?id=19654&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19654&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19654&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19654&r=globals
#16231 [Opn->Fbk]: when using include, __FILE__ prepends / to relative paths
ID: 16231 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: HP-UX 11.0 PHP Version: 4.1.2 New Comment: 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 Previous Comments: [2002-05-04 00:27:44] [EMAIL PROTECTED] Had some feedback from Scott Kearney from Harvard Uni:- He also experienced this on an OSF/1 platform. One of his colleagues traced this to a directory permissions issue. It appears that if a higher level directory has execute permission but not read permission, this problem appears. Changing the higher level directories to permission 555 fixed this. This is a good workaround but I don't want to compromise my system security to get an application to work ;-) Thanks to Scott and his colleagues for their input. [2002-03-23 09:12:54] [EMAIL PROTECTED] Summary: when using include, __FILE__ prepends / to relative paths History: Received errors from imp3.0 saying could not find included file. Error message reported strange path names. See Horde bugs #911 and #912. Sample Code: a.php => included as lib/a.php reports "; include 'lib/a.php'; echo "included as ./lib/a.php reports "; include './lib/a.php'; echo "included as /www/yacc/tmp/lib/a.php reports "; include '/www/yacc/tmp/lib/a.php'; ?> lib/a.php => When I do this, I get Calling file /www/yacc/tmp/a.php included as lib/a.php reports /lib/a.php included as ./lib/a.php reports /lib/a.php included as /www/yacc/tmp/lib/a.php reports /www/yacc/tmp/lib/a.php Something keeps putting a leading / on relative paths! Other Tests: I created a simple C program to print out the __FILE__ value. When is compile it with HP's ANSI C compiler it works as expected i.e. the value is as specified in the include. When I compile with GNU CC compiler (gcc) the value is "sanitised". See below /home/gedl/tmp $ cc -o a a.c ./lib/b.c && echo "The output" && ./a a.c: ./lib/b.c: The output a.c ./lib/b.c /home/gedl/tmp $ gcc -o a a.c ./lib/b.c && echo "The output" && ./a The output a.c lib/b.c /home/gedl/tmp $ Essentially the same but not exactly. However both compilers give a valid answer. I will continue to work on it but if someone has an answer it would be appreciated. Cheers Ged -- Edit this bug report at http://bugs.php.net/?id=16231&edit=1
#19653 [NEW]: sql 2000
From: [EMAIL PROTECTED] Operating system: windowx xp professional PHP version: 4.2.3 PHP Bug Type: *Database Functions Bug description: sql 2000 microsoft sql 2000 will not work in php 4.2.3, the driver mssql.dll can't open the database -- Edit bug report at http://bugs.php.net/?id=19653&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19653&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19653&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19653&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19653&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19653&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19653&r=support Expected behavior: http://bugs.php.net/fix.php?id=19653&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19653&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19653&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19653&r=globals
#15890 [Com]: MSSQL 2000 with php_mssql.dll - will not function
ID: 15890 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: MSSQL related Operating System: Windows 2000 advanced server PHP Version: 4.1.1 New Comment: es 1 de octubre del 2000 y el php con sql 2000 sigue sin funcionar alguien sabe como? Previous Comments: [2002-09-28 16:50:51] [EMAIL PROTECTED] es 1 de octubre del 2000 y el php con sql 2000 sigue sin funcionar alguien sabe como? [2002-06-18 15:39:57] [EMAIL PROTECTED] And it looks as thou I can't spell today. ;) [2002-06-18 15:38:46] [EMAIL PROTECTED] Even if you say they are Don't you think you should check first? I'm serios when I say I've tried the defaults a million times.. WITHOUT THAT IN PHP.INI IT WILL NOT FUNCTION! I have just under 12 million dollors worth of equipment that I'm working with here guys. [2002-06-18 04:53:08] [EMAIL PROTECTED] They are the defaults, I just checked. Closing this, as this is not a bug in PHP. Derick [2002-06-04 18:17:19] [EMAIL PROTECTED] they can't be. it does not work .period. without that info thrown into the PHP.ini file. I can't fathum how many times i've seen it not work with default. 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/15890 -- Edit this bug report at http://bugs.php.net/?id=15890&edit=1
#15890 [Com]: MSSQL 2000 with php_mssql.dll - will not function
ID: 15890 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: MSSQL related Operating System: Windows 2000 advanced server PHP Version: 4.1.1 New Comment: es 1 de octubre del 2000 y el php con sql 2000 sigue sin funcionar alguien sabe como? Previous Comments: [2002-06-18 15:39:57] [EMAIL PROTECTED] And it looks as thou I can't spell today. ;) [2002-06-18 15:38:46] [EMAIL PROTECTED] Even if you say they are Don't you think you should check first? I'm serios when I say I've tried the defaults a million times.. WITHOUT THAT IN PHP.INI IT WILL NOT FUNCTION! I have just under 12 million dollors worth of equipment that I'm working with here guys. [2002-06-18 04:53:08] [EMAIL PROTECTED] They are the defaults, I just checked. Closing this, as this is not a bug in PHP. Derick [2002-06-04 18:17:19] [EMAIL PROTECTED] they can't be. it does not work .period. without that info thrown into the PHP.ini file. I can't fathum how many times i've seen it not work with default. [2002-06-04 10:16:53] [EMAIL PROTECTED] Those are the default values i think. 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/15890 -- Edit this bug report at http://bugs.php.net/?id=15890&edit=1
#19111 [Opn->Dup]: Incorect working !false
ID: 19111
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Duplicate
Bug Type: Zend Engine 2 problem
Operating System: Windows2000
PHP Version: 4CVS-2002-08-26
New Comment:
duplicate of #18768
Previous Comments:
[2002-09-06 03:51:39] [EMAIL PROTECTED]
it looks like this problem only happens when the script is called with
php as an apache module, because true/false constants are not defined
and appear as string which means they always evaluate to true !
but when you var_dump(true) or var_dump(false) on a command line call
to php, then they are well defined as booleans !!!
[2002-08-26 12:36:33] [EMAIL PROTECTED]
Constriction
if (!false) {
echo "HERE";
}
under Win32 doestn work.
echo (int) (!false); // display 0
Under Linux all working.
Php 4.3 Dev
--
Edit this bug report at http://bugs.php.net/?id=19111&edit=1
#12360 [Com]: fsockopen timeout doesn't work
ID: 12360 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Sockets related Operating System: RedHat 6.2 PHP Version: 4.0.6 New Comment: It's now year 2002 and I'm using php 4.1.2 and neither is the timeout parameter to the fsockopen function working properly, nor is the socket_set_timeout function i've written a small monitoring program that kills php processes that has been working too long (i use the php scripts by running them in the console).. and the interesting thing is that when i run the same script in several instances, they seem to hang in pairs (but NOT always). Perhaps they try to use the same outgoing port? and this is not something rare, i've been logging the kills and it happens once (two kills) every 10-15 minutes, once killed they are restarted by a loop in a batch file. i'm using windows xp with php 4.1.2 and apache (but as i said, i'm simply running the scripts without apache in the console, "php script.php"..) i remember having this problem when run in linux.. i've seen many similar bugreports but nothing seem to have been done to adress the problem.. keep up the good work, Osman Darcan Previous Comments: [2001-08-10 16:16:06] [EMAIL PROTECTED] I put that include in CVS, and it will be in 4.0.7 if there are no problems with it. I did limited testing, but don't know this helped. alindeman: _please_ test this... If this isn't fixed, please reopen. [2001-08-06 18:16:02] [EMAIL PROTECTED] [EMAIL PROTECTED]: > I have not looked into this a lot so I might be mistaken, but it > seems that the problem is that fcntl.h is not defined in main/network.c > > If I add the following lines to main/network.c it seems that timeout > works again: > > #ifndef _FCNTL_H > #include > #endif > > I'm running Debian 2.2r3 with PHP 4.0.6 > > Regards, > Michael [2001-07-25 09:34:30] [EMAIL PROTECTED] I have reproduced this error. When requesting an valid address, but a port that the server does not listen on, the script hangs. (*Andy*) [2001-07-25 09:30:06] [EMAIL PROTECTED] or at least it doesn't time out until after a very long time [2001-07-25 09:29:17] [EMAIL PROTECTED] it never times out... 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/12360 -- Edit this bug report at http://bugs.php.net/?id=12360&edit=1
#13936 [Ver->Csd]: Magical Constant __FILE__ contains wrong information on included files
ID: 13936 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Verified +Status: Closed Bug Type: Scripting Engine problem Operating System: Solaris PHP Version: 4.3.0-dev 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-05-12 14:19:16] [EMAIL PROTECTED] this bug is also happening with OS: Open BSD 3.0, PHP 4.2.0 the following was generated on maintenenance-priority.php (the other __FILE__ prints were generated from the included files): __FILE__: /home2/kumar/www/chicagomodular.com/phpAdsNew/ admin/maintenance-priority.php __FILE__: /config.php __FILE__: /lib-maintenance.inc.php for the phpAdsNew application this is a serious bug since __FILE__ is used to define an include-path constant [2002-02-27 13:42:37] [EMAIL PROTECTED] Re-opening since this bug appear to be still going on. I didn't really test the fixes on 4.1.1 since I'm using a similar routine to report errors, but it would be nice to catch some attention. --Joao [2002-02-27 12:40:44] [EMAIL PROTECTED] I was having problems with this same thing on Solaris under PHP 4.1.1, so I tried the 4.2 version, and it seems to me that the problem is still there. I create a file called "test.php" containing: When I: php test.php I get: file test.php I expect to get: file /cs/home/jas/test.php Shouldn't __FILE__ always return a full path to a file? Jason. [2001-11-05 17:24:49] [EMAIL PROTECTED] Yeah, ok, but that was far from apparent in your original report. So you mean that the bug is that not the full path is given? I agree, that's a bug. __FILE__ should give the full path of the script in which the __FILE__ is. I reproduce it with 4.0.6, but it apparently is fixed in 4.2.0, since with the exact same env and script etc I get the correct result now. So closing. --Jeroen [2001-11-05 17:05:30] [EMAIL PROTECTED] Another good argument in favor of __FILE__ returning the full path is the actual purpose of this variable. People usually use __FILE__ and __LINE__ to develop routines to report problems or even events on their applications. As the manual says, one could write something like this: To get a report of eventual errors on some library file. Can you tell me how would I know _which_ library file or script the error occurred without __FILE__ returning me the full path of the offending script ? We could have several 'index.php' files running this 'report_error' function, and if __FILE__ returns only 'index.php', then we wouldn't know exactly which file it is. Anyway, I think it is pretty clear __FILE__ should return the full path. --Joao 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/13936 -- Edit this bug report at http://bugs.php.net/?id=13936&edit=1
#15983 [Com]: session variables lost between pages
ID: 15983
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: Debian/Linux mips platform
PHP Version: 4.1.2 and 4.2.0
Assigned To: sascha
New Comment:
PHP 4.2.3 works for me on Debian Woody PowerPC.
Previous Comments:
[2002-09-26 11:18:28] [EMAIL PROTECTED]
I cannot ensure you that 4.2.3 solves the problem
as I still have not upgraded from version 4.2.2,
but I am sure that it works, as the only change needed
to make things work for me has been the removal
of the lines that have been kindly removed
for version 4.2.3 (many thanks).
BTW, the same workaround has been backported on the
Debian Woody's 4.1.2 packages, and in a short time
I could check if the fix works on Woody for Sparc.
I also point out that, as this problem seems due to a glibc
bug and not to errors in the PHP code, I have submitted
a bug report to the Debian's glibc maintainer, asking him
to backport a fix for the glibc packages; hence, hopefully,
in the future, updated Linux distributions should have
a fixed glibc package and you could finally ignore this
problem and restore the code using pread().
But I would like to submit you a simple (and perhaps
stupid) suggestion.
Maybe you could provide a ./configure option to explicitly
disable the use of pread() and pwrite(), i.e.
./configure --no-pread --no-pwrite
In this case, you could release without problems the code
using pread() and pwrite(); the person that compiles and/or
packages PHP has the possibility of disabling pread()
and/or pwrite() if things do not work... is this
a bad idea?
[2002-09-25 16:36:09] [EMAIL PROTECTED]
Sascha it's not a problem of using a feature on their system, it's a
problem that the functionality is broken on their end. Your test,
while possibly being correct, doesn't have a way to check this and
I don't really think there is a way.
As of this moment I'm not even sure if there is a released version with
it working.
Marking this as open, as there is nothing the end user can comment back
on to this.
[2002-09-25 06:17:49] [EMAIL PROTECTED]
If you want us to avoid using certain features of your platform, then
you need to provide specific testcases. We will use these testcases to
determine whether pread/pwrite work on a platform.
Currently, we use this for pread (after echo test > conftest_in):
#include
#include
#include
#include
main() { char buf[3]; return !(pread(open("conftest_in", O_RDONLY),
buf, 2, 0) == 2);
And this for pwrite:
#include
#include
#include
#include
main() { return !(pwrite(open("conftest_in", O_WRONLY|O_CREAT, 0600),
"hi", 2, 0) == 2);
[2002-09-12 16:15:34] [EMAIL PROTECTED]
I'd like to see this fixed for 4.3.0. Right now the simple answer is
to remove PREAD (again).
[2002-09-12 16:06:39] [EMAIL PROTECTED]
Assigning to sascha as he was busy with it.
Derick
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/15983
--
Edit this bug report at http://bugs.php.net/?id=15983&edit=1
#19648 [Bgs]: fopen() and current user
ID: 19648 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Feature/Change Request Operating System: GNU/Linux or any Unix variant PHP Version: 4.2.2 New Comment: this is just how the unix security model works, only owner and root can chmod files Previous Comments: [2002-09-28 09:08:27] [EMAIL PROTECTED] I know its not a bug, thats why I put it under: Feature/Change Request :) Well, if you can't answer the question, can you tell me where I can get an answer then? :) [2002-09-28 09:04:19] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2002-09-28 08:56:56] [EMAIL PROTECTED] fopen() uses the user running PHP to open the selected file. This causes problems when you e.g. make a filemanager. All files created with the filemanger will be owned by the www user and chmod'ed to 644. On the other side, the filemanger cannot alter files as they are (mostly) owned by the user (e.g. raz0). This makes it quite hard to make useful filemanger. Other commands like unlink() and rmdir() don't bother whether the files are owned by one or another user. Is there someway you can fix this? -- Edit this bug report at http://bugs.php.net/?id=19648&edit=1
#19652 [Opn->Csd]: PHP eat first chars from strings
ID: 19652 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Strings related Operating System: Linux PHP Version: 4.2.3 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. Already fixed, for now recompile with --disable-mbstring Derick Previous Comments: [2002-09-28 13:50:19] [EMAIL PROTECTED] It seems that tis version (4.2.3) has a bug that sometimes remove the first 4 chars from array of strings generated by forms (both get and post using http_post_vars ecc),query and sessions. It remove only the first 4 chars and nothing more. downgrading to 4.2.2 fix the problem on all my scripts. Bye Kirys -- Edit this bug report at http://bugs.php.net/?id=19652&edit=1
#19652 [NEW]: PHP eat first chars from strings
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.3 PHP Bug Type: Strings related Bug description: PHP eat first chars from strings It seems that tis version (4.2.3) has a bug that sometimes remove the first 4 chars from array of strings generated by forms (both get and post using http_post_vars ecc),query and sessions. It remove only the first 4 chars and nothing more. downgrading to 4.2.2 fix the problem on all my scripts. Bye Kirys -- Edit bug report at http://bugs.php.net/?id=19652&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19652&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19652&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19652&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19652&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19652&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19652&r=support Expected behavior: http://bugs.php.net/fix.php?id=19652&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19652&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19652&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19652&r=globals
#19651 [Opn->Bgs]: configure error when use --with-isapi
ID: 19651 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Other web server Operating System: freebsd 4.7 RC PHP Version: 4CVS-2002-09-28 New Comment: looks bogus. .m4 looks fine, cant reproduce. - James Previous Comments: [2002-09-28 12:51:42] [EMAIL PROTECTED] when I use configure --with-isapi (not path follow), it works fine. [2002-09-28 12:26:35] [EMAIL PROTECTED] php version:php4-STABLE-200209280600 zeus version: 4.1r4 when I use configure --with-isapi=/usr/local/zeus it says checking for Zeus ISAPI support... configure: error: Unable to find httpext.h in =/usr/local/zeus/web/include I'm sure there is a file named httpext.h in /usr/local/zeus/web/include -- Edit this bug report at http://bugs.php.net/?id=19651&edit=1
#19292 [Opn->Csd]: random error: open_basedir restriction in effect. File is in wrong directory
ID: 19292 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Apache related Operating System: linux PHP Version: 4.2.3 New Comment: Close. Previous Comments: [2002-09-28 12:44:00] [EMAIL PROTECTED] It seems that it works. THX. [2002-09-28 11:36:13] [EMAIL PROTECTED] Could someone please check if this patch to 4.2.3 fixes this problem? http://cvs.php.net/diff.php/php4/main/fopen_wrappers.c?login=2&r1=1.142.2.3&r2=1.142.2.4&ty=u [2002-09-25 11:22:48] [EMAIL PROTECTED] Keep this critical. [2002-09-25 11:18:39] [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 Could one of you try a non-stable snapshot (don't try it on a production server!)? [2002-09-24 04:14:31] [EMAIL PROTECTED] We have exactly the same problem. 1 request under 20 fail under this error : Warning: open_basedir restriction in effect. File is in wrong directory in Unknown on line 0 Warning: Failed opening '/space_3/www_main/www/board/tickets/voter_a.php' for inclusion (include_path='.:/usr/local/lib/php') in Unknown on line 0 With php 4.2.3 (apache module) + apache 1.3.26 under debian 3.0 with no open_basedir configuration on php.ini and our vhost. duracell 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=19292&edit=1
#19651 [Com]: configure error when use --with-isapi
ID: 19651 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Other web server Operating System: freebsd 4.7 RC PHP Version: 4CVS-2002-09-28 New Comment: when I use configure --with-isapi (not path follow), it works fine. Previous Comments: [2002-09-28 12:26:35] [EMAIL PROTECTED] php version:php4-STABLE-200209280600 zeus version: 4.1r4 when I use configure --with-isapi=/usr/local/zeus it says checking for Zeus ISAPI support... configure: error: Unable to find httpext.h in =/usr/local/zeus/web/include I'm sure there is a file named httpext.h in /usr/local/zeus/web/include -- Edit this bug report at http://bugs.php.net/?id=19651&edit=1
#19292 [Fbk->Opn]: random error: open_basedir restriction in effect. File is in wrong directory
ID: 19292 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Apache related Operating System: linux PHP Version: 4.2.3 New Comment: It seems that it works. THX. Previous Comments: [2002-09-28 11:36:13] [EMAIL PROTECTED] Could someone please check if this patch to 4.2.3 fixes this problem? http://cvs.php.net/diff.php/php4/main/fopen_wrappers.c?login=2&r1=1.142.2.3&r2=1.142.2.4&ty=u [2002-09-25 11:22:48] [EMAIL PROTECTED] Keep this critical. [2002-09-25 11:18:39] [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 Could one of you try a non-stable snapshot (don't try it on a production server!)? [2002-09-24 04:14:31] [EMAIL PROTECTED] We have exactly the same problem. 1 request under 20 fail under this error : Warning: open_basedir restriction in effect. File is in wrong directory in Unknown on line 0 Warning: Failed opening '/space_3/www_main/www/board/tickets/voter_a.php' for inclusion (include_path='.:/usr/local/lib/php') in Unknown on line 0 With php 4.2.3 (apache module) + apache 1.3.26 under debian 3.0 with no open_basedir configuration on php.ini and our vhost. duracell [2002-09-19 11:13:43] [EMAIL PROTECTED] PS: may be a session/temporary directory trouble ? 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=19292&edit=1
#19324 [Fbk]: show PHP source on client's browser
ID: 19324 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Output Control Operating System: Solaris8 x86 PHP Version: 4.2.3 New Comment: Okay, looks like an old bug resurfaced. Can you do the following test, and stick to it very precise: 1. stop apache 2. start apache in single process mode like: /path/to/apache/httpd -X 3. Request a page from a vhost/directory where PHP is enabled 4. Do that again :) 5. Request a page from a vhost/directory where PHP is disabled 6. Request a page from a vhost/directory where PHP is enabled (but not explicit with php_engine = on, just the 'default') 7. Request a page from a vhost/directory where PHP is enabled (implicit wirth php_engine = on) Please tell us when you see the source and when not. regards, Derick Previous Comments: [2002-09-28 09:55:58] [EMAIL PROTECTED] Yes, I do. But I use tag to include it. because I want to make PHP can't work in some directories. Why the showing source arise randomly ? If I can't use "php_engine=off" , how I disable PHP in some directories, please ? [2002-09-28 04:55:42] [EMAIL PROTECTED] You dont have php_engine=off in any of your apache vhosts do you? - James [2002-09-28 04:44:55] [EMAIL PROTECTED] I used php4-20020928 . the running result is the same. [2002-09-27 06:43:22] [EMAIL PROTECTED] Try the latest snapshot not the stable, the 'stable' brach is likely not to have the fix you need. [2002-09-27 01:06:52] [EMAIL PROTECTED] No error as php4-200209241800 when I compiled php4-STABLE-200209261800 . But the running result is the same. :( 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/19324 -- Edit this bug report at http://bugs.php.net/?id=19324&edit=1
#19651 [NEW]: configure error when use --with-isapi
From: [EMAIL PROTECTED] Operating system: freebsd 4.7 RC PHP version: 4CVS-2002-09-28 PHP Bug Type: Other web server Bug description: configure error when use --with-isapi php version:php4-STABLE-200209280600 zeus version: 4.1r4 when I use configure --with-isapi=/usr/local/zeus it says checking for Zeus ISAPI support... configure: error: Unable to find httpext.h in =/usr/local/zeus/web/include I'm sure there is a file named httpext.h in /usr/local/zeus/web/include -- Edit bug report at http://bugs.php.net/?id=19651&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19651&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19651&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19651&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19651&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19651&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19651&r=support Expected behavior: http://bugs.php.net/fix.php?id=19651&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19651&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19651&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19651&r=globals
#19292 [Ctl->Fbk]: random error: open_basedir restriction in effect. File is in wrong directory
ID: 19292 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Feedback Bug Type: Apache related Operating System: linux PHP Version: 4.2.3 New Comment: Could someone please check if this patch to 4.2.3 fixes this problem? http://cvs.php.net/diff.php/php4/main/fopen_wrappers.c?login=2&r1=1.142.2.3&r2=1.142.2.4&ty=u Previous Comments: [2002-09-25 11:22:48] [EMAIL PROTECTED] Keep this critical. [2002-09-25 11:18:39] [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 Could one of you try a non-stable snapshot (don't try it on a production server!)? [2002-09-24 04:14:31] [EMAIL PROTECTED] We have exactly the same problem. 1 request under 20 fail under this error : Warning: open_basedir restriction in effect. File is in wrong directory in Unknown on line 0 Warning: Failed opening '/space_3/www_main/www/board/tickets/voter_a.php' for inclusion (include_path='.:/usr/local/lib/php') in Unknown on line 0 With php 4.2.3 (apache module) + apache 1.3.26 under debian 3.0 with no open_basedir configuration on php.ini and our vhost. duracell [2002-09-19 11:13:43] [EMAIL PROTECTED] PS: may be a session/temporary directory trouble ? [2002-09-19 11:08:48] [EMAIL PROTECTED] Hi, I have this problem too, and started when I updated from 4.2.2 (patched) to 4.2.3 : Redhat 7.3 Linux 2.4.18-3 Apache/1.3.26 PHP 4.2.3 Name Based Virtual Host './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-openssl=/usr/local/ssl' '-- enable-magic-quotes' '--with-zlib' '--with-zlib-dir=/usr/local/src/zlib' '--enable-bcmath' '-- with-curl=/usr/local/src/curl-7.9.8' '--with-fdftk=/usr/local/src/libFDF' '--enable-ftp' '-- with-gd=/usr/local/src/gd-1.8.4' '--with-mcrypt' '--enable-gd-native-ttf' '--with-jpeg-dir=/ usr/local/src/jpeg-6b' '--with-png-dir=/usr/local/src/libpng' '--with-imap=/usr/local/src/ imap-2001a' '--with-gettext' '--with-imap-ssl=/usr/local/src/openssl-0.9.6g' '--with- mysql=/usr/local/mysql' '--with-pdflib' '--with-pdflib-dir=/usr/local/src/pdflib-4.0.2/pdflib' '--with-jpeg-dir=/usr/local/src/jpeg-6b' '--with-png-dir=/usr/local/src/libpng' '--enable- sockets' '--with-regex=php' '--with-swf=/usr/local/lib/libSWF' '--enable-sysvsem' '-- enable-sysvshm' '--enable-tokenizer' '--enable-inline-optimization' 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=19292&edit=1
#19650 [NEW]: 4.2.3 (!) "include" operator mistake
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4.2.3 PHP Bug Type: Unknown/Other Function Bug description: 4.2.3 (!) "include" operator mistake I'm trying to write here again (maybe previous thread is down?). You said before this bug in NOT actual in 4.2.3, but code STILL DOES NOT work in 4.2.3. So, PHP v4.2.0 (and later) on Windows: include "/home/some/site.php"; - DOES NOT work (try to believe)! We have to use instead: include "z:/home/some/site.php"; # bad... Bad?.. BAD!!! Previous PHP v4.1.0: include "/home/some/site.php"; - works correct. I think that since 4.2.0 pathes like "/some/where" does not treated as absolute. For example, if we add "z:" to "include_path", include "/home/some/site.php" become workable - it is only the prove. It is VERY loathsome bug, because it makes Windows scripts incompatible with Unix and with previous PHP versions. Again, new version (4.2.3) has THE SAME bug: Z:\!distrib\php-4.2.3-Win32>php.exe ^Z Warning: Failed opening '/test.php' for inclusion (include_path='.;c:\php4\pear') in - on line 2 If I use "include 'z:/test.php'", it works. Please help (our clients are very angry!) P.S. DocumentRoot "/home/site/www" ... GET http://site/test.php - DOES NOT work too. It seems to me mod_php uses the same "include" function while starting the script. -- Edit bug report at http://bugs.php.net/?id=19650&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19650&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19650&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19650&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19650&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19650&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19650&r=support Expected behavior: http://bugs.php.net/fix.php?id=19650&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19650&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19650&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19650&r=globals
#19649 [NEW]: Nested [] in browscap.ini cause PHP to crash
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.2 PHP Bug Type: Reproducible crash Bug description: Nested [] in browscap.ini cause PHP to crash An entry in browscap.ini similar to the following: [Mozilla/4.76 (Macintosh;US;PPC) Opera 4.? [en]] .. will cause Apache/PHP to fail to start (segmentation fault) due to the nested [] symbols. The following complete browscap.ini would be enough to reproduce this: [Opera 4.0] [Mozilla/4.76 (Macintosh;US;PPC) Opera 4.? [en]] parent=Opera 4.0 platform=MacPPC Interestingly, without a correctly formed entry on the first line PHP reports a warning instead. -- Edit bug report at http://bugs.php.net/?id=19649&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19649&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19649&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19649&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19649&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19649&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19649&r=support Expected behavior: http://bugs.php.net/fix.php?id=19649&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19649&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19649&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19649&r=globals
#19324 [Com]: show PHP source on client's browser
ID: 19324 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Output Control Operating System: Solaris8 x86 PHP Version: 4.2.3 New Comment: Yes, I do. But I use tag to include it. because I want to make PHP can't work in some directories. Why the showing source arise randomly ? If I can't use "php_engine=off" , how I disable PHP in some directories, please ? Previous Comments: [2002-09-28 04:55:42] [EMAIL PROTECTED] You dont have php_engine=off in any of your apache vhosts do you? - James [2002-09-28 04:44:55] [EMAIL PROTECTED] I used php4-20020928 . the running result is the same. [2002-09-27 06:43:22] [EMAIL PROTECTED] Try the latest snapshot not the stable, the 'stable' brach is likely not to have the fix you need. [2002-09-27 01:06:52] [EMAIL PROTECTED] No error as php4-200209241800 when I compiled php4-STABLE-200209261800 . But the running result is the same. :( [2002-09-27 00:40:36] [EMAIL PROTECTED] Solaris' sed doesn't handle the long lines, you will have more luck with gnu sed. Can you install that and try again? Derick The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19324 -- Edit this bug report at http://bugs.php.net/?id=19324&edit=1
#19648 [Bgs]: fopen() and current user
ID: 19648 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Feature/Change Request Operating System: GNU/Linux or any Unix variant PHP Version: 4.2.2 New Comment: I know its not a bug, thats why I put it under: Feature/Change Request :) Well, if you can't answer the question, can you tell me where I can get an answer then? :) Previous Comments: [2002-09-28 09:04:19] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2002-09-28 08:56:56] [EMAIL PROTECTED] fopen() uses the user running PHP to open the selected file. This causes problems when you e.g. make a filemanager. All files created with the filemanger will be owned by the www user and chmod'ed to 644. On the other side, the filemanger cannot alter files as they are (mostly) owned by the user (e.g. raz0). This makes it quite hard to make useful filemanger. Other commands like unlink() and rmdir() don't bother whether the files are owned by one or another user. Is there someway you can fix this? -- Edit this bug report at http://bugs.php.net/?id=19648&edit=1
#19648 [Opn->Bgs]: fopen() and current user
ID: 19648 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: GNU/Linux or any Unix variant PHP Version: 4.2.2 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2002-09-28 08:56:56] [EMAIL PROTECTED] fopen() uses the user running PHP to open the selected file. This causes problems when you e.g. make a filemanager. All files created with the filemanger will be owned by the www user and chmod'ed to 644. On the other side, the filemanger cannot alter files as they are (mostly) owned by the user (e.g. raz0). This makes it quite hard to make useful filemanger. Other commands like unlink() and rmdir() don't bother whether the files are owned by one or another user. Is there someway you can fix this? -- Edit this bug report at http://bugs.php.net/?id=19648&edit=1
#19648 [NEW]: fopen() and current user
From: [EMAIL PROTECTED] Operating system: GNU/Linux or any Unix variant PHP version: 4.2.2 PHP Bug Type: Feature/Change Request Bug description: fopen() and current user fopen() uses the user running PHP to open the selected file. This causes problems when you e.g. make a filemanager. All files created with the filemanger will be owned by the www user and chmod'ed to 644. On the other side, the filemanger cannot alter files as they are (mostly) owned by the user (e.g. raz0). This makes it quite hard to make useful filemanger. Other commands like unlink() and rmdir() don't bother whether the files are owned by one or another user. Is there someway you can fix this? -- Edit bug report at http://bugs.php.net/?id=19648&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19648&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19648&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19648&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19648&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19648&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19648&r=support Expected behavior: http://bugs.php.net/fix.php?id=19648&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19648&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19648&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19648&r=globals
#19647 [NEW]: PHPRC does not work in WindowsXP
From: [EMAIL PROTECTED] Operating system: Windows XP PHP version: 4.2.3 PHP Bug Type: *Configuration Issues Bug description: PHPRC does not work in WindowsXP When I set enviroment variable PHPRC=d:\php and put php.ini into this directory the php.exe acted as there is no php.ini file (I guess php.exe does not look into PHPRC). I tryed to set PHPRC=d:\php\ and PHPRC=d:\php\php.ini. It only works when php.ini is in %systemroot%. SET command Command promt lists this: PHPRC=d:\php so I know (I think) I set it right. Is there any solution? -- Edit bug report at http://bugs.php.net/?id=19647&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19647&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19647&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19647&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19647&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19647&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19647&r=support Expected behavior: http://bugs.php.net/fix.php?id=19647&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19647&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19647&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19647&r=globals
#19324 [Fbk]: show PHP source on client's browser
ID: 19324 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Output Control Operating System: Solaris8 x86 PHP Version: 4.2.3 New Comment: You dont have php_engine=off in any of your apache vhosts do you? - James Previous Comments: [2002-09-28 04:44:55] [EMAIL PROTECTED] I used php4-20020928 . the running result is the same. [2002-09-27 06:43:22] [EMAIL PROTECTED] Try the latest snapshot not the stable, the 'stable' brach is likely not to have the fix you need. [2002-09-27 01:06:52] [EMAIL PROTECTED] No error as php4-200209241800 when I compiled php4-STABLE-200209261800 . But the running result is the same. :( [2002-09-27 00:40:36] [EMAIL PROTECTED] Solaris' sed doesn't handle the long lines, you will have more luck with gnu sed. Can you install that and try again? Derick [2002-09-26 21:23:13] [EMAIL PROTECTED] I downloaded php4-STABLE-200209261800 and used pure compiling . showing source still arisen . :( 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/19324 -- Edit this bug report at http://bugs.php.net/?id=19324&edit=1
#19301 [Asn->Fbk]: curl_exec crashes
ID: 19301 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Feedback Bug Type: cURL related Operating System: Windows XP Professional CZ PHP Version: 4.2.3 Assigned To: jmoore New Comment: OK just built Debug and Release versions of Curl (Curl-7.9.8) (NON-SSL) and the same of the PHP Extension from the latest CVS and cannot reproduce this bug in the latest versions. The crash no longer happens. Although it is reproduceable with PHP-4.2.3 which was downloadable from PHP.net. You can download the version I tested this with (Only got php_curl.dll & libcurl.dll accompanying it) from http://www.phpuk.org/~james/latest-cvs-with-curl.zip. Please let me know if the problem persists with you in this build. - James Previous Comments: [2002-09-25 04:19:11] [EMAIL PROTECTED] Ill have a look at this on friday and see if I can reproduce this and get a stack trace then hopefully fix it. If anyone wants a play before hand then they are welcome to. - James [2002-09-25 04:12:59] [EMAIL PROTECTED] Have just tried that on Win2K. The problem still exists, both when running php as standalone and sapi module under Apache 1.3.26 [2002-09-24 09:23:38] [EMAIL PROTECTED] Could you try to reproduce this with a non-stable snapshot? http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-24 08:41:05] [EMAIL PROTECTED] Could this be related to how Windows DLLs vs apps works? In Windows, you can't open a file and pass the handle of that file to have it read from or written to in a DLL. They somehow don't allow that kind of data to be shared like that. It seems as if it could be, the PHP code opens the file and passes the handle to the DLL that deals with it... Just my thoughts. I might be completely wrong. [2002-09-23 04:52:47] [EMAIL PROTECTED] It seems the bug doesn't affect only WinNT/2K/XP systems but it's also reproductible on Win98SE. 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/19301 -- Edit this bug report at http://bugs.php.net/?id=19301&edit=1
#19324 [Com]: show PHP source on client's browser
ID: 19324 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Output Control Operating System: Solaris8 x86 PHP Version: 4.2.3 New Comment: I used php4-20020928 . the running result is the same. Previous Comments: [2002-09-27 06:43:22] [EMAIL PROTECTED] Try the latest snapshot not the stable, the 'stable' brach is likely not to have the fix you need. [2002-09-27 01:06:52] [EMAIL PROTECTED] No error as php4-200209241800 when I compiled php4-STABLE-200209261800 . But the running result is the same. :( [2002-09-27 00:40:36] [EMAIL PROTECTED] Solaris' sed doesn't handle the long lines, you will have more luck with gnu sed. Can you install that and try again? Derick [2002-09-26 21:23:13] [EMAIL PROTECTED] I downloaded php4-STABLE-200209261800 and used pure compiling . showing source still arisen . :( [2002-09-26 20:36:12] [EMAIL PROTECTED] compiling fault. I use php4-200209241800 . /bin/sh libtool --silent --mode=link gcc -export-dynamic -avoid-version -module -L/usr/ucblib -L/usr/local/lib/gcc-lib/i386-pc-solaris2.8/3.2 -R /usr/ucblib -R /usr/local/lib/gcc-lib/i386-pc-solaris2.8/3.2 ext/ctype/ctype.lo ext/mbstring/mbfilter_ja.lo ext/mbstring/mbfilter_cn.lo ext/mbstring/mbfilter_tw.lo ext/mbstring/mbfilter_kr.lo ext/mbstring/mbfilter_ru.lo ext/mbstring/mbfilter.lo ext/mbstring/mbstring.lo ext/mbstring/mbregex.lo ext/mbstring/php_mbregex.lo ext/mbstring/html_entities.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo ext/mysql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo ext/mysql/libmysql/default.lo ext/mysql/libmysql/my_compress.lo ext/mysql/libmysql/array.lo ext/mysql/libmysql/my_once.lo ext/mysql/libmysql/list.lo ext/mysql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo ext/mysql/libmysql/strxmov.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.lo ext/mysql/libmysql/strend.lo ext/mysql/libmysql/strfill.lo ext/mysql/libmysql/is_prefix.lo ext/mysql/libmysql/int2str.lo ext/mysql/libmysql/str2int.lo ext/mysql/libmysql/strinstr.lo ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/strcend.lo ext/mysql/libmysql/bchange.lo ext/mysql/libmysql/bmove.lo ext/mysql/libmysql/bmove_upp.lo ext/mysql/libmysql/longlong2str.lo ext/mysql/libmysql/strtoull.lo ext/mysql/libmysql/strtoll.lo ext/mysql/libmysql/charset.lo ext/mysql/libmysql/ctype.lo ext/overload/overload.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.l
#19639 [Opn->Fbk]: PHP crashes apache on restart of the webserver
ID: 19639 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Slackware 8.1 - Linux 2.4.19 PHP Version: 4.2.3 New Comment: Try CVS versions both PHP and Apache2. Does it help? Previous Comments: [2002-09-27 15:19:09] [EMAIL PROTECTED] In apache 2.0.40/42 I got the following messages when attempting to *restart* the server. -- [Fri Sep 27 16:54:34 2002] [notice] SIGHUP received. Attempting to restart [Fri Sep 27 16:54:34 2002] [notice] Digest: generating secret for digest authentication ... [Fri Sep 27 16:54:34 2002] [notice] Digest: done [Fri Sep 27 16:54:35 2002] [notice] seg fault or similar nasty error detected in the parent process --- I tried PHP versions 4.2.3 and CVS 25/Sep 26/Sep, all combinations giving the same problem. If I do a ./apachectl start, the server comes up ok and a phpinfo() show everything normally. The problem only occurs on a restart of the server. The backtrace --- Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-slackware-linux"... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X [New Thread 1024 (LWP 469)] Program received signal SIGHUP, Hangup. [Switching to Thread 1024 (LWP 469)] _dl_debug_state () at dl-debug.c:57 57 dl-debug.c: No such file or directory. in dl-debug.c (gdb) (gdb) bt #0 _dl_debug_state () at dl-debug.c:57 #1 0x400caec6 in dlclose_doit (handle=0x812cfb0) at dlclose.c:25 #2 0x4000a1b0 in _dl_catch_error (objname=0x8129408, errstring=0x812940c, operate=0x400caeac , args=0x812cfb0) at dl-error.c:152 #3 0x400cb2a0 in _dlerror_run (operate=0x400caeac , args=0x812cfb0) at dlerror.c:130 #4 0x400caef0 in dlclose (handle=0x812cfb0) at dlclose.c:31 #5 0x4005d7ef in dso_cleanup (thedso=0x812b068) at dso.c:110 #6 0x4005c87b in run_cleanups (c=0x8184398) at apr_pools.c:1961 #7 0x4005bacf in apr_pool_clear (pool=0x80f9358) at apr_pools.c:709 #8 0x0807290e in main (argc=2, argv=0xb924) at main.c:600 #9 0x400fb17d in __libc_start_main (main=0x8072340 , argc=2, ubp_av=0xb924, init=0x8065464 <_init>, fini=0x80d74b0 <_fini>, rtld_fini=0x4000a534 <_dl_fini>, stack_end=0xb91c) at ../sysdeps/generic/libc-start.c:129 --- My configure lines... ./configure --prefix=/usr/local/php --with-apxs2=/usr/local/apache/bin/apxs --enable-libgcc --enable-ftp --enable-sockets and ./configure --prefix=/usr/local/php --with-apxs2=/usr/local/apache/bin/apxs --with-zlib=shared --with-zlib-dir=shared,/usr/lib --with-bz2=shared,/usr/lib --with-dom=shared,/usr/lib --with-expat-dir=shared,/usr/local/expat --with-dom-xslt=shared,/usr/lib --with-expat-dir=shared,/usr/local/expat --with-dom-exslt=shared,/usr/lib --with-expat-dir=shared,/usr/local/expat --with-gettext=shared,/usr/local/gettext --with-pgsql=shared,/usr/local/postgresql --with-m --with-openssl=shared,/usr/local/openssl --with-gd=shared,/usr/local/gd --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-pear=/usr/local/php/lib/pear --enable-libgcc --enable-dio --enable-ftp --enable-sockets Any comments? William -- Edit this bug report at http://bugs.php.net/?id=19639&edit=1
#19637 [Opn->Bgs]: .php file truncated
ID: 19637 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: windows xp PHP Version: 4.2.3 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Apache2filter support is EXPERIMENTAL. Use CVS version of PHP and Apache2 for test driving Apache2filter. If you still have the problem, try to get backtrace. (Do we have HOWTO for getting backtrace from Windows?) Previous Comments: [2002-09-27 12:41:17] [EMAIL PROTECTED] I was trying to test a portion of my webpage in mozilla. I asked a coworker to try it out, and he got the page. I then loaded the page and it was fine. I then went to edit the .php file and it was truncated to nothing, as in the file still existed, but was blank. I dont know if this was due to apache or to php. I am running the latest versions of both. ( not cvs ) -- Edit this bug report at http://bugs.php.net/?id=19637&edit=1
#19646 [Opn->Ctl]: session variables only work if register globals is turned off
ID: 19646 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: Session related Operating System: linux PHP Version: 4CVS-2002-09-28 Previous Comments: [2002-09-28 02:59:57] [EMAIL PROTECTED] I think the last update to sessions broke. eg. register_globals = On Sessions dont work register_globals = Off Sessions work Ok. While its not a bad idea :) - I dont think that was intended.. :) -- Edit this bug report at http://bugs.php.net/?id=19646&edit=1
#19392 [Fbk->Ana]: $_SESSION = ""; PHP crashes
ID: 19392 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Analyzed Bug Type: Session related Operating System: Linux, win32 PHP Version: 4.2.3 New Comment: I should commit fix, but don't have much time now. The cause would be php_session_save_current_state() is trying to save current state blindly. We need to check if the PS(http_session_vars) is array. If not, just return. I don't see the fix in current CVS or is this delt in other place? Previous Comments: [2002-09-26 18:37:18] [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 Cannot replicate the crash on Win32 or Linux using the latest CVS. [2002-09-13 10:39:29] [EMAIL PROTECTED] I can verify this on linux and latest CVS HEAD (I now, $_SESSION is expected to be an array, but it shouldn't segfault nevertheless) here's a backtrace #0 zend_hash_get_current_key_ex (ht=0x4036e92a, str_index=0xb188, str_length=0xb18c, num_index=0xb190, duplicate=0, pos=0xb198) at /opt/cvs/php4.3/Zend/zend_hash.c:1054 #1 0x4026850a in php_session_save_current_state () at /opt/cvs/php4.3/ext/session/session.c:566 #2 0x4026aad1 in php_session_flush () at /opt/cvs/php4.3/ext/session/session.c:1435 #3 0x4026ab10 in zm_deactivate_session (type=1, module_number=35) at /opt/cvs/php4.3/ext/session/session.c:1449 #4 0x403107e6 in module_registry_cleanup (module=0x81368b8) at /opt/cvs/php4.3/Zend/zend_API.c:1170 #5 0x403124a2 in zend_hash_apply (ht=0x40399ac0, apply_func=0x403107ac ) at /opt/cvs/php4.3/Zend/zend_hash.c:688 #6 0x4030da7c in zend_deactivate_modules () at /opt/cvs/php4.3/Zend/zend.c:585 #7 0x402e6b5d in php_request_shutdown (dummy=0x0) at /opt/cvs/php4.3/main/main.c:898 #8 0x40326623 in apache_php_module_main (r=0x818d624, display_source_mode=0) at /opt/cvs/php4.3/sapi/apache/sapi_apache.c:61 #9 0x40327110 in send_php (r=0x818d624, display_source_mode=0, filename=0x0) at /opt/cvs/php4.3/sapi/apache/mod_php4.c:563 #10 0x40327172 in send_parsed_php (r=0x818d624) at /opt/cvs/php4.3/sapi/apache/mod_php4.c:578 #11 0x08073d89 in ap_invoke_handler () #12 0x080894df in process_request_internal () #13 0x08089546 in ap_process_request () #14 0x0807ffd6 in child_main () #15 0x08080191 in make_child () #16 0x0808030c in startup_children () #17 0x0808099d in standalone_main () #18 0x0808120c in main () #19 0x400b80bf in __libc_start_main () from /lib/libc.so.6 chregu [2002-09-13 10:27:15] [EMAIL PROTECTED] Seems that PHP crashes when using $_SESSION = ""; or $_SESSION = null; at Linux and win32. $_SESSION = array(); works fine. -- Edit this bug report at http://bugs.php.net/?id=19392&edit=1
#15982 [Com]: PHP Freeze with swffont() call
ID: 15982
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Ming related
Operating System: Win XP Prof
PHP Version: 4.2.1
New Comment:
you'll find some .fdb fonts at:
http://www.neuralust.com/~mingdocs/fonts/getfonts.htm
Previous Comments:
[2002-09-25 05:37:13] [EMAIL PROTECTED]
I didnt recieve any font file, setting to feedback
[2002-09-25 04:14:39] [EMAIL PROTECTED]
The problem is definitely not gone. Opened this bug...
[2002-09-25 04:01:25] [EMAIL PROTECTED]
Hello,
I think this is not fair, the bug is 100 % reproduced at every
tentative, you cannot say "you are no longer experiencing the
problem".
What should I do to make this bug is taken in account ?
Henri
[2002-09-23 08:02:12] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2002-08-30 07:59:02] [EMAIL PROTECTED]
Hi all, same problem for me:
Iexplorer systematically crashes using a file:
SWFFont("verdana.fdb");
Iexplorer crashes sometimes using an internal font:
SWFFont("-sans");
Could you please help.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/15982
--
Edit this bug report at http://bugs.php.net/?id=15982&edit=1
#19646 [NEW]: session variables only work if register globals is turned off
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4CVS-2002-09-28 PHP Bug Type: Session related Bug description: session variables only work if register globals is turned off I think the last update to sessions broke. eg. register_globals = On Sessions dont work register_globals = Off Sessions work Ok. While its not a bad idea :) - I dont think that was intended.. :) -- Edit bug report at http://bugs.php.net/?id=19646&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19646&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19646&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19646&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19646&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19646&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19646&r=support Expected behavior: http://bugs.php.net/fix.php?id=19646&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19646&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19646&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19646&r=globals
