[PHP-DEV] PHP 4.0 Bug #10230 Updated: Apache Segmentation Fault
ID: 10230 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: Reproduceable crash Description: Apache Segmentation Fault I was desperately searching for code fragments that seemed to reproduce the problem, but I ran into it in the midst of an EXTREMELY large object-oriented app built on top of a full-blown generic PHP object framework...the page on which the error was generated was parsing at least 1500 lines of code before executing. Given that I was getting NO output for feedback, it was impossible to tell during what segment of execution PHP was tanking. I've written tens of thousands of lines of PHP code, and never ran into this problem before, so I knew it wasn't a simple matter, and wasn't likely to be captured in a short, self-contained script. Not much help for tracking down the problem, I know, but it is likely that it was a case of a whole series of events/variable declarations/parse errors that all contributed to the crash. Altering the code in several places at once (since most functionality was dependant upon other functionality) was the only way I managed to resolve the issue and stop the crashes. Previous Comments: --- [2001-04-08 01:54:20] [EMAIL PROTECTED] It would help a lot if you would add a shortest possible self containing script into this report which could be used to reproduce this. And you should also try with latest CVS snapshot from http://snaps.php.net/ --Jani --- [2001-04-08 01:38:56] [EMAIL PROTECTED] After careful rewriting of several code segments that contributed to the conditions causing the crash, I appear to have resolved the problem. I can now attribute the circumstances to bad coding somewhere, but there was nonetheless something un-graceful about PHP's handling of the error. I'll leave the bug open for now in case someone wants to look at cleaning up PHP's manner of handling the error, but close it if appropriate. --- [2001-04-07 20:41:24] [EMAIL PROTECTED] While developing a complex PHP application, I wrote an include file that generates a simple web-based form. This include file is accessed through one of 2 different pages (admins.php or members.php). When the file is included in admins.php, everything works peachy. When the file is included in members.php, the form only partially displays, Apache generates a seg fault, and the page is never rendered. This problem occurred on only one other script page that I noticed. I originally discovered this with an OS X install (on a dual-G4, built from packages found on the web), but copied all the relevant files to a Linux PPC machine (604e) with different build options, and encountered the same problem there. Then I copied the files to an OpenBSD machine, and did NOT see the problem (which leads me to believe it may be processor related). I built a new version of PHP to include --enable-debug and a few other options (gd, trans-sid), and now even MORE pages generate seg faults, though a simple php_info() page works fine. I'm including below a copy of the Apache seg fault error line, and the backtrace. Happy to allow access to php_info upon request... Apache's error log reads: [Sat Apr 7 20:18:18 2001] [notice] child pid 25681 exit signal Segmentation fault (11) No core is dumped (Mac OS X doesn't seem to do this). Running Apache under gdb as instructed generates this backtrace: #0 0x00ee7a4c in execute (op_array=0x9179b4) at ./ zend_execute.c:925 #1 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #2 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #3 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #4 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #5 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #6 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #7 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #8 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #9 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #10 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #11 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #12 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #13 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #14 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #15 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #16 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #17 0x00eebcd8 in execute (op_array=0x6f8e84) at
[PHP-DEV] PHP 4.0 Bug #10229 Updated: buffer error in fread
ID: 10229
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Filesystem function related
Description: buffer error in fread
I have only seen php code once, and I was't able to reproduce it. I suppose it was a
case where php code was stored in a variable (for online editing or something). This
is only a guess, as it's not my code that I see, but code from someone else on the
same server.
Previous Comments:
---
[2001-04-07 20:51:58] [EMAIL PROTECTED]
I ran it through a couple hundred times and absolutely no PHP code whatsoever.
The only problem I see here is $content is never cleaned up properly and contains BOTH
of the fread()s jumbled. Which is very strange.
$fp = fopen("http://www.newsplanet.be/", "r");
while (!feof($fp)) $content .= fread($fp, 4000);
fclose($fp);
You would be better off using the above as it works properly.
Whomever is handling the fopen-wrappers should probably look at this.
-Chris
---
[2001-04-07 20:17:03] [EMAIL PROTECTED]
I've been testing a bit more and have a clear reproducible codesnippet, it yields the
same results in php 4.0.4p1, so I changed the PHP version for this bugreport.
---start---
$fp = fopen("http://www.newsplanet.be/", "r");
$content = fread($fp, 10);
fclose($fp);
$fp = fopen("http://www.google.com/", "r");
$content = fread($fp, 10);
mail("me@host", "topic", $content);
---stop---
In this mail, I see the sourcecode from google.com followed by the rest of the code
from newsplanet.be. This does occur in about 1/3 of the mails I try, although I'm
unable to see why this isn't always the case.
---
[2001-04-07 19:46:47] [EMAIL PROTECTED]
Can't reproduce with CVS version. Try upgrading to the newest release 4.04pl1 or grab
a CVS snapshot from http://snaps.php.net/
What URL is it that is doing this? Or is it every URL?
-Chris
---
[2001-04-07 19:25:09] [EMAIL PROTECTED]
While running the following code, I got weird results in my mailbox. It seemed like I
got the entire buffer of 10 bytes mailed, instead of only the length of the result
of the url. And those mails contained php code from another site hosted at the same
server. This worries me, and I think this needs a serious checkup.
The bug is reproducible :)
---start---
$fp = fopen("http://someurl/", "r");
$content = fread($fp, 10);
mail("someone@somehost", "test", $content);
---stop---
Additional info:
'./configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-gd'
'--with-gettext=/usr' '--enable-safe-mode' '--with-config-file-path=/etc/httpd'
'--with-exec-dir=/usr/bin' '--with-zlib' '--enable-magic-quotes' '--with-regex=system'
'--with-ttf=/usr/lib/libttf.so' '--enable-track-vars' '--enable-xml' '--disable-debug'
'--with-db3' '--with-interbase=shared' '--with-pgsql=shared' '--with-ldap'
'--with-imap'
---
Full Bug description available at: http://bugs.php.net/?id=10229
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10231: The Icons in the downloadsection of PHP.net are not transparent.
From: [EMAIL PROTECTED] Operating system: Windows 2k PHP version: 4.0.4pl1 PHP Bug Type: *General Issues Bug description: The Icons in the downloadsection of PHP.net are not transparent. -- Edit Bug report at: http://bugs.php.net/?id=10231edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10231 Updated: The Icons in the downloadsection of PHP.net are not transparent.
ID: 10231 Updated by: eschmid Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: *General Issues Assigned To: Comments: No comment! Previous Comments: --- [2001-04-08 06:26:38] [EMAIL PROTECTED] --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10231edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10232: effects of safemode not described
From: [EMAIL PROTECTED] Operating system: PHP version: 4.0.4pl1 PHP Bug Type: Documentation problem Bug description: effects of safemode not described I can't find a description of the effects of turning on the safe mode configuration option anywhere in the docs or on the site (even using a search). There is a user contributed note on the security page that refers you to the php 2 manual that is no longer present on the server. -- Edit Bug report at: http://bugs.php.net/?id=10232edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10232 Updated: effects of safemode not described
ID: 10232 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Documentation problem Assigned To: Comments: This is undocumented and unsupported feature and gives a false sense of security which it should not really give. It might well have a total rewrite or be removed totally in a future version so its probably best left undocumented as in its current incarnation its very limited in what it does (security should not be at the PHP Level really but at the webserver level done with appropriate permissions).. - James Previous Comments: --- [2001-04-08 06:47:04] [EMAIL PROTECTED] I can't find a description of the effects of turning on the safe mode configuration option anywhere in the docs or on the site (even using a search). There is a user contributed note on the security page that refers you to the php 2 manual that is no longer present on the server. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10232edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10233: Big file uploading problem form HTML FORM
From: [EMAIL PROTECTED] Operating system: Window ME PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: Big file uploading problem form HTML FORM I try file uploading using Apache + PHP under WINDOW ME. I have set the my php.ini as following : ;;; ; Resource Limits ; ;;; PHPRC=C:/WINDOWS max_execution_time = 600 ; Maximum execution time of each script, in seconds memory_limit = 8M post_max_size = 100M ; File Uploads ; file_uploads= On; Whether to allow HTTP file uploads upload_tmp_dir = D:/temp upload_max_filesize = 100M I could upload file sized 5.96 MB but could not upload above filesize,5.96 MB. Maybe this is bug. Please e-mail to me with solutions. Good luck to you. -- Edit Bug report at: http://bugs.php.net/?id=10233edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10233 Updated: Big file uploading problem form HTML FORM
ID: 10233 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Apache related Assigned To: Comments: I don't think this is a bug, but that your script took more than 8MB of memory. Can you try changing your memory limit to a higher value? Previous Comments: --- [2001-04-08 07:11:16] [EMAIL PROTECTED] I try file uploading using Apache + PHP under WINDOW ME. I have set the my php.ini as following : ;;; ; Resource Limits ; ;;; PHPRC=C:/WINDOWS max_execution_time = 600 ; Maximum execution time of each script, in seconds memory_limit = 8M post_max_size = 100M ; File Uploads ; file_uploads= On; Whether to allow HTTP file uploads upload_tmp_dir = D:/temp upload_max_filesize = 100M I could upload file sized 5.96 MB but could not upload above filesize,5.96 MB. Maybe this is bug. Please e-mail to me with solutions. Good luck to you. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10233edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Suggestion for bug system
Jani seems to have to waste several minutes each month clearing bugs from the database which are actually comments or fixes to do with the php web site. I'm sure that these several minutes put to better use would equate to another 10 bugs cleared:) Is it possible to add an extra category of 'php website' to the bug tracking system which causes the report to be just emailed the webmaster rather than entered into the system? Cheers -- Phil Driscoll Dial Solutions +44 (0)113 294 5112 http://www.dialsolutions.com http://www.dtonline.org -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Suggestion for bug system
On Sun, 8 Apr 2001, Phil Driscoll wrote: Is it possible to add an extra category of 'php website' to the bug tracking system which causes the report to be just emailed the webmaster rather than entered into the system? I don't mind clearing those bogus reports. And besides, there's a note that those kind of 'bug reports' should be sent to [EMAIL PROTECTED] and if the submitter is stupid what can we do about it? :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Suggestion for bug system
I've heard whispers that a new bug system is being developed. Who's heading that up? What is the status of it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jani Taskinen Sent: Sunday, April 08, 2001 11:43 AM To: Phil Driscoll Cc: php developers Subject: Re: [PHP-DEV] Suggestion for bug system On Sun, 8 Apr 2001, Phil Driscoll wrote: Is it possible to add an extra category of 'php website' to the bug tracking system which causes the report to be just emailed the webmaster rather than entered into the system? I don't mind clearing those bogus reports. And besides, there's a note that those kind of 'bug reports' should be sent to [EMAIL PROTECTED] and if the submitter is stupid what can we do about it? :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Suggestion for bug system
Make sure it is able to import all the old bugs. We can't lose those. -Rasmus On Sun, 8 Apr 2001, Jani Taskinen wrote: On Sun, 8 Apr 2001, Sean R. Bright wrote: I've heard whispers that a new bug system is being developed. Who's heading that up? What is the status of it? Not even started yet..still designing things.. --Jani -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jani Taskinen Sent: Sunday, April 08, 2001 11:43 AM To: Phil Driscoll Cc: php developers Subject: Re: [PHP-DEV] Suggestion for bug system On Sun, 8 Apr 2001, Phil Driscoll wrote: Is it possible to add an extra category of 'php website' to the bug tracking system which causes the report to be just emailed the webmaster rather than entered into the system? I don't mind clearing those bogus reports. And besides, there's a note that those kind of 'bug reports' should be sent to [EMAIL PROTECTED] and if the submitter is stupid what can we do about it? :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Suggestion for bug system
On Sun, 8 Apr 2001, Rasmus Lerdorf wrote: Make sure it is able to import all the old bugs. We can't lose those. Yup. But that's the smallest of problems. :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Suggestion for bug system
What about leveraging an existing bug system? There is Alexandria over at sourceforge which looks like it is still in development, and by enhancing it projects at sourceforge may also benefit. It sometimes seems that some of the best aspects of open source are not taken advantage of. A ton of systems get developed, but do not continue to evolve over the years... Good luck either way... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Suggestion for bug system
For the love of all things sane and normal, please don't model it after bugzilla. *shudder* Daniel - Original Message - From: "August Zajonc" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, April 08, 2001 12:52 PM Subject: Re: [PHP-DEV] Suggestion for bug system What about leveraging an existing bug system? There is Alexandria over at sourceforge which looks like it is still in development, and by enhancing it projects at sourceforge may also benefit. It sometimes seems that some of the best aspects of open source are not taken advantage of. A ton of systems get developed, but do not continue to evolve over the years... Good luck either way... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10234: if (... != ...) does not work properly with strings
From: [EMAIL PROTECTED] Operating system: Win2000 Prof PHP version: 4.0.4pl1 PHP Bug Type: Unknown/Other Function Bug description: if (... != ...) does not work properly with strings ?php /* I want to compare two strings and if they are equal show a message on the screen. But I discovered that it's imposible, because PHP think that they are equal anyway :((( Example of script */ //EX 1. something wrong $qqq = "00041001001001001001001001001001001002000"; $xxx = "00041001001001001"; # with != just the same effect as if ($qqq $xxx) echo "hr$qqqbr b!=/b br$xxxhr"; //it should be on the screen, but ... else echo "hr$qqqbr b=/b br$xxx hr"; //it's appear every time on the screen :((( if ($qqq != $xxx) echo "hr$qqqbr b!=/b br$xxx"; else echo "hr$qqqbr b=/b br$xxx hr"; //(strval($qqq) != strval($xxx)) does not work too if (strval($qqq) != strval($xxx)) echo "hr$qqqbr b!=/b br$xxxhr"; else echo "hr$qqqbr b=/b br$xxx hr"; //EX 2 - all OK $qqq = "000410010"; $xxx = "00041001001001001001001001001001001002000"; # with != just the same effect as if ($qqq $xxx) echo "$qqqbr b!=/b br$xxx"; else echo "$qqqbr b=/b br$xxx hr"; if ($qqq != $xxx) echo "$qqqbr b!=/b br$xxx"; else echo "$qqqbr b=/b br$xxx hr"; ? -- Edit Bug report at: http://bugs.php.net/?id=10234edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10234 Updated: if (... != ...) does not work properly with strings
ID: 10234 Updated by: cnewbill Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Bogus Bug Type: Unknown/Other Function Assigned To: Comments: For string comparison use !== for NOT and === for EQUALS. -Chris Previous Comments: --- [2001-04-08 14:58:54] [EMAIL PROTECTED] ?php /* I want to compare two strings and if they are equal show a message on the screen. But I discovered that it's imposible, because PHP think that they are equal anyway :((( Example of script */ //EX 1. something wrong $qqq = "00041001001001001001001001001001001002000"; $xxx = "00041001001001001"; # with != just the same effect as if ($qqq $xxx) echo "hr$qqqbr b!=/b br$xxxhr"; //it should be on the screen, but ... else echo "hr$qqqbr b=/b br$xxx hr"; //it's appear every time on the screen :((( if ($qqq != $xxx) echo "hr$qqqbr b!=/b br$xxx"; else echo "hr$qqqbr b=/b br$xxx hr"; //(strval($qqq) != strval($xxx)) does not work too if (strval($qqq) != strval($xxx)) echo "hr$qqqbr b!=/b br$xxxhr"; else echo "hr$qqqbr b=/b br$xxx hr"; //EX 2 - all OK $qqq = "000410010"; $xxx = "00041001001001001001001001001001001002000"; # with != just the same effect as if ($qqq $xxx) echo "$qqqbr b!=/b br$xxx"; else echo "$qqqbr b=/b br$xxx hr"; if ($qqq != $xxx) echo "$qqqbr b!=/b br$xxx"; else echo "$qqqbr b=/b br$xxx hr"; ? --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10234edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10235: Segfault on domxml_root()
From: [EMAIL PROTECTED] Operating system: Debian Linux 2.2 i386 PHP version: 4.0 Latest CVS (08/04/2001) PHP Bug Type: Reproduceable crash Bug description: Segfault on domxml_root() ? $file1 = "/tmp/file1"; $file2 = "/tmp/file2"; $doc = xmldocfile($file1); $root = domxml_root($doc); print_r($root); ? ./configure --prefix=/usr --with-apxs=/usr/bin/apxs --with-config-file-path=/etc/php4/apache --enable-debug --with-dom php.ini-dist (not relevant) Program received signal SIGSEGV, Segmentation fault. 0x403ada4e in compile_branch (options=0, brackets=0x8, codeptr=0x0, ptrptr=0x403b1824, errorptr=0x4046baf4, optchanged=0x2, reqchar=0x2, countlits=0x2, cd=0x10) at pcre.c:1209 1209for (c = 0; c 32; c++) class[c] |= ~cbits[c+cbit_word]; (gdb) bt #0 0x403ada4e in compile_branch (options=0, brackets=0x8, codeptr=0x0, ptrptr=0x403b1824, errorptr=0x4046baf4, optchanged=0x2, reqchar=0x2, countlits=0x2, cd=0x10) at pcre.c:1209 #1 0x4046baf4 in inflate_mask () from /usr/lib/libxml2.so.2 #2 0x403b1846 in match (eptr=0x1 Address 0x1 out of bounds, ecode=0x8155afc "", offset_top=0, md=0x1, ims=135616424, eptrb=0x0, flags=1078193993) at pcre.c:3956 #3 0x40375147 in php_if_apache_lookup_uri (ht=135598500, return_value=0x2, this_ptr=0x6e616d6d, return_value_used=1077437309) at php_apache.c:407 #4 0x40386420 in php_xpath_get_object (wrapper=0x8, rsrc_type1=3, rsrc_type2=0) at php_domxml.c:332 #5 0x4039e4c3 in fn_ext ( name=0xbaf8 "\002f\023\b\024c\023\b\f/\016\b\020\022\025\b") at mf_fn_ext.c:24 #6 0x40399b9e in vio_blocking (vio=0x81347ec, set_blocking_mode=8 '\b') at violite.c:216 #7 0x4039a8ab in atoi_octal (str=0x81347ec "ÄG\023\b\224\236\024\bÌÔ\f\b") at my_init.c:40 #8 0x4039a8ef in atoi_octal (str=0x81347ec "ÄG\023\b\224\236\024\bÌÔ\f\b") at my_init.c:42 #9 0x8053ef4 in ap_invoke_handler () #10 0x806283c in ap_some_auth_required () #11 0x8062898 in ap_process_request () #12 0x805c5b9 in ap_child_terminate () #13 0x805c74c in ap_child_terminate () #14 0x805c869 in ap_child_terminate () #15 0x805cd1b in ap_child_terminate () #16 0x805d3dd in main () #17 0x400c2a42 in __libc_start_main () from /lib/libc.so.6 -- Edit Bug report at: http://bugs.php.net/?id=10235edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10211 Updated: CURLOPT_HTTPHEADER does not work
ID: 10211
User Update by: [EMAIL PROTECTED]
Status: Closed
Bug Type: cURL related
Description: CURLOPT_HTTPHEADER does not work
I downloaded the 4.0.5RC1 binary from http://www.php4win.de/, but it doesn't work
either. Although, it looks like the values for CURLOPT_HTTPHEADER and CURLOPT_HEADER
are now correct.
Then I went to http://snaps.php.net/ and grabbed the source 4.0.6 (I think it is),
which compiled ok. Then I grabbed cURL from http://curl.haxx.se/, but I'm unable to
get that to compile to a DLL (despite several attempts). Any suggestions would be
appreciated.
thanks for your quick response.
chris
Previous Comments:
---
[2001-04-06 11:35:57] [EMAIL PROTECTED]
Or as you have windows, try latest build from http://www.php4win.de/
--Jani
---
[2001-04-06 11:35:26] [EMAIL PROTECTED]
This should be fixed in CVS. Please try the latest snapshot
from http://snaps.php.net/
--Jani
---
[2001-04-06 11:31:14] [EMAIL PROTECTED]
Also, noticed that CURLOPT_HTTPHEADER and CURLOPT_HEADER have the same value.
Using curl -H "UID: spud" http://... works properly.
Except for CURLOPT_HTTPHEADER and chopping off 2 bytes at the end of a
CURLOPT_RETURNTRANSFER ... everything works great.
Here's my script:
?php
$url = "http://localhost/perl-bin/mod_perl_test.pl";
$user_agent = "VanillaZilla/2001";
$ch = curl_init();
curl_setopt ($ch, CURLOPT_HTTPHEADER, "UID: spud");
curl_setopt ($ch, 23, "UID: spud");
echo "after CURLOPT_HTTPHEADER(".CURLOPT_HTTPHEADER."
CURLOPT_HEADER=".CURLOPT_HEADER."):br";
echo "curl_errno=". curl_errno($ch) ."br";
echo "curl_error=". curl_error($ch) ."br";
curl_setopt ($ch, CURLOPT_VERBOSE, 1);
curl_setopt ($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_HEADER, 1);
curl_setopt ($ch, CURLOPT_USERAGENT, $user_agent);
curl_setopt ($ch, CURLOPT_COOKIE, "spud=tater;tater=spud");
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_POST, 1);
curl_setopt ($ch, CURLOPT_POSTFIELDS, "pass=spuddata=stuffcase=en");
$result = curl_exec ($ch);
echo "after curl_exec:br";
echo "curl_errno=". curl_errno($ch) ."br";
echo "curl_error=". curl_error($ch) ."br";
curl_close ($ch);
print "hrpre";
echo $result . "br";
print "/pre";
?
thanks.
chris [EMAIL PROTECTED]
---
Full Bug description available at: http://bugs.php.net/?id=10211
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10211 Updated: CURLOPT_HTTPHEADER does not work
ID: 10211
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: cURL related
Description: CURLOPT_HTTPHEADER does not work
I downloaded the 4.0.5RC1 binary from http://www.php4win.de/, but it doesn't work
either. Although, it looks like the values for CURLOPT_HTTPHEADER and CURLOPT_HEADER
are now correct.
Then I went to http://snaps.php.net/ and grabbed the source 4.0.6 (I think it is),
which compiled ok. Then I grabbed cURL from http://curl.haxx.se/, but I'm unable to
get that to compile to a DLL (despite several attempts). Any suggestions would be
appreciated.
thanks for your quick response.
chris
Previous Comments:
---
[2001-04-08 18:03:08] [EMAIL PROTECTED]
I downloaded the 4.0.5RC1 binary from http://www.php4win.de/, but it doesn't work
either. Although, it looks like the values for CURLOPT_HTTPHEADER and CURLOPT_HEADER
are now correct.
Then I went to http://snaps.php.net/ and grabbed the source 4.0.6 (I think it is),
which compiled ok. Then I grabbed cURL from http://curl.haxx.se/, but I'm unable to
get that to compile to a DLL (despite several attempts). Any suggestions would be
appreciated.
thanks for your quick response.
chris
---
[2001-04-06 11:35:57] [EMAIL PROTECTED]
Or as you have windows, try latest build from http://www.php4win.de/
--Jani
---
[2001-04-06 11:35:26] [EMAIL PROTECTED]
This should be fixed in CVS. Please try the latest snapshot
from http://snaps.php.net/
--Jani
---
[2001-04-06 11:31:14] [EMAIL PROTECTED]
Also, noticed that CURLOPT_HTTPHEADER and CURLOPT_HEADER have the same value.
Using curl -H "UID: spud" http://... works properly.
Except for CURLOPT_HTTPHEADER and chopping off 2 bytes at the end of a
CURLOPT_RETURNTRANSFER ... everything works great.
Here's my script:
?php
$url = "http://localhost/perl-bin/mod_perl_test.pl";
$user_agent = "VanillaZilla/2001";
$ch = curl_init();
curl_setopt ($ch, CURLOPT_HTTPHEADER, "UID: spud");
curl_setopt ($ch, 23, "UID: spud");
echo "after CURLOPT_HTTPHEADER(".CURLOPT_HTTPHEADER."
CURLOPT_HEADER=".CURLOPT_HEADER."):br";
echo "curl_errno=". curl_errno($ch) ."br";
echo "curl_error=". curl_error($ch) ."br";
curl_setopt ($ch, CURLOPT_VERBOSE, 1);
curl_setopt ($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_HEADER, 1);
curl_setopt ($ch, CURLOPT_USERAGENT, $user_agent);
curl_setopt ($ch, CURLOPT_COOKIE, "spud=tater;tater=spud");
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_POST, 1);
curl_setopt ($ch, CURLOPT_POSTFIELDS, "pass=spuddata=stuffcase=en");
$result = curl_exec ($ch);
echo "after curl_exec:br";
echo "curl_errno=". curl_errno($ch) ."br";
echo "curl_error=". curl_error($ch) ."br";
curl_close ($ch);
print "hrpre";
echo $result . "br";
print "/pre";
?
thanks.
chris [EMAIL PROTECTED]
---
Full Bug description available at: http://bugs.php.net/?id=10211
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch
[Jon Parise [EMAIL PROTECTED]] Does anyone object to the following patch to the PHP configure system? It removes the --disable-pear flag in favor of a new --with-pear option. The --with-pair option also allows the specification of the PEAR installation directory at compilation time. For example: ./configure --with-pear=/var/www/pear ... would install the PEAR hierarchy in /var/www/pear. The new PEAR directory is also added to the default 'include_path', too (that behavior isn't really new, but it's a lot more useful now that the PEAR location can be specified at compile time). This patch overlaps with some changes I did on my way home from ApacheCon. I haven't committed them yet, but here's a summary: 1. Using --datadir to determine where PEAR PHP files go. With --datadir=/usr/share or --datadir=/usr/share/php, PHP architecture independent files go to /usr/share/php, and PEAR's PHP files go to /usr/share/php/pear. I've added your --with-pear option to override this. 2. Using --libdir to determine where extensions go. With --libdir=/usr/lib or --libdir=/usr/lib/php, extensions are installed in /usr/lib/php/APIVER. I've also shortened the APIVER part so "no-debug" and "non-zts" are skipped. The alternatives are now "20001222", "20001222-zts", "20001222-debug" and "20001222-zts-debug". 3. Using --sysconfdir to determine php.ini path. The default is now $prefix/etc. 4. The CGI version of PHP is always built and installed. Let me know if you have any problems with these changes. They should make it a lot easier for distributions to build PHP, because we conform more to de-facto build conventions (at least on Linux). Also you won't have to re-run configure and make to build the CGI in order to run tests, the PEAR installer etc. - Stig -- Stig Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch
On 8 Apr 2001, Stig Sther Bakken wrote: 4. The CGI version of PHP is always built and installed. It would be nice if we could disable this, like: --without-cgi Regards, Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED] Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PEAR_INSTALLDIR breakage
[Sascha Schumann [EMAIL PROTECTED]]
Is there a reason the $'s were escape, or can I commit my fix?
If EXTENSION_DIR/INCLUDE_PATH are used outside makefiles,
your patch should be applied.
They are used outside makefiles, but they should be as separate
variables that are expanded. I've committed a fix for it.
Jon, the reason for the ${foo} syntax is that this is the only way to
reference a variable that works in both "make", "sh" and PHP. In the
makefiles we want to defer expansion as long as possible, to give the
user bigger flexibility for redefining individual variables from the
"make" command line.
- Stig
--
Stig Sther Bakken [EMAIL PROTECTED]
Fast Search Transfer ASA, Trondheim, Norway
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch
[Derick Rethans [EMAIL PROTECTED]] On 8 Apr 2001, Stig Sther Bakken wrote: 4. The CGI version of PHP is always built and installed. It would be nice if we could disable this, like: --without-cgi I'll add it. - Stig -- Stig Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Quick fix (was: Re: [PHP-DEV] OCI8 Thread safety)
I'm still a neophite at thread safety/PHP internals, but I found a quick fix to the OCI8 and PHP in threaded envrionment. Changing OCI_THREADED to OCI_DEFAULT in the OCIInitialize function is the quick fix I discovered. It works because the OCI8 exention is designed for seperate address space for all oci calls. You can't call OCIInitialize or OCIEnvInit mutiple times in a process. They are designed to be called once through the life of a process. OCI in a threaded environment the threads share the parent's OCIEnvironment. The OCI module currently doesn't take this into consideration and calls OCIEnvInit when it grabs a copy of the OCI_globals. Works fine if they're not sharing the Parent environment, traditional Unix style processes. Not using OCI_THREADED in OCIInitialize, OCI threads act like seperate processes. OCI8 has the ability to take full advantage of a threaded environment. I've studied the calls etc. and there is a lot of resource sharing that can be implemented with OCI in threaded environment. Implementing OCI_SHARED can provide supererior perfomance increases on threaded servers. It's and ideal switch to throw into the mix, but a lot of rewiring needs to be done on the OCI8 module for this to work as advertised. Thies, I'd love to work with you on this, if you're interested... I need some help understanding how the existing code operates. I have a feel for it, but would like some assumption verification. ;-) joebrown podiatryfl.com ""Thies C. Arntzen"" [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Fri, Apr 06, 2001 at 10:50:49PM -0400, Joe Brown wrote: It appears to me that the oci8 module does not behave well on win32 - a threaded environment. I've begun to study the code, and believe I can make it mind the rules. what is not thread-safe in your opinion? i don't use windows or any other threded server so i can't really tell Thread safe programming is new to me. (hehe were have you heard that b4?-) Is anyone else working on the OCI8 extension? i am tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10236: ftruncate problem
From: [EMAIL PROTECTED]
Operating system: Linux 2.2.5 / glibc 2.0.7
PHP version: 4.0.4
PHP Bug Type: Filesystem function related
Bug description: ftruncate problem
I've had a little problem with ftruncate, here is a sample
script that misbehaves for me:
?
function movedata ($fd, $count)
{
$p = ftell($fd);
if ( $count 0 )
{
$p += $count;
}
$r = 1024;
if ($count 0 $r $count)
{
$r = $count;
}
else if ($count 0 $r -$count)
{
$r = -$count;
}
$c1 = strlen($buf1 = fread($fd,$r));
$eof = false;
while ( !$eof )
{
$c2 = strlen($buf2 = fread($fd,$r));
$eof = feof($fd);
fseek($fd,-$c2-$c1+$count,SEEK_CUR);
fwrite($fd,$buf1,$c1);
fseek($fd,$c2-$count,SEEK_CUR);
$buf1 = $buf2;
$c1 = $c2;
}
fseek($fd,-$c1+$count,SEEK_CUR);
fwrite($fd,$buf1,$c1);
ftruncate($fd,ftell($fd));
// Uncomment the fflush to get it working
// fflush($fd);
fseek($fd,$p,SEEK_SET);
};
header("Content-type: text/plain");
$fd = fopen('test','w+') or die("Couldn't open file.\n");
$file = EOL
aa
A
/aa
b
BB
/b
EOL;
fputs($fd,$file);
fclose($fd);
$fd = fopen('test','r+') or die("Couldn't open file.\n");
$str =
"C\n";
fseek($fd,9+strlen($str),SEEK_SET);
movedata($fd,-strlen($str));
movedata($fd,strlen($str));
fseek($fd,9,SEEK_SET);
fputs($fd,$str);
fseek($fd,0,SEEK_SET);
fpassthru($fd);
?
Here is the output:
aa
C
/aa
b
BB
/b
AAA
/aa
b
BB
/b
I think it should be:
aa
C
/aa
b
BB
/b
What I found is that the second movedata call doesn't work
the way I want it to. As you can see in the output there is
some garbage data that seems to come from the first movedata
call.
I'm not really sure if the thing I found is really a bug,
since the above code might also be buggy. Furthermore this
is really the only case I found to reproduce the problem
(simpler test programs worked fine). The problem might also
be caused by linux/glibc (I know the given versions are
quite old, I'll upgrade soon :-)).
I think there might be a problem with buffered i/o so that
eof doesn't know about the new file size set by ftruncate
since the libc buffered i/o layered isn't flushed and php
source only calls fileno to find out the fd, but the stream
isn't flushed, and the ftruncate libc call isn't in sync
with the buffered i/o layer.
I think php function ftruncate should do a fflush libc call
before doing the ftruncate library call, so that everything
works fine and the php programmer won't have to care about that.
Have fun.
Mattias Nissler ([EMAIL PROTECTED])
--
Edit Bug report at: http://bugs.php.net/?id=10236edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10230 Updated: Apache Segmentation Fault
ID: 10230 Updated by: bbonev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Reproduceable crash Assigned To: Comments: i am almost sure this is the infinite include problem. e.g. a.php: ?include 'a.php'? it is known and can be fixed using include_once/require_once if you have found something different, please reopen Previous Comments: --- [2001-04-08 03:22:19] [EMAIL PROTECTED] I was desperately searching for code fragments that seemed to reproduce the problem, but I ran into it in the midst of an EXTREMELY large object-oriented app built on top of a full-blown generic PHP object framework...the page on which the error was generated was parsing at least 1500 lines of code before executing. Given that I was getting NO output for feedback, it was impossible to tell during what segment of execution PHP was tanking. I've written tens of thousands of lines of PHP code, and never ran into this problem before, so I knew it wasn't a simple matter, and wasn't likely to be captured in a short, self-contained script. Not much help for tracking down the problem, I know, but it is likely that it was a case of a whole series of events/variable declarations/parse errors that all contributed to the crash. Altering the code in several places at once (since most functionality was dependant upon other functionality) was the only way I managed to resolve the issue and stop the crashes. --- [2001-04-08 01:54:20] [EMAIL PROTECTED] It would help a lot if you would add a shortest possible self containing script into this report which could be used to reproduce this. And you should also try with latest CVS snapshot from http://snaps.php.net/ --Jani --- [2001-04-08 01:38:56] [EMAIL PROTECTED] After careful rewriting of several code segments that contributed to the conditions causing the crash, I appear to have resolved the problem. I can now attribute the circumstances to bad coding somewhere, but there was nonetheless something un-graceful about PHP's handling of the error. I'll leave the bug open for now in case someone wants to look at cleaning up PHP's manner of handling the error, but close it if appropriate. --- [2001-04-07 20:41:24] [EMAIL PROTECTED] While developing a complex PHP application, I wrote an include file that generates a simple web-based form. This include file is accessed through one of 2 different pages (admins.php or members.php). When the file is included in admins.php, everything works peachy. When the file is included in members.php, the form only partially displays, Apache generates a seg fault, and the page is never rendered. This problem occurred on only one other script page that I noticed. I originally discovered this with an OS X install (on a dual-G4, built from packages found on the web), but copied all the relevant files to a Linux PPC machine (604e) with different build options, and encountered the same problem there. Then I copied the files to an OpenBSD machine, and did NOT see the problem (which leads me to believe it may be processor related). I built a new version of PHP to include --enable-debug and a few other options (gd, trans-sid), and now even MORE pages generate seg faults, though a simple php_info() page works fine. I'm including below a copy of the Apache seg fault error line, and the backtrace. Happy to allow access to php_info upon request... Apache's error log reads: [Sat Apr 7 20:18:18 2001] [notice] child pid 25681 exit signal Segmentation fault (11) No core is dumped (Mac OS X doesn't seem to do this). Running Apache under gdb as instructed generates this backtrace: #0 0x00ee7a4c in execute (op_array=0x9179b4) at ./ zend_execute.c:925 #1 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #2 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #3 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #4 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #5 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #6 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #7 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #8 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #9 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #10 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #11 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #12 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #13 0x00eebcd8 in
[PHP-DEV] PHP 4.0 Bug #10233 Updated: Big file uploading problem form HTML FORM
ID: 10233 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: Apache related Description: Big file uploading problem form HTML FORM REPLY to derick I have considered your comments that my script took more than 8MB of memory. But the same problem occurred. Exact error message from IE5.0 is "Can not display this page". I think FORM HTML problem. What can I do ? ID: 10233 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Apache related Assigned To: Comments: I don't think this is a bug, but that your script took more than 8MB of memory. Can you try changing your memory limit to a higher value? Previous Comments: --- [2001-04-08 07:11:16] [EMAIL PROTECTED] I try file uploading using Apache + PHP under WINDOW ME. I have set the my php.ini as following : ;;; ; Resource Limits ; ;;; PHPRC=C:/WINDOWS max_execution_time = 600 ; Maximum execution time of each script, in seconds memory_limit = 8M post_max_size = 100M ; File Uploads ; file_uploads= On; Whether to allow HTTP file uploads upload_tmp_dir = D:/temp upload_max_filesize = 100M I could upload file sized 5.96 MB but could not upload above filesize,5.96 MB. Maybe this is bug. Please e-mail to me with solutions. Good luck to you. Previous Comments: --- [2001-04-08 07:26:03] [EMAIL PROTECTED] I don't think this is a bug, but that your script took more than 8MB of memory. Can you try changing your memory limit to a higher value? --- [2001-04-08 07:11:16] [EMAIL PROTECTED] I try file uploading using Apache + PHP under WINDOW ME. I have set the my php.ini as following : ;;; ; Resource Limits ; ;;; PHPRC=C:/WINDOWS max_execution_time = 600 ; Maximum execution time of each script, in seconds memory_limit = 8M post_max_size = 100M ; File Uploads ; file_uploads= On; Whether to allow HTTP file uploads upload_tmp_dir = D:/temp upload_max_filesize = 100M I could upload file sized 5.96 MB but could not upload above filesize,5.96 MB. Maybe this is bug. Please e-mail to me with solutions. Good luck to you. --- Full Bug description available at: http://bugs.php.net/?id=10233 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch
On Sun, Apr 08, 2001 at 06:21:50PM -0400, Stig Sther Bakken wrote: 1. Using --datadir to determine where PEAR PHP files go. With --datadir=/usr/share or --datadir=/usr/share/php, PHP architecture independent files go to /usr/share/php, and PEAR's PHP files go to /usr/share/php/pear. I've added your --with-pear option to override this. 2. Using --libdir to determine where extensions go. With --libdir=/usr/lib or --libdir=/usr/lib/php, extensions are installed in /usr/lib/php/APIVER. I've also shortened the APIVER part so "no-debug" and "non-zts" are skipped. The alternatives are now "20001222", "20001222-zts", "20001222-debug" and "20001222-zts-debug". Both of these sounds good to me. 3. Using --sysconfdir to determine php.ini path. The default is now $prefix/etc. Would this be a replacement for --with-config-file-path? 4. The CGI version of PHP is always built and installed. I assume that would --bindir, right? Let me know if you have any problems with these changes. They should make it a lot easier for distributions to build PHP, because we conform more to de-facto build conventions (at least on Linux). Also you won't have to re-run configure and make to build the CGI in order to run tests, the PEAR installer etc. I think you're proposed changes cover a lot more (useful) ground than my simple patch. Go for it! =) -- Jon Parise ([EMAIL PROTECTED]) . Rochester Inst. of Technology http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10237: sybase_query returns 1 instead of link id with action queries
From: [EMAIL PROTECTED]
Operating system: Linux 2.2.16-3, Redhat 6.2
PHP version: 4.0.4pl1
PHP Bug Type: Sybase-ct (ctlib) related
Bug description: sybase_query returns 1 instead of link id with action queries
sybase_query returns 1 instead of a link id when I run an action query. The following
code reproduces the error:
$con = sybase_connect("SYBASE", "user", "pass");
sybase_select_db("cope");
$qry = sybase_query("update ...", $con);
echo sybase_affected_rows($qry);
sybase_close($con);
The update query works in isql.
Here is my configure line:
'./configure' '--with-apache=../apache_1.3.19' '--with-sybase-ct=/opt/sybase'
'--with-curl=../curl-7.7' '--with-mm=../mm-1.1.3' '--enable-bcmath'
'--enable-calendar' '--enable-ctype' '--enable-exif' '--enable-ftp'
'--enable-gd-imgstrttf' '--with-gd' '--enable-trans-sid' '--enable-shmop'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-wddx'
--
Edit Bug report at: http://bugs.php.net/?id=10237edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
