#19525 [Ver]: Yet Another Output Buffering Issue (YAOBI)
ID: 19525 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Output Control -Operating System: All modules in ZTS mode +Operating System: Windows -PHP Version: 4CVS-2002-09-21 +PHP Version: 4CVS-2002-09-20 Assigned To: james New Comment: This is a ZTS issue (Derick tested under linux with ZTS enabled and it failed). Previous Comments: [2002-09-21 12:15:28] [EMAIL PROTECTED] Just tested on Linux with a CLI build with --enable-experimental-zts and this doesn't show any error either. Derick [2002-09-20 15:23:30] [EMAIL PROTECTED] Verified under Windows, Linux works fine [2002-09-20 10:40:12] [EMAIL PROTECTED] I tested this with both CGI and CLI SAPI modules. My php.ini is below. allow_call_time_pass_reference = Off error_reporting = E_ALL & ~E_NOTICE display_errors = On display_startup_errors = On report_memleaks = On register_globals = Off register_argc_argv = On include_path = ".;c:\server\pear;c:\server\htdocs" extension_dir = c:\home\php\php4\release_ts ;extension=php_adt.dll ;extension=php_gd.dll session.save_path = c:\server\apache\sessions\ url_rewriter.tags = "a=href, area=href, frame=src, input=src, form=fakeentry" docref_ext = ".html" docref_root = "file:///C:/Dokumente und Einstellungen/Administrator/Eigene Dateien/PHP Manual/" [2002-09-20 09:51:54] [EMAIL PROTECTED] Both Andrei and myself were not be able to reproduce this. We both got the error message with CVS HEAD> Perhaps it is related to settings in php.ini, or related to the SAPI? Can you point us to the php.ini and tell which SAPI you used? Derick [2002-09-20 09:12:23] [EMAIL PROTECTED] Here is a reproducing script. It does not make sense, because it is ripped out of its XML_Transformer context: echo 'test'; PHP 4.2.3 Fatal error: Cannot use output buffering in output buffering display handlers HEAD Neither output nor error message. -- Edit this bug report at http://bugs.php.net/?id=19525&edit=1
#14136 [Ctl->Fbk]: Segfaults when forget xslt_free()
ID: 14136
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Critical
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Debian/Linux
PHP Version: 4.0CVS-2001-11-2
Assigned To: sterling
New Comment:
I cant reproduce this on windows nor can rei (Ilia) on slackware. This
bug is not really critical as it has a workaround of using xslt_free.
Can you please provide us with a SHORT test script (Including the XSLT
and XML required) which reproduces this behaviour so we can localize
and fix this bug if it does exist.
Status => User feedback.
Many thanks,
- James
--
James Moore
[EMAIL PROTECTED]
Previous Comments:
[2002-03-26 03:31:24] [EMAIL PROTECTED]
Sterling, can you please check this?
Derick
[2002-02-27 07:40:26] [EMAIL PROTECTED]
Assinging this to you sterling, have fun with it!
[2001-11-20 15:21:51] [EMAIL PROTECTED]
Doesn't look like a Zend problem to me. Apparently the table ends up
containing the wrong entries (i.e., the same entry more than once) or,
if the analysis is accurate, then the dependencies aren't properly
implemented, and a resource (the parser) is freed prematurely.
[2001-11-20 07:34:40] [EMAIL PROTECTED]
Seems a Zend problem...
[2001-11-20 03:59:03] [EMAIL PROTECTED]
Tested this with php compiled as cgi.
Everything works ok when after doing transformation
you use xslt_free() in your script.
When you forget to do so php may segfault.
This happens when there were a scheme/sax handler defined
with object reference:
xslt_set_sax_handlers($xslt, array("characters" =>
array(&$this, "func")));
Now when php shuts down it calls free_processor() which
after some recursive *_ptr_dtor() and alike calls reaches
again free_processor() with same zval handle. Since
sablotron processor is already destroyed it eventually
comes to segfault.
This doesn't happen when ordinary function is used as
callback handler.
Backtrace:
#0 0x in ?? ()
#1 0x400d8432 in Situation::generateMessage
(this=0x81c4bb8, type=MT_WARN, code=W1_HLR_NOT_REGISTERED,
arg1=@0xbfffee08,
arg2=@0xbfffedfc, theMessage=@0xbfffed70) at
situa.cpp:267
#2 0x400d8ae2 in Situation::message (this=0x81c4bb8,
type=MT_WARN, code=W1_HLR_NOT_REGISTERED,
arg1=@0xbfffee08, arg2=@0xbfffedfc)
at situa.cpp:348
#3 0x400cfb63 in Processor::report (this=0x81c4c58,
S=@0x81c4bb8, type=MT_WARN, code=W1_HLR_NOT_REGISTERED,
arg1=@0xbfffee08,
arg2=@0xbfffedfc) at proc.cpp:991
#4 0x400ce583 in Processor::setHandler (this=0x81c4c58,
S=@0x81c4bb8, type=HLR_MESSAGE, handler=0x0, userData=0x0)
at proc.cpp:741
#5 0x400d1a8c in SablotUnregHandler
(processor_=0x81c4c58, type=HLR_MESSAGE, handler=0x0,
userData=0x0) at sablot.cpp:728
#6 0x0811adc1 in free_processor (rsrc=0x81c0a8c) at
sablot.c:613
#7 0x080c3a2a in list_entry_destructor (ptr=0x81c0a8c) at
zend_list.c:177
#8 0x080c128e in zend_hash_del_key_or_index
(ht=0x818dc44, arKey=0x0, nKeyLength=0, h=1, flag=1) at
zend_hash.c:512
#9 0x080c378b in _zend_list_delete (id=1) at
zend_list.c:56
#10 0x080d9581 in _zval_dtor (zvalue=0x81c4574,
__zend_filename=0x813d01c "zend_execute_API.c",
__zend_lineno=274)
at zend_variables.c:64
#11 0x080c66ab in _zval_ptr_dtor (zval_ptr=0x81c0ad8,
__zend_filename=0x8149313 "zend_variables.c",
__zend_lineno=189)
at zend_execute_API.c:274
#12 0x080d98b4 in _zval_ptr_dtor_wrapper
(zval_ptr=0x81c0ad8) at zend_variables.c:189
#13 0x080c13ba in zend_hash_destroy (ht=0x81c101c) at
zend_hash.c:541
#14 0x080d9551 in _zval_dtor (zvalue=0x81c4a34,
__zend_filename=0x813d01c "zend_execute_API.c",
__zend_lineno=274)
at zend_variables.c:57
#15 0x080c66ab in _zval_ptr_dtor (zval_ptr=0x81c0b90,
__zend_filename=0x8149313 "zend_variables.c",
__zend_lineno=189)
at zend_execute_API.c:274
#16 0x080d98b4 in _zval_ptr_dtor_wrapper
(zval_ptr=0x81c0b90) at zend_variables.c:189
#17 0x080c13ba in zend_hash_destroy (ht=0x81c0b24) at
zend_hash.c:541
#18 0x080d9521 in _zval_dtor (zvalue=0x81c0c5c,
__zend_filename=0x813d01c "zend_execute_API.c",
__zend_lineno=274)
at zend_variables.c:51
#19 0x080c66ab in _zval_ptr_dtor (zval_ptr=0x81c4b9c,
__zend_filename=0x81672fb "sablot.c", __zend_lineno=633)
at zend_execute_API.c:274
#20 0x0811b00e in free_processor (rsrc=0x81c0a8c) at
sablot.c:633
#21 0x080c3a2a in list_entry_destructor (ptr=0x81c0a8c) at
zend_list.c:177
#22 0x080c3c15 in zend_destroy_rsrc_list (ht=0x818dc44) at
zend_list.c:248
#
#19207 [Opn->Fbk]: php-cgi.exe does not correctly set HTTP status
ID: 19207
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: IIS related
Operating System: Windows 2000/.Net Server RC1
PHP Version: 4CVS-2002-08-30
New Comment:
what version of IIS are you using.. this works fine on Win XP Pro (No
service pack) so IIS 5.0.
- James
--
James Moore
[EMAIL PROTECTED]
Previous Comments:
[2002-09-05 11:22:02] [EMAIL PROTECTED]
Just tried the latest snapshot php4-win32-200209051400.zip and the
issue still exists. php-cgi.exe returns the following headers:
Status: 401
Content-type: text/html
WWW-authenticate: basic realm=Logon
The correct headers for php-cgi.exe to work in IIS should be:
HTTP/1.1 401 Unauthorized
Content-type: text/html
WWW-authenticate: basic realm=Logon
[2002-09-04 21:30:20] [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
I believe there was just a patch submitted that fixes this. I could be
wrong though too, please test and update if still valid. :\
[2002-08-30 20:09:13] [EMAIL PROTECTED]
The following code fragment works great with PHP 4.2.2 on IIS:
Header("WWW-authenticate: basic realm=Logon");
Header("HTTP/1.1 401 Unauthorized");
echo "\n";
echo " \n";
echo " Authorization Required\n";
echo " \n";
echo " \n";
echo " Invalid username and password with which to access this
webpage.\n";
echo " \n";
echo "\n";
exit;
This code works correctly in 4.2.2. It sets the status of the page to
401 and makes the browser prompt for the password.
However using php-cgi.exe in the latest 4.3.0 development builds in IIS
the code does not work. The browser receive a "HTTP/1.1 200 OK"
instead of "HTTP/1.1 401 Unauthorized". If I simply run the CGI script
from the command prompt using php-cgi.exe in 4.3.0 I get the
following:
Status: 401
Content-type: text/html
WWW-authenticate: basic realm=Logon
Authorization Required
Invalid username and password with which to access this
webpage.
Running php.exe 4.2.2 from the console I get the following:
HTTP/1.1 401 Unauthorized
Content-type: text/html
WWW-authenticate: basic realm=Logon
Authorization Required
Invalid username and password with which to access this
webpage.
Noticed that php 4.2.2 correctly returns the HTTP page status as
"HTTP/1.1 401 Unauthorized" and php 4.3.0 only returns the tag "Status:
401".
The new tag "Status: 401" does not work in IIS, it needs to be the full
"HTTP/1.1 401 Unauthorized".
--
Edit this bug report at http://bugs.php.net/?id=19207&edit=1
#14971 [Opn->Ctl]: unhandled exception processing the ISAPI
ID: 14971 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: IIS related Operating System: WIN2000 server (SP2) PHP Version: 4.1.1 New Comment: As normal with these kinda bugs my ISAPI/IIS is rock solid so its very difficult to track this down. Im moving this bug to critical as it affects quite a few people. If any of you can compile on your webservers I would be interested to see if you compile what happens. Also make sure you always use the latest version of PHP as we are always fixing Thread Safety issues (To the best of my knowledge this is probably what is causing this). Hopefully we can gradually improve performance of the ISAPI extension. If you have any other information or a short script that seems to cause it a lot then please add information about it in this bug report. Also please try unloading extensions from PHP and testing without that as it might be a thread safety issue in that extension. Basically until we can get some more concerete information about this lack of stability its very difficult to track down so anything that may help is very welcome. - James Previous Comments: [2002-03-07 04:44:56] [EMAIL PROTECTED] We already had the php4isapi.dll als ISAPI-Filter included, but nevertheless it does not work at all. The crashes are gone for sure, but the new flavour ist that sporadically the connection to an Oracle Database get's lost somehow, somewhere, and all my scripts do not work anymore. The problem occures more often after the server has had a heavy load. Point is: PHP does not crash anymore, but in order to have a working DB connection I have to restart the iisadmin-service. regards, Bernd [2002-02-06 09:31:55] [EMAIL PROTECTED] I was experiencing this type of crashing over and over myself with win2k SP2. The solution was to add the ISAPI DLL in the ISAPI Filters list as well as the App Mappings. After this ISAPI has been rock solid. This is the same solution as in this bug report: http://bugs.php.net/bug.php?id=15324 . Note: I did not do this at first because the PHP Manual specifically said that I should not do so (http://www.php.net/manual/en/install.iis.php) unless I needed it for HTTP Authentication. Maybe someone should place some errata in the documentation? [2002-01-31 07:41:23] [EMAIL PROTECTED] Hi there, we've got the same problem too. Even on older Versions of PHP it appeares from time to time. 4.1.1 creates the same SysLog-Message on W2k Sp2, but we only use ODBC. Only NET STOP IISADMIN solves the problem, but from time to time you need to reboot the machine. Using the Zend Optimizer or not is not the problem, it is re-creatable without Zend... One thing to mention is, that it only appears on querys that are quite time consuming. regards, Bernd [2002-01-22 10:51:01] [EMAIL PROTECTED] I have the same problem. However, I even unloaded all extensions and the Optimizer thinking that they had to do with it but it still crashes. [2002-01-14 07:12:28] [EMAIL PROTECTED] I have this problem too...But, 6 virtual servers work for me, and, the most surprising, given message appears only on four of six 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/14971 -- Edit this bug report at http://bugs.php.net/?id=14971&edit=1
#14971 [Fbk->Ctl]: unhandled exception processing the ISAPI
ID: 14971 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Critical Bug Type: IIS related Operating System: WIN2000 server (SP2) -PHP Version: 4.1.1 +PHP Version: Latest CVS New Comment: Jani.. Im using latest CVS. Anyway. A bit more of a probe and I have come up with the following stack trace (Caused when IIS is under heavy load using the script and doing lots and lots of requests NTDLL! 77f7d293() _emalloc(unsigned int 256, char * 0x013b7a80 `string', unsigned int 27, char * 0x, unsigned int 0) line 154 + 62 bytes zend_stack_init(_zend_stack * 0x018f2ce0) line 27 + 30 bytes zend_init_compiler_data_structures(void * * * 0x018f1fe0) line 73 + 21 bytes init_compiler(void * * * 0x018f1fe0) line 100 + 9 bytes zend_activate(void * * * 0x018f1fe0) line 588 + 9 bytes php_request_startup(void * * * 0x018f1fe0) line 835 + 9 bytes HttpExtensionProc(_EXTENSION_CONTROL_BLOCK * 0x00814888) line 756 + 12 bytes WAM! 5a857a91() WAM! 5a858634() W3SVC! 5aa51473() W3SVC! 5aa51385() W3SVC! 5aa40a38() W3SVC! 5aa40bc2() W3SVC! 5aa4ad47() W3SVC! 5aa3a6c9() W3SVC! 5aa39187() W3SVC! 5aa39416() ISATQ! 65f18599() ISATQ! 65f19630() e877e317() Havnt particularly looked at this in any depth yet but will do... Back to critical as IIS is unstable.. although its not critical for all systems it is for IIS & Windows so its certainly not a show stopper but needs to be kept in mind and worked on gradually.. Previous Comments: [2002-09-24 12:07:06] [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 There were some thread-safety issues fixed just recently in CVS so please try the snapshot. [2002-09-24 12:01:14] [EMAIL PROTECTED] As normal with these kinda bugs my ISAPI/IIS is rock solid so its very difficult to track this down. Im moving this bug to critical as it affects quite a few people. If any of you can compile on your webservers I would be interested to see if you compile what happens. Also make sure you always use the latest version of PHP as we are always fixing Thread Safety issues (To the best of my knowledge this is probably what is causing this). Hopefully we can gradually improve performance of the ISAPI extension. If you have any other information or a short script that seems to cause it a lot then please add information about it in this bug report. Also please try unloading extensions from PHP and testing without that as it might be a thread safety issue in that extension. Basically until we can get some more concerete information about this lack of stability its very difficult to track down so anything that may help is very welcome. - James [2002-03-07 04:44:56] [EMAIL PROTECTED] We already had the php4isapi.dll als ISAPI-Filter included, but nevertheless it does not work at all. The crashes are gone for sure, but the new flavour ist that sporadically the connection to an Oracle Database get's lost somehow, somewhere, and all my scripts do not work anymore. The problem occures more often after the server has had a heavy load. Point is: PHP does not crash anymore, but in order to have a working DB connection I have to restart the iisadmin-service. regards, Bernd [2002-02-06 09:31:55] [EMAIL PROTECTED] I was experiencing this type of crashing over and over myself with win2k SP2. The solution was to add the ISAPI DLL in the ISAPI Filters list as well as the App Mappings. After this ISAPI has been rock solid. This is the same solution as in this bug report: http://bugs.php.net/bug.php?id=15324 . Note: I did not do this at first because the PHP Manual specifically said that I should not do so (http://www.php.net/manual/en/install.iis.php) unless I needed it for HTTP Authentication. Maybe someone should place some errata in the documentation? [2002-01-31 07:41:23] [EMAIL PROTECTED] Hi there, we've got the same problem too. Even on older Versions of PHP it appeares from time to time. 4.1.1 creates the same SysLog-Message on W2k Sp2, but we only use ODBC. Only NET STOP IISADMIN solves the problem, but from time to time you need to reboot the machine. Using the Zend Optimizer or not is not the problem, it is re-creatable without Zend... One thing to mention is, that it only appears on querys that are quite time consuming. regards, Bernd The remainder of the comments for th
#19582 [Opn->Csd]: Easier Heredoc mode
ID: 19582 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Debian GNU/Linux PHP Version: 4.2.3 New Comment: I dont think this syntax is particularly intuative and would lead to a lot of very ugly code. Remember you only ever write the code once but you are likley to read it many times (fixing bugs etc) so you are better off spending a bit more time writing it and making it easier to understand. Many thanks for your thoughts, - James Previous Comments: [2002-09-24 15:39:47] [EMAIL PROTECTED] Hello, First of all, I would like to say (as hundreds of people says to you each day) that you're all doing a GREAT JOB ! I feel kinda stupid to ask you to consider this feature request, so please consider this as the only thing PHP should include to make my little person very very happy :)) Here's the point : When dealing html which is not mine but generated by a graphist who use dreamweaver or something, I spent a lot of time (and I think lot of people too) quoting, cleaning, line breaking html code. This happens for parts of code which have to be repeated and have to contains output of variables and functions. Then I discovered while reading the doc :) that php has perl- like HEREDOC mode. It sound cool ! I'm using this mode a lot, but when I want to output the result of a function, i'm forced to go out of the heredoc mode, or set a variable with the result of the function before using heredoc mode, and I think the code is getting ugly when doing this. I think the heredoc mode would be very very cool if it was python like. I should use something like that. echo """ Some html lines, $var $var2 more html more $vars """ . function_output() . """ more html ..."""; This would be very cool. But php is already very very cool !! Again, thanks you all for keeping this great job !! -- Edit this bug report at http://bugs.php.net/?id=19582&edit=1
#19552 [Opn->Bgs]: path is always where php was compiled
ID: 19552 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: linux PHP Version: 4.2.3 New Comment: This might be for one of two reasons, this was the dir you started apache from, or it might be a bug in apache2. I cannot see how this bug comes from PHP. The variables' and the values for them are taken directly from the server or environment variables provided to PHP. Bogusify. - James Previous Comments: [2002-09-24 15:27:12] [EMAIL PROTECTED] I tried the latest version. now $_ENV['PWD'] is just /home/sproctor/php4-200209240900. I imagine it's an apache2 issue because that's the only weird thing I'm doing. apache2 works fine on our server for everything else. I'll try building it as a CGI and see if that works. [2002-09-23 05:27:48] [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-22 16:53:11] [EMAIL PROTECTED] $_ENV['PWD'] always returns /home/sproctor/php-4.2.3 (where php was compiled). I expect it to be /var/www/reliance/pn (where the script is run from). I compiled php with apxs2 and apache 2.0.40. It's not just the variable that's wrong, but doing something like include "filename" will search in /home/sproctor/php-4.2.3, for clarity. Thanks! -- Edit this bug report at http://bugs.php.net/?id=19552&edit=1
#19423 [Fbk]: Problem with extension_dir in PHP.ini
ID: 19423 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: *Web Server problem Operating System: Windows 9x/NT/ME/2000/XP PHP Version: 4.2.3 New Comment: No php.ini does not have to be on the c: drive. However please make sure you are using the c:\\ or c:/ syntax. Also make sure that your php.ini file is in the correct location (look at the output of phpinfo()). With the cli and cgi versions you can often get away with putting the php.ini file in the same dir as the executable and it will find it there. - James Previous Comments: [2002-09-24 17:03:32] [EMAIL PROTECTED] Same issue. However, its it a requirement that the php directory be on the c: drive? I have the same problem with any php version I install on the Win2k Server. [2002-09-21 14:27:49] [EMAIL PROTECTED] try changing 'c:\php\extensions' to 'c:\\php\\extensions' or 'c:/php/extensions' and see if it begins to work. [2002-09-16 08:32:29] [EMAIL PROTECTED] Oh yeah, I forgot to add that all the pertinent files for this extension are in the %system% directory! [2002-09-16 08:29:45] [EMAIL PROTECTED] To mficher: If you can give me some cookbook instructions on how to use this tool, then I would be glad to give it a try. It looks as though it needs a running process, but the error occurs when I start IIS. How can I accomplish what you need? [2002-09-16 03:24:32] [EMAIL PROTECTED] Is there a chance to use the strace tool [1] to track what's going on/wrong here? This tool may help tracking down which directory/files are really accessed. [1] http://razor.bindview.com/tools/desc/strace_readme.html 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/19423 -- Edit this bug report at http://bugs.php.net/?id=19423&edit=1
#19301 [Fbk->Asn]: curl_exec crashes
ID: 19301 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Assigned Bug Type: cURL related Operating System: Windows XP Professional CZ PHP Version: 4.2.3 -Assigned To: +Assigned To: jmoore New Comment: 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 Previous Comments: [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. [2002-09-12 03:03:37] [EMAIL PROTECTED] Same issue was reported against PHP 4.2.1 in bug 17782. I can see that bug has been thought to be solved as it wasn't reproducible on Linux. Apparenly not the case. It must be a Windows only issue with CURL. The offending code is the functionality enabled with curl_setopt ($ch, CURLOPT_FILE, $fp); with that line enabled curl_exec() crashes (application error/GPF) both when running PHP from commandline and as module under Apache 1.3.26 Disabling above line with CURLOPT_FILE it works, but that is not very usefull in my case as I need CURLOPT_FILE :-) I assume the developer responsible for php_curl.dll (or someone else) will be able to debug this on Windows? >From my point of view this issue is beginning to get a bit critical, so I wouldn't mind to see a quick solution 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
#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 [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
#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 [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
#19301 [Fbk->Csd]: curl_exec crashes
ID: 19301 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: cURL related Operating System: Windows XP Professional CZ PHP Version: 4.2.3 Assigned To: jmoore New Comment: mine was latest CVS on the date I posted it, it might be a bug in curl which is casuing the crash and the machine which is doing the snap shot builds is using an older version. Ill find out and get that updated if that is the case. CLosing this bug for now as it seems a tertary problem rather than a PHP one. - James Previous Comments: [2002-09-30 04:32:32] [EMAIL PROTECTED] I just tried your latest-cvs-with-curl build and yes that is also working for me. However, the latest non-stable snapshot http://snaps.php.net/win32/php4-win32-latest.zip (dated 20020929) is still failing and I would have thought that was the same code as you tested, or is there just some latency from CVS to the latest non-stable builds? [2002-09-28 04:50:41] [EMAIL PROTECTED] 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 [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 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
#19301 [Csd->Asn]: curl_exec crashes
ID: 19301 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Assigned Bug Type: cURL related Operating System: Windows XP Professional CZ PHP Version: 4.2.3 Assigned To: jmoore New Comment: reopening as snaps system uses latest release of curl. - James Previous Comments: [2002-09-30 15:45:50] [EMAIL PROTECTED] mine was latest CVS on the date I posted it, it might be a bug in curl which is casuing the crash and the machine which is doing the snap shot builds is using an older version. Ill find out and get that updated if that is the case. CLosing this bug for now as it seems a tertary problem rather than a PHP one. - James [2002-09-30 04:32:32] [EMAIL PROTECTED] I just tried your latest-cvs-with-curl build and yes that is also working for me. However, the latest non-stable snapshot http://snaps.php.net/win32/php4-win32-latest.zip (dated 20020929) is still failing and I would have thought that was the same code as you tested, or is there just some latency from CVS to the latest non-stable builds? [2002-09-28 04:50:41] [EMAIL PROTECTED] 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 [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 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
#19689 [Bgs->Opn]: 4.2.3 and higher "include" operator mistake
ID: 19689 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 4CVS-2002-10-01 New Comment: Hello, A lot of people work very hard on PHP for no money, there is a general etiquette which is advisable to stick to when reporting a bug and that is to be nice. Now I havnt looked at your other reports personally and I dont know why they were marked as bogus (perhaps someone was tired, could not understand exactly what you mean or for many other reasons) and I appolgize for that, a better way to approach it is to ask why the bug has been marked as bogus rather than ranting that it has. We deal with many bugs each day and have limited time thus those that get fixed are those which either are highly important to us (If Im affected by a bug Ill fix it myself I wont expect other people too) or one that affects a lot of people. Remember you have not paid for PHP and are asking us to do work for you for free. Now you have spent an hour fixing that bug and Ill have a look at the patch now check it fixes it and does not break anything else and if that is the case then it will be applied before the next version and I thank you for your time, but I promise you it will still use up at least 20 mins of my time (and IMHO my time is more important to me than your time is). So what I am saying is that yes you have a bug in PHP you want fixed but dont expect it to happen straight away, localizing and fixing a bug and checking its implications is a slow and boring game and we dont always get it right but we do it for free so have a touch more patience with us and we are likley to be more helpful. Sorry to rant. - James Previous Comments: [2002-10-01 08:58:29] [EMAIL PROTECTED] OK, if you cannot correct your own program without misleading words (you said before TWICE that there is no bug, and it is the ONLY thing disagreeable to me), get it: php-4.2.3/TSRM/tsrm_virtual_cwd.h, line 56: - #define IS_ABSOLUTE_PATH(path, len) \ - (len >= 2 && isalpha(path[0]) && path[1] == ':') + #define IS_ABSOLUTE_PATH(path, len) \ + (len >= 2 && isalpha(path[0]) && path[1] == ':') \ + || (len >= 1 && IS_SLASH(path[0])) This section is under #ifdef TSRM_WIN32 block (of course). I'm not a specialist in PHP core, so I have spent about an hour to find bug location. Unfortunately I CANNOT stop on that, because our users still download PHP from your site. I will be very glad if you correct this bug in the next version (4.3.0 I suppose?). [2002-10-01 08:58:28] [EMAIL PROTECTED] OK, if you cannot correct your own program without misleading words (you said before TWICE that there is no bug, and it is the ONLY thing disagreeable to me), get it: php-4.2.3/TSRM/tsrm_virtual_cwd.h, line 56: - #define IS_ABSOLUTE_PATH(path, len) \ - (len >= 2 && isalpha(path[0]) && path[1] == ':') + #define IS_ABSOLUTE_PATH(path, len) \ + (len >= 2 && isalpha(path[0]) && path[1] == ':') \ + || (len >= 1 && IS_SLASH(path[0])) This section is under #ifdef TSRM_WIN32 block (of course). I'm not a specialist in PHP core, so I have spent about an hour to find bug location. Unfortunately I CANNOT stop on that, because our users still download PHP from your site. I will be very glad if you correct this bug in the next version (4.3.0 I suppose?). [2002-10-01 08:06:18] [EMAIL PROTECTED] Oh, I forgot: http://www.derickrethans.nl/20020426.php [2002-10-01 08:03:43] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead. Thank you for your interest in PHP. [2002-10-01 08:02:52] [EMAIL PROTECTED] I'm trying to write here THIRD time (maybe previous two threads is down?). You said before this bug in NOT actual in 4.2.3 and in CVS snapshot: http://snaps.php.net/win32/php4-win32-latest.zip but code STILL DOES NOT work in 4.2.3 and 4.3.0-dev. 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
#19650 [Bgs->Dup]: 4.2.3 (!) "include" operator mistake
ID: 19650 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Duplicate Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 4.2.3 New Comment: Dup not bogus Previous Comments: [2002-10-01 10:33:38] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead. Thank you for your interest in PHP. The other report of yours, #19689, has more information so closing this.. [2002-09-30 06:28:36] [EMAIL PROTECTED] Version http://snaps.php.net/win32/php4-win32-latest.zip STILL DOES NOT WORK (z:/test.php contains "echo '!'"): Z:\!distrib\aaa>php.exe ^Z ! Z:\!distrib\aaa>php.exe ^Z Warning: main(/test.php) [http://www.php.net/function.main]: failed to create stream: No such file or directory in Z:\!distrib\aaa\- on line 2 Warning: Failed opening '/test.php' for inclusion (include_path='.;c:\php4\pear') in Z:\!dis trib\aaa\- on line 2 [2002-09-28 23:01:54] [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-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
#19143 [Opn->Fbk]: Segmentation fault upon attempt to login to horde
ID: 19143 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Linux (Debian) PHP Version: 4.3.0 New Comment: The backtrace you provided is of no use to us as you have not compiled with --enable-debug, please do this and then submit the resulting backtrace. http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Compile with --enable-debug (and use the snapshot) Many thanks. - James Previous Comments: [2002-10-01 16:11:22] [EMAIL PROTECTED] Hi, is there any progress on this issue? This is still treated as open I assume? [2002-09-06 06:46:16] [EMAIL PROTECTED] I'm not too sure exactly all you are looking for so I included as much as possible. It says no debugging symbols found a lot. This is probably because this is a debian package installed apache, but I have compiled php with --enable-debug and something appears to be showing here. I hope this helps. CT. (gdb) run -X Starting program: /usr/sbin/apache-ssl -X (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Reading key for server anor.piglets.org:443 Launching... /usr/lib/apache-ssl/gcache pid=25857 Reading key for server anor.piglets.org:443 Launching... /usr/lib/apache-ssl/gcache pid=25858 (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x4026284b in free () from /lib/libc.so.6 (gdb) bt #0 0x4026284b in free () from /lib/libc.so.6 #1 0x402626d3 in free () from /lib/libc.so.6 #2 0x425e75f6 in mhash_free () from /usr/lib/libmhash.so.2 #3 0x40349682 in zif_mhash (ht=2, return_value=0x825560c, this_ptr=0x0, return_value_used=1) at /home/colin/download/php/php4-200209020300/ext/mhash/mhash.c:208 #4 0x40461a9c in execute (op_array=0x81540a4) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1601 #5 0x40461c21 in execute (op_array=0x8255194) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1643 #6 0x40461c21 in execute (op_array=0x81418a4) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1643 #7 0x40461c21 in execute (op_array=0x8153b04) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1643 #8 0x40461c21 in execute (op_array=0x8153cdc) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1643 #9 0x40461c21 in execute (op_array=0x81e3fe4) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1643 #10 0x40461c21 in execute (op_array=0x821bf9c) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1643 #11 0x40461c21 in execute (op_array=0x8143ebc) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1643 #12 0x4045052e in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/colin/download/php/php4-200209020300/Zend/zend.c:814 #13 0x4042a396 in php_execute_script (primary_file=0xb3a8) at /home/colin/download/php/php4-200209020300/main/main.c:1524 #14 0x404684de in apache_php_module_main (r=0x813badc, display_source_mode=0) at /home/colin/download/php/php4-200209020300/sapi/apache/sapi_apache.c:55 #15 0x40469020 in send_php (r=0x813badc, display_source_mode=0, filename=0x0) at /home/colin/download/php/php4-200209020300/sapi/apache/mod_php4.c:563 #16 0x40469085 in send_parsed_php (r=0x813badc) at /home/colin/download/php/php4-200209020300/sapi/apache/mod_php4.c:578 #17 0x08053be4 in ap_invoke_handler () #18 0x0806348c in ap_some_auth_required () #19 0x080634e8 in ap_process_request () #20 0x0805cce9 in ap_child_terminate () #21 0x0805ce7c in ap_child_terminate () #22 0x0805cf99 in ap_child_terminate () #23 0x0805d475 in ap_child_terminate () #24 0x0805db7d in main () #25 0x4020d0bf in __libc_start_main () from /lib/libc.so.6 (gdb) [2002-09-03 18:03:51] [EMAIL PROTECTED]
#19143 [Opn->Fbk]: Segmentation fault upon attempt to login to horde
ID: 19143 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Linux (Debian) PHP Version: 4.3.0 New Comment: feedback is the right status as I have asked you to produce a backtrace with --enable-debug turned on in your configure. - James Previous Comments: [2002-10-01 16:19:36] [EMAIL PROTECTED] I think I misunderstood the form to change the status. Sorry... I hope this will do it... [2002-10-01 16:17:41] [EMAIL PROTECTED] The backtrace you provided is of no use to us as you have not compiled with --enable-debug, please do this and then submit the resulting backtrace. http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Compile with --enable-debug (and use the snapshot) Many thanks. - James [2002-10-01 16:11:22] [EMAIL PROTECTED] Hi, is there any progress on this issue? This is still treated as open I assume? [2002-09-06 06:46:16] [EMAIL PROTECTED] I'm not too sure exactly all you are looking for so I included as much as possible. It says no debugging symbols found a lot. This is probably because this is a debian package installed apache, but I have compiled php with --enable-debug and something appears to be showing here. I hope this helps. CT. (gdb) run -X Starting program: /usr/sbin/apache-ssl -X (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Reading key for server anor.piglets.org:443 Launching... /usr/lib/apache-ssl/gcache pid=25857 Reading key for server anor.piglets.org:443 Launching... /usr/lib/apache-ssl/gcache pid=25858 (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x4026284b in free () from /lib/libc.so.6 (gdb) bt #0 0x4026284b in free () from /lib/libc.so.6 #1 0x402626d3 in free () from /lib/libc.so.6 #2 0x425e75f6 in mhash_free () from /usr/lib/libmhash.so.2 #3 0x40349682 in zif_mhash (ht=2, return_value=0x825560c, this_ptr=0x0, return_value_used=1) at /home/colin/download/php/php4-200209020300/ext/mhash/mhash.c:208 #4 0x40461a9c in execute (op_array=0x81540a4) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1601 #5 0x40461c21 in execute (op_array=0x8255194) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1643 #6 0x40461c21 in execute (op_array=0x81418a4) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1643 #7 0x40461c21 in execute (op_array=0x8153b04) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1643 #8 0x40461c21 in execute (op_array=0x8153cdc) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1643 #9 0x40461c21 in execute (op_array=0x81e3fe4) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1643 #10 0x40461c21 in execute (op_array=0x821bf9c) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1643 #11 0x40461c21 in execute (op_array=0x8143ebc) at /home/colin/download/php/php4-200209020300/Zend/zend_execute.c:1643 #12 0x4045052e in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/colin/download/php/php4-200209020300/Zend/zend.c:814 #13 0x4042a396 in php_execute_script (primary_file=0xb3a8) at /home/colin/download/php/php4-200209020300/main/main.c:1524 #14 0x404684de in apache_php_module_main (r=0x813badc, display_source_mode=0) at /home/colin/download/php/php4-200209020300/sapi/apache/sapi_apache.c:55 #15 0x40469020 in send_php (r=0x813badc, display_source_mode=0, filename=0x0) at /home/colin/download/php/php4-200209020300/sapi/apache/mod_php4.c:563 #16 0x40469085 in send_parsed_php (r=0x813badc) at /home/colin/download/php/php4-200209020300/sapi/apache/mod_php4.c:578 #17 0x08053be4 in ap_invoke_handler () #1
#19748 [Opn->Bgs]: PHP ISAPI crashes IIS 5.0
ID: 19748 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: IIS related Operating System: WIN2000 Pro 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-04 03:18:36] [EMAIL PROTECTED] I've installed PHP4.2.3 ISAPI with IIS 5.0 on a WIN2000 Server. While I'm not calling any php script in a HTML page, my asp pages work corrrectly, but as soon as I load a page with a PHP script (phpinfo() for instance) my asp application does not work anymore... -- Edit this bug report at http://bugs.php.net/?id=19748&edit=1
Bug #16373 Updated: Security Hole
ID: 16373 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *General Issues Operating System: Red Hat 7.1 PHP Version: 4.1.2 New Comment: Hey that 3-d maze game was the best piece of that software.. kept me amused for hours.. Previous Comments: [2002-04-02 00:12:34] [EMAIL PROTECTED] Hmm. A picture of Betty Boop saying "Happy April Fools Day" would have been easier to swallow. But guy! :) [2002-04-01 17:52:12] [EMAIL PROTECTED] Oh, lighten up! But if you really have such a problem with it, turn it off via the expose_php directive in your php.ini file. It's not like we embedded an entire 3-d maze game in your spreadsheet like a certain company from Redmond did. [2002-04-01 17:48:13] [EMAIL PROTECTED] the server that I first noticed this image on is running 4.1.2. Today is April fools. None the less I found the image very distaste full and unprofessional. [2002-04-01 08:17:48] [EMAIL PROTECTED] Anyway, the picture is NOT a security hole, it's an easter egg. But [EMAIL PROTECTED] is right, you're running a very old version of PHP. Upgrading is strongly recommended. [2002-04-01 07:58:49] [EMAIL PROTECTED] You are not running php 4.1.2 but php 4.0.1pl2. Your version of php is very old and remotely exploitable. 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/16373 -- Edit this bug report at http://bugs.php.net/?id=16373&edit=1
