[PHP-DEV] Bug #13385 Updated: nl2br hangs on specific strings
ID: 13385 Updated by: bbonev Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Strings related Operating System: Linux glibc 2.2 PHP Version: 4.0CVS-2001-09-21 New Comment: forgot to close Previous Comments: [2001-09-22 17:14:51] [EMAIL PROTECTED] it is fixed in current CVS [2001-09-22 04:32:37] [EMAIL PROTECTED] bbonev@orange:~/php/php4$ ./php X-Powered-By: PHP/4.0.8-dev Content-type: text/html Fatal error: Maximum execution time of 30 seconds exceeded in - on line 1 btw. i have noticed this while trying to rewrite nl2br to be faster and more compatible. Edit this bug report at http://bugs.php.net/?id=13385&edit=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] Bug #13385 Updated: nl2br hangs on specific strings
ID: 13385 Updated by: bbonev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Strings related Operating System: Linux glibc 2.2 PHP Version: 4.0CVS-2001-09-21 New Comment: it is fixed in current CVS Previous Comments: [2001-09-22 04:32:37] [EMAIL PROTECTED] bbonev@orange:~/php/php4$ ./php X-Powered-By: PHP/4.0.8-dev Content-type: text/html Fatal error: Maximum execution time of 30 seconds exceeded in - on line 1 btw. i have noticed this while trying to rewrite nl2br to be faster and more compatible. Edit this bug report at http://bugs.php.net/?id=13385&edit=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] Bug #13385: nl2br hangs on specific strings
From: [EMAIL PROTECTED] Operating system: Linux glibc 2.2 PHP version: 4.0CVS-2001-09-21 PHP Bug Type: Strings related Bug description: nl2br hangs on specific strings bbonev@orange:~/php/php4$ ./php X-Powered-By: PHP/4.0.8-dev Content-type: text/html Fatal error: Maximum execution time of 30 seconds exceeded in - on line 1 btw. i have noticed this while trying to rewrite nl2br to be faster and more compatible. -- Edit bug report at: http://bugs.php.net/?id=13385&edit=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] Bug #11088 Updated: Buildconf fails on Latest CVS
ID: 11088 Updated by: bbonev Reported By: [EMAIL PROTECTED] Old-Status: Suspended Status: Open Bug Type: *Install and Config Operating system: PHP Version: 4.0 Latest CVS (2001-05-24) Assigned To: Comments: buildconf: autoconf version 2.50 (ok) downgrade this to 2.13 i had the same problem yesterday Previous Comments: --- [2001-05-24 11:30:23] [EMAIL PROTECTED] On hold until we get the automake situation figured out. (Use automake 2.13 to make this work) --- [2001-05-24 11:13:46] [EMAIL PROTECTED] buildconf on OpenBSD 2.8 fails: --- ns1# uname -a OpenBSD ns1 2.8 GENERIC#399 i386 ns1# ns1# ./buildconf buildconf: checking installation... buildconf: autoconf version 2.50 (ok) buildconf: automake version 1.4-p1 (ok) buildconf: libtool version 1.4 (ok) rebuilding Makefile templates automake: configure.in: installing `Zend/ylwrap' rebuilding configure ./aclocal.m4:904: error: m4_defn: undefined: _m4_divert_diversion ./aclocal.m4:452: PHP_SUBST is expanded from... ./aclocal.m4:904: the top level rebuilding acconfig.h rebuilding main/php_config.h.in autoheader: error: shell error while sourcing /tmp/ahue7647/traces.sh --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11088&edit=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] Bug #11010 Updated: current cvs cannot configure
ID: 11010 Updated by: bbonev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: *Install and Config Operating system: PHP Version: 4.0 Latest CVS (2001-05-22) Assigned To: Comments: as far as i can see Sacha fixed this one Previous Comments: --- [2001-05-22 04:25:19] [EMAIL PROTECTED] freshmeat on autoconf: Changes: This version includes 2 years of accumulated improvements and bugfixes. While almost every line of code has been touched since version 2.13, Autoconf 2.50 aims to be backward compatible for well-written configure.in scripts. i removed 2.50 and put back 2.13 and everything is ok now i've looked further but they do not define well-written... --- [2001-05-22 02:34:54] [EMAIL PROTECTED] after upgrading libtool to 1.4 i have upgraded automake and autoconf to latest stable versions, here is the result: buildconf: checking installation... buildconf: autoconf version 2.50 (ok) build/buildcheck.sh: test: 4-p1: integer expression expected buildconf: automake version 1.4-p1 (ok) buildconf: libtool version 1.4 (ok) WARNING: automake and libtool are installed in different directories. This may cause aclocal to fail. continuing anyway rebuilding Makefile templates automake: configure.in: installing `Zend/ylwrap' rebuilding configure ./aclocal.m4:904: error: m4_defn: undefined: _m4_divert_diversion ./aclocal.m4:452: PHP_SUBST is expanded from... ./aclocal.m4:904: the top level rebuilding acconfig.h rebuilding main/php_config.h.in autoheader: error: shell error while sourcing /tmp/ah26273/traces.sh in build/buildcheck.sh: first problem - automake version is 1.4-p1 and this check fails: IFS=.; set $am_version; IFS=' ' if test "$1" = "1" -a "$2" -lt "4" || test "$1" -lt "1"; then fix: Index: build/buildcheck.sh === RCS file: /repository/php4/build/buildcheck.sh,v retrieving revision 1.8 diff -u -r1.8 buildcheck.sh --- build/buildcheck.sh 2001/05/06 18:51:21 1.8 +++ build/buildcheck.sh 2001/05/22 00:25:01 @@ -40,7 +40,7 @@ fi # automake 1.4 or newer -am_version=`automake --version 2>/dev/null|head -1|sed -e 's/^[^0-9]*//' -e 's/[a-z]* *$//'` +am_version=`automake --version 2>/dev/null|head -1|sed -e 's/^[^0-9]*//' -e 's/[a-z]* +*$//' -e 's/-/./'` if test "$am_version" = ""; then echo "buildconf: automake not found." echo " You need automake version 1.4 or newer installed" second problem - after double checking for libtool, $libtool is set to `which libtool` or `which glibtool`. in the check if libtool and automake are in the same path again which is used that is incorrect because which /bin/libtool founds nothing. fix: Index: build/buildcheck.sh === RCS file: /repository/php4/build/buildcheck.sh,v retrieving revision 1.8 diff -u -r1.8 buildcheck.sh --- build/buildcheck.sh 2001/05/06 18:51:21 1.8 +++ build/buildcheck.sh 2001/05/22 00:30:21 @@ -81,7 +81,7 @@ fi am_prefix=`which automake | sed -e 's#/[^/]*/[^/]*$##'` -lt_prefix=`which $libtool | sed -e 's#/[^/]*/[^/]*$##'` +lt_prefix=`echo $libtool | sed -e 's#/[^/]*/[^/]*$##'` if test "$am_prefix" != "$lt_prefix"; then echo "WARNING: automake and libtool are installed in different" echo " directories. This may cause aclocal to fail." i'd update this bug when i find what else is going wrong --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11010&edit=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] Bug #11008 Updated: exit() should return an exit status if passed, not send to stdout
ID: 11008 Updated by: bbonev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating system: PHP Version: 4.0 Latest CVS (2001-05-21) Assigned To: Comments: indeed it does both: if php; then echo yes; fi X-Powered-By: PHP/4.0.5 Content-type: text/html 0yes if php; then echo yes; fi X-Powered-By: PHP/4.0.5 Content-type: text/html 1 i don't see a real reason for the echoed exit status though Previous Comments: --- [2001-05-21 21:34:23] [EMAIL PROTECTED] Working with a shell script here. I hoped that exit() would work like perl and return the passed status as and exist status. As it stands now, it sends it to stdout. This is unexpected. It would be much more useful if exit() could be used to enable the use of PHP in shell scripts by returning the passed value as an exit status. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11008&edit=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] Bug #9859 Updated: mail() doesn't send cc or bcc as in the manual instructions
ID: 9859
Updated by: bbonev
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Mail related
Operating system:
PHP Version: 4.0.4pl1
Assigned To:
Comments:
see also bug #10136
the facts are: mail on win32 require \r\n newlines
also it is case sensitive on Cc: and Bcc: - it will not honour them if spelled any
other way.
here is the offending code (located in win32/sendmail.c):
if (headers && (pos1 = strstr(headers, "Cc:"))) {
pos2 = strstr(pos1, "\r\n");
tempMailTo = estrndup(pos1, pos2-pos1);
token = strtok(tempMailTo, ",");
i do not have win32 build env setup so cannot fix this
Previous Comments:
---
[2001-05-21 05:06:18] [EMAIL PROTECTED]
I've corrected the Cc: and Bcc: problems in the mail() example, but I'm reclassifying
this as a Mail Function problem. Is it necessary for the win32 version of the mail()
function to require that you use rn?
If it is, I can add this information to the mail function docs.
---
[2001-03-20 02:42:22] [EMAIL PROTECTED]
script example:
-
the mail was sent?
returnvar= $returnvar";
?>
-
The above does not send the carbon copy.
The pdf manual says:
--
$headers .= "cc:[EMAIL PROTECTED]"; // CC to
$headers .= "bcc:[EMAIL PROTECTED], [EMAIL PROTECTED]"; // BCCs to
/* and now mail it */
mail($recipient, $subject, $message, $headers);
---
That does not work since Win32 sendmail.c looks for case sensitve "Cc:"
sendmail.c also does not look for "bcc:"
Also you must have "rn" not just "n".
I think the problem is here in win32 sendmail.c :
if (headers && (pos1 = strstr(headers, "Cc:"))) {
pos2 = strstr(pos1, "rn");
tempMailTo = estrndup(pos1, pos2-pos1);
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9859&edit=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] Bug #10519 Updated: $HTTP_COOKIE_VARS spoofing
ID: 10519 Updated by: bbonev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Variables related PHP Version: 4.0.4pl1 Assigned To: Comments: indeed i have missed one of the points - the fact that when passing data in the array form, all the values combine in a single array. further testing showed that the cookies also appear in HTTP_GET_VARS. i am sure that if there is a post to an url with a get var and some cookies (all varnames in array form) HTTP_*_ARRAY will contain all the values. this issue is a serious concern about the --enable-track-vars code. it must be resolved by overwriting the whole arrays, not adding data to them in order to be consistent e.g. get var: myarr[one]=1 post var: myarr[two]=2 cookie var: myarr[three]=3 gpc order is GPC the global array $myarr has only the 'one' key the HTTP_*_VARS have only the proper arrays Previous Comments: --- [2001-04-29 13:23:27] [EMAIL PROTECTED] think about cookies the same way as GET data or POST data - they are at the same level and can be spoofed very easy with a cURL client for example. one can tell his client what cookie with what value to pass for a given request the issue here is not security but programmers comfort. but when one uses the short representations of variables she must be aware of the GPC order setting. i think this is the same like overriding a post variable with a get one. do you think this bug shall be closed? --- [2001-04-26 21:35:49] [EMAIL PROTECTED] If you access this page with the command line arguement ?cookie[three]=three print_r will show cookie[three] in $HTTP_COOKIE_VARS. Just a bit of incongrous material, but for some sites could cause problems if cookies are spoofed thusly. Regards --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10519&edit=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] Bug #10519 Updated: $HTTP_COOKIE_VARS spoofing
ID: 10519 Updated by: bbonev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Variables related PHP Version: 4.0.4pl1 Assigned To: Comments: think about cookies the same way as GET data or POST data - they are at the same level and can be spoofed very easy with a cURL client for example. one can tell his client what cookie with what value to pass for a given request the issue here is not security but programmers comfort. but when one uses the short representations of variables she must be aware of the GPC order setting. i think this is the same like overriding a post variable with a get one. do you think this bug shall be closed? Previous Comments: --- [2001-04-26 21:35:49] [EMAIL PROTECTED] If you access this page with the command line arguement ?cookie[three]=three print_r will show cookie[three] in $HTTP_COOKIE_VARS. Just a bit of incongrous material, but for some sites could cause problems if cookies are spoofed thusly. Regards --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10519&edit=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] Bug #8621 Updated: be careful with interactive cmd line mode
ID: 8621
Updated by: bbonev
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Reproduceable crash
PHP Version: 4.0.3pl1 - 4.0.6-dev
Assigned To:
Comments:
date: Sun Apr 29 19:59:15 EEST 2001
cvs up
./cvsclean
./buildconf
./configure
make
gdb
file ./php
set args -a
run
Interactive mode enabled
X-Powered-By: PHP/4.0.6-dev
Content-type: text/html
Program received signal SIGSEGV, Segmentation fault.
0x80c09b9 in _zval_ptr_dtor (zval_ptr=0x8169130) at zend_execute_API.c:259
259 (*zval_ptr)->refcount--;
(gdb) bt full
#0 0x80c09b9 in _zval_ptr_dtor (zval_ptr=0x8169130) at zend_execute_API.c:259
zval_ptr = (zval **) 0x8169130
#1 0x80c9d81 in zend_hash_destroy (ht=0x813dfac) at zend_hash.c:560
ht = (HashTable *) 0x813dfac
p = (Bucket *) 0x0
q = (Bucket *) 0x8169124
#2 0x80c085a in shutdown_executor () at zend_execute_API.c:165
No locals.
#3 0x80c6c7f in zend_deactivate () at zend.c:536
No locals.
#4 0x805e89e in php_request_shutdown (dummy=0x0) at main.c:660
No locals.
#5 0x805dc9e in main (argc=2, argv=0xb904) at cgi_main.c:768
exit_status = 0
cgi = 0
c = 31
i = -1073743732
len = 135668168
file_handle = {type = 2 '\002', filename = 0x80f2885 "-", opened_path = 0x0,
handle = {fd = 1075232896,
fp = 0x4016c080}, free_filename = 0 '\000'}
s = 0x81621c8 ""
behavior = 1
no_headers = 0
orig_optind = 1
orig_optarg = 0x0
argv0 = 0x0
script_file = 0x0
global_vars = {head = 0x0, tail = 0x0, size = 4, dtor = 0, persistent = 0
'\000', traverse_ptr = 0x4000aa70}
interactive = 1
#6 0x400a1577 in __libc_start_main () from /lib/libc.so.6
Previous Comments:
---
[2001-04-29 12:00:19] [EMAIL PROTECTED]
user reports:
bbonev@orange:~/php/php4$ ./php -a
Interactive mode enabled
X-Powered-By: PHP/4.0.6-dev
Content-type: text/html
Segmentation fault
bbonev@orange:~/php/php4$
it still exists, maybe this does not crash on win32?
what about interactive mode with win32 cgi php? i am not sure but it may be
handled differently on *nix and win32
---
I tried this on Linux, and it didn't segfault for me.
Can you make a backtrace of it and add it here?
---
[2001-04-28 14:20:53] [EMAIL PROTECTED]
I can not reproduce this with the latest CVS (28/04/2001)
so closing.
---
[2001-01-10 15:47:04] [EMAIL PROTECTED]
really i think that merely noone cares about interactive mode but... problem exists in
latest CVS:
Interactive mode enabled
X-Powered-By: PHP/4.0.5-dev
Content-type: text/html
Segmentation fault
---
[2001-01-09 18:26:15] [EMAIL PROTECTED]
tst.php:
php -a tst.php
produces:
Interactive mode enabled
X-Powered-By: PHP/4.0.3pl1
Content-type: text/html
Segmentation fault
---
another command line example:
php -a
Interactive mode enabled
X-Powered-By: PHP/4.0.3pl1
Content-type: text/html
Segmentation fault
same result with 4.0.4 soon will test with latest CVS
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8621&edit=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] Bug #10510 Updated: ini_set() as relates to max upload filesize setting
ID: 10510 Updated by: bbonev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: *Function Specific PHP Version: 4.0.4pl1 Assigned To: Comments: Please take into account that the processing of post data happens _before_ your call to ini_set. Thus your new limit value has no effect to the upload and succeeds (of course) after the upload is rejected. I would recommend setting the value through .htaccess or apache's config. Previous Comments: --- [2001-04-26 09:58:38] [EMAIL PROTECTED] First, let me say that I'm not entirely sure I would class this report as a bug, but it very well could be. Recently, as in yesterday, I spent a number of hours trying to find a work-around to the maximum upload filesize setting. I came across the ini_set() functions. This appeared to be something of a solution to the delimma, by issuing a ini_set() to the max upload filesize, I figured I would be able to conduct a file upload that exceeded the default 2M limit. It would appear that I was wrong. Here is the situation which presented itself, and ultimately will explain why I'm emailing as a bug report. The Scenario - My script resides on a "hosted" server, one which is beyond my direct control. Naturally the host controls the settings, and the like. I needed to conduct file uploads, which may or may not exceed the default limit. After reviewing the manual, I found the ini_set functions. So, I decided to test the over-ride of the ini's setting for a max upload filesize. For test purposes, we chose 4M, and issued an ini_set() to PHP. The set was successful, and our local value for the max upload filesize was 4M. No problem, this is awesome I thought to myself, so we moved forward and attempted to upload, using a "file" field named file_url. The end result was just un-real. We selected a file that weighed in at approx. 2.2MB just .2 over the default limit, but well within our defined max size. We watched our modems and bandwidth meters, seeing the transmit of the file to the server... (we think all is going sweetly).. then, nothing. PHP gave no errors, as a matter of fact the script executed perfectly. cept that the value of file_url became "none".. obviously something went wrong.. Here's what we ultimately discovered. 1) "IF" the file exceeded 2M (the default) the value of the file field is stripped and returns as "none" (as if no file was uploaded). 2) PHP Gives no "limit exceeded" error, or any errors for that matter. 3) "IF" the file is below the 2M limit, all is perfect. In short, it would appear that the ini_set(), though it displays as being set, has no real affect. Bug? I don't know.. I do however feel, that at the very least, PHP should give us some type of error message.. In the end, I'm left with the feeling that one of two possiblities exist here, 1) the ini_set() function holds no real coding value, or 2) I don't fully understand the function. Granted, documentation is somewhat limited on these.. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10510&edit=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] Bug #10501 Updated: array_sumn causes segfault when used with unset vars
ID: 10501 Updated by: bbonev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Unknown/Other Function PHP Version: 4.0.4pl1 Assigned To: Comments: this is fixed in CVS, wait for 4.0.5 $ ./php X-Powered-By: PHP/4.0.5RC6 Content-type: text/html Warning: The argument to array_sum() should be an array in - on line 3 Previous Comments: --- [2001-04-25 20:12:39] [EMAIL PROTECTED] causes a seg fault because $test is not set. no error is given in the log files or on screen. only apache's error_log shows a segfault. Chris Lee [EMAIL PROTECTED] --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10501&edit=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 #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: 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_execut
[PHP-DEV] PHP 4.0 Bug #10136 Updated: Function mail() does not work properly
ID: 10136
Updated by: bbonev
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Mail related
Assigned To:
Comments:
i'd suggest one thing - try this (it will give more light if the problem is in your
mailserver):
telnet localhost 25
helo there
mail from: [EMAIL PROTECTED]
rcpt to: [EMAIL PROTECTED]
data
from: "your name" <[EMAIL PROTECTED]>
to: "name 1" <[EMAIL PROTECTED]>, "name 2" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
subject: some subject
some nice body
Previous Comments:
---
[2001-04-03 09:57:57] [EMAIL PROTECTED]
First, I tried making mail() function work() on a Win2k - IIS 5.0 server and on
Win98SE - Apache 1.3.19 both with PHP 4.0.4pl1.
there are several things wrong (so far it wouldn't be me the problem ;-) ) :
- first :
mail ("Arnaud <[EMAIL PROTECTED]>","A subject here","A message body here",...);
(as mentioned in PHP manual), It won't work, i have a "Warning: Server error on
blabla.php3:lineXX" but if the "To:" Field is replace by just an email adress :
mail("[EMAIL PROTECTED]",); this would work... So I can't send mails with the name
of the recipients properly set (just their email adress)...
NB: Multiple "To:" Recipients works but only with email adresses
That's not the most important problem for me, the most important is Cc: and Bcc: won't
work.
The manual mentions to add From: Cc: and Bcc: information, in the fourth parameters
(the headers)... So I tried :
mail("[EMAIL PROTECTED]","A subject here","A (very nice !) body here","From: The
Administrator <[EMAIL PROTECTED]>nBcc: My Friend <[EMAIL PROTECTED]>nCc: My Father
<[EMAIL PROTECTED]>");
it obviously doesn't work :-(( (that's why I'm writing you !!)
There are several things to say :
- The From: section of headers works well, nothing to say about it... No problem
- Seems the Bcc: part is just ignored, nothing happen, no mail is sent to Bcc: address
- For Cc:, when typed "cc:" (all lowercase) seems to be ignored but when typed "Cc:"
=> It looks like there is a memory leak or something like that both IIS and Apache
return me a "emalloc() : unable to allocate -851230 bytes"... The number of
unallocated bytes is not ever the same but this is the same error message...
Extra info :
- On both config, the mail server is a local mail server (FTGate 2.2.2.1)
- It seems that this bug is similar to #9858 and #9859 in the bug database
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10136&edit=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 #9528 Updated: /home/sas/src/php4/ext/standard/url_scanner_ex.re ... permission denied
ID: 9528 Updated by: bbonev Reported By: [EMAIL PROTECTED] Old-Status: Feedback Status: Closed Bug Type: Compile Failure Assigned To: Comments: you can safely remove or comment #line-s and recompile. eighter you are using solaris native cc or your gcc is too old (not a problem by itself) new versions of gcc do not complain on #line with nonexistent path Previous Comments: --- [2001-03-03 16:59:46] [EMAIL PROTECTED] Are you sure you're using the php4.0.4pl1 source tarball from www.php.net?? I just checked that file and it doesn't have any #line directives in it. --Jani --- [2001-03-02 14:04:44] [EMAIL PROTECTED] the following is the second line of the file [path-to-php]/ext/standard/url_scanner_ex.c : #line 1 "/home/sas/src/php4/ext/standard/url_scanner_ex.re" the line above and below are comments, and are remarked correctly for a c program with /* and */ unfortunately, the gcc compiler tries to interpret the offending line that begins with a shell script comment symbol and pukes upon the encounter. I'm not a programmer, but when I added the correct comments around the text and ran make install again, it finished neatly and without incident. Sincerely, Rick Dettwyler --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9528&edit=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 #9515 Updated: PHP misbehaves when run as a script with SERVER_NAME environment variable def'd
ID: 9515 Updated by: bbonev Reported By: [EMAIL PROTECTED] Status: Open Old-Bug Type: Scripting Engine problem Bug Type: Feature/Change Request Assigned To: Comments: ooops. forgot to change type - this is expected behav, not a problem Previous Comments: --- [2001-03-01 22:57:18] [EMAIL PROTECTED] a working setup is: ScriptAlias /cgi-bin/ /home/someuser/cgi-bin/ AddType application/x-httpd-php .php AddHandler php-script .php Action php-script /cgi-bin/php a way to solve the SERVER_NAME, PATH_INFO, etc. vars problem is to make an 'unset' wrapper. plase note that when these vars are set php will get the script name to execute from them. if for instance from a php script you exec (not include) another one starting with #!/path-to-php/php the latter invocation will execute the page requested by http again. there are two cases: 1) php is invoked as shell script and shall process command line only no matter what env vars are set 2) php is invoked the way described above and shall preffer env vars (for security reasons - the /cgi-bin/php/etc/passwd issue) if no - command line please note that php itself cannot distinguish those cases - #2 is the expected behaviour for all cgi setups, while IMHO #1 does not exist and may be activated through an option --- [2001-03-01 19:01:27] [EMAIL PROTECTED] In order to run a php script under a separate account while serving a web page, I use suexec to run php script as a shell. Problem: When the environment variable SERVER_NAME is defined, PHP misbelieves that it is NOT a shell script. In reality, it is a shell script. Bug 8898 is more less the same problem with another symptom. Some functions simply do not work correctly. GetMyUID() returns nothing when PHP is running as a shell script, but the environment variable SERVER_NAME is defined. As a last resort, an invocation flag option should be available to inform PHP that it is a shell script being invoked by a web server. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9515&edit=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 #9515 Updated: PHP misbehaves when run as a script with SERVER_NAME environment variable def'd
ID: 9515 Updated by: bbonev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Assigned To: Comments: a working setup is: ScriptAlias /cgi-bin/ /home/someuser/cgi-bin/ AddType application/x-httpd-php .php AddHandler php-script .php Action php-script /cgi-bin/php a way to solve the SERVER_NAME, PATH_INFO, etc. vars problem is to make an 'unset' wrapper. plase note that when these vars are set php will get the script name to execute from them. if for instance from a php script you exec (not include) another one starting with #!/path-to-php/php the latter invocation will execute the page requested by http again. there are two cases: 1) php is invoked as shell script and shall process command line only no matter what env vars are set 2) php is invoked the way described above and shall preffer env vars (for security reasons - the /cgi-bin/php/etc/passwd issue) if no - command line please note that php itself cannot distinguish those cases - #2 is the expected behaviour for all cgi setups, while IMHO #1 does not exist and may be activated through an option Previous Comments: --- [2001-03-01 19:01:27] [EMAIL PROTECTED] In order to run a php script under a separate account while serving a web page, I use suexec to run php script as a shell. Problem: When the environment variable SERVER_NAME is defined, PHP misbelieves that it is NOT a shell script. In reality, it is a shell script. Bug 8898 is more less the same problem with another symptom. Some functions simply do not work correctly. GetMyUID() returns nothing when PHP is running as a shell script, but the environment variable SERVER_NAME is defined. As a last resort, an invocation flag option should be available to inform PHP that it is a shell script being invoked by a web server. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9515&edit=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 #9462 Updated: NULL bute eats rest of string
ID: 9462 Updated by: bbonev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Filesystem function related Assigned To: Comments: just error reporting functions are not binary safe. although i do not see a reason to open a file containing a null char in the name - most OSes will get the part before the first null char. lets call it bug because current behav doesn't help enough to track the problem Previous Comments: --- [2001-02-26 09:17:33] [EMAIL PROTECTED] I'm not sure if this is a bug or feature, comments are apreciated. http://bugs.horde.org/show_bug.cgi?id=621 Example: include($string . ".php"); with "magic_quotes_gpc = On" (php.ini) calling test.php?string=test%00 result: Warning: Failed opening 'test -- 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 #9231 Updated: when usign ob_gzhandler HTTP HEAD does not work
ID: 9231 Updated by: bbonev Reported By: [EMAIL PROTECTED] Old-Status: Bogus Status: Open Bug Type: Output Control Assigned To: Comments: reopened Previous Comments: --- [2001-02-17 11:50:18] [EMAIL PROTECTED] HTTP-1.0 and HTTP/1.0 are just the same for apache this bug report says that ob_gzhandler crashes HEAD requests when php is an apache module --- [2001-02-14 12:25:12] [EMAIL PROTECTED] shouldn't it reaad HEAD / HTTP/1.0 bogus --- [2001-02-12 15:05:20] [EMAIL PROTECTED] php.ini: output_handler = ob_gzhandler tests: a plain html request: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. HEAD / HTTP-1.0 HTTP/1.1 200 OK Date: Mon, 12 Feb 2001 19:57:47 GMT Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev Last-Modified: Mon, 04 Dec 2000 13:01:35 GMT ETag: "ac04-1f6-3a2b95af" Accept-Ranges: bytes Content-Length: 502 Connection: close Content-Type: text/html Connection closed by foreign host. php script request: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. HEAD / HTTP-1.0 host: mail.bonev.com same php script, but now GET instead of HEAD: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. GET / HTTP/1.0 host: mail.bonev.com HTTP/1.1 302 Found Date: Mon, 12 Feb 2001 19:57:22 GMT Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev X-Powered-By: PHP/4.0.5-dev location: /6bcf63364235c745643078ff1e0df2d6/ Connection: close Content-Type: text/html Connection closed by foreign host. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9231&edit=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 #9043 Updated: popen returns a 'Resource id #' (non null) when process cannot be created.
ID: 9043 Updated by: bbonev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Directory/Filesystem functions Assigned To: Comments: confirmed on linux both php4.0.3pl1 and latest CVS Previous Comments: --- [2001-02-01 00:16:30] [EMAIL PROTECTED] n"; ?> Returns the following: Result is Resource id #1 --- Full Bug description available at: http://bugs.php.net/?id=9043 -- 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]
