Bug #15805 Updated: Use undefined global variable in function - not warning
ID: 15805 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows 2000 PHP Version: 4.1.1 New Comment: OK, command global may define variable, but if global variable that name is not defined, PHP write this to output (if E_NOTICE is enabled). Without this debugging code from example is dificult. Previous Comments: [2002-03-01 03:37:52] [EMAIL PROTECTED] Expected behaviour. Global defines that variable. [2002-03-01 03:10:29] [EMAIL PROTECTED] I try use global variable in function. When variable is not defined and I have set error_reporting to E_ALL, PHP doesn't report, that variable is not defined, but silently define it. Is this problem known? -- Edit this bug report at http://bugs.php.net/?id=15805&edit=1
Bug #15303 Updated: Error compiling
ID: 15303 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: rocklinux 1.4 PHP Version: 4.1.1 New Comment: same thing with php version 4.1.2 and gd 1.8.4 Previous Comments: [2002-02-03 07:09:34] [EMAIL PROTECTED] that was the wrong message. [2002-02-03 07:08:53] [EMAIL PROTECTED] The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". [2002-01-30 16:31:10] [EMAIL PROTECTED] Hello Dont know if this is a gd or php issus. I downloaded gd to have it to work with gd cause i wanted to generate alpha blending images on the fly. therefore i choosed the 2.0.1 beta build. When i compile gd everything is allright but when i try to compile php i get this error message gcc -I. -I/usr/src/php-4.1.1/ext/gd -I/usr/src/php-4.1.1/main -I/usr/src/php -4.1.1 -I/usr/src/php-4.1.1/Zend -I/usr/src/php-4.1.1/ext/mysql/libmysql -I/ usr/src/php-4.1.1/ext/xml/expat -I/usr/src/php-4.1.1/TSRM -g -O2 -c gd.c && touch gd.lo In file included from /usr/include/gd.h:25, from php_gd.h:33, from gd.c:36: /usr/include/gd_io.h:21: undefined or invalid # directive In file included from gd.c:36: php_gd.h:69: warning: static declaration for `gdImageColorResolve' follows non-static gd.c:92: conflicting types for `gdIOCtx' /usr/include/gd_io.h:18: previous declaration of `gdIOCtx' make[3]: *** [gd.lo] Error 1 make[3]: Leaving directory `/usr/src/php-4.1.1/ext/gd' The only option i have supplied is ./configure --with-gd Im using rocklinux 1.4 and have tried to download and install zlib libpng libjpeg freetype several times. Whats wrong? Should i send a bugreport to php or is this a gd issue? Thanx for a good software /Alexander -- Edit this bug report at http://bugs.php.net/?id=15303&edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529
Updated by: [EMAIL PROTECTED]
-Summary: script doesn't always finish output
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.1.2
New Comment:
Can you please try a shapshot from snaps.php.net, my guess is that this
is already fixed.
Derick
Previous Comments:
[2002-03-04 00:55:05] [EMAIL PROTECTED]
It looks you are having session bug.
It seems you are unset()ing $HTTP_SESSION_VARS or $_SESSION somewhere
in your script, aren't you?
[2002-03-03 21:12:33] [EMAIL PROTECTED]
I'm seeing the same problem with 4.1.2. Can reproduce, but with no
consistency.
I'm also seeing a problem where PHP isn't responded to POSTs (watching
it in ethereal, I had to post
repeatedly to get a response; the responding page was to set a couple
cookies and do a redirect). Any
possibility that they might be related?
(Had added a comment with a backtrace, but this one looks much more
useful):
#0 0x402ad693 in _zend_is_inconsistent (ht=0x0,
file=0x403fcb84 "zend_hash.c", line=975) at zend_hash.c:84
#1 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x0,
pos=0xb090)
at zend_hash.c:975
#2 0x4031da18 in php_session_save_current_state () at session.c:544
#3 0x40320579 in php_session_flush () at session.c:1381
#4 0x403205bd in zm_deactivate_session (type=1, module_number=3)
at session.c:1393
#5 0x402ac614 in module_registry_cleanup (module=0x8054dc8) at
zend_API.c:1165
#6 0x402af394 in zend_hash_apply (ht=0x404808c0,
apply_func=0x402ac5d0 ) at
zend_hash.c:669
#7 0x402a8a4e in zend_deactivate_modules () at zend.c:585
#8 0x402b9eb0 in php_request_shutdown (dummy=0x0) at main.c:723
#9 0x402b63ff in apache_php_module_main (r=0x80ab44c,
display_source_mode=0)
at sapi_apache.c:96
#10 0x402b71d0 in send_php (r=0x80ab44c, display_source_mode=0,
filename=0x80ab9cc "/usr/local/apache/htdocs/planworld/index.php")
at mod_php4.c:575
#11 0x402b724c in send_parsed_php (r=0x80ab44c) at mod_php4.c:590
#12 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1
#13 0x400630b9 in ?? () from /lib/libdb.so.3
#14 0x40063529 in ?? () from /lib/libdb.so.3
#15 0x400354e2 in ?? () from /lib/libcrypt.so.1
#16 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1
#17 0x400630b9 in ?? () from /lib/libdb.so.3
#18 0x4006312f in ?? () from /lib/libdb.so.3
#19 0x4005910d in _ufc_foobar () from /lib/libcrypt.so.1
#20 0x400592e3 in _ufc_foobar () from /lib/libcrypt.so.1
#21 0x40059476 in _ufc_foobar () from /lib/libcrypt.so.1
#22 0x40059c34 in _ufc_foobar () from /lib/libcrypt.so.1
#23 0x4005a645 in _ufc_foobar () from /lib/libcrypt.so.1
#24 0x80486dd in ?? () from /usr/local/apache/libexec/mod_caucho.so
#25 0x401589cb in __gconv_transform_internal_utf16 (step=0x80486c0,
data=0x2,
inbuf=0xbaa4, inbufend=0x8048560 "U\211åSè",
written=0x804877c,
do_flush=1073786464) at ../iconv/loop.c:151
[2002-03-03 20:56:34] [EMAIL PROTECTED]
I've been seeing the same thing in 4.1.2. In some cases, it partially
displays pages. In others (I think
this may be related), it doesn't acknowledge a POST until it's been
submitted multiple times (3 or 4
generally). Both behaviors are very inconsistent (they happen
frequently on a site with moderate use, but I
can't reproduce them).
Here's a backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x403fcb84 "zend_hash.c", line=975) at zend_hash.c:84
84 if (ht->inconsistent==HT_OK) {
(gdb) bt
#0 0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x403fcb84 "
>ýÿþ>ýÿýÿ\025?ýÿG?F?ýÿýÿk?l?\205uTvýÿÌ?ýÿUvýÿË?§v¨vù?ýÿýÿýÿýÿx@z@u@ýÿv@w@ýÿýÿê@î@í@ýÿì@\017yýÿýÿ\204A\205A\203Aýÿ¼A½AÔAýÿýÿýÿýÿUBýÿPBLBHBýÿSBýÿWBTBNBJBQBýÿýÿIBKBcBýÿýÿ§B¦B¤Býÿýÿýÿä|å|ýÿýÿe~N~\027Cýÿ\026CýÿýÿcCýÿýÿ\202\177ýÿ{C|Cýÿ"...,
line=975) at zend_hash.c:84
#1 0x4046b258 in ?? () from /usr/local/apache/libexec/libphp4.so
#2 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x5a5a5a5a,
pos=0xb090) at zend_hash.c:975
First symbol in segment of executable not a source symbol
[2002-02-28 17:15:48] [EMAIL PROTECTED]
Regarding the configure line and your MySQL problems. You should NEVER
(okay this is my opinion) use the bundled MySQL libs. On your
configure line you should do
--with-mysql=/usr | --with-mysql=/usr/local
Just depends on where it put your libs, which you can find like so
[root@somemachine /]# ldconfig -p | grep mysql
libmysqlclient.so.10 (libc6) =>
/usr/local/lib/mysql/libmysqlclient.so.1
Bug #15853 Updated: Problem with Chop function :: Apache/PHP crashes with Dr. Watson error
ID: 15853 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Strings related Operating System: Windows NT Service Pack 6 PHP Version: 4.1.1 New Comment: Can you post a reproducing script? Previous Comments: [2002-03-04 03:04:46] [EMAIL PROTECTED] Hi, The problem is bit vagarious and sometimes is not reproducible too. deepak [2002-03-04 03:01:12] [EMAIL PROTECTED] Hi, I am encountering this strange problem whilst using chop() function in PHP to trim some specified characters from the trailing part of the string. PHP Manual says that chop and rtrim are aliases of each other. But when I use chop() function, Apache crashes with a Dr. Watson Error message. My PHP is configured for a SAPI dll use with Apache as against CGI solution. When I reconfigured my Apache to use PHP as CGI, the error message was different. PHP crashes with a Dr. Watson Error (OleWnd...) and Apache reports a 500 Internal Server Error. I have read in some Perl book that chop is a function in Perl. I doubt whether to use chop function, any implementation of Perl is needed. Please help... Deepak -- Edit this bug report at http://bugs.php.net/?id=15853&edit=1
Bug #15854: allow_url_fopen setting in php.ini ignores the false INI constants
From: [EMAIL PROTECTED]
Operating system: Linux Mandrake 7.2
PHP version: 4.0.6
PHP Bug Type: *General Issues
Bug description: allow_url_fopen setting in php.ini ignores the false INI constants
Before:
The output of phpinfo(), in the "Configuration - PHP Core" section, for
the "allow_url_fopen" directive says "no value" for both "Local Value" and
"Master Value".
Aim:
To set the allow_url_fopen to say off / disabled, as opposed to "no
value", for a more secure PHP installation.
Changes made:
To the /etc/php.ini, tried adding the following lines, one at a time, then
restarting the web server, then checking the output of phpinfo():
allow_url_fopen = False ;
allow_url_fopen = false ;
allow_url_fopen = Off ;
allow_url_fopen = off ;
After:
The output of phpinfo(), in the "Configuration - PHP Core" section, for
the "allow_url_fopen" directive _still_ says "no value" for both "Local
Value" and "Master Value" in all of the above cases.
What _does_ fix this problem:
Using the integer value, like so:
allow_url_fopen = 0 ;
In this case the value prints as "0".
What does work as expected:
Basically, all the true cases that I tried, namely:
allow_url_fopen = 1 ;
allow_url_fopen = True ;
allow_url_fopen = true ;
allow_url_fopen = On ;
allow_url_fopen = on ;
In all of these cases the value prints as "1".
Why this is a problem:
Besides being completely inconsistent, it also does not comply with the
documentation:
The php.ini file says this:
> The value can be a string, a number, a PHP constant (e.g. E_ALL or
M_PI), one
> of the INI constants (On, Off, True, False, Yes, No and None) or an
expression
> (e.g. E_ALL & ~E_NOTICE), or a quoted string ("foo").
Furthermore many of the values in the php.ini file are either "On" or
"Off". Most normal people would thus quite reasonably assume that the same
consistent syntax would also work for allow_url_fopen, and it does, but
only if you want to enable it, not if you want to disable it (which is
what most people would probably want to do) [**bangs head repeatedly
against table**].
Answers to the questions I expect you to ask:
There is no duplicate existing line that is overwriting the value of the
allow_url_fopen directive, as evidenced by this:
===
[root@dev ~]# grep -i "fopen" /etc/php.ini
; prevent the URL-aware fopen wrappers from accessing URL objects
allow_url_fopen = 0 ;
===
I know that I am editing the correct php.ini file, because it can be made
to work, but only if I change the value to any true/on/1 value, or to 0.
This is not a brand new problem. The same problem happened in PHP 4.04pl1,
but I gave up looking harder at it then when I could not get "False" or
"Off" to work straight away. I had hoped that upgrading to PHP 4.06 might
make it go away, but no joy. I only found that 0 or 1 work out of an
annoyed determination to try everything when upgrading to 4.06 due to
recent security updates.
Evidence that this has bit other people in the ass too:
I have searched the PHP bugs database, and noticed that someone else has
experienced something similar, but it is included as a side note in a bug
report (not as the main content):
http://bugs.php.net/?id=12748
The reporter of that bug (#12748) wrote:
> When I leave out the setting in httpd.conf, and just have
> "allow_url_fopen = Off" in the php.ini file, phpinfo() has
> "no value" written for the Master Value and Local Value.
Recommendation:
_Please_ fix the "allow_url_fopen" directive to work with _all_ the INI
constants - namely "On, Off, True, False, Yes, No".
My configuration information:
These PHP packages are using the distro's RPMs, namely:
php-4.0.6-5.7mdk.i586.rpm, php-common-4.0.6-5.7mdk.i586.rpm,
php-devel-4.0.6-5.7mdk.i586.rpm
Am I willing to update to whatever the latest and greatest PHP version is
right now?:
Absolutely not. I've got what I have to work, but I want to stop this from
being a problem for anyone else (or myself in two year's time).
The top bit of phpinfo() shows this:
===
PHP Version 4.0.6
System Linux updates.mandrakesoft.com 2.4.8-34.1mdkenterprise #1 SMP Mon
Nov 19 11:56:45 MST 2001 i686 unknown
Build Date Feb 27 2002
Configure Command './configure' '--disable-static' '--disable-debug'
'--disable-rpath' '--enable-pic' '--enable-inline-optimization'
'--prefix=/usr' '--with-zlib' '--with-config-file-path=/etc'
'--enable-magic-quotes' '--enable-debugger' '--enable-track-vars'
'--enable-safe-mode' '--with-exec-dir=/usr/bin' '--with-regex=system'
'--with-versioning' '--enable-sysvsem' '--enable-sysvshm'
'--with-mod_charset' '--enable-force-cgi-redirect' '--with-mm'
'--enable-trans-sid' '--with-dbase' '--with-filepro' '--enable-yp'
'--enable-ftp' '--with-xml' '--with-gettext' [Some modules are
external: look for packages php-pgsql,php-mysql,...]
Server API Apache
Virtual Direct
Bug #15841 Updated: CRLF to separate mail headers is incorrect
ID: 15841 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Mail Related Operating System: Linux PHP Version: 4.1.2 New Comment: on windows we *do* talk STMP ... Previous Comments: [2002-03-03 16:27:44] [EMAIL PROTECTED] This is causing mail generated by PHP to be BLOCKED as being potentially a virus by some anti-virus SMTP servers. The presence of "\r\n" in headers is typically a sign of a virus trying to reach Outlook. Some antivirus products now totally block MIME mail containing "\r\n". This means all mail generated by PHP programs... [2002-03-02 20:05:00] [EMAIL PROTECTED] Last November the mail documentation was changed from saying: "Multiple extra headers are separated with a newline." to: "Multiple extra headers are separated with a carriage return and newline. Note: You must use \r\n to seperate headers, although some Unix mail transfer agents may work with just a single newline (\n)." This change is inaccurate. Line breaks in headers should be the native line endings for the system on which PHP is running. The mail() function is not talking to an SMTP server, so RFC2822 does not apply here. mail() is talking to a command line program on the local system, and it is reasonable to expect that program to require system-native line breaks. Use of CRLF is known to break qmail systems where no conversion of line breaks occurs on the input data. In this case using CRLF causes all but the first extra header to appear in the message body (CRLF is interpreted as two line breaks). Possibly the best resolution to this problem would be for the mail() function to convert any line breaks in arg 4 into the system's native line breaks. -- Edit this bug report at http://bugs.php.net/?id=15841&edit=1
Bug #13472 Updated: input type=hidden should be in a fieldset if there is one
ID: 13472 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Session related Operating System: Any PHP Version: 4.0.6 New Comment: as a workaround in php.ini: url_rewriter.tags = "...,form=fakeentry" change it to url_rewriter.tags = "...,form=action" to have the id added to the action url instead of being added as a hidden field gives you legal xhtml, but session id is always a GET parameter, even with method=POST ... Previous Comments: [2002-03-03 08:08:25] [EMAIL PROTECTED] Notice .. any blocklevel tag is affected .. not just fieldset and as such any solution to this problem should take this issue into account. [2002-03-03 08:04:33] [EMAIL PROTECTED] I could not find any suitable workaround :( I hope this will be fixed soon, cause this is really killing me... [2002-03-03 07:34:13] [EMAIL PROTECTED] anyone know how long before this is fixed or if there is any known workaround? [2001-12-07 09:16:24] [EMAIL PROTECTED] Reclassified back to session-related because Yasuo persuaded me to call it a bug ;) [2001-12-05 13:22:53] [EMAIL PROTECTED] hum... not a bug ? PHP is not rewriting html code well, so I'd call it a bug :-) Anyway... any chance to get it fixed soon ? That shouldnt be /that/ hard to do, since you just have to write the input after the first fieldset if there is one, or jst after the form is there isnt any... 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/13472 -- Edit this bug report at http://bugs.php.net/?id=13472&edit=1
Bug #15855: problems with sending data
From: [EMAIL PROTECTED] Operating system: windows 95 PHP version: 4.1.1 PHP Bug Type: Session related Bug description: problems with sending data Using php 4.1.1 on windows 95, there is this problem: suppose you make a link of this type: http://localhost/show.php?code=3";>; if you write "echo $code" in page show.php, nothing is printed on the output! -- Edit bug report at http://bugs.php.net/?id=15855&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15855&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15855&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15855&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15855&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15855&r=support Expected behavior: http://bugs.php.net/fix.php?id=15855&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15855&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15855&r=submittedtwice
Bug #15855 Updated: problems with sending data
ID: 15855 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: windows 95 PHP Version: 4.1.1 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-03-04 05:44:41] [EMAIL PROTECTED] Using php 4.1.1 on windows 95, there is this problem: suppose you make a link of this type: http://localhost/show.php?code=3";>; if you write "echo $code" in page show.php, nothing is printed on the output! -- Edit this bug report at http://bugs.php.net/?id=15855&edit=1
Bug #15778 Updated: Segmentation Fault with iPlanet module on php4_init
ID: 15778 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: AIX 4.3.3 PHP Version: 4.1.2 New Comment: Bug verified and still present in snapshot "php4-20020304" on AIX 4.3.3 and iPlanet 4.1 Previous Comments: [2002-03-01 12:27:31] [EMAIL PROTECTED] Ok, as another test, Ive tried to compile PHP 4.1.2 on the same AIX 4.3.3 box, but now as an Apache 1.3.22 DSO module, and that seems to work just fine. And since ive got the same php version (4.1.1 & 4.1.2) in combination with the same iPlanet version (4.1) running correctly on Linux, I guess this means that this only occurs on this specific combined setup: AIX 4.3.3 iPlanet 4.1 PHP 4.1.1 & 4.1.2 (at least, maybe other versions too) [2002-02-28 06:13:51] [EMAIL PROTECTED] As a test, Ive tried compiling the same version of PHP in combination with the same version of iPlanet on my linux system, and everything seems to work fine on my linux box. So I guess this only occurs in combination with AIX. [2002-02-28 06:04:27] [EMAIL PROTECTED] When I compile PHP as an iPlanet module, the httpd server crashes on loading the module (php4_init) with a signal 11/segmentation fault. I get the same behaviour with php 4.1.1 and with 4.1.2. (output below is from 4.1.2) When compiling as a commandline executable, everything seems to work fine though, so I guess its a problem with iPlanet and maybe in combination with AIX 4.3.3 and shared libraries. I compiled using GCC, not AIX's 'native' compiler. If more information is needed to address this issue, please let me know. Please be aware though, that even though I am decently skilled in *nix administration, I have no programming or debugging skills, so please provide 'idiot instructions' ;) The configure line I used: ./configure --with-nsapi=/appl/netscape4/server4 --prefix=/appl/php -exec-prefix=/appl/php --enable-debug The output of gdb (bt): # gdb /appl/netscape4/server4/bin/https/bin/ns-httpd /appl/netscape4/server4/https-splu9029/config/config/core GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-ibm-aix4.3.2.0"...(no debugging symbols found)... Core was generated by `ns-httpd'. Program terminated with signal 11, Segmentation fault. (no debugging symbols found)...#0 0xd1541508 in php4_init (pb=0x5, sn=0x0, rq=0x0) at nsapi.c:492 492 log_error(LOG_INFORM, "php4_init", sn, rq, "Initialized PHP Module\n"); (gdb) bt #0 0xd1541508 in php4_init (pb=0x5, sn=0x0, rq=0x0) at nsapi.c:492 #1 0xd0d9aca8 in func_native_pool_wait_work () #2 0xd0d9bd88 in func_exec_str () #3 0xd0d9b2b4 in INTfunc_exec () #4 0xd0d8eea0 in INTconf_run_late_init_functions () #5 0xd0e11d50 in DaemonProcessorUX::__ct () #6 0xd0e105fc in DaemonProcessor::NewDaemonProcessor () #7 0xd0e41640 in daemon_run () #8 0x10001bac in ?? () from /appl/netscape4/server4/bin/https/bin/ns-httpd -- Edit this bug report at http://bugs.php.net/?id=15778&edit=1
Bug #14861 Updated: nlist and rawlist don`t work with ftp-daemon of Suse
ID: 14861
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: FTP related
Operating System: Linux and W2K
PHP Version: 4.1.1
New Comment:
I have found a workaround: If you try to get a file in binary mode
befor you try to get the list, you would get a list.
This also work if the file you order with ftp_get is not there.
Previous Comments:
[2002-01-19 17:34:26] [EMAIL PROTECTED]
Hello?
[2002-01-05 07:05:07] [EMAIL PROTECTED]
Hello,
I tried to use PHP4.1.1, but there was the same Problem. Then I tried
again to resolve the problem by my self, and it works! But I don't
know if it is OK in connection with other FTP-server and want to use
my Script with several FTP-server on several plattforms. I made the
following modifaktion in file ftp.c.
Line 1226:
if (*ptr == '\n' )
Line 1254:
if (ch == '\n' ) {
Can you use this for the standard? So that I can use the next Version?
Thanhs, Bernd
[2002-01-04 18:56:14] [EMAIL PROTECTED]
Please test 4.1.1 and see if the problem still exists.
[2002-01-04 17:40:11] [EMAIL PROTECTED]
Hello,
I tried to user ftp_nlist to get an directory-listing of an Suse7.1
ftp-Server, but the function returns nothing.
I tried the same code to connect to an ftp-server on an
Windows-System.
To analyse the problem I made some printentries in the file ftp.c. I
edited
the file in the array of line 1195. I think that here is one problem:
the code expect "\r" and "\n", but only retrieves "\n".
Here is the code:
while ((ch = getc(tmpfp)) != EOF) {
printf("%d ",ch);
/*
if (ch == '\n' && lastch == '\r') {
*/
if (ch == '\n' ) {
*(text - 1) = 0;
printf("\nText:%s\n\n", text);
*++entry = text;
}
else {
*text++ = ch;
}
lastch = ch;
}
*entry = NULL;
if (ferror(tmpfp))
goto bail;
fclose(tmpfp);
if (!ftp_getresp(ftp) || (ftp->resp != 226 && ftp->resp != 250)) {
free(ret);
return NULL;
}
printf("ret[0]:%s\n", ret[0]);
printf("ret[1]:%s\n\n", ret[1]);
return ret;
And here is the output from my PHP-Script:
X-Powered-By: PHP/4.0.6
Content-type: text/html
45 114 119 45 114 45 45 114 45 45 32 32 49 32 114 111 111 116 32 32 32
114 111 111 116 32 32 32 49 54 51 57 32 68 101 99 32 50 49 32 50 51 58
51 48 32 105 99 97 112 46 112 104 112 10
Text:icap.php
-rw-r- 1 bernd users 1717 Dec 21 23:29 kal.php
45 114 119 45 114 45 45 45 45 45 32 32 49 32 98 101 114 110 100 32 32
117 115 101 114 115 32 32 49 55 49 55 32 68 101 99 32 50 49 32 50 51 58
50 57 32 107 97 108 46 112 104 112 10
Text:9 kal.php
ret[0]::¶
ret[1]:-rw-r- 1 bernd users 1717 Dec 21 23:29 kal.ph
array(2) {
[0]=>
string(4) ":¶"
[1]=>
string(52) "-rw-r- 1 bernd users 1717 Dec 21 23:29 kal.ph"
}
Thanks
Bernd
--
Edit this bug report at http://bugs.php.net/?id=14861&edit=1
Bug #15835 Updated: Problem on function gmp_invert ()
ID: 15835
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: *Math Functions
Operating System: Linux - Red Hat 7.2
PHP Version: 4.1.2
New Comment:
gmp_invert() should return the multiplicative inverse (if exist) of a
number, module something.
It's the extended Euclidean algorithm. I wrote this code and I can give
you. I think there is something wrong to gmp_invert.
Previous Comments:
[2002-03-03 06:42:28] [EMAIL PROTECTED]
I can't get gmp_invert() return anything other than false, but that
might be because I have no idea what gmp_invert() does :)
Can you supply some (human understandable) data that does work?
[2002-03-02 14:20:49] [EMAIL PROTECTED]
Example:
$x =
gmp_init("0x00d2d025ec7e1dbb6d778a52394c988594c57b47d7327a3e676d3a5ca7a5af87c4153c80994cf781f6a9d4a2f0e66d04baffb0059853a8937a895f6d17e76950e1");
// mod
$y = gmp_init("6211846575289879599"); // value
$w = gmp_invert($y,$x);
The $w value should be :
667351618289984699831448814604762419850017638123963706466136275029334435034698239463153441869117173460635003602664197747901516108936488872273669129832
[2002-03-02 13:29:43] [EMAIL PROTECTED]
Please provide a short reproducing script with values that you are
using and expected output.
Sean
[2002-03-02 11:44:47] [EMAIL PROTECTED]
The function resource gmp_invert() doesn't work right. It always return
zero.
I implemented the extended Euclides algoritm that do exactly the same
that this function and, it returned me the right value.
--
Edit this bug report at http://bugs.php.net/?id=15835&edit=1
Bug #15835 Updated: Problem on function gmp_invert ()
ID: 15835
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: *Math Functions
Operating System: Linux - Red Hat 7.2
PHP Version: 4.1.2
New Comment:
Are you sure that the extended Euclidean Algorithm does the same as
gmp_invert? The Euclidean Algorithm computes the greatest common
divisor, gmp_invert doesn't seem to do that...
Anyway, gmp_invert seems to be broken. I can't get it to return
anything else than false.
So I ask you again: can you give me some human understandable data that
works or should work?
Previous Comments:
[2002-03-04 07:30:06] [EMAIL PROTECTED]
gmp_invert() should return the multiplicative inverse (if exist) of a
number, module something.
It's the extended Euclidean algorithm. I wrote this code and I can give
you. I think there is something wrong to gmp_invert.
[2002-03-03 06:42:28] [EMAIL PROTECTED]
I can't get gmp_invert() return anything other than false, but that
might be because I have no idea what gmp_invert() does :)
Can you supply some (human understandable) data that does work?
[2002-03-02 14:20:49] [EMAIL PROTECTED]
Example:
$x =
gmp_init("0x00d2d025ec7e1dbb6d778a52394c988594c57b47d7327a3e676d3a5ca7a5af87c4153c80994cf781f6a9d4a2f0e66d04baffb0059853a8937a895f6d17e76950e1");
// mod
$y = gmp_init("6211846575289879599"); // value
$w = gmp_invert($y,$x);
The $w value should be :
667351618289984699831448814604762419850017638123963706466136275029334435034698239463153441869117173460635003602664197747901516108936488872273669129832
[2002-03-02 13:29:43] [EMAIL PROTECTED]
Please provide a short reproducing script with values that you are
using and expected output.
Sean
[2002-03-02 11:44:47] [EMAIL PROTECTED]
The function resource gmp_invert() doesn't work right. It always return
zero.
I implemented the extended Euclides algoritm that do exactly the same
that this function and, it returned me the right value.
--
Edit this bug report at http://bugs.php.net/?id=15835&edit=1
Bug #15856: SESSION DESTROY-Hangs PHP4TS.DLL- Memory leak
From: [EMAIL PROTECTED] Operating system: WINDOWS 98 PHP version: 4.1.0 PHP Bug Type: Session related Bug description: SESSION DESTROY-Hangs PHP4TS.DLL- Memory leak I use output buffering at a page start, if I start a session and do session_destory(),e.g. authentication failure, the the dll hangs with an win32 page fault. I use PHP as CGI on an apache on an wamp system. The Session Destroy is capsuled in an loginclass, -- Edit bug report at http://bugs.php.net/?id=15856&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15856&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15856&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15856&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15856&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15856&r=support Expected behavior: http://bugs.php.net/fix.php?id=15856&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15856&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15856&r=submittedtwice
Bug #15856 Updated: SESSION DESTROY-Hangs PHP4TS.DLL- Memory leak
ID: 15856 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: WINDOWS 98 -PHP Version: 4.1.0 +PHP Version: 4.1.0 + 4.11 New Comment: The PHP4TS.DLL hangs.. sorry.. Previous Comments: [2002-03-04 09:48:19] [EMAIL PROTECTED] I use output buffering at a page start, if I start a session and do session_destory(),e.g. authentication failure, the the dll hangs with an win32 page fault. I use PHP as CGI on an apache on an wamp system. The Session Destroy is capsuled in an loginclass, -- Edit this bug report at http://bugs.php.net/?id=15856&edit=1
Bug #15856 Updated: session_destroy() - hangs php4ts.dll - memory leak
ID: 15856 Updated by: [EMAIL PROTECTED] -Summary: SESSION DESTROY-Hangs PHP4TS.DLL- Memory leak Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related -Operating System: WINDOWS 98 +Operating System: Windows 98 PHP Version: 4.1.0 + 4.11 New Comment: Can you provide a simple sample script? P.S.: no I don't like caps :) Previous Comments: [2002-03-04 09:49:48] [EMAIL PROTECTED] The PHP4TS.DLL hangs.. sorry.. [2002-03-04 09:48:19] [EMAIL PROTECTED] I use output buffering at a page start, if I start a session and do session_destory(),e.g. authentication failure, the the dll hangs with an win32 page fault. I use PHP as CGI on an apache on an wamp system. The Session Destroy is capsuled in an loginclass, -- Edit this bug report at http://bugs.php.net/?id=15856&edit=1
Bug #15857: Object Overload __set __get allow set by reference
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.0CVS-2002-03-04 PHP Bug Type: Feature/Change Request Bug description: Object Overload __set __get allow set by reference The object overloading is pretty cool. However, it definately needs to support setting and getting values by reference. Thx -- Edit bug report at http://bugs.php.net/?id=15857&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15857&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15857&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15857&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15857&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15857&r=support Expected behavior: http://bugs.php.net/fix.php?id=15857&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15857&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15857&r=submittedtwice
Bug #15856 Updated: session_destroy() - hangs php4ts.dll - memory leak
ID: 15856
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Session related
Operating System: Windows 98
PHP Version: 4.1.0 + 4.11
New Comment:
Only the login function that is capsuled in the class. called on one
page the session start is before the constructor of the class...
if the login failed it passes the session_destroy...
the do login function is called after a post form...
hope that helps..
what do you mean with caps
---
function doLogin($pseudo,$pw){
global $s_userAuthorisation;
global $s_loginRetries;
if ($this->DEBUG) { echo " doLogin($pseudo,$pw)";}
$loginOk=false;
$s_userData=array();
if (!isset($s_loginRetries)){
session_register("s_loginRetries");
$s_loginRetries=0;
}
// count the retris
$s_loginRetries++;
// check pseudo
$userid=$this->getUserIdFromPseudo($pseudo);
if ($userid==0) {
if ($s_loginRetries<3) {
// nothing to do as no timeout to set
if ($this->DEBUG) {echo "Loginretries ".$s_loginRetries;}
$this->ErrorMsg="Login inkorrekt";
}
else
{
$this->ErrorMsg="10sec. Timeout 3 fehlerhafte
Loginversuche";
if ($this->DEBUG) { echo " 10sec. Timeout 3 fehlerhafte
Loginversuche";}
flush();
sleep(10);
$s_loginRetries=0;
}
}
// pseudo exist so check the login
else{
// perform the login check
$qstring = "select * ";
$qstring = $qstring." from ".$this->tablename;
$qstring = $qstring." where vch_pseudo ='".$pseudo."' ";
$qstring = $qstring." and vch_pw ='".$pw."' ";
$qstring = $qstring." and ".$this->activeRecord;
$queryst = sprintf($qstring);
$this->query($queryst);
// only one row allowed
if ($this->num_Rows()!=0) {
while($this->next_record()) {
$loginOk=true;
if ($this->DEBUG) {
echo "DOLOGINQUERYRESULT";
echo "sUserId:".$this->f("i_id")." ";
echo "sSalutationId" .$this->f("i_salutation_id")." ";
echo "sUserName" . $this->f("vch_pseudo")." ";
echo "sUniqueId". $this->f("vch_unique")." ";
echo "sEmail". $this->f("vch_email")." ";
echo "sFirstName". $this->f("vch_first_name")." ";
echo "sLastName". $this->f("vch_last_name")." ";
echo "sLastLogin". $this->f("dt_last_login")." ";
echo "sLoginSince". date("H:i:s")." ";
}
$s_userAuthorisation=array("sUserId" =>$this->f("i_id"),
"sSalutationId"
=>$this->f("i_salutation_id"),
"sUserName" => $this->f("vch_pseudo"),
"sUniqueId" => $this->f("vch_unique"),
"sEmail" => $this->f("vch_email"),
"sFirstName" => $this->f("vch_first_name"),
"sLastName" => $this->f("vch_last_name"),
"sLastLogin" => $this->f("dt_last_login"),
"sLoginSince" => date("H:i:s"));
session_register("s_userAuthorisation");
if ($this->DEBUG) {
echo "Login ok ".$s_loginRetries;}
$this->lastLoginDateTime=$this->f("dt_last_login");
$this->loggedInPseudo=$pseudo;
$this->updateLastLoginDate($pseudo);
$this->ErrorMsg="";
$s_loginRetries=0;
// put to member online
$k=new Keepalive();
$k->updateUserLoggedIn(session_id(),$s_userAuthorisation["sUserName"],$s_userAuthorisation["sUserId"]);
if ($this->DEBUG) { $this->displaySessionVars(); }
}
}
else
{
// login failed
// delete Session
// here is the bug: HANGSPHP
session_destroy();
// some security
if ($this->DEBUG) { $this->displaySessionVars(); }
if ($s_loginRetries<3) {
// nothing to do as no timeout to set
if ($this->DEBUG) {echo "Loginretries ".$s_loginRetries;}
$this->ErrorMsg="Login inkorrekt";
}
else
{
$this->ErrorMsg="10sec. Timeout 3 fehlerhafte
Loginversuche";
if ($this->DEBUG) { echo " 10sec. Timeout 3 fehlerhafte
Loginversuche in Folge";}
flush();
sleep(10);
$s_loginRetries=0;
}
// secutity end
$this->lastLoginDateTime="";
$this->loggedInPseudo="";
}
}
return $loginOk;
}
Previous Comments:
[2002-03-04 10:23:24] [EMAIL PROTECTED]
Can you provide a simple sample script?
P.S.: no I don't like caps :)
[2002-03-04 09:49:48] [EMAIL PROTECTED]
The PHP4TS.DLL hangs.. sorry..
Bug #15835 Updated: Problem on function gmp_invert ()
ID: 15835
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: *Math Functions
Operating System: Linux - Red Hat 7.2
PHP Version: 4.1.2
New Comment:
Yes, I'm sure. The "Euclidean Algorithm" computes the greatest common
divisor but, the "Extended Euclidean Algorithm" give you the
multiplicative inverse.
The multiplicative inverse of 7 module 13 is 2 so, if I use
gmp_invert(7,13) it should return 2.
Ok ?
Previous Comments:
[2002-03-04 09:12:30] [EMAIL PROTECTED]
Are you sure that the extended Euclidean Algorithm does the same as
gmp_invert? The Euclidean Algorithm computes the greatest common
divisor, gmp_invert doesn't seem to do that...
Anyway, gmp_invert seems to be broken. I can't get it to return
anything else than false.
So I ask you again: can you give me some human understandable data that
works or should work?
[2002-03-04 07:30:06] [EMAIL PROTECTED]
gmp_invert() should return the multiplicative inverse (if exist) of a
number, module something.
It's the extended Euclidean algorithm. I wrote this code and I can give
you. I think there is something wrong to gmp_invert.
[2002-03-03 06:42:28] [EMAIL PROTECTED]
I can't get gmp_invert() return anything other than false, but that
might be because I have no idea what gmp_invert() does :)
Can you supply some (human understandable) data that does work?
[2002-03-02 14:20:49] [EMAIL PROTECTED]
Example:
$x =
gmp_init("0x00d2d025ec7e1dbb6d778a52394c988594c57b47d7327a3e676d3a5ca7a5af87c4153c80994cf781f6a9d4a2f0e66d04baffb0059853a8937a895f6d17e76950e1");
// mod
$y = gmp_init("6211846575289879599"); // value
$w = gmp_invert($y,$x);
The $w value should be :
667351618289984699831448814604762419850017638123963706466136275029334435034698239463153441869117173460635003602664197747901516108936488872273669129832
[2002-03-02 13:29:43] [EMAIL PROTECTED]
Please provide a short reproducing script with values that you are
using and expected output.
Sean
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/15835
--
Edit this bug report at http://bugs.php.net/?id=15835&edit=1
Bug #15858: Reproducible segmentation fault in pages using oci8 (Oracle 8.1.7)
From: [EMAIL PROTECTED] Operating system: UnixWare 7.1.1 PHP version: 4.1.2 PHP Bug Type: Reproducible crash Bug description: Reproducible segmentation fault in pages using oci8 (Oracle 8.1.7) Hi! we have - SuperMicro P3TDLE, 2* Pentium III, 1 GB RAM - UnixWare 7.1.1 with latest patches installed - Apache 1.3.23 - PHP 4.1.2 - Oracle 8.1.7.2 - gcc 2.95.2 PHP was configured with command: export ORACLE_HOME=/u01/app/oracle/product/8.1.7 export LD_LIBRARY_PATH=/usr/local/lib:$ORACLE_HOME/lib ./configure --with-oci8 --with-apxs --without-mysql --enable-sigchild --host=i486-sco-sysv5uw7 We have found (at least) one php page using database connection (this page is rather complicated, but we can provide it on demand), which generates "Segmentation fault" reproducibly. It seems, that "Segmentation fault" is caused by php, as it can be seen from following lines generated by gdb session: egg 174# gdb /usr/local/apache.dbg/bin/httpd (gdb) run -X Starting program: /usr/local/apache.dbg/bin/./httpd -X warning: Lowest section in /usr/lib/libdl.so.1 is .hash at 0094 Program received signal SIGSEGV, Segmentation fault. _efree (ptr=0x0) at zend_alloc.c:222 222 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size); [New Thread 1] (gdb) bt #0 _efree (ptr=0x0) at zend_alloc.c:222 #1 0xbfd6b787 in zend_hash_destroy (ht=0x0) at zend_hash.c:548 #2 0xbfd651b4 in _zval_dtor (zvalue=0x82072f4) at zend_variables.c:57 #3 0xbfd5d498 in _zval_ptr_dtor (zval_ptr=0x82566d0) at zend_execute_API.c:274 #4 0xbfd6b7d0 in zend_hash_clean (ht=0x81cede4) at zend_hash.c:567 #5 0xbfd57f07 in execute () from /usr/local/apache.dbg/libexec/libphp4.so #6 0xbfd66a97 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #7 0xbfd77326 in php_execute_script (primary_file=0x80479d8) at main.c:1307 #8 0xbfd71af6 in apache_php_module_main (r=0x812d7e4, display_source_mode=0) at sapi_apache.c:90 #9 0xbfd72d2f in send_php (r=0x812d7e4, display_source_mode=0, filename=0x0) at mod_php4.c:575 #10 0xbfd72d96 in send_parsed_php (r=0x0) at mod_php4.c:590 #11 0x8056aa5 in ap_invoke_handler () #12 0x806d910 in process_request_internal () #13 0x806d97a in ap_process_request () #14 0x8063be7 in child_main () #15 0x8063da9 in make_child () #16 0x8063f22 in startup_children () #17 0x80644f0 in standalone_main () #18 0x8064d40 in main () #19 0x804f149 in _start () Unfortunately, we are unable to configure PHP with --enable-debug option, it crashes with "Segmentation fault" during Apache startup :-( Can somebody help ? Pavel -- Edit bug report at http://bugs.php.net/?id=15858&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15858&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15858&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15858&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15858&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15858&r=support Expected behavior: http://bugs.php.net/fix.php?id=15858&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15858&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15858&r=submittedtwice
Bug #15859: Apache crash when using apache2filter and latest CVS
From: [EMAIL PROTECTED] Operating system: Windows NT Server 4 PHP version: 4.0CVS-2002-03-04 PHP Bug Type: Apache2 related Bug description: Apache crash when using apache2filter and latest CVS I've compiled the latest beta version of Apache2 and built the latest (2002-03-04) version of PHP to use the Apache2Filter. It works initially but after a few requests of different pages an Access Violation is generated in apache. Didn't seem to be too dependent on what the script was although simple scripts (i.e. just calling phpinfo()) didn't seem to cause it. I think I've seen this before here but I couldn't find it again. so here's the call stack from Visual C++ ap_save_brigade(ap_filter_t * 0x00832068, apr_bucket_brigade * * 0x0083116c, apr_bucket_brigade * * 0x1136fe78, apr_pool_t * 0x00830930) line 473 + 49 bytes php_output_filter(ap_filter_t * 0x00832068, apr_bucket_brigade * 0x008321d8) line 350 + 32 bytes ap_pass_brigade(ap_filter_t * 0x00832068, apr_bucket_brigade * 0x008321d8) line 445 + 16 bytes default_handler(request_rec * 0x00830968) line 2996 ap_run_handler(request_rec * 0x00830968) line 186 + 78 bytes ap_invoke_handler(request_rec * 0x00830968) line 359 + 9 bytes ap_process_request(request_rec * 0x00830968) line 290 + 9 bytes ap_process_http_connection(conn_rec * 0x0082c9b8) line 287 + 9 bytes ap_run_process_connection(conn_rec * 0x0082c9b8) line 85 + 78 bytes ap_process_connection(conn_rec * 0x0082c9b8, void * 0x0082c8f8) line 230 worker_main(long 249) line 1077 MSVCRTD! 1020bf53() KERNEL32! 77f04ede() Also when compiling the Apache2Filter these error messages were generated. Configuration: php4apache2 - Win32 Debug_TS Compiling... apache_config.c d:\build_area\httpd-2.0.32\srclib\apr\include\apr.h(323) : warning C4142: benign redefinition of type php_functions.c d:\build_area\httpd-2.0.32\srclib\apr\include\apr.h(323) : warning C4142: benign redefinition of type d:\build_area\php4-200203040600\sapi\apache2filter\php_functions.c(91) : warning C4244: 'function' : conversion from '__int64 ' to 'long ', possible loss of data d:\build_area\php4-200203040600\sapi\apache2filter\php_functions.c(92) : warning C4244: 'function' : conversion from '__int64 ' to 'long ', possible loss of data sapi_apache2.c d:\build_area\php4-200203040600\sapi\apache2filter\php_functions.c(91) : warning C4761: integral size mismatch in argument; conversion supplied d:\build_area\php4-200203040600\sapi\apache2filter\php_functions.c(92) : warning C4761: integral size mismatch in argument; conversion supplied d:\build_area\httpd-2.0.32\srclib\apr\include\apr.h(323) : warning C4142: benign redefinition of type d:\build_area\php4-200203040600\sapi\apache2filter\sapi_apache2.c(119) : warning C4018: '<' : signed/unsigned mismatch Linking... LINK : fatal error LNK1104: cannot open file "php4ts.lib" Error executing link.exe. php4apache2.dll - 1 error(s), 77 warning(s) The link error is because the php4ts.lib was actually generated as php4ts_debug.lib but the project file didn't reflect this. Changing that solved the linker problem but the other warnings remained. the crash also happens in release builds. The build was just a standard windows PHP build and so was the apache one. The error occurs in both debug and release builds. Cheers Pete Dishman -- Edit bug report at http://bugs.php.net/?id=15859&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15859&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15859&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15859&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15859&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15859&r=support Expected behavior: http://bugs.php.net/fix.php?id=15859&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15859&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15859&r=submittedtwice
Bug #15572 Updated: apxs check fails because of missing quotes
ID: 15572 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Compile Issues Operating System: Solaris 8 PHP Version: 4.1.1 New Comment: Same exact problem but the fix didn't help me. Same thing happens for 4.1.1 and 4.1.2. Also on Solaris 7. I just get the apxs usage message. Note: Currently running Apache 1.3.22 and PHP 4.1.0, in case remnants from those could be hosing it. Previous Comments: [2002-02-15 11:14:30] [EMAIL PROTECTED] A little glitch in sapi/apache/config.m4 causes the apxs check of working -S option to fail. Although the compile succeeds the installation isn't performed correctly, at least not when using INSTALL_ROOT. The patch included below fixes the problem. regards, Ralf Nyrén diff -ur php-4.1.1.orig/sapi/apache/config.m4 php-4.1.1/sapi/apache/config.m4 --- php-4.1.1.orig/sapi/apache/config.m4Mon Nov 19 01:52:02 2001 +++ php-4.1.1/sapi/apache/config.m4 Fri Feb 15 15:22:47 2002 @@ -41,7 +41,7 @@ PHP_SAPI=apache # Test whether apxs support -S option - $APXS -q -S CFLAGS=$APXS_CFLAGS CFLAGS >/dev/null 2>&1 + $APXS -q -S CFLAGS="$APXS_CFLAGS" CFLAGS >/dev/null 2>&1 if test "$?" != "0"; then APACHE_INSTALL="$APXS -i -a -n php4 $SAPI_SHARED" # Old apxs does not have -S option -- Edit this bug report at http://bugs.php.net/?id=15572&edit=1
Bug #15860: crypt function returns garbage
From: [EMAIL PROTECTED] Operating system: RH 6.2 PHP version: 4.1.2 PHP Bug Type: Unknown/Other Function Bug description: crypt function returns garbage crypt function returns garbage without salt. crypt with salt returns encrypted password as expected. -- Edit bug report at http://bugs.php.net/?id=15860&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15860&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15860&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15860&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15860&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15860&r=support Expected behavior: http://bugs.php.net/fix.php?id=15860&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15860&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15860&r=submittedtwice
Bug #15772 Updated: PHP is developed and maintained by morons
ID: 15772
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: *General Issues
Operating System: all
PHP Version: 4.0.6
New Comment:
Folks, please, we need a working fix, stop bitching at each other.
Is the official response from the PHP team that "the fix is in CVS, so
it is fixed"?
Previous Comments:
[2002-03-03 02:34:50] [EMAIL PROTECTED]
> Fuck you ...php
This posting is most probably a fake, cause there is
noone at [EMAIL PROTECTED]
And for the rest of the trolls:
The patch from [EMAIL PROTECTED] will not be applied.
All his claims were as bogus as his patch.
He just added lots of redundant code. And the best:
In his patch every single variable is double freed.
You know how dangerous that is...
[2002-03-02 15:56:21] [EMAIL PROTECTED]
Fuck you ...php
[2002-03-01 07:03:10] [EMAIL PROTECTED]
I have had a long look at rfc1867.c v 1.71.2.2 2002/02/21
from a download of php4.1.2 today (1 Mar 10:00 CET). There are a large
number of dubious cases of handling of the buffer being processed. The
following diffs address most of these (I believe). I am posting the
patches to the php-dev list, since it's difficult if not impossible to
create a properfly formatted diff in this edit window.
[2002-02-28 17:50:58] [EMAIL PROTECTED]
How about this patch:
--- main/rfc1867.c.orig Thu Feb 28 14:08:25 2002
+++ main/rfc1867.c Thu Feb 28 14:33:03 2002
@@ -163,20 +163,28 @@
SAFE_RETURN;
}
/* some other headerfield
found, skip it */
- loc = (char *) memchr(ptr,
'\n', rem)+1;
+ loc = (char *) memchr(ptr,
'\n', rem);
if (!loc) {
/* broken */
php_error(E_WARNING,
"File Upload Mime headers garbled ptr: [%c%c%c%c%c]", *ptr, *(ptr + 1),
*(ptr + 2), *(ptr
+ 3), *(ptr + 4));
SAFE_RETURN;
}
+ else
+ {
+ loc++;
+ }
while (*loc == ' ' || *loc ==
'\t') {
/* other field is
folded, skip it */
- loc = (char *)
memchr(loc, '\n', rem-(loc-ptr))+1;
+ loc = (char *)
memchr(loc, '\n', rem-(loc-ptr));
if (!loc) {
/* broken */
php_error(E_WARNING, "File Upload Mime headers garbled ptr:
[%c%c%c%c%c]", *ptr, *(ptr + 1), *(ptr +
2), *(ptr + 3), *(ptr + 4));
SAFE_RETURN;
}
+ else
+ {
+ loc++;
+ }
}
rem -= (loc - ptr);
ptr = loc;
@@ -232,6 +240,10 @@
* pre 4.0.6 code here
*/
loc2 = memchr(loc + 1, '\n',
rem);
+ if (!loc2) {
+ php_error(E_WARNING,
"File Upload Mime headers - no newline");
+ SAFE_RETURN;
+ }
rem -= (loc2 - ptr) + 1;
ptr = loc2 + 1;
/* is_arr_upload is true when
name of file upload field
[2002-02-28 05:06:42] [EMAIL PROTECTED]
You are again wrong, cnt must be supplied.
I advise you to think before you speak.
A POST fileupload block can have lots of '\0's in it.
Without the number of bytes it would be impossibe to
handle such a block.
Bug #14998 Updated: Can't name a class 'Directory'
ID: 14998 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Red Hat Linux 7.0 PHP Version: 4.0.5 New Comment: This one just bit me for 20 minutes as well. A documentation change would be quite helpful (Also, I think this is something that would generally be happier in PEAR or similar, but that's a diffrent problem :). Previous Comments: [2002-01-11 13:54:29] [EMAIL PROTECTED] See http://www.php.net/manual/en/function.get-declared-classes.php.; It is predefined. Should be pointed out more clearly, -> documentation problem. [2002-01-11 12:17:37] [EMAIL PROTECTED] For example, given the code: PHP gives the error: "Cannot redeclare class directory". Maybe the the dir() function/class interferes?? Configuration: './configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-exec-dir=/usr/bin' '--with-config-file-path=/etc/httpd' '--with-regex=system' '--enable-debugger' '--enable-magic-quotes' '--enable-sysvshm' '--with-dom' '--enable-force-cgi-redirect' '--enable-sigchild' '--with-wddx' '--enable-inline-optimization' '--with-gnu-ld' '--enable-bcmath' '--enable-crypt' '--with-xml' '--with-sablot' '--enable-dbg=shared' '--with-dbg-profiler' Thanks. -- Edit this bug report at http://bugs.php.net/?id=14998&edit=1
Bug #15860 Updated: crypt function returns garbage
ID: 15860 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: RH 6.2 PHP Version: 4.1.2 New Comment: >From the manual: "If the salt argument is not provided, one will be randomly generated by PHP". Or are you observing something other than a string encrypted with a random salt? Previous Comments: [2002-03-04 12:12:12] [EMAIL PROTECTED] crypt function returns garbage without salt. crypt with salt returns encrypted password as expected. -- Edit this bug report at http://bugs.php.net/?id=15860&edit=1
Bug #15572 Updated: apxs check fails because of missing quotes
ID: 15572 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *Compile Issues Operating System: Solaris 8 PHP Version: 4.1.1 New Comment: Patch applied in CVS, this will be in 4.2.x Derick Previous Comments: [2002-03-04 12:04:18] [EMAIL PROTECTED] Same exact problem but the fix didn't help me. Same thing happens for 4.1.1 and 4.1.2. Also on Solaris 7. I just get the apxs usage message. Note: Currently running Apache 1.3.22 and PHP 4.1.0, in case remnants from those could be hosing it. [2002-02-15 11:14:30] [EMAIL PROTECTED] A little glitch in sapi/apache/config.m4 causes the apxs check of working -S option to fail. Although the compile succeeds the installation isn't performed correctly, at least not when using INSTALL_ROOT. The patch included below fixes the problem. regards, Ralf Nyrén diff -ur php-4.1.1.orig/sapi/apache/config.m4 php-4.1.1/sapi/apache/config.m4 --- php-4.1.1.orig/sapi/apache/config.m4Mon Nov 19 01:52:02 2001 +++ php-4.1.1/sapi/apache/config.m4 Fri Feb 15 15:22:47 2002 @@ -41,7 +41,7 @@ PHP_SAPI=apache # Test whether apxs support -S option - $APXS -q -S CFLAGS=$APXS_CFLAGS CFLAGS >/dev/null 2>&1 + $APXS -q -S CFLAGS="$APXS_CFLAGS" CFLAGS >/dev/null 2>&1 if test "$?" != "0"; then APACHE_INSTALL="$APXS -i -a -n php4 $SAPI_SHARED" # Old apxs does not have -S option -- Edit this bug report at http://bugs.php.net/?id=15572&edit=1
Bug #15572 Updated: apxs check fails because of missing quotes
ID: 15572 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *Compile Issues Operating System: Solaris 8 PHP Version: 4.1.1 New Comment: I apologize to Ralf & everyone! It's my (cached) configuration mistake. Ralf's fix is good. Thanks Ralf! -Adam Previous Comments: [2002-03-04 12:47:40] [EMAIL PROTECTED] Patch applied in CVS, this will be in 4.2.x Derick [2002-03-04 12:04:18] [EMAIL PROTECTED] Same exact problem but the fix didn't help me. Same thing happens for 4.1.1 and 4.1.2. Also on Solaris 7. I just get the apxs usage message. Note: Currently running Apache 1.3.22 and PHP 4.1.0, in case remnants from those could be hosing it. [2002-02-15 11:14:30] [EMAIL PROTECTED] A little glitch in sapi/apache/config.m4 causes the apxs check of working -S option to fail. Although the compile succeeds the installation isn't performed correctly, at least not when using INSTALL_ROOT. The patch included below fixes the problem. regards, Ralf Nyrén diff -ur php-4.1.1.orig/sapi/apache/config.m4 php-4.1.1/sapi/apache/config.m4 --- php-4.1.1.orig/sapi/apache/config.m4Mon Nov 19 01:52:02 2001 +++ php-4.1.1/sapi/apache/config.m4 Fri Feb 15 15:22:47 2002 @@ -41,7 +41,7 @@ PHP_SAPI=apache # Test whether apxs support -S option - $APXS -q -S CFLAGS=$APXS_CFLAGS CFLAGS >/dev/null 2>&1 + $APXS -q -S CFLAGS="$APXS_CFLAGS" CFLAGS >/dev/null 2>&1 if test "$?" != "0"; then APACHE_INSTALL="$APXS -i -a -n php4 $SAPI_SHARED" # Old apxs does not have -S option -- Edit this bug report at http://bugs.php.net/?id=15572&edit=1
Bug #15572 Updated: apxs check fails because of missing quotes
ID: 15572 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *Compile Issues Operating System: Solaris 8 PHP Version: 4.1.1 New Comment: Patch applied in CVS, this will be in 4.2.x Derick Previous Comments: [2002-03-04 12:47:49] [EMAIL PROTECTED] I apologize to Ralf & everyone! It's my (cached) configuration mistake. Ralf's fix is good. Thanks Ralf! -Adam [2002-03-04 12:47:40] [EMAIL PROTECTED] Patch applied in CVS, this will be in 4.2.x Derick [2002-03-04 12:04:18] [EMAIL PROTECTED] Same exact problem but the fix didn't help me. Same thing happens for 4.1.1 and 4.1.2. Also on Solaris 7. I just get the apxs usage message. Note: Currently running Apache 1.3.22 and PHP 4.1.0, in case remnants from those could be hosing it. [2002-02-15 11:14:30] [EMAIL PROTECTED] A little glitch in sapi/apache/config.m4 causes the apxs check of working -S option to fail. Although the compile succeeds the installation isn't performed correctly, at least not when using INSTALL_ROOT. The patch included below fixes the problem. regards, Ralf Nyrén diff -ur php-4.1.1.orig/sapi/apache/config.m4 php-4.1.1/sapi/apache/config.m4 --- php-4.1.1.orig/sapi/apache/config.m4Mon Nov 19 01:52:02 2001 +++ php-4.1.1/sapi/apache/config.m4 Fri Feb 15 15:22:47 2002 @@ -41,7 +41,7 @@ PHP_SAPI=apache # Test whether apxs support -S option - $APXS -q -S CFLAGS=$APXS_CFLAGS CFLAGS >/dev/null 2>&1 + $APXS -q -S CFLAGS="$APXS_CFLAGS" CFLAGS >/dev/null 2>&1 if test "$?" != "0"; then APACHE_INSTALL="$APXS -i -a -n php4 $SAPI_SHARED" # Old apxs does not have -S option -- Edit this bug report at http://bugs.php.net/?id=15572&edit=1
Bug #15861: bad build tool
From: [EMAIL PROTECTED] Operating system: Linux - RedHat6.1 PHP version: 4.1.2 PHP Bug Type: *General Issues Bug description: bad build tool suggested on PHP site: autoconf-2.52,automake-1.4,libtool-1.4 - build FAILS autoconf-2.52,automake-1.4,libtool-1.4.2 - build FAILS BUT: autoconf-2.13,automake-1.4,libtool-1.4 - build OK, ?? (not tested) autoconf-2.13,automake-1.4,libtool-1.4.2 - build OK, but crashes running with libmcrypt-1.4.9, works with libmcrypt-1.4.20 autoconf-2.13,automake-1.4,libtool-1.3.5 - build OK, works with libmcrypt-1.4.9, works with libmcrypt-1.4.20 What tools I should use? -- Edit bug report at http://bugs.php.net/?id=15861&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15861&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15861&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15861&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15861&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15861&r=support Expected behavior: http://bugs.php.net/fix.php?id=15861&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15861&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15861&r=submittedtwice
Bug #15822 Updated: session variables disappear
ID: 15822
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Duplicate
Bug Type: Session related
Operating System: Linux 2.2.19
PHP Version: 4.1.2
New Comment:
I did.
I also checked the changelog, but it's still not updated for 4.1.2.
I also checked the session fn docs, but didn't see anything relevant in
either the static documentation or the comments.
Perhaps the bug is marked as closed already? I'm not sure I checked
for closed bugs, but you didn't include the original bug number when
telling me my entry was a duplicate, so I really have no idea what it
was I missed on my first search.
If it's a known bug, is it slated to be fixed? In 4.2.0? Is there a
work-around? Again, my search for further information has left me dry.
Any pointer to a worthwhile starting point, even just the original bug
#, would be far more useful than simply assuming I never bothered
looking and telling me to buzz off.
Previous Comments:
[2002-03-02 02:16:52] [EMAIL PROTECTED]
It's known problem. Session become read only.
Thanks for reporting but search reports first :)
[2002-03-01 16:32:53] [EMAIL PROTECTED]
My web host recently upgraded to PHP 4.1.2. At the same time, my user
login scripts stopped working. A session variable registered with
session_register() is not holding its information when the page
reloads.
Details:
I have a file included in every page that looks like:
class UserSession
{
var $user_id = 0;
var $username = "";
var $logged_in = false;
//other stuff elided
}
session_start();
global $user_session;
if (!session_is_registered("user_session"))
{
session_register("user_session");
$user_session = new UserSession();
}
function ProcessLogin($Username, $Password)
{
global $user_session;
//username and password are checked against DB contents
//if that's all good, get user row with mysql_fetch_array()
$user_session->user_id = $row[user_id];
$user_session->username = $row[user_name];
$user_session->logged_in = true;
//cookies are set and other stuff happens
}
When a page loads immediately after the user logs in, all is well, and
the values in $user_session are all as I expect them to be. Reloading
the same page, though, causes $user_session to be set back to its
default values. Before the 4.1.2 upgrade, this worked fine.
I've stripped the code down almost to what I show above, and it still
fails, so I'm pretty sure I'm not doing anything to stomp the values
later in the page. I double-checked that on the page reload,
$user_session is still registered, and it appears to be.
The changelog at http://www.php.net/ChangeLog-4.php only goes up to
version 4.1.1, so I couldn't tell if there was any change to session
variable handling in 4.1.2.
Any thoughts? All suggestions are appreciated.
Config line:
'./configure' '--with-mysql' '--with-apache=../apache_1.3.23'
'--enable-track-vars' '--with-xml' '--enable-memory-limit=yes'
'--enable-bcmath' '--with-gd=../gd-2.0.1' '--enable-gd-native-tt'
'--enable-gd-imgstrttf' '--with-gdbm=/usr/include' '--enable-calendar'
'--with-png-dir=/usr/lib' '--with-zlib-dir=/usr/include'
'--with-freetype-dir=/usr/local/include/freetype2'
'--with-jpeg-dir=/usr/local/lib' '--with-mcrypt' '--enable-trans-sid'
'--with-sablot=/usr/local/lib' '--with-imap' '--enable-xslt'
'--with-xslt-sablot' '--enable-sablot-errors-descriptive'
Host info:
Linux *.*.com 2.2.19-6.2.11 #1 Fri Oct 19 13:28:00 EDT 2001 i686
unknown
Server is latest stable Apache.
--
Edit this bug report at http://bugs.php.net/?id=15822&edit=1
Bug #15056 Updated: rpm build problem: apxs capabilities misdetected
ID: 15056 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *Compile Issues Operating System: linux PHP Version: 4.1.1 New Comment: This bug has been fixed in CVS. (dupe of #15572) Previous Comments: [2002-01-15 16:15:19] [EMAIL PROTECTED] --- php-4.1.1/sapi/apache/config.m4 Mon Nov 19 01:52:02 2001 +++ php-4.1.1.new/sapi/apache/config.m4 Tue Jan 15 20:46:44 2002 @@ -41,7 +41,7 @@ PHP_SAPI=apache # Test whether apxs support -S option - $APXS -q -S CFLAGS=$APXS_CFLAGS CFLAGS >/dev/null 2>&1 + $APXS -q -S "CFLAGS=$APXS_CFLAGS" CFLAGS >/dev/null 2>&1 if test "$?" != "0"; then APACHE_INSTALL="$APXS -i -a -n php4 $SAPI_SHARED" # Old apxs does not have -S option (he guys, you should really add a "attach file" option to your bug reporting system like it is common in bugzilla...) [2002-01-15 16:12:50] [EMAIL PROTECTED] When I compile my self-created php rpm the configure script misdetects the capabilities of the installed apxs (speak: the -S option). That leads to files installed directly in /usr/lib/apache and not /var/tmp/php-root/... I tracked it down and it looks like a bash incompatibilty (I'm using bash 2.04). The attached patch fixes the problem for me. -- Edit this bug report at http://bugs.php.net/?id=15056&edit=1
Bug #15009 Updated: Compile Error in file gd.c
ID: 15009 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Linux (Kernel 2.4.17) PHP Version: 4.1.1 New Comment: The same error also occurs with PHP versions dating as far back as 4.0.6 with distributions of both GD 1(.8.4) and 2(.0.1). Previous Comments: [2002-02-28 15:04:34] [EMAIL PROTECTED] This problem also occurs with GD 2.0.1, on earlier and later kernels (on separate machines), and on machines which are both fresh installs and which have had PHP (and older versions of gd) installed before. [2002-01-12 16:09:46] [EMAIL PROTECTED] If i compiled php with gd. There was an error while compiling gd.c: gd.c:92: conflicting types for `gdIOCtx' /usr/local/include/gd_io.h:18: previous declaration of `gdIOCtx' It works, if I've uncomment the line 92 in gd.c. I compiled previously gd 1.8.4 -- Edit this bug report at http://bugs.php.net/?id=15009&edit=1
Bug #15009 Updated: Compile Error in file gd.c
ID: 15009 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Linux (Kernel 2.4.17) PHP Version: 4.1.1 New Comment: This is due to you having multiple versions of GD installed on your system. PHP should probably do a better job of handling that, but if you only have one installed it works just fine. Previous Comments: [2002-03-04 13:37:59] [EMAIL PROTECTED] The same error also occurs with PHP versions dating as far back as 4.0.6 with distributions of both GD 1(.8.4) and 2(.0.1). [2002-02-28 15:04:34] [EMAIL PROTECTED] This problem also occurs with GD 2.0.1, on earlier and later kernels (on separate machines), and on machines which are both fresh installs and which have had PHP (and older versions of gd) installed before. [2002-01-12 16:09:46] [EMAIL PROTECTED] If i compiled php with gd. There was an error while compiling gd.c: gd.c:92: conflicting types for `gdIOCtx' /usr/local/include/gd_io.h:18: previous declaration of `gdIOCtx' It works, if I've uncomment the line 92 in gd.c. I compiled previously gd 1.8.4 -- Edit this bug report at http://bugs.php.net/?id=15009&edit=1
Bug #15862: Reborn bug: "error is SSL: couldn't create a context!"
From: [EMAIL PROTECTED] Operating system: Freebsd 4.3 PHP version: 4.1.2 PHP Bug Type: cURL related Bug description: Reborn bug: "error is SSL: couldn't create a context!" When attempting to use cURL over https, php returns the error: "SSL: couldn't create a context!" Command-line operation in cURL works without error. A similar situation was reported, and reportedly fixed, in 4.1.1 CVS, but it has re-appeared in 4.1.2 release. The earlier problem was apparently related to compiling SSL into both PHP and cURL; I re-complied PHP without SSL but the problem persists. Any work-arounds will be greatly appreciated. -- Matt Daly ./configure --with-apxs=/usr/local/sbin/apxs --with-curl --with-config-file-path=/usr/local/etc --enable-versioning --with-system-regex --disable-debug --enable-track-vars --with-gd=/usr/local --with-ttf=/usr/local --with-zlib --with-mcrypt=/usr/local --with-mhash=/usr/local --with-mysql=/usr/local --with-xml=/usr/local --enable-ftp --with-gettext=/usr/local --enable-sockets --enable-trans-sid --prefix=/usr/local -- Edit bug report at http://bugs.php.net/?id=15862&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15862&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15862&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15862&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15862&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15862&r=support Expected behavior: http://bugs.php.net/fix.php?id=15862&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15862&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15862&r=submittedtwice
Bug #15792 Updated: sapi_apache2.c:247
ID: 15792 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: GNU/Linux PHP Version: 4.1.2 New Comment: > What's your configure line? ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --without-mysql > What version of Apache do you use? httpd-2.0.32-beta.tar.gz Previous Comments: [2002-03-01 03:42:40] [EMAIL PROTECTED] What's your configure line? What version of Apache do you use? You should compile PHP with the latest CVS of Apache 2, (although beta 32 may work too). [2002-02-28 15:05:36] [EMAIL PROTECTED] in sapi/apache2filter/sapi_apache2.c sapi_apache2.c: In function `php_apache_sapi_register_variables': sapi_apache2.c:148: warning: initialization discards qualifiers from pointer target type sapi_apache2.c: In function `php_input_filter': sapi_apache2.c:247: incompatible type for argument 4 of `ap_get_brigade' sapi_apache2.c:247: too few arguments to function `ap_get_brigade' sapi_apache2.c: In function `php_register_hook': sapi_apache2.c:408: warning: passing arg 2 of `ap_register_input_filter' from incompatible pointer type -- Edit this bug report at http://bugs.php.net/?id=15792&edit=1
Bug #15850 Updated: Compiling not possible due to incorrect creation of Makefile
ID: 15850 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: LinuxMandrake 7.2 (2.2.17-21mdk) PHP Version: 4.1.2 New Comment: Compiling path: /mnt/raid/Samba/Linux Programme/php-4.1.2 Everything works fine until the last step (creating files/generating files), as already mentioned. As this "bogus" _bug_ is reproducible, it would not have been difficult to figure that out by yourself, although I mentioned it. Extract from ./configure +++ Generating files checking for working mkdir -p... (cached) yes creating config_vars.mk updating cache ./config.cache creating ./config.status creating php4.spec creating Zend/Makefile creating main/build-defs.h creating pear/scripts/pear creating pear/scripts/phpize creating pear/scripts/php-config creating pear/scripts/pearize creating pear/scripts/phptar creating TSRM/Makefile creating main/php_config.h main/php_config.h is unchanged creating sapi/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/sapi/Makefile.in: No such file or directory creating ext/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/Makefile.in: No such file or directory creating Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/Makefile.in: No such file or directory creating pear/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/pear/Makefile.in: No such file or directory creating main/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/main/Makefile.in: No such file or directory creating ext/mysql/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/mysql/Makefile.in: No such file or directory creating ext/mysql/libmysql/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/mysql/libmysql/Makefile.in: No such file or directory creating ext/pcre/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/pcre/Makefile.in: No such file or directory creating ext/pcre/pcrelib/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/pcre/pcrelib/Makefile.in: No such file or directory creating ext/posix/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/posix/Makefile.in: No such file or directory creating ext/session/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/session/Makefile.in: No such file or directory creating ext/standard/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/standard/Makefile.in: No such file or directory creating ext/xml/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/xml/Makefile.in: No such file or directory creating ext/xml/expat/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/xml/expat/Makefile.in: No such file or directory creating sapi/apache/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/sapi/apache/Makefile.in: No such file or directory creating regex/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/regex/Makefile.in: No such file or directory creating main/internal_functions.c cat: ./main/internal_functions.c.in: No such file or directory +++ Happy? Previous Comments: [2002-03-04 03:02:31] [EMAIL PROTECTED] Completely non-sensical bug report. [2002-03-03 17:49:56] [EMAIL PROTECTED] --enable-fff of course is --enable-track-vars [2002-03-03 17:48:43] [EMAIL PROTECTED] The bug appears when I try to compile PHP 4.1.2 as an apxs dynamic apache module. First I had a #configure --with-mysql --with-gd --enable-fff --with-apxs which produced an (almost) empty Makefile afterwards. Only 5 lines of path definitions where in there. This resulted in an error when trying to #make the project, as it returned: make: *** No targets. Stop. I just found the solution! It really is a bug in your configure script, please fix it as soon as you have time. I had the PHP sources located in /mnt/raid/Samba/Linux Programme/php-4.1.2 During the last step (creating files) the configure script tried to access the path, but did not use a metacharacter space (Linux\ Programme), so it tried to write in /mnt/raid/Samba/Linux, where of course no files were! Cool, I got that one :-) Anyways, if I hadn't found this bug, I'm sure you would have, and I'm sure you'd have helped me. You people are the ones who make PHP such a great language. PHP is incredibly awesome, you're doing a fa
Bug #15850 Updated: Compiling not possible due to incorrect creation of Makefile
ID: 15850 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Feedback Bug Type: Compile Failure Operating System: LinuxMandrake 7.2 (2.2.17-21mdk) PHP Version: 4.1.2 New Comment: Which versions of libtool, automake and autoconf are you using? Derick Previous Comments: [2002-03-04 14:37:08] [EMAIL PROTECTED] Compiling path: /mnt/raid/Samba/Linux Programme/php-4.1.2 Everything works fine until the last step (creating files/generating files), as already mentioned. As this "bogus" _bug_ is reproducible, it would not have been difficult to figure that out by yourself, although I mentioned it. Extract from ./configure +++ Generating files checking for working mkdir -p... (cached) yes creating config_vars.mk updating cache ./config.cache creating ./config.status creating php4.spec creating Zend/Makefile creating main/build-defs.h creating pear/scripts/pear creating pear/scripts/phpize creating pear/scripts/php-config creating pear/scripts/pearize creating pear/scripts/phptar creating TSRM/Makefile creating main/php_config.h main/php_config.h is unchanged creating sapi/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/sapi/Makefile.in: No such file or directory creating ext/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/Makefile.in: No such file or directory creating Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/Makefile.in: No such file or directory creating pear/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/pear/Makefile.in: No such file or directory creating main/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/main/Makefile.in: No such file or directory creating ext/mysql/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/mysql/Makefile.in: No such file or directory creating ext/mysql/libmysql/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/mysql/libmysql/Makefile.in: No such file or directory creating ext/pcre/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/pcre/Makefile.in: No such file or directory creating ext/pcre/pcrelib/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/pcre/pcrelib/Makefile.in: No such file or directory creating ext/posix/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/posix/Makefile.in: No such file or directory creating ext/session/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/session/Makefile.in: No such file or directory creating ext/standard/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/standard/Makefile.in: No such file or directory creating ext/xml/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/xml/Makefile.in: No such file or directory creating ext/xml/expat/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/xml/expat/Makefile.in: No such file or directory creating sapi/apache/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/sapi/apache/Makefile.in: No such file or directory creating regex/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/regex/Makefile.in: No such file or directory creating main/internal_functions.c cat: ./main/internal_functions.c.in: No such file or directory +++ Happy? [2002-03-04 03:02:31] [EMAIL PROTECTED] Completely non-sensical bug report. [2002-03-03 17:49:56] [EMAIL PROTECTED] --enable-fff of course is --enable-track-vars [2002-03-03 17:48:43] [EMAIL PROTECTED] The bug appears when I try to compile PHP 4.1.2 as an apxs dynamic apache module. First I had a #configure --with-mysql --with-gd --enable-fff --with-apxs which produced an (almost) empty Makefile afterwards. Only 5 lines of path definitions where in there. This resulted in an error when trying to #make the project, as it returned: make: *** No targets. Stop. I just found the solution! It really is a bug in your configure script, please fix it as soon as you have time. I had the PHP sources located in /mnt/raid/Samba/Linux Programme/php-4.1.2 During the last step (creating files) the configure script tried to access the path, but did not use a metacharacter space (Linux\ Programme), so it tried to write in /mnt/raid/Samba/Linux, where of course no files were! Cool, I got
Bug #15850 Updated: Compiling not possible due to incorrect creation of Makefile
ID: 15850 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: LinuxMandrake 7.2 (2.2.17-21mdk) PHP Version: 4.1.2 New Comment: Here are the version numbers. It really all goes back to the directory, when I changed from "/mnt/raid/Samba/Linux Programme/php-4.1.2" to "/mnt/raid/Samba/php-4.1.2" it worked perfectly. ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) automake (GNU automake) 1.4 Copyright (C) 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Tom Tromey <[EMAIL PROTECTED]> Autoconf version 2.13 Previous Comments: [2002-03-04 14:38:52] [EMAIL PROTECTED] Which versions of libtool, automake and autoconf are you using? Derick [2002-03-04 14:37:08] [EMAIL PROTECTED] Compiling path: /mnt/raid/Samba/Linux Programme/php-4.1.2 Everything works fine until the last step (creating files/generating files), as already mentioned. As this "bogus" _bug_ is reproducible, it would not have been difficult to figure that out by yourself, although I mentioned it. Extract from ./configure +++ Generating files checking for working mkdir -p... (cached) yes creating config_vars.mk updating cache ./config.cache creating ./config.status creating php4.spec creating Zend/Makefile creating main/build-defs.h creating pear/scripts/pear creating pear/scripts/phpize creating pear/scripts/php-config creating pear/scripts/pearize creating pear/scripts/phptar creating TSRM/Makefile creating main/php_config.h main/php_config.h is unchanged creating sapi/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/sapi/Makefile.in: No such file or directory creating ext/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/Makefile.in: No such file or directory creating Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/Makefile.in: No such file or directory creating pear/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/pear/Makefile.in: No such file or directory creating main/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/main/Makefile.in: No such file or directory creating ext/mysql/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/mysql/Makefile.in: No such file or directory creating ext/mysql/libmysql/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/mysql/libmysql/Makefile.in: No such file or directory creating ext/pcre/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/pcre/Makefile.in: No such file or directory creating ext/pcre/pcrelib/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/pcre/pcrelib/Makefile.in: No such file or directory creating ext/posix/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/posix/Makefile.in: No such file or directory creating ext/session/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/session/Makefile.in: No such file or directory creating ext/standard/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/standard/Makefile.in: No such file or directory creating ext/xml/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/xml/Makefile.in: No such file or directory creating ext/xml/expat/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/xml/expat/Makefile.in: No such file or directory creating sapi/apache/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/sapi/apache/Makefile.in: No such file or directory creating regex/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/regex/Makefile.in: No such file or directory creating main/internal_functions.c cat: ./main/internal_functions.c.in: No such file or directory +++ Happy? [2002-03-04 03:02:31] [EMAIL PROTECTED] Completely non-sensical bug report. [2002-03-03 17:49:56] [EMAIL PROTECTED] --enable-fff of course is --enable-track-vars [2002-03-03 17:48:43] [EMAIL PROTECTED] The bug appears when I try to compile PHP 4.1.2 as an apxs dynamic apache module. First I had a #configure --with
Bug #14529 Updated: script doesn't always finish output
ID: 14529
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.1.2
New Comment:
Yasuo - nope. I'm *using* sessions, but the pages that crash it aren't
doing any creating, destroying or unsetting.
In any case, I've been running this morning's snapshot all day without
any problems. It seems to have been fixed (the POST problems went away
as well).
Thanks.
Previous Comments:
[2002-03-04 04:38:12] [EMAIL PROTECTED]
Can you please try a shapshot from snaps.php.net, my guess is that this
is already fixed.
Derick
[2002-03-04 00:55:05] [EMAIL PROTECTED]
It looks you are having session bug.
It seems you are unset()ing $HTTP_SESSION_VARS or $_SESSION somewhere
in your script, aren't you?
[2002-03-03 21:12:33] [EMAIL PROTECTED]
I'm seeing the same problem with 4.1.2. Can reproduce, but with no
consistency.
I'm also seeing a problem where PHP isn't responded to POSTs (watching
it in ethereal, I had to post
repeatedly to get a response; the responding page was to set a couple
cookies and do a redirect). Any
possibility that they might be related?
(Had added a comment with a backtrace, but this one looks much more
useful):
#0 0x402ad693 in _zend_is_inconsistent (ht=0x0,
file=0x403fcb84 "zend_hash.c", line=975) at zend_hash.c:84
#1 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x0,
pos=0xb090)
at zend_hash.c:975
#2 0x4031da18 in php_session_save_current_state () at session.c:544
#3 0x40320579 in php_session_flush () at session.c:1381
#4 0x403205bd in zm_deactivate_session (type=1, module_number=3)
at session.c:1393
#5 0x402ac614 in module_registry_cleanup (module=0x8054dc8) at
zend_API.c:1165
#6 0x402af394 in zend_hash_apply (ht=0x404808c0,
apply_func=0x402ac5d0 ) at
zend_hash.c:669
#7 0x402a8a4e in zend_deactivate_modules () at zend.c:585
#8 0x402b9eb0 in php_request_shutdown (dummy=0x0) at main.c:723
#9 0x402b63ff in apache_php_module_main (r=0x80ab44c,
display_source_mode=0)
at sapi_apache.c:96
#10 0x402b71d0 in send_php (r=0x80ab44c, display_source_mode=0,
filename=0x80ab9cc "/usr/local/apache/htdocs/planworld/index.php")
at mod_php4.c:575
#11 0x402b724c in send_parsed_php (r=0x80ab44c) at mod_php4.c:590
#12 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1
#13 0x400630b9 in ?? () from /lib/libdb.so.3
#14 0x40063529 in ?? () from /lib/libdb.so.3
#15 0x400354e2 in ?? () from /lib/libcrypt.so.1
#16 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1
#17 0x400630b9 in ?? () from /lib/libdb.so.3
#18 0x4006312f in ?? () from /lib/libdb.so.3
#19 0x4005910d in _ufc_foobar () from /lib/libcrypt.so.1
#20 0x400592e3 in _ufc_foobar () from /lib/libcrypt.so.1
#21 0x40059476 in _ufc_foobar () from /lib/libcrypt.so.1
#22 0x40059c34 in _ufc_foobar () from /lib/libcrypt.so.1
#23 0x4005a645 in _ufc_foobar () from /lib/libcrypt.so.1
#24 0x80486dd in ?? () from /usr/local/apache/libexec/mod_caucho.so
#25 0x401589cb in __gconv_transform_internal_utf16 (step=0x80486c0,
data=0x2,
inbuf=0xbaa4, inbufend=0x8048560 "U\211åSè",
written=0x804877c,
do_flush=1073786464) at ../iconv/loop.c:151
[2002-03-03 20:56:34] [EMAIL PROTECTED]
I've been seeing the same thing in 4.1.2. In some cases, it partially
displays pages. In others (I think
this may be related), it doesn't acknowledge a POST until it's been
submitted multiple times (3 or 4
generally). Both behaviors are very inconsistent (they happen
frequently on a site with moderate use, but I
can't reproduce them).
Here's a backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x403fcb84 "zend_hash.c", line=975) at zend_hash.c:84
84 if (ht->inconsistent==HT_OK) {
(gdb) bt
#0 0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x403fcb84 "
>ýÿþ>ýÿýÿ\025?ýÿG?F?ýÿýÿk?l?\205uTvýÿÌ?ýÿUvýÿË?§v¨vù?ýÿýÿýÿýÿx@z@u@ýÿv@w@ýÿýÿê@î@í@ýÿì@\017yýÿýÿ\204A\205A\203Aýÿ¼A½AÔAýÿýÿýÿýÿUBýÿPBLBHBýÿSBýÿWBTBNBJBQBýÿýÿIBKBcBýÿýÿ§B¦B¤Býÿýÿýÿä|å|ýÿýÿe~N~\027Cýÿ\026CýÿýÿcCýÿýÿ\202\177ýÿ{C|Cýÿ"...,
line=975) at zend_hash.c:84
#1 0x4046b258 in ?? () from /usr/local/apache/libexec/libphp4.so
#2 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x5a5a5a5a,
pos=0xb090) at zend_hash.c:975
First symbol in segment of executable not a source symbol
[2002-02-28 17:15:48] [EMAIL PROTECTED]
Regarding the configure line and your MySQL problems. You should N
Bug #15826 Updated: Crash when sending 'authenticate' header
ID: 15826
Updated by: [EMAIL PROTECTED]
-Summary: Crash when sending 'authenticate' header
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Reproducible crash
Operating System: Windows, Linux
PHP Version: 4.1.1
New Comment:
Additional PHP crash on header('WWW-Authenticate') in safe mode info:
My configure command while getting backtrace was:
./configure --with-mysql=/usr/local/mysql
--with-apxs=/usr/local/apache/bin/apxs --enable-xslt --with-xslt-sablot
--with-zlib --with-iconv --enable-debug
though I probably could get segfault without all these extensions.
When compiled with debug, more info appears in apache error_log
than simple 'child segfault':
[Mon Mar 4 09:54:02 2002] Script:
'/usr/local/apache/htdocs/testzone/auth.php'
---
SAPI.c(505) : Block 0x404279DC status:
Beginning: Overrun (magic=0x, expected=0x7312F8DC)
[Mon Mar 4 09:54:03 2002] [notice] child pid 32384 exit signal
Segmentation fault (11)
And finally the backtrace I got under gdb with httpd -X:
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x40128ebc in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0x40128ebc in memcpy () from /lib/libc.so.6
#1 0x0054 in ?? ()
#2 0x401fdf79 in _mem_block_check (ptr=0x402f2a00, silent=1,
__zend_filename=0x402f574d "SAPI.c", __zend_lineno=505,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
zend_alloc.c:659
#3 0x401fce64 in _efree (ptr=0x402f2a00, __zend_filename=0x402f574d
"SAPI.c",
__zend_lineno=505, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at zend_alloc.c:224
#4 0x40231ba6 in sapi_add_header_ex (
header_line=0x810afe4 Z , "\204Ì\217*",
header_line_len=35, duplicate=1 001, replace=1 001) at SAPI.c:505
#5 0x40286ad4 in zif_header (ht=1, return_value=0x810afa4,
this_ptr=0x0,
return_value_used=0) at head.c:56
#6 0x4020a18d in execute (op_array=0x810aec4) at
./zend_execute.c:1590
#7 0x4021b3f0 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at zend.c:814
#8 0x4022df42 in php_execute_script (primary_file=0xb360) at
main.c:1307
#9 0x40228b7e in apache_php_module_main (r=0x80fc154,
display_source_mode=0)
at sapi_apache.c:90
#10 0x40229a6c in send_php (r=0x80fc154, display_source_mode=0,
filename=0x80fdc44 "/usr/local/apache/htdocs/testzone/auth.php")
at mod_php4.c:575
#11 0x40229ae5 in send_parsed_php (r=0x80fc154) at mod_php4.c:590
#12 0x0806c187 in ?? ()
#13 0x0808163b in ?? ()
#14 0x080816b0 in ?? ()
#15 0x08078652 in ?? ()
#16 0x08078824 in ?? ()
#17 0x08078998 in ?? ()
#18 0x08079040 in ?? ()
#19 0x080798cf in ?? ()
#20 0x400bf0de in __libc_start_main () from /lib/libc.so.6
Here PHP 4.1.1 was used with Apache 1.3.22 with mod_ssl
(and all the patches it applies to Apache),
all built from source with standart in that case options
under Mandrake Linux 8.0 'fresh' and quite 'full' installation.
Mysql 3.23.46 was also present and working there, built from source.
The script used to crash PHP was the example script from PHP docs:
Hello $PHP_AUTH_USER.";
echo "You entered $PHP_AUTH_PW as your password.";
}
?>
The same crash occured under Windows 2000, XP, and 98 with downloaded
Apache and PHP binaries, from which no debug info could be extracted :)
Previous Comments:
[2002-03-02 00:16:40] [EMAIL PROTECTED]
A backtrace of a core dump for this would be really helpful. It sounds
like something is going wrong in the realm mangling code which happens
under safe mode in the sapi_add_header_ex() function in main/SAPI.c
If you can reliably reproduce it, build PHP using --enable-debug, run
httpd -X under gdb and when you get the crash, type: bt
Send me that backtrace and I will have a shot at finding it.
[2002-03-01 23:32:46] [EMAIL PROTECTED]
I saw this reported about Linux a couple of times... I dared to report
third time for I met with this bug on both Windows (98, 2000, XP) and
Linux (RedHat 7.0, Mandrake 8.0) - apache child process crashes in PHP
module about half of the time header("WWW-Authenticate...") is sent, if
PHP is in 'Safe Mode'. I think it's a general PHP problem, not related
to OS.
--
Edit this bug report at http://bugs.php.net/?id=15826&edit=1
Bug #15863: ./buildconf and ./configure fail
From: [EMAIL PROTECTED] Operating system: Linux 2.4.10 PHP version: 4.1.2 PHP Bug Type: Compile Failure Bug description: ./buildconf and ./configure fail I am trying to compile 4.1.2 but it fails when trying to add the binary distribution of sablotron without having to recompile (JS package problem) I tried to build the configfile but ./buildconf reports a multiple call to AC_PROG_LEX and the following ./configure fails also. automake 1.5 and 1.4 autoconf 2.54 libtool 1.4.1 Greetings Wolfgang -- Edit bug report at http://bugs.php.net/?id=15863&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15863&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15863&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15863&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15863&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15863&r=support Expected behavior: http://bugs.php.net/fix.php?id=15863&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15863&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15863&r=submittedtwice
Bug #15864: setcookie('cookie_var'); # In CVS. does not delete cookie 'cookie_var'.
From: [EMAIL PROTECTED]
Operating system: linux 2.4
PHP version: 4.0CVS-2002-03-04
PHP Bug Type: Output Control
Bug description: setcookie('cookie_var'); # In CVS. does not delete cookie
'cookie_var'.
FYI, my CVS is dated from Friday, March 1. If this has been fixed in the
past few days, forgive me.
in 4.2.0-dev, setcookie('T'), does not delete the cookie var 'T'. In
4.0.6 this works just fine.
Jeremy
---
Have a cookie called 'T' set to something.
--
Edit bug report at http://bugs.php.net/?id=15864&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15864&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15864&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15864&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15864&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15864&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15864&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15864&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15864&r=submittedtwice
Bug #15317 Updated: setcookie() does not work with CGI PHP
ID: 15317 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Operating System: Windows 2000 SP2 PHP Version: 4.1.1 New Comment: Experiencing the same problem. If the cookies are set using setcookie() on a *nix box, they can successfully be read using PHP/ASP running on Windows or *nix. However, cookies set with PHP using setcookie() on Windows cannot be read by *either* ASP or PHP running on *either* Windows or *nix. Since it's not triggering IE's cookie protection nor lynx's it's a safe assumption that maybe setcookie() just doesnt work on Windows. Previous Comments: [2002-01-31 14:04:31] [EMAIL PROTECTED] When I use the IIS CGI version on Windows the setcookie() function does not set the cookie. The $HTTP_COOKIE_VARS and $_COOKIE arrays are both totally empty. However, it does work with the (very unstable) ISAPI version and always works on Apache no matter the OS. -- Edit this bug report at http://bugs.php.net/?id=15317&edit=1
Bug #14345 Updated: cookies
ID: 14345 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: windows2000 PHP Version: 4.0.6 New Comment: That only applies when you are trying to access the cookie from the same page that wrote it. Since cookie information is sent to the server from the client with the header information, the server cant get the cookie until the header information is sent to it (eg from a page request, refresh, header redirect, etc). That's somewhat different than setcookie() outright not working on win2k/iis5 :) Previous Comments: [2001-12-04 17:17:04] [EMAIL PROTECTED] Not a bug, from the manual (http://uk.php.net/manual/en/function.setcookie.php): Common Pitfalls: * Cookies will not become visible until the next loading of a page that the cookie should be visible for. [2001-12-04 17:15:32] [EMAIL PROTECTED] setcookie does not send cookie to browser, you have to refresh the page for the cookie to be send, i cannot find any other solution -- Edit this bug report at http://bugs.php.net/?id=14345&edit=1
Bug #15864 Updated: setcookie('cookie_var'); # In CVS. does not delete cookie 'cookie_var'.
ID: 15864
Updated by: [EMAIL PROTECTED]
-Summary: setcookie('cookie_var'); # In CVS. does not delete
cookie 'cookie_var'.
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Output Control
Operating System: linux 2.4
PHP Version: 4.0CVS-2002-03-04
New Comment:
Bogus. I'm on crack! ;)
-jeremy
Previous Comments:
[2002-03-04 16:31:37] [EMAIL PROTECTED]
FYI, my CVS is dated from Friday, March 1. If this has been fixed in
the past few days, forgive me.
in 4.2.0-dev, setcookie('T'), does not delete the cookie var 'T'. In
4.0.6 this works just fine.
Jeremy
---
Have a cookie called 'T' set to something.
--
Edit this bug report at http://bugs.php.net/?id=15864&edit=1
Bug #15864 Updated: setcookie('cookie_var'); # In CVS. does not delete cookie 'cookie_var'.
ID: 15864
Updated by: [EMAIL PROTECTED]
-Summary: setcookie('cookie_var'); # In CVS. does not delete
cookie 'cookie_var'.
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Bogus
Bug Type: Output Control
Operating System: linux 2.4
-PHP Version: 4.0CVS-2002-03-04
+PHP Version: 4.0CVS-2002-03-0
New Comment:
bogus means bogus ;)
Previous Comments:
[2002-03-04 18:01:00] [EMAIL PROTECTED]
Bogus. I'm on crack! ;)
-jeremy
[2002-03-04 16:31:37] [EMAIL PROTECTED]
FYI, my CVS is dated from Friday, March 1. If this has been fixed in
the past few days, forgive me.
in 4.2.0-dev, setcookie('T'), does not delete the cookie var 'T'. In
4.0.6 this works just fine.
Jeremy
---
Have a cookie called 'T' set to something.
--
Edit this bug report at http://bugs.php.net/?id=15864&edit=1
Bug #14423 Updated: PHP won't compile with --with-iconv turned on
ID: 14423
Updated by: [EMAIL PROTECTED]
-Summary: PHP won't compile with --with-iconv turned on
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Closed
Bug Type: Compile Failure
Operating System: FreeBSD 4.4-STABLE
PHP Version: 4.1.0
New Comment:
This bug has been fixed in CVS.
Previous Comments:
[2002-03-03 01:36:58] [EMAIL PROTECTED]
any chance you can test this patch out on your machine against a
current CVS checkout?
Index: config.m4
===
RCS file: /repository/php4/ext/iconv/config.m4,v
retrieving revision 1.7
diff -u -r1.7 config.m4
--- config.m4 30 Nov 2001 18:59:38 - 1.7
+++ config.m4 3 Mar 2002 06:24:44 -
@@ -7,15 +7,27 @@
if test "$PHP_ICONV" != "no"; then
+dnl This is a fix for why FreeBSD does not work with ICONV
+dnl It seems libtool checks for libiconv_open which only exists in
+dnl the giconv series of files under FreeBSD
+
+ ac_os_uname = `uname -s 2>/dev/null`
+
+ if test "$ac_os_uname" = "FreeBSD"; then
+ lib_name=giconv
+ else
+ lib_name=iconv
+ fi
+
for i in /usr /usr/local $PHP_ICONV; do
-test -r $i/include/iconv.h && ICONV_DIR=$i
+test -r $i/include/${lib_name}.h && ICONV_DIR=$i
done
if test -z "$ICONV_DIR"; then
AC_MSG_ERROR(Please reinstall the iconv library.)
fi
- if test -f $ICONV_DIR/lib/libconv.a -o -f
$ICONV_DIR/lib/libiconv.$SHLIB_SUFFIX_NAME ; then
+ if test -f $ICONV_DIR/lib/libconv.a -o -f
$ICONV_DIR/lib/lib${lib_name}.$SHLIB_SUFFIX_NAME ;
then
PHP_ADD_LIBRARY_WITH_PATH(iconv, $ICONV_DIR/lib,
ICONV_SHARED_LIBADD)
AC_CHECK_LIB(iconv, libiconv_open, [
AC_DEFINE(HAVE_ICONV, 1, [ ])
Index: php_iconv.h
===
RCS file: /repository/php4/ext/iconv/php_iconv.h,v
retrieving revision 1.9
diff -u -r1.9 php_iconv.h
--- php_iconv.h 13 Dec 2001 14:31:16 - 1.9
+++ php_iconv.h 3 Mar 2002 06:24:44 -
@@ -26,8 +26,9 @@
#define PHP_ICONV_API
#endif
+#if HAVE_ICONV
extern zend_module_entry iconv_module_entry;
-#define phpext_iconv_ptr &iconv_module_entry
+#define iconv_module_ptr &iconv_module_entry;
PHP_MINIT_FUNCTION(miconv);
PHP_MSHUTDOWN_FUNCTION(miconv);
@@ -53,6 +54,14 @@
#define ICONV_INPUT_ENCODING "ISO-8859-1"
#define ICONV_OUTPUT_ENCODING "ISO-8859-1"
#define ICONV_INTERNAL_ENCODING "ISO-8859-1"
+
+#else
+
+#define iconv_module_ptr NULL
+
+#endif /* HAVE_ICONV */
+
+#define phpext_iconv_ptr iconv_module_entry
#endif /* PHP_ICONV_H */
[2002-02-23 06:40:15] [EMAIL PROTECTED]
I'm experiencing the same Problem with PHP4.1.1 and FreeBSD 4.5
[2002-01-24 09:06:32] [EMAIL PROTECTED]
Yes, just tried on 4.5-PRERELEASE.
[2002-01-23 16:29:09] [EMAIL PROTECTED]
Does it *always* fail with the former configure line?
[2001-12-24 10:48:32] [EMAIL PROTECTED]
Here is configure, which works fine. But I cannot find out what caused
it to fail in previous case...
'./configure' '--with-config-file-path=/usr/local/etc/php.standalone'
'--disable-pear'
'--enable-discard-path' '--with-readline=/usr'
'--enable-versioning' '--with-system-regex'
'--disable-debug'
'--enable-track-vars' '--with-gd=/usr/local'
'--with-freetype-dir=/usr/local'
'--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr/local' '--with-zlib' '--with-mysql=/usr/local'
'--with-pgsql=/usr/local'
'--with-openssl=/usr' '--with-xml'
'--with-xmlrpc=/usr/local' '--with-ttf' '--with-freetype'
'--enable-xslt'
'--with-xslt-sablot' '--with-expat-dir=/usr/local'
Bug #15851 Updated: Output has extra garbage past end of output
ID: 15851 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Output Control Operating System: Debian/testing Linux 2.2.18pre21 PHP Version: 4.1.2 New Comment: The extra fragment appears everytime, and is the same whenever the affected page is loaded. We do use trans_sid, however we do not use output buffering of any kind. Interestingly, the problem goes away when output buffering is enabled. Previous Comments: [2002-03-04 00:49:38] [EMAIL PROTECTED] Do you see the extra fragment everytime? Do you use trans sid? Do you use mb_output_handler? Do you use trans sid? Do you use ob_gzhandler? [2002-03-03 20:15:18] [EMAIL PROTECTED] We have some PHP4 scripts, running against PHP4.1.2 and Apache 1.3.23, output buffering off. For some unknown reason, script output has extra fragments of the document, after the tag. Like: ...document... face="Arial"> or ...doc... color="#ff"> -- Edit this bug report at http://bugs.php.net/?id=15851&edit=1
Bug #15865: default PHP_INCLUDE_PATH set to "c:\\php4\\pear"
From: [EMAIL PROTECTED] Operating system: Windows XP PHP version: 4.1.2 PHP Bug Type: PHP options/info functions Bug description: default PHP_INCLUDE_PATH set to "c:\\php4\\pear" in the file php-4.1.2/main/config.w32.h there is the following definition : #define PHP_INCLUDE_PATH"c:\\php4\\pear" in the php-4.1.1 tree it was : #define PHP_INCLUDE_PATHNULL sometimes this causes the include() function not to work, complaining that it didnt find the included file in C:\php4\pear. I reverted back to NULL an the errors are gone. ciao, Enrico -- Edit bug report at http://bugs.php.net/?id=15865&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15865&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15865&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15865&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15865&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15865&r=support Expected behavior: http://bugs.php.net/fix.php?id=15865&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15865&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15865&r=submittedtwice
Bug #15866: using echo for expression 3 in for loop creates parse error
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: Scripting Engine problem Bug description: using echo for expression 3 in for loop creates parse error Using Echo in expression 3 of a for loop creates a parse error. For instance: $blah = (0,1,2,3,4,5,6,7,8,9); for ($i = 0; $i < 10; echo $blah[$i++]); results in this error: Parse error: parse error, expecting `')'' in /home/chunky/public_html/test.php on line XX (line of for loop) However, this will parse properly: $blah = (0,1,2,3,4,5,6,7,8,9); for ($i = 0; $i < 10; print $blah[$i++]); -- Edit bug report at http://bugs.php.net/?id=15866&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15866&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15866&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15866&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15866&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15866&r=support Expected behavior: http://bugs.php.net/fix.php?id=15866&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15866&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15866&r=submittedtwice
Bug #13034 Updated: Apache segfaults when acessing certain scripts
ID: 13034 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Reproducible crash Operating System: RedHat Linux 7.0. PHP Version: 4.1.1 New Comment: No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-02-04 02:18:17] [EMAIL PROTECTED] Could you identify which function call is causing this segfault? http://bugs.php.net/bugs-generating-backtrace.php [2002-01-06 10:15:28] [EMAIL PROTECTED] Well that problem occured some time ago. As far as I can say it doesn't occur with php-4.1.1, but it occured only under some circumstances: Accessing Arrays or Objects in a recursive way. Well with 4.1.1 there are other problems now: When I use the builtin sessionmanagement with register_globals off it doesn't work at all (I followed the release notes) - but that is another story and I don't have the time right now to do debugging on that. best regards Daniel [datenPUNK] Khan [2002-01-06 07:39:33] [EMAIL PROTECTED] Does this problem still occur with 4.1.1 and/or the latest CVS? [2001-08-30 17:10:27] [EMAIL PROTECTED] yes - i couldn't get the crash over apache - then i tried via CGI and it crashed. it crashes with php 4.0.6 and the dev snap of 29th of august. [2001-08-30 17:00:23] [EMAIL PROTECTED] I can not reproduce this. 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/13034 -- Edit this bug report at http://bugs.php.net/?id=13034&edit=1
Bug #15266 Updated: segfault when CR in URL and no CR in body
ID: 15266 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Reproducible crash Operating System: Linux PHP Version: 4.1.1 New Comment: No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-02-04 02:02:29] [EMAIL PROTECTED] To properly diagnose this bug, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read 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". [2002-01-28 20:24:21] [EMAIL PROTECTED] I have a file, test.php, like this: "; ?> No CR, nothing else in there. If I do: lynx -dump 'http://localhost/test.php?a=b' all is well, but lynx -dump 'http://localhost/test.php?a=b ' will crash it,every time. This is on a Debian GNU/Linux box, and it happens on at least two servers I have tried. An i386 running PHP 4.1.1-1 and Alpha AXP running PHP 4.1-2. -- Edit this bug report at http://bugs.php.net/?id=15266&edit=1
Bug #15293 Updated: Incorrect brackets in strlen crashes server
ID: 15293 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Reproducible crash Operating System: Linux 2.2.14-5.0 (RedHat 6.2) PHP Version: 4.0.6 New Comment: No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-02-04 02:07:09] [EMAIL PROTECTED] I think you should have test/development box, aren't you? Anyway, attach complete script that works. i.e. include tag that can directly feed to CGI or CLI version PHP. Even if it a few line. It may be a few line for you, but it will be many line for us with hundreds of bug reports. [2002-01-31 02:12:41] [EMAIL PROTECTED] './configure' '--with-oracle=/u01/app/oracle/product/8.1.6' '--with-oci8=/u01/app/oracle/product/8.1.6' '--with-apache=/usr/local/apache_1.3.20' '--enable-sigchild' Unfortunately, the server is a live and very active server and I can not get approval to change to config to add --enable-debug. Sorry. Quite interestingly the server runs with 10 httpd processes however when the script is executed this dramatically increases to approx 70 processes then gradually dies back to 31 processes before hanging. The time scale for the whole call to hang is round one minute. [2002-01-30 14:52:58] [EMAIL PROTECTED] Can you provide a backtrace (see http://bugs.php.net/bugs-generating-backtrace.php) and your configure-line? [2002-01-30 03:41:25] [EMAIL PROTECTED] Using an apache linux box if the brackets are in the wrong place, (see below) the box spawns hundreds of processes eventually crashing the server. (strlen($local[1] < "3")) [INCORRECT BRACKETS] Rather than: (strlen($local[1]) < "3") [CORRECT BRACKETS] [Basic php install with sigchild enabled and Oracle support] -- Edit this bug report at http://bugs.php.net/?id=15293&edit=1
Bug #15867: Session variable disappears under Windows 2000
From: [EMAIL PROTECTED]
Operating system: Windows 2000 Professional
PHP version: 4.1.0
PHP Bug Type: Session related
Bug description: Session variable disappears under Windows 2000
I have 2 scripts: providerlogin.php sets session variable $userSN
displayprovider.php tests $userSN and displays
info depending on result
Both scripts work as expected under
Win98, Apache 1.13.22, php 4.1.0
WinNT, Apache 1.13.22, php 4.1.0
WinNT, IIS, php 4.1.0
but under Windows 2000 Professional, Apache 1.13.22, php 4.1.0 $userSN has
disappeared when I run displayprovider.php or even if I return to
providerlogin.php.
providerlogin.php
...
session_start(); // starting session
// session variables must be global
global $userSN;
// registering session variables
session_register("userSN");
// test if user is loged-in
?>
$result = odbc_exec($conn, $query);
if(odbc_fetch_row($result, 1)) {
$realUserSN = odbc_result($result, 1);
$providerName = odbc_result($result, 2);
$userName = odbc_result($result, 3);
$realPassword = odbc_result($result, 4);
$refereeStat= odbc_result($result, 5);
$userSN = $realUserSN;
odbc_free_result($result);
odbc_close($conn);
if (isset($userSN)) {
printf("Welcome to Provider
Login");
printf("%s\n", $providerName);
printf("You are logged on from : %s \n",
$REMOTE_ADDR);
}
else printf("ERROR setting session
cookie");
printf("");
exit;
}
else { //didn't find the given password
$notFound = true;
}
displayprovider.php
// If user is logged in, may send messages to this provider
if (isset($userSN)) {
// User may update provider if OnLine and myCookie corresponds to the
displayed provider or is admin login 555fff
if (($OnLine == true) && ($userSN == $providersn)) {
printf("Update
Details\n", $providersn);
}
} //End of myCookie is set, thus user is logged in
else { // if myCookie is not set, print message about logging in
echo "- To send messages to this provider, you must have logged
in.";
}
[Session]
session.save_handler=files
session.save_path=C:\Program Files\PHP\sessiondata; argument passed to
save_handler
session.use_cookies=1
session.name=PHPSESSID
session.auto_start=0
session.cookie_lifetime=0
session.cookie_path=/
session.cookie_domain=
session.serialize_handler=php
session.gc_probability=1
session.gc_maxlifetime=1440
session.referer_check=
session.entropy_length=0
session.entropy_file=
;session.entropy_length=16
;session.entropy_file=/dev/urandom
session.cache_limiter=nocache
session.cache_expire=180
session.use_trans_sid=1
url_rewriter.tags="a=href,area=href,frame=src,input=src,form=fakeentry"
The closest I can find in the bug database is 14636.
Lee
--
Edit bug report at http://bugs.php.net/?id=15867&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15867&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15867&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15867&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15867&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15867&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15867&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15867&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15867&r=submittedtwice
Bug #15866 Updated: using echo for expression 3 in for loop creates parse error
ID: 15866 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.0.6 New Comment: I've found such differences some time ago (but didn't care about it yet). E.g. <-- parser error <-- outputs 1 'print' always evals to int(1) Previous Comments: [2002-03-04 23:31:57] [EMAIL PROTECTED] Using Echo in expression 3 of a for loop creates a parse error. For instance: $blah = (0,1,2,3,4,5,6,7,8,9); for ($i = 0; $i < 10; echo $blah[$i++]); results in this error: Parse error: parse error, expecting `')'' in /home/chunky/public_html/test.php on line XX (line of for loop) However, this will parse properly: $blah = (0,1,2,3,4,5,6,7,8,9); for ($i = 0; $i < 10; print $blah[$i++]); -- Edit this bug report at http://bugs.php.net/?id=15866&edit=1
Bug #15866 Updated: using echo for expression 3 in for loop creates parse error
ID: 15866 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.0.6 New Comment: The last sentence if wrong. print actually returns a value (as stated in the manual), maybe that's the difference. Previous Comments: [2002-03-05 00:19:03] [EMAIL PROTECTED] I've found such differences some time ago (but didn't care about it yet). E.g. <-- parser error <-- outputs 1 'print' always evals to int(1) [2002-03-04 23:31:57] [EMAIL PROTECTED] Using Echo in expression 3 of a for loop creates a parse error. For instance: $blah = (0,1,2,3,4,5,6,7,8,9); for ($i = 0; $i < 10; echo $blah[$i++]); results in this error: Parse error: parse error, expecting `')'' in /home/chunky/public_html/test.php on line XX (line of for loop) However, this will parse properly: $blah = (0,1,2,3,4,5,6,7,8,9); for ($i = 0; $i < 10; print $blah[$i++]); -- Edit this bug report at http://bugs.php.net/?id=15866&edit=1
Bug #9673 Updated: Relative paths in require(), require_once(), include(), include_once()
ID: 9673 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Scripting Engine problem -Operating System: RedHat Linux 7.0 +Operating System: RedHat Linux 7.1 -PHP Version: 4.0.1pl2 +PHP Version: 4.1.1 New Comment: I was happy for awhile, but eventually I noticed a problem with *some* relative paths (in version 4.1.1). Say, there is the main script 'test.php' and two other files, 'a.inc' and 'b.inc' (in subdirs): File './test.php': File './include/a/a.inc': File './include/b.inc': Running 'test.php' fails with: Fatal error: Failed opening required '../b.inc' (include_path='.:/usr/local/lib/php') in /home/geeba/include/a/a.inc on line 2 This isn't intended, is it? Thank you! Previous Comments: [2001-07-16 12:07:02] [EMAIL PROTECTED] include() (and the other functions in its family) will now also look in the current executing file's directory, so this issue should be resolved. [2001-03-15 10:09:07] [EMAIL PROTECTED] We are talking about all four functions here, not just include(). The resemblance of require() to the #include directive, as documented: The require() statement replaces itself with the specified file, much like the C preprocessor's #include works. If it's a "known issue", are there any plans to fix it? Thanks. [2001-03-15 09:08:11] [EMAIL PROTECTED] First, PHP include() is in no way related or was promised to relate to C preprocessor directives, so no wonder it behaves differently. Now, all relative pathes are resolved against the current directory of the including script (which is the directory where it's located). This is a known issue. Use include_pathes in the meantime. [2001-03-10 16:45:48] [EMAIL PROTECTED] Here is an example of how relative paths are currently resolved with cascading inclusions (command line is 'php /home/joe/a.php'): File '/home/joe/a.php': File '/home/joe/include/b.inc': File '/home/joe/include/c.inc': The way all four functions [require(), require_once(), include(), include_once()] resolve relative paths is counter-intuitive and unproductive with large directory structures, because some trickery is required to fix this problem. Not to mention that it hurts to see a different behavior from C-preprocessor #include directives. If you don't believe me, then see comments to the include() function... -- Edit this bug report at http://bugs.php.net/?id=9673&edit=1
Bug #15866 Updated: using echo for expression 3 in for loop creates parse error
ID: 15866 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.0.6 New Comment: echo is a language construct and not a function. It's different this way from print which is a function (a built-in one). Not a bug -> Bogus Derick Previous Comments: [2002-03-05 00:22:42] [EMAIL PROTECTED] The last sentence if wrong. print actually returns a value (as stated in the manual), maybe that's the difference. [2002-03-05 00:19:03] [EMAIL PROTECTED] I've found such differences some time ago (but didn't care about it yet). E.g. <-- parser error <-- outputs 1 'print' always evals to int(1) [2002-03-04 23:31:57] [EMAIL PROTECTED] Using Echo in expression 3 of a for loop creates a parse error. For instance: $blah = (0,1,2,3,4,5,6,7,8,9); for ($i = 0; $i < 10; echo $blah[$i++]); results in this error: Parse error: parse error, expecting `')'' in /home/chunky/public_html/test.php on line XX (line of for loop) However, this will parse properly: $blah = (0,1,2,3,4,5,6,7,8,9); for ($i = 0; $i < 10; print $blah[$i++]); -- Edit this bug report at http://bugs.php.net/?id=15866&edit=1
Bug #15866 Updated: using echo for expression 3 in for loop creates parse error
ID: 15866 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.0.6 New Comment: The something else is bogus too. From the manual: echo() is not actually a function (it is a language construct) ... and print() is not actually a function (it is a language construct) So the phrase "is a language construct" alone doesn't weight much. There *is* a difference, but it's not the 'being a language construct'. Previous Comments: [2002-03-05 01:29:16] [EMAIL PROTECTED] echo is a language construct and not a function. It's different this way from print which is a function (a built-in one). Not a bug -> Bogus Derick [2002-03-05 00:22:42] [EMAIL PROTECTED] The last sentence if wrong. print actually returns a value (as stated in the manual), maybe that's the difference. [2002-03-05 00:19:03] [EMAIL PROTECTED] I've found such differences some time ago (but didn't care about it yet). E.g. <-- parser error <-- outputs 1 'print' always evals to int(1) [2002-03-04 23:31:57] [EMAIL PROTECTED] Using Echo in expression 3 of a for loop creates a parse error. For instance: $blah = (0,1,2,3,4,5,6,7,8,9); for ($i = 0; $i < 10; echo $blah[$i++]); results in this error: Parse error: parse error, expecting `')'' in /home/chunky/public_html/test.php on line XX (line of for loop) However, this will parse properly: $blah = (0,1,2,3,4,5,6,7,8,9); for ($i = 0; $i < 10; print $blah[$i++]); -- Edit this bug report at http://bugs.php.net/?id=15866&edit=1
Bug #13595 Updated: Solution for "PHP Fatal error: Unable to start session mm module in Unknown on
ID: 13595 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Session related Operating System: Debian Sid PHP Version: 4.0.6 New Comment: I'm seeing this problem on Slackware 8.0, when upgrading from the original mod_php.tgz package (PHP 4.0.5) to the updated version (PHP 4.1.2). I already checked, there is no 'session_mm.sem' file to remove (stopping apache automatically removes the file). So my question is, what is going on, and how do I fix it? Previous Comments: [2001-11-11 12:37:22] [EMAIL PROTECTED] So it's not a bug in PHP. Thanks & Closing... [2001-10-08 05:46:33] [EMAIL PROTECTED] Hello there, Every time I when I upgrade my Debian-install I get errors with php4-cgi. When it is invoked, php4-cgi says "PHP Fatal error: Unable to start session mm module in Unknown on line 0". I posted a message, and Peter Cech helped me out: rm /etc/session_mm.sem did the job. Cheers y'all pla. -- Edit this bug report at http://bugs.php.net/?id=13595&edit=1
Bug #13595 Updated: Solution for "PHP Fatal error: Unable to start session mm module in Unknown on
ID: 13595 Updated by: [EMAIL PROTECTED] -Summary: Solution for "PHP Fatal error: Unable to start session mm module in Unknown on Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Feedback Bug Type: Session related Operating System: Debian Sid PHP Version: 4.0.6 New Comment: Can you try a snapshot from snaps.php.net? It might be fixed, if not we need feedback on that branch anyways. regards, Derick Previous Comments: [2002-03-05 01:48:33] [EMAIL PROTECTED] I'm seeing this problem on Slackware 8.0, when upgrading from the original mod_php.tgz package (PHP 4.0.5) to the updated version (PHP 4.1.2). I already checked, there is no 'session_mm.sem' file to remove (stopping apache automatically removes the file). So my question is, what is going on, and how do I fix it? [2001-11-11 12:37:22] [EMAIL PROTECTED] So it's not a bug in PHP. Thanks & Closing... [2001-10-08 05:46:33] [EMAIL PROTECTED] Hello there, Every time I when I upgrade my Debian-install I get errors with php4-cgi. When it is invoked, php4-cgi says "PHP Fatal error: Unable to start session mm module in Unknown on line 0". I posted a message, and Peter Cech helped me out: rm /etc/session_mm.sem did the job. Cheers y'all pla. -- Edit this bug report at http://bugs.php.net/?id=13595&edit=1
Bug #13595 Updated: Solution for "PHP Fatal error: Unable to start session mm module in Unknown on
ID: 13595 Updated by: [EMAIL PROTECTED] -Summary: Solution for "PHP Fatal error: Unable to start session mm module in Unknown on Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Session related Operating System: Debian Sid PHP Version: 4.0.6 New Comment: An other alternative would be to use use 'strace' on the apache process (make sure you start apache with -X switch), maybe you can gather where it has failed, e.g. strace -e trace=file -o output /usr/sbin/apache -X and see in file 'output' what fails. Previous Comments: [2002-03-05 02:17:02] [EMAIL PROTECTED] Can you try a snapshot from snaps.php.net? It might be fixed, if not we need feedback on that branch anyways. regards, Derick [2002-03-05 01:48:33] [EMAIL PROTECTED] I'm seeing this problem on Slackware 8.0, when upgrading from the original mod_php.tgz package (PHP 4.0.5) to the updated version (PHP 4.1.2). I already checked, there is no 'session_mm.sem' file to remove (stopping apache automatically removes the file). So my question is, what is going on, and how do I fix it? [2001-11-11 12:37:22] [EMAIL PROTECTED] So it's not a bug in PHP. Thanks & Closing... [2001-10-08 05:46:33] [EMAIL PROTECTED] Hello there, Every time I when I upgrade my Debian-install I get errors with php4-cgi. When it is invoked, php4-cgi says "PHP Fatal error: Unable to start session mm module in Unknown on line 0". I posted a message, and Peter Cech helped me out: rm /etc/session_mm.sem did the job. Cheers y'all pla. -- Edit this bug report at http://bugs.php.net/?id=13595&edit=1
Bug #15868: infinitive loop hanged apache
From: [EMAIL PROTECTED] Operating system: Debian 3.0 PHP version: 4.1.2 PHP Bug Type: Performance problem Bug description: infinitive loop hanged apache I run php 4.1.2 module with apache 1.3.22 on Debian 3.0 and kernel 2.2.20, glibc version libc6-2.2.4-7. PHP configure line: ./configure' '--prefix=/usr/local/php4' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mysql' '--with-pgsql' '--with-gd' '--enable-ftp' '--with-mail' '--with-jpeg-dir' '--enable-dbase' '--with-freetype-dir' '--enable-gd-native-ttf' '--with-openssl=shared' '--with-curl=shared' '--with-imap' '--enable-trans-sid' '--with-zlib' Sometimes one or more apache processes hang on, using most of CPU time. This processes don't stop, I must kill them by kill -9 pid. Stack of this processes look like: - process hanged after running php script - #0 0x4010fd4f in free () from /lib/libc.so.6 #1 0x4010fac3 in free () from /lib/libc.so.6 #2 0x402fd88c in shutdown_memory_manager (silent=1, clean_cache=0) at zend_alloc.c:485 #3 0x40323880 in php_request_shutdown (dummy=0x0) at main.c:742 #4 0x40320993 in apache_php_module_main (r=0x846120c, display_source_mode=0) at sapi_apache.c:96 #5 0x4032143e in send_php (r=0x846120c, display_source_mode=0, filename=0x0) at mod_php4.c:575 #6 0x403214a5 in send_parsed_php (r=0x846120c) at mod_php4.c:590 #7 0x08076079 in ap_invoke_handler () #8 0x0808b3cf in process_request_internal () #9 0x0808b436 in ap_process_request () #10 0x08082246 in child_main () #11 0x080824ea in make_child () #12 0x08082878 in perform_idle_server_maintenance () #13 0x08082e4c in standalone_main () #14 0x080834ac in main () #15 0x400ba65f in __libc_start_main () from /lib/libc.so.6 - process hanged after display image - #0 0x4010fd4f in free () from /lib/libc.so.6 #1 0x4010fac3 in free () from /lib/libc.so.6 #2 0x4031b15a in zend_hash_del_key_or_index (ht=0x859c030, arKey=0x4047ea31 "rename", nKeyLength=7, h=0, flag=0) at zend_hash.c:517 #3 0x40319662 in zend_unregister_functions (functions=0x404a1bd0, count=-1, function_table=0x0) at zend_API.c:1085 #4 0x4031979d in module_destructor (module=0x858b5d0) at zend_API.c:1127 #5 0x4031b1de in zend_hash_destroy (ht=0x404c91e0) at zend_hash.c:541 #6 0x4031618f in zend_shutdown () at zend.c:494 #7 0x40323e8f in php_module_shutdown () at main.c:995 #8 0x40323e5c in php_module_shutdown_wrapper (sapi_globals=0x40498c60) at main.c:972 #9 0x403219c1 in php_child_exit_handler (s=0x80c0a44, p=0x870b4cc) at mod_php4.c:816 #10 0x0807860c in ap_child_exit_modules () #11 0x0807eb0f in clean_child_exit () #12 0x0808099a in just_die () #13 0x080809bf in usr1_handler () #14 0x400ca848 in sigaction () from /lib/libc.so.6 #15 0x0807ecfc in accept_mutex_on_sysvsem () #16 0x08081e39 in child_main () #17 0x080824ea in make_child () #18 0x08082878 in perform_idle_server_maintenance () #19 0x08082e4c in standalone_main () #20 0x080834ac in main () #21 0x400ba65f in __libc_start_main () from /lib/libc.so.6 -- Edit bug report at http://bugs.php.net/?id=15868&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15868&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15868&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15868&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15868&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15868&r=support Expected behavior: http://bugs.php.net/fix.php?id=15868&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15868&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15868&r=submittedtwice
