[PHP-BUG] Bug #53425 [NEW]: mysqli_real_connect() ignores client flags when built to call libmysql
From: Operating system: PHP version: trunk-SVN-2010-11-29 (SVN) Package: MySQLi related Bug Type: Bug Bug description:mysqli_real_connect() ignores client flags when built to call libmysql Description: The MySQLi PHP extension has a build option, MYSQLI_USE_MYSQLND, that selects between calling the old library libmysql (FALSE) and the new native driver mysqlnd (TRUE). When built to call mysqlnd, the client flags passed in to mysqli_real_connect() (e.g. MYSQLI_CLIENT_FOUND_ROWS) are properly passed down. However, when built to call libmysql, the passed client flags are ignored. I can see no reason for this except that it was an oversight in the change that added the flags argument: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/mysqli/mysqli_nonapi.c?r1=251525r2=252376pathrev=303911 The attached trivial patch fixes this. As current releases of Fedora/RHEL/CentOS (and probably other distributions and platforms) build the MySQLi PHP extension to call libmysql, this is still a relevant issue. -- Edit bug report at http://bugs.php.net/bug.php?id=53425edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53425r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53425r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53425r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53425r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53425r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53425r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53425r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53425r=needscript Try newer version: http://bugs.php.net/fix.php?id=53425r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53425r=support Expected behavior: http://bugs.php.net/fix.php?id=53425r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53425r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53425r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53425r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53425r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53425r=dst IIS Stability: http://bugs.php.net/fix.php?id=53425r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53425r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53425r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53425r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53425r=mysqlcfg
Bug #50918 [Com]: Access violation in php.exe (Bug #49626 redux)
Edit report at http://bugs.php.net/bug.php?id=50918edit=1
ID: 50918
Comment by: bugs-php-net at onethumb dot com
Reported by: hardon at online dot no
Summary: Access violation in php.exe (Bug #49626 redux)
Status: Assigned
Type: Bug
Package: Reproducible crash
Operating System: win32 only - Windows
PHP Version: 5.3.1
Assigned To: pajoye
New Comment:
I'm experiencing this bug (or something extremely similar) on PHP v5.3.2
on
CentOS 5.4.
Essentially, if I build PHP with --enable-maintainer-zts (for use with
Apache's
worker mpm) and try to load any extensions, PHP instantly segfaults at
/ext/date/php_date.c:844 in guess_timezone() when it tries to call
DATEG(timezone):
(gdb) run
Starting program: /home/onethumb/zts/php-5.3.2/sapi/cli/php
[Thread debugging using libthread_db enabled]
[New Thread 0x2b1fea7adc00 (LWP 20681)]
Program received signal SIGSEGV, Segmentation fault.
0x0042ab9d in guess_timezone (tzdb=0xea1f60, tsrm_ls=0x1f370500)
at
/home/onethumb/zts/php-5.3.2/ext/date/php_date.c:844
844 if (DATEG(timezone) (strlen(DATEG(timezone)) 0)) {
I have date.timezone properly set in php.ini. Running without any
extensions
confirms.
Hardcoding guess_timezone() to return a valid timezone simply moves the
crash
farther into php_date, to the next DATEG() call in timezone caching.
Extensions I've tried include very common PECL extensions like zip, apc,
and
memcached, among others. Adding any extension = line to php.ini
appears to
trigger this crash.
Previous Comments:
[2010-03-31 12:31:48] paj...@php.net
Let me try to give Derick a bt and details about the crash.
[2010-03-18 09:02:02] progunster at gmail dot com
Well, after reboot I can't reproduce it anymore.
So, what i did:
1.) Installed httpd-2.2.15-win32-x86-openssl-0.9.8m-r2.msi
It Works!
2.) Changed httpd.conf, to disable http and enable https (also created
self-signed certificates)
3.) Installed PHP from php-5.3.2-Win32-VC6-x86.msi
Right after that httpd.exe was crashing on start. After reboot it all
went gone.
On another computer it was the same.
[2010-03-17 16:05:53] paj...@php.net
When does this crash happen exactly? As you seem to be able to reproduce
it, always, I would like to know how :)
[2010-03-17 15:43:30] progunster at gmail dot com
Added
date.timezone = Europe/Kiev
to [Date] section of php.ini, it didn't helped.
Same error, same place.
[2010-03-17 15:01:48] paj...@php.net
btw, it is not windows specific, crashes occur on other platform as
well.
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/bug.php?id=50918
--
Edit this bug report at http://bugs.php.net/bug.php?id=50918edit=1
#32694 [NEW]: fsockopen timeout - solution for debian lost
From: bugs-php-net at airport1 dot de Operating system: Debian 2.4 - Apache/2.0.52 PHP version: 4.3.10 PHP Bug Type: Network related Bug description: fsockopen timeout - solution for debian lost Description: As stated in several bug reports there CAN be a problem with fsockopen not considering the given timeout. Especially if the connected side is down or hangs. There seems to be a solution (having been online for a long time ago in the archived mailing lists?) for DEBIAN by recompiling PHP with special parameters OR/AND modifying (before?) a file something having to do with fcntl... Unfortunately I have seached for the solution several hours now, but did not find it. Would be nice if someone could point me to the solution (just drop an URL?). Think further: This would also minimize the number of always the same bug report ;-) -- Edit bug report at http://bugs.php.net/?id=32694edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32694r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32694r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32694r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32694r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32694r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32694r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32694r=needscript Try newer version: http://bugs.php.net/fix.php?id=32694r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32694r=support Expected behavior: http://bugs.php.net/fix.php?id=32694r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32694r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32694r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32694r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32694r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32694r=dst IIS Stability: http://bugs.php.net/fix.php?id=32694r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32694r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32694r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32694r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32694r=mysqlcfg
#30935 [Opn]: compact fails for superglobals
ID: 30935
User updated by: bugs-php-net at schirmeier dot com
Reported By: bugs-php-net at schirmeier dot com
Status: Open
Bug Type: Arrays related
Operating System: Linux x86
PHP Version: 5.0.2
New Comment:
Well, Keita Ito thankfully informed me about the Warning: Please note
that variable variables cannot be used with PHP's Superglobal arrays
within functions or class methods. on
http://www.php.net/variables.variable -- which also seems to be valid
for compact().
It'd be helpful if this could be included in the documentation for
compact().
Or even better: Remove this weird behaviour for variable variables AND
compact().
Previous Comments:
[2004-11-29 22:22:48] bugs-php-net at schirmeier dot com
Version: corrected to latest stable version the bug was reproduced
with.
[2004-11-29 22:19:05] bugs-php-net at schirmeier dot com
Description:
compact() does not see superglobals like $_GET/$_POST/etc. when
called within a function (documentation says: Any strings that are not
set will simply be skipped.).
Tested on PHP versions 4.3.2, 4.3.9 (both Apache module and cli),
5.0.0, 5.0.1 (cli), 5.0.2, php5.1-dev-cli.
Reproduce code:
---
?php
function foo()
{
var_dump(compact('_GET', '_POST', '_SESSION', '_ENV', '_COOKIE',
'_SERVER'));
}
var_dump(compact('_GET', '_POST', '_SESSION', '_ENV', '_COOKIE',
'_SERVER'));
echo \n\n;
foo();
?
Expected result:
A dump of an array with indexes '_GET', '_POST' etc. pointing to the
contents of the respective superglobals, then a dashed line, then the
same dump again.
Actual result:
--
The expected dump, the dashed line, and a:0:{}.
--
Edit this bug report at http://bugs.php.net/?id=30935edit=1
#30935 [Opn]: compact fails for superglobals
ID: 30935
User updated by: bugs-php-net at schirmeier dot com
Reported By: bugs-php-net at schirmeier dot com
Status: Open
Bug Type: Arrays related
Operating System: Linux x86
-PHP Version: 4.3.9
+PHP Version: 5.0.2
New Comment:
Version: corrected to latest stable version the bug was reproduced
with.
Previous Comments:
[2004-11-29 22:19:05] bugs-php-net at schirmeier dot com
Description:
compact() does not see superglobals like $_GET/$_POST/etc. when
called within a function (documentation says: Any strings that are not
set will simply be skipped.).
Tested on PHP versions 4.3.2, 4.3.9 (both Apache module and cli),
5.0.0, 5.0.1 (cli), 5.0.2, php5.1-dev-cli.
Reproduce code:
---
?php
function foo()
{
var_dump(compact('_GET', '_POST', '_SESSION', '_ENV', '_COOKIE',
'_SERVER'));
}
var_dump(compact('_GET', '_POST', '_SESSION', '_ENV', '_COOKIE',
'_SERVER'));
echo \n\n;
foo();
?
Expected result:
A dump of an array with indexes '_GET', '_POST' etc. pointing to the
contents of the respective superglobals, then a dashed line, then the
same dump again.
Actual result:
--
The expected dump, the dashed line, and a:0:{}.
--
Edit this bug report at http://bugs.php.net/?id=30935edit=1
#30935 [NEW]: compact fails for superglobals
From: bugs-php-net at schirmeier dot com
Operating system: Linux x86
PHP version: 4.3.9
PHP Bug Type: Arrays related
Bug description: compact fails for superglobals
Description:
compact() does not see superglobals like $_GET/$_POST/etc. when called
within a function (documentation says: Any strings that are not set will
simply be skipped.).
Tested on PHP versions 4.3.2, 4.3.9 (both Apache module and cli), 5.0.0,
5.0.1 (cli), 5.0.2, php5.1-dev-cli.
Reproduce code:
---
?php
function foo()
{
var_dump(compact('_GET', '_POST', '_SESSION', '_ENV', '_COOKIE',
'_SERVER'));
}
var_dump(compact('_GET', '_POST', '_SESSION', '_ENV', '_COOKIE',
'_SERVER'));
echo \n\n;
foo();
?
Expected result:
A dump of an array with indexes '_GET', '_POST' etc. pointing to the
contents of the respective superglobals, then a dashed line, then the same
dump again.
Actual result:
--
The expected dump, the dashed line, and a:0:{}.
--
Edit bug report at http://bugs.php.net/?id=30935edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30935r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30935r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30935r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30935r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30935r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30935r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30935r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30935r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30935r=support
Expected behavior: http://bugs.php.net/fix.php?id=30935r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30935r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30935r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30935r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30935r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30935r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30935r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30935r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30935r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30935r=mysqlcfg
#28898 [Com]: PHP has encountered an Access Violation at 01350AFD
ID: 28898 Comment by: bugs-php-net at remember dot dk Reported By: sam at freepeers dot com Status: Bogus Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.3.7 New Comment: I have the same problem with Windows 2000 Server IIS5 PHP 4.3.7 4.3.8 Running as ISAPI module PHP info here: http://lisa.andersenit.dk/serverinfo/info/php/ If i downgrade to PHP 4.3.6 it works fine again, the only change i have made in php.ini from 4.3.6 to 4.3.7 / 4.3.8 is that i have changed from mysql.trace_mode = On to Off I have this problem on multiple servers. The php4isapi.dll module has been quite stabe until PHP 4.3.7 Previous Comments: [2004-07-08 10:11:34] renato at ostorero dot it - NO COMMENT - [2004-07-06 15:38:54] [EMAIL PROTECTED] The isapi module is unstable at it's best anyway, use CGI if you need stable environment. (or rather, install Apache..) [2004-07-03 21:05:58] renato at ostorero dot it Same problem here, downgrade to 4.3.6 or 4.3.5 doesn't solve it, the only way is to set memory recycling in IIS 6 to very low level such 20 mb for max used memory and 30 for max virtual memory. This way of work permits to recycle often the working processes and limit PHP access violation but in some cases cause event id 1013 exceed of time during shut down. Windows 2003 Enterprise PHP 4.3.5 / 4.3.6 / 4.3.7 ISAPI Extensions: php_gd2.dll [2004-07-02 13:26:46] miho at centrum dot cz Downgrading to 4.3.6 solved that problem for me. Extensions: php_gd2.dll [2004-06-30 15:50:19] sam at freepeers dot com I am not loading any extensions. 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/28898 -- Edit this bug report at http://bugs.php.net/?id=28898edit=1
#24444 [Com]: Problem with argument
ID: 2 Comment by: postings-php-net at hans-spath dot de Reported By: benjamindeliege at hotmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Win 98 + Apache PHP Version: 5.0.0b1 (beta1) New Comment: Let me guess, you have register_globals = off in your php.ini? Previous Comments: [2003-07-01 13:55:31] [EMAIL PROTECTED] Works fine here. Try $_GET['id'].. [2003-07-01 13:48:17] benjamindeliege at hotmail dot com Description: Hello, In php 4 when i called a page with : index.php?id=355 id take the value 355 But with php 5 when I call this same page with the same argument, id don't take any value... I don't know if it's a bug, I hope because it's very easy to call page with argument by this way... Benjamin Deliege... -- Edit this bug report at http://bugs.php.net/?id=2edit=1
#20473 [Com]: Cannot redeclare gc()
ID: 20473 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Unknown/Other Function Operating System: Linux PHP Version: 4.3.0RC1 New Comment: I found it to be an old line in my php.ini: auto_prepend = /usr/local/apache/php/prepend.php3 Update your php.ini and you'll see it goes away again. Edwin, bitten by this problem too :-) Previous Comments: [2003-02-04 15:30:53] [EMAIL PROTECTED] SURELY someone knows how to fix this annoying error? It was first reported over 2 months ago and there are no postings on this problem report showing a resolution. Well? [2003-01-02 07:42:13] [EMAIL PROTECTED] This one also just hit me upgrading from 4.2.3 to 4.3.0 on Gentoo Linux. Since I cannot seem to find a solution online, I will try and rename the PHPLIB functions. [2002-12-06 21:56:44] [EMAIL PROTECTED] Has anybody got a solution for this problem. The same thing is happening to some of our websites. Is there some setting in php.ini file that can be set to get around this problem. Thanks, Craig Marchant [2002-11-18 01:56:50] [EMAIL PROTECTED] seems that this is an enhancement of php - because the bug is really in phplib. sorry. [2002-11-18 01:30:18] [EMAIL PROTECTED] Our webserver scripts make heavy use of the phplib. with php4.3.0rc1 I will get the error Fatal error: Cannot redeclare gc() in /usr/lib/php/phplib/session.inc on line 461 thats because phplib defines a function named gc(). with the php4.3.pre1 and earlier versions this problem has not been apeared - last but not least with the documentation I have not found a hint about a gc() function within php itself. -- Edit this bug report at http://bugs.php.net/?id=20473edit=1
#21931 [NEW]: Mail() fifth parameter
From: [EMAIL PROTECTED] Operating system: Linux 2.4.19 PHP version: 4.3.0 PHP Bug Type: Mail related Bug description: Mail() fifth parameter The fifth parameter of the mail() function is disabled in safe_mode, but the changelog says the security issue is already fixed: Changed mail() to use escape_shell_cmd() to allow multiple extra parameters to the invocation of the mailer as used in the fifth parameter. (Derick) Can it be enabled in the next version of php? -- Edit bug report at http://bugs.php.net/?id=21931edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21931r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21931r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21931r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21931r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21931r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21931r=support Expected behavior: http://bugs.php.net/fix.php?id=21931r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21931r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21931r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21931r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21931r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21931r=dst IIS Stability: http://bugs.php.net/fix.php?id=21931r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21931r=gnused
#21830 [Bgs]: libphp4.so not created
ID: 21830 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: RedHat 7.3 PHP Version: 4.3.0 New Comment: BTW, php-4.2.3 works just fine with Apache 2.0.44 Previous Comments: [2003-01-22 21:39:54] [EMAIL PROTECTED] I'll recompile Apache 2.0.44 again and try with the latest snapshot and see what I get... I appreciate you taking the time to confirm Apache 2.0.44 and PHP's snapshot will work fine on RedHat 7.3 Thanks! [2003-01-22 21:31:55] [EMAIL PROTECTED] If it only happens with Apache2, I suggest you check your apache2 installation and preferrably reinstall it anyway. I just tried with latest Apache2 and it works just fine here. In any case, this is not a PHP bug. [2003-01-22 21:20:14] [EMAIL PROTECTED] sapi/cli/php compiled successfully I'll keep trying things to see if I can get libphp4.so created. [2003-01-22 21:17:29] [EMAIL PROTECTED] That is not an error..it's just a warning which can safely be ignore. [2003-01-22 21:06:12] [EMAIL PROTECTED] Results: [snip] ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam': /bulk/jay/build/php4-STABLE-200301230230/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' No libphp4.so created... I will try your suggested configure options next 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/21830 -- Edit this bug report at http://bugs.php.net/?id=21830edit=1
#21830 [NEW]: libphp4.so not created
From: [EMAIL PROTECTED] Operating system: RedHat 7.3 PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: libphp4.so not created I am trying to create the DSO version for Apache 2.0.44 $ ./configure --with-mysql --with-axps2=/web/bin/apxs Normal output. $ make all (does not complete) $ make libphp4.la [snip] ext/ctype/ctype.lo: file not recognized: File truncated collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 $ make libs/libphp4.bundle [snip]... /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [libs/libphp4.bundle] Error 1 There is nothing in libs and there is nothing in .libs I have also tried this with php4-STABLE-200301220430 and I get the same results. -- Edit bug report at http://bugs.php.net/?id=21830edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21830r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21830r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21830r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21830r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21830r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21830r=support Expected behavior: http://bugs.php.net/fix.php?id=21830r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21830r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21830r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21830r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21830r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21830r=dst IIS Stability: http://bugs.php.net/fix.php?id=21830r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21830r=gnused
#21830 [Com]: libphp4.so not created
ID: 21830 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: RedHat 7.3 PHP Version: 4.3.0 New Comment: Ok. I just removed config.cache and did make clean. Running make again... I will report results shortly. Previous Comments: [2003-01-22 20:14:52] [EMAIL PROTECTED] Please check this report, and the last comment in it: http://bugs.php.net/bug.php?id=19924 This really isn't any PHP bug but something done wrong. (rm config.cache / make clean usually helps.) [2003-01-22 20:08:09] [EMAIL PROTECTED] I am trying to create the DSO version for Apache 2.0.44 $ ./configure --with-mysql --with-axps2=/web/bin/apxs Normal output. $ make all (does not complete) $ make libphp4.la [snip] ext/ctype/ctype.lo: file not recognized: File truncated collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 $ make libs/libphp4.bundle [snip]... /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [libs/libphp4.bundle] Error 1 There is nothing in libs and there is nothing in .libs I have also tried this with php4-STABLE-200301220430 and I get the same results. -- Edit this bug report at http://bugs.php.net/?id=21830edit=1
#21830 [Com]: libphp4.so not created
ID: 21830 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: RedHat 7.3 PHP Version: 4.3.0 New Comment: $ make libphp4.la [snip] ext/ctype/ctype.lo: file not recognized: File truncated collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 $ cat ext/ctype/ctype.lo [one blank line] $ make libs/libphp4.bundle [snip] /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [libs/libphp4.bundle] Error 1 $ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o glibc-devel-2.2.5-42 Should I be using gcc3 perhaps? Previous Comments: [2003-01-22 20:23:14] [EMAIL PROTECTED] Ok. I just removed config.cache and did make clean. Running make again... I will report results shortly. [2003-01-22 20:14:52] [EMAIL PROTECTED] Please check this report, and the last comment in it: http://bugs.php.net/bug.php?id=19924 This really isn't any PHP bug but something done wrong. (rm config.cache / make clean usually helps.) [2003-01-22 20:08:09] [EMAIL PROTECTED] I am trying to create the DSO version for Apache 2.0.44 $ ./configure --with-mysql --with-axps2=/web/bin/apxs Normal output. $ make all (does not complete) $ make libphp4.la [snip] ext/ctype/ctype.lo: file not recognized: File truncated collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 $ make libs/libphp4.bundle [snip]... /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [libs/libphp4.bundle] Error 1 There is nothing in libs and there is nothing in .libs I have also tried this with php4-STABLE-200301220430 and I get the same results. -- Edit this bug report at http://bugs.php.net/?id=21830edit=1
#21830 [Com]: libphp4.so not created
ID: 21830 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: RedHat 7.3 PHP Version: 4.3.0 New Comment: Yes. I still have a working copy of php-4.2.3 from last year that I compiled, installed, and have been running... but I wanted to tempt fate tonight... :) I am pulling back the snap and will report results. Thanks! Previous Comments: [2003-01-22 20:44:34] [EMAIL PROTECTED] btw. Were you able to compile any previous PHP versions?? Like 4.2.3 ?? [2003-01-22 20:43:57] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip That libs/libphp4.bundle is NOT meant for Linux, it's for MacOSX so using it does not help. Please try the snapshot. [2003-01-22 20:39:25] [EMAIL PROTECTED] $ make libphp4.la [snip] ext/ctype/ctype.lo: file not recognized: File truncated collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 $ cat ext/ctype/ctype.lo [one blank line] $ make libs/libphp4.bundle [snip] /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [libs/libphp4.bundle] Error 1 $ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o glibc-devel-2.2.5-42 Should I be using gcc3 perhaps? [2003-01-22 20:23:14] [EMAIL PROTECTED] Ok. I just removed config.cache and did make clean. Running make again... I will report results shortly. [2003-01-22 20:14:52] [EMAIL PROTECTED] Please check this report, and the last comment in it: http://bugs.php.net/bug.php?id=19924 This really isn't any PHP bug but something done wrong. (rm config.cache / make clean usually helps.) 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/21830 -- Edit this bug report at http://bugs.php.net/?id=21830edit=1
#21830 [Fbk-Opn]: libphp4.so not created
ID: 21830 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: RedHat 7.3 PHP Version: 4.3.0 New Comment: No, not -exactly- I have all current RPM's from RedHat via up2date installed so I am sure gcc and glibc, for example, are the latest version(s) and not what was installed last year. Sorry about using the comment entry. Previous Comments: [2003-01-22 20:56:33] [EMAIL PROTECTED] And please don't use the 'Add Comment' when you add comments to your _own_ report. Anyway, can you try this configure line if the snapshot fails too: ./configure --disable-all --disable-cgi [2003-01-22 20:54:18] [EMAIL PROTECTED] So you compiled 4.2.3 with the EXACTLY same environment? Same compiler version, same kernel, etc? [2003-01-22 20:49:02] [EMAIL PROTECTED] Yes. I still have a working copy of php-4.2.3 from last year that I compiled, installed, and have been running... but I wanted to tempt fate tonight... :) I am pulling back the snap and will report results. Thanks! [2003-01-22 20:44:34] [EMAIL PROTECTED] btw. Were you able to compile any previous PHP versions?? Like 4.2.3 ?? [2003-01-22 20:43:57] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip That libs/libphp4.bundle is NOT meant for Linux, it's for MacOSX so using it does not help. Please try the snapshot. 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/21830 -- Edit this bug report at http://bugs.php.net/?id=21830edit=1
#21830 [Opn]: libphp4.so not created
ID: 21830 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: RedHat 7.3 PHP Version: 4.3.0 New Comment: Results: [snip] ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam': /bulk/jay/build/php4-STABLE-200301230230/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' No libphp4.so created... I will try your suggested configure options next Previous Comments: [2003-01-22 21:01:50] [EMAIL PROTECTED] No, not -exactly- I have all current RPM's from RedHat via up2date installed so I am sure gcc and glibc, for example, are the latest version(s) and not what was installed last year. Sorry about using the comment entry. [2003-01-22 20:56:33] [EMAIL PROTECTED] And please don't use the 'Add Comment' when you add comments to your _own_ report. Anyway, can you try this configure line if the snapshot fails too: ./configure --disable-all --disable-cgi [2003-01-22 20:54:18] [EMAIL PROTECTED] So you compiled 4.2.3 with the EXACTLY same environment? Same compiler version, same kernel, etc? [2003-01-22 20:49:02] [EMAIL PROTECTED] Yes. I still have a working copy of php-4.2.3 from last year that I compiled, installed, and have been running... but I wanted to tempt fate tonight... :) I am pulling back the snap and will report results. Thanks! [2003-01-22 20:44:34] [EMAIL PROTECTED] btw. Were you able to compile any previous PHP versions?? Like 4.2.3 ?? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/21830 -- Edit this bug report at http://bugs.php.net/?id=21830edit=1
#21830 [Fbk-Opn]: libphp4.so not created
ID: 21830 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: RedHat 7.3 PHP Version: 4.3.0 New Comment: sapi/cli/php compiled successfully I'll keep trying things to see if I can get libphp4.so created. Previous Comments: [2003-01-22 21:17:29] [EMAIL PROTECTED] That is not an error..it's just a warning which can safely be ignore. [2003-01-22 21:06:12] [EMAIL PROTECTED] Results: [snip] ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam': /bulk/jay/build/php4-STABLE-200301230230/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' No libphp4.so created... I will try your suggested configure options next [2003-01-22 21:01:50] [EMAIL PROTECTED] No, not -exactly- I have all current RPM's from RedHat via up2date installed so I am sure gcc and glibc, for example, are the latest version(s) and not what was installed last year. Sorry about using the comment entry. [2003-01-22 20:56:33] [EMAIL PROTECTED] And please don't use the 'Add Comment' when you add comments to your _own_ report. Anyway, can you try this configure line if the snapshot fails too: ./configure --disable-all --disable-cgi [2003-01-22 20:54:18] [EMAIL PROTECTED] So you compiled 4.2.3 with the EXACTLY same environment? Same compiler version, same kernel, etc? 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/21830 -- Edit this bug report at http://bugs.php.net/?id=21830edit=1
#21830 [Bgs]: libphp4.so not created
ID: 21830 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: RedHat 7.3 PHP Version: 4.3.0 New Comment: I'll recompile Apache 2.0.44 again and try with the latest snapshot and see what I get... I appreciate you taking the time to confirm Apache 2.0.44 and PHP's snapshot will work fine on RedHat 7.3 Thanks! Previous Comments: [2003-01-22 21:31:55] [EMAIL PROTECTED] If it only happens with Apache2, I suggest you check your apache2 installation and preferrably reinstall it anyway. I just tried with latest Apache2 and it works just fine here. In any case, this is not a PHP bug. [2003-01-22 21:20:14] [EMAIL PROTECTED] sapi/cli/php compiled successfully I'll keep trying things to see if I can get libphp4.so created. [2003-01-22 21:17:29] [EMAIL PROTECTED] That is not an error..it's just a warning which can safely be ignore. [2003-01-22 21:06:12] [EMAIL PROTECTED] Results: [snip] ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam': /bulk/jay/build/php4-STABLE-200301230230/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' No libphp4.so created... I will try your suggested configure options next [2003-01-22 21:01:50] [EMAIL PROTECTED] No, not -exactly- I have all current RPM's from RedHat via up2date installed so I am sure gcc and glibc, for example, are the latest version(s) and not what was installed last year. Sorry about using the comment entry. 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/21830 -- Edit this bug report at http://bugs.php.net/?id=21830edit=1
#21536 [NEW]: ob_get_length() is broken for ob_gzhandler and zlib.output_compression
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.7 PHP version: 4.3.0 PHP Bug Type: Output Control Bug description: ob_get_length() is broken for ob_gzhandler and zlib.output_compression When ob_gzhandler or zlib.output_compression is switched on, ob_get_length() should report the compressed length, however it reports the uncompressed length. I found an old bug - #12631 - that is identical to this, but it seems it was fixed a while ago, and then unfixed. I cannot seem to work around it with strlen(ob_get_contents()). -- Edit bug report at http://bugs.php.net/?id=21536edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21536r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21536r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21536r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21536r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21536r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21536r=support Expected behavior: http://bugs.php.net/fix.php?id=21536r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21536r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21536r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21536r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21536r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21536r=dst IIS Stability: http://bugs.php.net/fix.php?id=21536r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21536r=gnused
#20802 [Com]: memory limit crash
ID: 20802
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Redhat 7.0
PHP Version: 4.3.0RC2
New Comment:
I have reproduced this issue with the released 4.3.0. When the memory
limit is exceeded, the program dies without the slitest indication as
to why.
The exact same test with PHP 4.2.3 prints an error: PHP Fatal error:
Allowed memory size of 10485760 bytes exhausted (tried to allocate 1
bytes) in - on line 1. The following command line is what I used to
produce the message above:
echo -n '?php $s = ; for ($i = 0; $i 100; $i++) {$s .=
;} print(finished); ?' | php -q
Previous Comments:
[2002-12-18 03:01:01] [EMAIL PROTECTED]
I have the same problem with PHP 4.2.3 on SPARC Solaris 2.7. My program
is very complex and I cannot provide simple script to reproduce it.
It seems to be hitting default 8 mb memory at random points in the code
when it processed enough data.
But instead of reporting an error, PHP engine just dies and re-starts
execution of the script from the very beginning (!).
No records in the logs.
PHP is running as Apache 1.3.26 module.
[2002-12-13 07:24:57] [EMAIL PROTECTED]
I'm having the same problem with PHP 4.3RC3 with Apache 2.0.43 running
with the perchild MPM.
After the crash occours, apache does not accept any more connections,
even though there are other processes that could handle them, and I'm
required to restart it.
Here are some outputs from ps and top, before and after the crash,
perhaps it will be usefull with something:
/* I've pasted only the part that shows the root process, and a
single child with its accompanying threads; there are 4 more children
(with their threads), but they are similar and their state doesn't
change */
(1) ps ax --forest before
3541 ?S 0:00 /opt/httpd-2.0.43/bin/httpd -k start
3542 ?S 0:00 \_ /opt/httpd-2.0.43/bin/httpd -k start
3545 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k
start
3546 ?S 0:38 | \_ /opt/httpd-2.0.43/bin/httpd -k
start
3549 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k
start
3550 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k
start
3556 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k
start
3561 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k
start
3578 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k
start
(2) ps ax --forest before
3541 ?S 0:00 /opt/httpd-2.0.43/bin/httpd -k start
3542 ?S 0:00 \_ /opt/httpd-2.0.43/bin/httpd -k start
3545 ?Z 0:00 | \_ [httpd defunct]
(3) top output after the crash
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ Command
PPID nFLT nDRT WCHAN Flags
3542 httpd 9 0 58028 56m 4972 S 0.0 7.5 0:00.00
/opt/httpd- 35411 13k rt_sigsus .14.
3545 httpd 8 0 000 Z 0.0 0.0 0:00.04 ( httpd
de 354200 exit ..44
on previous occassions, when I did not know about this bug, I used to
kill the child process with SIGTERM. That, plus other things, has
yielded some lines in the apache log.
(1)This is after sending a signal:
[Thu Dec 12 20:03:16 2002] [notice] child pid 2716 exit signal
Segmentation fault (11)
(2) This is probably related somehow:
[Thu Dec 12 20:14:02 2002] [info] (104)Connection reset by peer:
core_output_filter: writing data to the net
work
[Thu Dec 12 20:14:03 2002] [info] (32)Broken pipe: core_output_filter:
writing data to the network
[2002-12-08 06:19:34] [EMAIL PROTECTED]
I can also verify this with 4.3.0-cvs. With the cli PHP I can get a
core dump showing a nearly endless calling stack - probably the
memory_limit only looks at the data size, not at the stack size (but of
course this huge stack usage should not happen in the first place).
#0 0x081d0c26 in php_error_cb ()
(gdb) bt -30
#29239 0x081d0c4d in php_error_cb ()
#29240 0x08209b38 in zend_error ()
#29241 0x081f5d03 in _emalloc ()
#29242 0x081f5fc1 in _erealloc ()
#29243 0x081d4154 in xbuf_resize ()
#29244 0x081d41ec in xbuf_init ()
#29245 0x081d4f4a in vspprintf ()
#29246 0x081d0c4d in php_error_cb ()
#29247 0x08209b38 in zend_error ()
#29248 0x081f5d03 in _emalloc ()
#29249 0x081f5fc1 in _erealloc ()
#29250 0x081d4154 in xbuf_resize ()
#29251 0x081d41ec in xbuf_init ()
#29252 0x081d4f4a in vspprintf ()
#29253 0x081d0c4d in php_error_cb ()
#29254 0x08209b38 in zend_error ()
#29255 0x081f5d03 in _emalloc ()
#29256 0x081f5fc1 in _erealloc ()
#29257 0x081d4154 in xbuf_resize ()
#29258 0x081d41ec in xbuf_init ()
#20989 [Com]: URL variable without = affects other URL variable
ID: 20989 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: *URL Functions Operating System: Linux PHP Version: 4.2.2 New Comment: The bug has already been fixed, I checked 4.4.0-dev (php4-200212191830). Previous Comments: [2002-12-13 08:17:47] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-13 08:16:24] [EMAIL PROTECTED] ?abc=3d=4e=5 This results in HTTP_GET_VARS: a= b= c=3 The variables d and e are missing. For each variable without = it deletes a variable at the end. -- Edit this bug report at http://bugs.php.net/?id=20989edit=1
#20989 [NEW]: URL variable without = affects other URL variable
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.2 PHP Bug Type: *URL Functions Bug description: URL variable without = affects other URL variable ?abc=3d=4e=5 This results in HTTP_GET_VARS: a= b= c=3 The variables d and e are missing. For each variable without = it deletes a variable at the end. -- Edit bug report at http://bugs.php.net/?id=20989edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20989r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20989r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20989r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20989r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20989r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20989r=support Expected behavior: http://bugs.php.net/fix.php?id=20989r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20989r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20989r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20989r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20989r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20989r=dst IIS Stability: http://bugs.php.net/fix.php?id=20989r=isapi
#16411 [Com]: CGI application misbehaved by not returning a complete set of
ID: 16411 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: What are you doing with your database connections? Are they persistant (mssql_pconnect) or transient (mssql_connect)? Do you close your connections explicitly (mssql_close) before the end of your script? vielina, your connections will be closed each time as you are running under the CGI. Previous Comments: [2002-11-21 03:29:36] [EMAIL PROTECTED] I have this problem too. [2002-06-20 15:19:45] [EMAIL PROTECTED] Same problem, slightly different case... win2000 running php.exe 4.2.1 (and mssql 2000) seems to happen mostly during redrects like... header(Method: GET); header(Status: 302 Moved); header(Location: . $ABSOLUTE_URL); some claim they solved this problem by applying the workaround by microsoft (Q160422). others say they have fixed this by blanking out the doc_root in php.ini I still have this problem [2002-06-02 22:14:18] [EMAIL PROTECTED] I did that but it still did not work. I further tested another way: I left every thing as it was, except that I did not open an MSSQL connection. The script worked pretty well. When I changed it back, the same type of bug happened. When looking at phpinfo, even with the latest php version (4.2.1) I saw that in the MSSQL support section, the MSSQL library version was 7.0. Is this a potential source of that bug? Loi Le V. [2002-06-02 17:53:17] [EMAIL PROTECTED] Please try it again with a right header like Location: http://www.domain.tld/some.php. Location header needs a complete absolute URI. Regards, Kai [2002-04-03 09:46:44] [EMAIL PROTECTED] I have the same set of php scripts, php 4.0.6 CGI running on: 1-Windows NT 4.0 with IIS4, MySQL, MS-SQL 7; this works fine; 2-Windows 2000 server with IIS5, MySQL, MS-SQL 7; this works fine; 3-Windows 2000 advanced server with IIS5, MySQL, MS-SQL 7; this works fine; 4-Windows 2000 advanced server with IIS5, MySQL, MS-SQL 2000; this still works except that a curious error occurs: Im using a lot of Header (location: some.php) for redirections. In this particular installation, right after the call of header function, the browser still gets the right URI, but then it issues the following error (a copy again here): message CGI ERROR CGI application misbehaved by not returning a complete set of headers.The headers that it did return are: /message The funny thing was that if I refresh the page then it works just fine. When I look back at the 4 installations, the only difference was the installation 4: MS-SQL 2000. I later made another test: from the installation 3, I made an upgrade of MS SQL from 7.0 to 2000. The same problem happened. I have tested with php 4.1.2 and 4.0.6. I had the same symptoms with both versions Is there anything in php_mssql that does the job with MS-SQL 2000 but has some sort of side-effect that causes the above strange bug? Would any one spend time looking into the code? It would help us a lot. Thank you very much! Loi Le V. -- Edit this bug report at http://bugs.php.net/?id=16411edit=1
#17563 [Com]: PHP has encountered an Access Violation at 77XXXXX
ID: 17563 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MSSQL related Operating System: WIN2K PHP Version: 4.2.1 New Comment: Can you please be very specific about your table and column names. The ODBC driver doesn't handle odd names very well. There's a big difference between: SELECT * FROM froo SELECT * FROM [FR oO] Previous Comments: [2002-08-25 23:54:30] [EMAIL PROTECTED] Yes, try that first, after recreate the data field, I have no problem afterwards. You can use the mssql.dll if you want~ I use that in all time, I don't like ODBC, [2002-08-25 00:51:28] [EMAIL PROTECTED] Hi I Have this problem Too I use an Odbc conennection on Win2000 prof and IIS ver 5 I try to fetch some data from my database by this lines : $query=Select username,name,family,Sex,pic,pic_type ,about from [users]; ... ... $username = odbc_result($result, 1); $name = odbc_result($result, 2); this page is work probebly at first time but after some refreshing I recive PHP has encountered an Access Violation at X only at this page and other .php page is work probebly; I install PHP on my computer in ISAPI mode in my users table Pic_type and about allow null I rename these fieldes but not effect . you say I remove this field's and add them again ? is it effective? I try it but not sure thank's [2002-06-08 20:28:34] [EMAIL PROTECTED] Server Version: MSSQL Server 2000 Operating System: WIN2K Server Database Details: The error field is smallmoney, allow null. Error Solution: I've tried rename it with other field which is also 'smallmoney' and 'allow null', but problem does not solve this way. The only way to solve this problem is to remove that field and create another new field again. Notice: Notice that the field works fine inside the MSSQL server's 'Query Analyzer', no error occur inside MSSQL server itself, but it produce error with the PHP engine. How does the bug act like: This error might not hang the whole php engine in first few times you recieve the message PHP has encountered an Access Violation at , but it will eventually hang when you load that page few more times. [2002-06-08 05:05:19] [EMAIL PROTECTED] That's a start (and probably not a duplicte). But we need more information. What vrsion of MSSQL ? And type was this field of ? Can you reproduce this by creating a second field exactly as the first which crashes, which crashes too ? Please be as detailed as possible about the database setup and the field in general (so someone with the appropriate environment can rebuild this scenery), thx. [2002-06-08 04:54:26] [EMAIL PROTECTED] GUYS!! Found it, as I said, there is one field have error, I remove that field and add another field that is exactly the same datatype and everything and the problem solved. Try it out. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/17563 -- Edit this bug report at http://bugs.php.net/?id=17563edit=1
#18933 [Com]: MSSQL issues under stress
ID: 18933
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: MSSQL related
Operating System: win2k
PHP Version: 4.2.2
New Comment:
Looks like two separate bugs.
#1 - this would be a problem with your MS SQL server settings. Not a
PHP issue.
#2, #3, #4 - are you running as an ISAPI or CGI? There are issues with
PHP ISAPI under stress.
Previous Comments:
[2002-08-15 20:43:32] [EMAIL PROTECTED]
The MSSQL extension seems to have a few issues under heavy stress.
Running a similar test with a mysql server produces no errors:
?
$link = mssql_connect(127.0.0.1,1,1);
mssql_select_db(test);
$bit_result = mssql_query('SELECT testbitmoo FROM testbit');
$bit_row = mssql_fetch_array($bit_result);
print $bit_row['testbitmoo'];
mssql_close ($link);
?
Running the above test script produces the following error log
entries:
1. MS SQL: Unable to connect to server: 127.0.0.1
-- mysql doesn't fail taking new connections, but that error could be
a server config setting.
2.
Corrupt Log file Entries e.g. :
ndex.php on line 3
2
ine 8
tdocs\php\index.php on line 8
3. Failure connecting to server null:
MS SQL: Unable to connect to server: (null)
(should be 127.0.0.1)
4. Attempting to connect as a null user:
MS SQL message: Login failed for user '(null)'.
(should be 1)
Paul
--
Edit this bug report at http://bugs.php.net/?id=18933edit=1
#20649 [NEW]: date(W) is buggy
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.3 PHP Bug Type: Date/time related Bug description: date(W) is buggy Hi, check this out: echo date(W,mktime(0,0,0,12,31,2002)); It's 53 instead of 1. Greetz, BS -- Edit bug report at http://bugs.php.net/?id=20649edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20649r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20649r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20649r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20649r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20649r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20649r=support Expected behavior: http://bugs.php.net/fix.php?id=20649r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20649r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20649r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20649r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20649r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20649r=dst IIS Stability: http://bugs.php.net/fix.php?id=20649r=isapi
#20568 [NEW]: Apache2/PHP 4.2.3 File Upload Corruption
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.3 PHP Bug Type: Apache2 related Bug description: Apache2/PHP 4.2.3 File Upload Corruption Hi there, I'm seeing odd corruption occurring to JPEG files (others unconfirmed) when uploading using POST. This is a localhost-localhost connection, on a file getting uploaded from the same hard disk that the web server saves it to. Upon downgrading to Apache 1.3.27, the problem went away. At the URL below you can find my configuration details, the code that handles the upload (I'm pretty sure it's not that), and some sample damaged files. I cannot tell what kind of damage is occurring, the file size changes randomly, as does the visible damage to the image. I have tried with both w3m and Mozilla. Sample files, the code, my configuration: http://botanicus.net/dw/tmp/phpbug/ Thanks, Dave. -- Edit bug report at http://bugs.php.net/?id=20568edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20568r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20568r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20568r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20568r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20568r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20568r=support Expected behavior: http://bugs.php.net/fix.php?id=20568r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20568r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20568r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20568r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20568r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20568r=dst IIS Stability: http://bugs.php.net/fix.php?id=20568r=isapi
#20516 [NEW]: RFC: C-style string concatenation
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.3 PHP Bug Type: Feature/Change Request Bug description: RFC: C-style string concatenation Hi there, I was wondering if it would be at all possible to get ANSI C / ISO C99-style string literal concatenation added? The PHP syntax already borrows so much from C that this seems to be a worthy addition. It would also make it much easier for wrapping ugly SQL for pretty source files. String literal concatenation being: $a = MY NAME IS DAVE WILSON /* some comment tokens that get ignored */ WAS HERE // 2002 2003; Or, more useful: SELECT id,x,y,z FROM tbl /* grab required cols */ WHERE y = %d /* for our y coordinate. */ -- Edit bug report at http://bugs.php.net/?id=20516edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20516r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20516r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20516r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20516r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20516r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20516r=support Expected behavior: http://bugs.php.net/fix.php?id=20516r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20516r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20516r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20516r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20516r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20516r=dst IIS Stability: http://bugs.php.net/fix.php?id=20516r=isapi
#20516 [Com]: RFC: C-style string concatenation
ID: 20516 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Won\'t fix Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.2.3 New Comment: Conformity, ease of porting, the usual reasons why a change might be made. IMHO, the dot operator is ugly and I hate using it, simply because of the colour it appears as in vim :). If no-one wants to hack this in, can I be pointed toward the correct place in the source so I may? Thanks. Previous Comments: [2002-11-20 07:38:50] [EMAIL PROTECTED] Why do you want that? PHP really doesn't need that, since we have the dot as string concatenation operator. What's wrong with it? FOO . /* weird comment if you like that */ BAR [2002-11-20 07:30:13] [EMAIL PROTECTED] Hi there, I was wondering if it would be at all possible to get ANSI C / ISO C99-style string literal concatenation added? The PHP syntax already borrows so much from C that this seems to be a worthy addition. It would also make it much easier for wrapping ugly SQL for pretty source files. String literal concatenation being: $a = MY NAME IS DAVE WILSON /* some comment tokens that get ignored */ WAS HERE // 2002 2003; Or, more useful: SELECT id,x,y,z FROM tbl /* grab required cols */ WHERE y = %d /* for our y coordinate. */ -- Edit this bug report at http://bugs.php.net/?id=20516edit=1
#20381 [Ver]: array_merge_recursive mangles input arrays
ID: 20381 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Arrays related Operating System: SuSE Linux 7.3 PHP Version: 4.3.0-dev New Comment: In 4.3.2 the source arrays are mangled even when you don't add them to the result. This was just for a nicer, smaller example. Example // Same $a and $b as before $result = array_merge_recursive( $a, $b ); print_r( $c ); print_r( $a ); print_r( $b ); // have sadly the same effect Previous Comments: [2002-11-12 06:33:56] [EMAIL PROTECTED] Reproduced using latest CVS. The original arrays are fine, but when they're added to the resulting array, then they get mangled. [2002-11-11 23:04:18] [EMAIL PROTECTED] Similar to #14990 (exept that the demo code there runs fine) and the first source array gets mangled. Example = pre? $a = array( 'a1' = 1, 'a2' = array( 1, 2, 3 ), 'a3' = array( 'a' = array( 10, 20, 30 ), 'b' = 'b' ) ); $b = array( 'a1' = 2, 'a2' = array( 3, 4, 5 ), 'a3' = array( 'c' = 'cc', 'a' = array( 10, 40 ) ) ); $c['result'] = array_merge_recursive( $a, $b ); $c['a'] = $a; $c['b'] = $b; print_r( $c ); ? Example Output Array ( [result] = Array ( [a1] = Array ( [0] = 1 [1] = 2 ) [a2] = Array ( [0] = 1 [1] = 2 [2] = 3 [3] = 3 [4] = 4 [5] = 5 ) [a3] = Array ( [a] = Array ( [0] = 10 [1] = 20 [2] = 30 [3] = 10 [4] = 40 ) [b] = b [c] = cc ) ) [a] = Array ( [a1] = 1 [a2] = Array ( [0] = 1 [1] = 2 [2] = 3 [3] = 3 [4] = 4 [5] = 5 ) [a3] = Array ( [a] = Array ( [0] = 10 [1] = 20 [2] = 30 [3] = 10 [4] = 40 ) [b] = b [c] = cc ) ) [b] = Array ( [a1] = 2 [a2] = Array ( [0] = 3 [1] = 4 [2] = 5 ) [a3] = Array ( [c] = cc [a] = Array ( [0] = 10 [1] = 40 ) ) ) ) -- Edit this bug report at http://bugs.php.net/?id=20381edit=1
Bug #11461 Updated: \. after \- does not work
ID: 11461
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Regexps related
Operating System: Linux 2.2.16-SMP
PHP Version: 4.0.6RC3
New Comment:
@rasmus:
It sounds like you've mistaken ^ for [^ ...
http://sunsite.utk.edu/gnu/regex/regex_17.html#SEC17
http://sunsite.utk.edu/gnu/regex/regex_23.html#SEC23
Previous Comments:
[2002-05-14 12:31:25] [EMAIL PROTECTED]
A bracket expression is a list of characters enclosed in
`[]'. It normally matches any single character from the
list (but see below). If the list begins with `^', it
matches any single character (but see below) not from the
rest of the list. If two characters in the list are sepa
rated by `-', this is shorthand for the full range of
characters between those two (inclusive) in the collating
sequence, e.g. `[0-9]' in ASCII matches any decimal digit.
It is illegal- for two ranges to share an endpoint, e.g.
`a-c-e'. Ranges are very collating-sequence-dependent,
and portable programs should avoid relying on them.
To include a literal `]' in the list, make it the first
character (following a possible `^'). To include a lit
eral `-', make it the first or last character, or the sec
ond endpoint of a range. To use a literal `-' as the
first endpoint of a range, enclose it in `[.' and `.]' to
make it a collating element (see below). With the excep
tion of these and some combinations using `[' (see next
paragraphs), all other special characters, including `\',
lose their special significance within a bracket expres
sion.
[2001-06-13 05:25:01] [EMAIL PROTECTED]
I tried to check email with
$check =
ereg('^[0-9A-Za-z_\-\.]+@[0-9A-Za-z_\-]+\.[0-9A-Za-z_\-\.]+[0-9A-Za-z_\-]+$',$email);
This does not work with '[EMAIL PROTECTED]', for example, althoug the
regular expression is correct. It works this way in any other
programming language.
But if you write it in the following way it also works fine in PHP:
$check =
ereg('^[\.0-9A-Za-z_\-]+@[0-9A-Za-z_\-]+\.[\.0-9A-Za-z_\-]+[0-9A-Za-z_\-]+$',$email);
Maybe the parser thinks of - as the range separator, althoug it is
written as \- ?
--
Edit this bug report at http://bugs.php.net/?id=11461edit=1
Bug #16800 Updated: problem with registration an array variable in session
ID: 16800
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: linux
PHP Version: 4.1.2
New Comment:
@ [EMAIL PROTECTED]:
I hope that should be a bad joke ...
I've tested the code below with 4.1.1 and it worked.
(session support is broken in 4.1.2 AFAIK)
$bar = array(
'something' = array( 1,2,3,4 ),
'nothing' = NULL,
'test' = true,
'test2' = array( 'x','y'=2 )
);
session_register('bar');
Previous Comments:
[2002-04-24 12:49:19] [EMAIL PROTECTED]
I made it a documentation problem. The manual page for
'session_register()' should explicitly mention this.
[2002-04-24 12:47:56] [EMAIL PROTECTED]
arrays can't be registered in sessions. However, you can store a
serialized array:
$arr = serialize($array);
session_register($arr);
-daniel
[2002-04-24 12:46:52] [EMAIL PROTECTED]
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
[2002-04-24 12:28:56] [EMAIL PROTECTED]
I've tried to register a seesion variable $array[$i] with
sessionn_register(), where $i is an integer index, but failed. In a
temporary session file in my /tmp directory I found a declaration like
!array[0]|, and now values.
Please help! Thanks
--
Edit this bug report at http://bugs.php.net/?id=16800edit=1
Bug #15333 Updated: strndup access violation
ID: 15333 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: IIS related Operating System: Windows 2000 Pro PHP Version: 4.2.0 RC2 New Comment: There is a tool called tkill / kill / tlist that will let you terminate processes. Get the PID from tlist or Task Manager and then run kill with the PID for the argument. inetinfo.exe will be running under a different user that Administrator does not have the power to kill the processes of, so using Task Manager to kill inetinfo.exe is a waste of time. Previous Comments: [2002-04-21 06:32:35] [EMAIL PROTECTED] I tried setting the app protection to 'Low (IIS Process)' and still get the error. And I tried killing inetinfo.exe and running the net stop commands from the command line, but Windows won't kill the process. This issue has turned out to be the biggest reason my I haven't embraced PHP yet -- because I hate rebooting my machine all of the time. I would love to hear of a workaround that works, and better yet, see a published fix. Any more ideas out there? [2002-04-17 15:19:04] [EMAIL PROTECTED] I am getting this error with 4.2.0 RC2. I upgraded from 4.1.2 to 4.2.0 RC2 (both ISAPI) because 4.1.2 wasn't handling sessions correctly. I tried setting the app protection to 'Low (IIS Process)' and all I received were 'Invalid access to memory location' errors. PHP 4.2.0 RC2 (ISAPI) IIS5 Win2K Pro SP2 PIII 733MHz 384 MB RAM [2002-04-17 01:29:45] [EMAIL PROTECTED] I am also receiving this error with: Win2k Server SP2 w/all security patches But I am running PHP 4.1.2 ISAPI under IIS 5.0 Thanks. [2002-04-09 08:14:55] [EMAIL PROTECTED] I have been super busy lately, but, since I switched the app protection down to 'Low (IIS Process)' a week ago I haven't gotten a single error or lock up. Thanks for your persistance. Still using 4.1.2. [2002-04-08 12:04:38] [EMAIL PROTECTED] Ok. It definitely happens with RC2. You can restart IIS without rebooting, you've got to perform the following: kill the inetinfo.exe process using the task manager run from command line: net stop w3svc net stop iisadmin net start iisadmin net start w3svc Marking this bug critical because it should be fixed before 4.2.0 release. Still looking for fix. 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/15333 -- Edit this bug report at http://bugs.php.net/?id=15333edit=1
Bug #16562 Updated: imap_open does not open port after PHP upgrade
ID: 16562
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: IMAP related
Operating System: RedHat 6.x
PHP Version: 4.1.2
New Comment:
I thought I'd tried that already, but there must have been something
else wrong when I did, because that fixed it. Thanks. :-)
Side note... the reason I was trying it that way is because that's how
NOCC v.0.92 (see http://sourceforge.net/projects/nocc/ )was
successfully doing it. I guess the syntax for imap_open isn't as
flexible as it used to be. My guess is that they've fixed NOCC in
later versions and that's why no one else seems to be having this
problem.
It's always a bummer when something that worked in a previous version
of PHP stops working in the current one. But, as it stands, I guess
that's not PHP's problem... this is a NOCC bug. Unfortunately, I've
got to go track down dozens of old NOCC installations (on lots of
different servers) and fix the syntax to the way the current PHP wants
to see it. :-(
Previous Comments:
[2002-04-12 10:44:18] [EMAIL PROTECTED]
What if you use this instead:
$mbox = imap_open ({localhost:110/pop3}INBOX, user_id,
password);
(straight from the manual)
[2002-04-11 23:29:07] [EMAIL PROTECTED]
After upgrading to PHP 4.1.2 from 4.0.4pl1 and doing this:
imap_open({hostname/POP3:110}INBOX, userid, password)
...simply returns Couldn't open stream when trying to talk to
POP3/110. I checked tcpdump and I see nothing happening on port 110.
Switching back to 4.0.4pl1 fixes the problem. Tried installing the
latest c-client and still nothing. Seems something about imap_open has
been broken in this version.
--
Edit this bug report at http://bugs.php.net/?id=16562edit=1
Bug #16562 Updated: imap_open does not open port after PHP upgrade
ID: 16562
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: IMAP related
Operating System: RedHat 6.x
PHP Version: 4.1.2
New Comment:
Additional note: I did some more experimenting and it turns out that
the current PHP does NOT have a problem with this syntax:
imap_open({hostname/pop3:110}INBOX, userid, password)
...which is the same syntax NOCC v.9.2 used with the exception that
pop3 is lower case.
In summary, in previous versions of imap_open() the protocol specifier
was not case sensitive. Now it is.
Previous Comments:
[2002-04-12 12:52:07] [EMAIL PROTECTED]
Actually it's the imap library whose syntax did change, not PHP itself.
[2002-04-12 12:23:53] [EMAIL PROTECTED]
I thought I'd tried that already, but there must have been something
else wrong when I did, because that fixed it. Thanks. :-)
Side note... the reason I was trying it that way is because that's how
NOCC v.0.92 (see http://sourceforge.net/projects/nocc/ )was
successfully doing it. I guess the syntax for imap_open isn't as
flexible as it used to be. My guess is that they've fixed NOCC in
later versions and that's why no one else seems to be having this
problem.
It's always a bummer when something that worked in a previous version
of PHP stops working in the current one. But, as it stands, I guess
that's not PHP's problem... this is a NOCC bug. Unfortunately, I've
got to go track down dozens of old NOCC installations (on lots of
different servers) and fix the syntax to the way the current PHP wants
to see it. :-(
[2002-04-12 10:44:18] [EMAIL PROTECTED]
What if you use this instead:
$mbox = imap_open ({localhost:110/pop3}INBOX, user_id,
password);
(straight from the manual)
[2002-04-11 23:29:07] [EMAIL PROTECTED]
After upgrading to PHP 4.1.2 from 4.0.4pl1 and doing this:
imap_open({hostname/POP3:110}INBOX, userid, password)
...simply returns Couldn't open stream when trying to talk to
POP3/110. I checked tcpdump and I see nothing happening on port 110.
Switching back to 4.0.4pl1 fixes the problem. Tried installing the
latest c-client and still nothing. Seems something about imap_open has
been broken in this version.
--
Edit this bug report at http://bugs.php.net/?id=16562edit=1
Bug #16562 Updated: imap_open does not open port after PHP upgrade
ID: 16562
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IMAP related
Operating System: RedHat 6.x
PHP Version: 4.1.2
New Comment:
Oops... I didn't see [EMAIL PROTECTED]'s comment. Perhaps it is in the
imap libary, but what's strange is I tried using the same library that
I used with the prior PHP version and it still had a problem.
Previous Comments:
[2002-04-12 12:54:18] [EMAIL PROTECTED]
Additional note: I did some more experimenting and it turns out that
the current PHP does NOT have a problem with this syntax:
imap_open({hostname/pop3:110}INBOX, userid, password)
...which is the same syntax NOCC v.9.2 used with the exception that
pop3 is lower case.
In summary, in previous versions of imap_open() the protocol specifier
was not case sensitive. Now it is.
[2002-04-12 12:52:07] [EMAIL PROTECTED]
Actually it's the imap library whose syntax did change, not PHP itself.
[2002-04-12 12:23:53] [EMAIL PROTECTED]
I thought I'd tried that already, but there must have been something
else wrong when I did, because that fixed it. Thanks. :-)
Side note... the reason I was trying it that way is because that's how
NOCC v.0.92 (see http://sourceforge.net/projects/nocc/ )was
successfully doing it. I guess the syntax for imap_open isn't as
flexible as it used to be. My guess is that they've fixed NOCC in
later versions and that's why no one else seems to be having this
problem.
It's always a bummer when something that worked in a previous version
of PHP stops working in the current one. But, as it stands, I guess
that's not PHP's problem... this is a NOCC bug. Unfortunately, I've
got to go track down dozens of old NOCC installations (on lots of
different servers) and fix the syntax to the way the current PHP wants
to see it. :-(
[2002-04-12 10:44:18] [EMAIL PROTECTED]
What if you use this instead:
$mbox = imap_open ({localhost:110/pop3}INBOX, user_id,
password);
(straight from the manual)
[2002-04-11 23:29:07] [EMAIL PROTECTED]
After upgrading to PHP 4.1.2 from 4.0.4pl1 and doing this:
imap_open({hostname/POP3:110}INBOX, userid, password)
...simply returns Couldn't open stream when trying to talk to
POP3/110. I checked tcpdump and I see nothing happening on port 110.
Switching back to 4.0.4pl1 fixes the problem. Tried installing the
latest c-client and still nothing. Seems something about imap_open has
been broken in this version.
--
Edit this bug report at http://bugs.php.net/?id=16562edit=1
Bug #16325: Memory leak causes DLLHOST to become large
From: [EMAIL PROTECTED] Operating system: Windows 2000 Server PHP version: 4.1.2 PHP Bug Type: IIS related Bug description: Memory leak causes DLLHOST to become large The setup: IIS5 has an ISAPI application mapping to php4isapi.dll Steps to reproduce: - Start IIS - Generate heavy load (~40+ hits / second) - Watch DLLHOST in the Task Manager. It takes more and more memory (40 - 45MB) - PHP error log begins reporting spurious errors (the page has no errors, but under heavy load it starts complaining about duplicate function definitions) Bug: #13324 - IIS stops serving PHP files but still serves static content DLLHOST disappears from the task list at this point. Other times it may begin taking 100% CPU and need to be terminated by hand. Killing DLLHOST usually causes it to be restarted and requests continue being served. Otherwise you may end up alternating between the two errors on bug #13324. -- Edit bug report at http://bugs.php.net/?id=16325edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16325r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16325r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16325r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16325r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16325r=support Expected behavior: http://bugs.php.net/fix.php?id=16325r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16325r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16325r=submittedtwice
Bug #13098 Updated: Problems to bring up IIS after shutting it down through a command prompt.
ID: 13098 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Operating System: Microsoft Windows 2000 PHP Version: 4.0.6 New Comment: Are you sure this is a PHP-related bug? You may have misconfigured IIS. (Close this report?) Previous Comments: [2001-09-02 18:03:11] [EMAIL PROTECTED] I read the Beginning PHP4 book from Wrox. When I got myself to page 28 which is to shut down IIS and bring it up through a command prompt. I successfully shut down IIS but I got this when I tried to bring it up again. C:\net start w3svc The World Wide Web Publishing service is starting. The World Wide Web Publishing service cannot be started. A system error has occured. System error 1747 has occured. The authentication service is unknown. -- Edit this bug report at http://bugs.php.net/?id=13098edit=1
Bug #16227 Updated: Using internal hash position is tricky.
ID: 16227 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: ANY PHP Version: PHP4 only New Comment: OK, as a newbie PHP-er (experienced with Perl and Java) the documentation I've been using suggested using that example before foreach(). The foreach() behavior is free from the problem it seems, even though documentation for foreach() on php.net claims that they should be equivalent. Can anyone explain to this newbie why the (while list each) version was the intended behavior? Of course, having to use reset() seems kind of odd to me anyway, but I wonder what was wrong with my first code... PHP seems to look like it has Perl's more than one way to do it, but only in very limited areas. (I suppose if push came to shove I could go back to using my own array walkers, but still...) Previous Comments: [2002-03-23 07:10:07] [EMAIL PROTECTED] Ok. Then this is documentation problem. (I would like to hear from Andi or Zeev, though) There should be note that internal hash position is reset if value is assigned. (Both LVALUE and RVLAUE. They are the same value anyway.) Also, reference counting side effect should be documented fully. BTW, to fix this misbihavior, we need a additional variable to keep track of hash position for each zval. (and change related codes) PHP3 does not have problem, since it does not have reference counting. [2002-03-23 06:46:24] [EMAIL PROTECTED] It's not a flaw, it's designed like this. Derick [2002-03-23 06:39:14] [EMAIL PROTECTED] Derick, foreach() does not solve this bug. ZendEngine is resetting internal hash position by an assignment. Therefore, foreach() does does not work. i.e. The issue is _not_ Not resetting hash posisiton, but Incorrectly resetting RVALUE hash position by an assignment. This is serious flaw in language. [2002-03-23 06:01:49] [EMAIL PROTECTED] Not a bug, but intended behavior. Use foreach(). Derick [2002-03-22 20:55:39] [EMAIL PROTECTED] BTW, I haven't check the exact behavior. Zend might be resetting internal hash position due to the assignment. 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/16227 -- Edit this bug report at http://bugs.php.net/?id=16227edit=1
Bug #2560 Updated: max_execution_time is not accurate
ID: 2560
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Misbehaving function
Operating System: BSDI BSD/OS 4.0.1
PHP Version: 4.0 Beta 2
New Comment:
This bug is still present in PHP 4.1.2, exactly as described by djm
Previous Comments:
[1999-12-03 12:27:55] [EMAIL PROTECTED]
Fixed in CVS by Rasmus.
[1999-10-18 11:48:12] [EMAIL PROTECTED]
I'm using PHP 4.0B2 as a DSO with apache 1.3.9. In my httpd.conf I
have set
AddType application/x-httpd-php .php3
AddType application/x-httpd-php .php
php_admin_flag safe_mode On
php_admin_value doc_root /homes/www141/webtest
php_admin_value open_basedir /homes/www141/webtest
php_admin_value safe_mode_exec_dir /homes/www141/webtest/bin
php_flag log_errors On
php_value error_log /homes/www141/webtest/logs/php.log
php_value max_execution_time 3
php_value memory_limit 8388608
When I run the following PHP script, it is not aborted before printing
the
second message, despite having run for more than 3 seconds. And it
takes about 13-18 wall clock seconds before PHP aborts the infinite
loop. Printing
phpinfo() confirms that max_execution_time is indeed set to 3.
htmlheadtitletest of max_execution_time/title/headbody
?
echo beforep\n; sleep(10); echo afterp\n;
while (1) { $i++; }
?
/body/html
This is being run on a 450MHz server that's doing nothing else, so I
don't
think CPU contention is an issue.
--
Edit this bug report at http://bugs.php.net/?id=2560edit=1
Bug #15730: Autoglobal (Variable) Variables within funktions.
From: [EMAIL PROTECTED]
Operating system: Win2k
PHP version: 4.1.1
PHP Bug Type: Variables related
Bug description: Autoglobal (Variable) Variables within funktions.
I tried to access the autoglobal variables via the variable variables
'trick'. But that doesn't work within functions.
Examples:
That works:
?
?hr?
$test1 = '_TEST';
$test2 = '_SERVER';
$_TEST = '[test1]';
?pre?
var_dump( $test1 );
var_dump( ${'_TEST'} );
var_dump( ${$test1} );
var_dump( ${$test1} );
?hr?
var_dump( $test2 );
var_dump( ${'_SERVER'} );
var_dump( ${$test2} );
var_dump( ${$test2} );
?/prehr?
That doesn't work:
?
function foolme()
{
?hr?
$test1 = '_TEST';
$test2 = '_SERVER';
$_TEST = '[test1]';
?pre?
var_dump( $test1 );
var_dump( ${'_TEST'} );
var_dump( ${$test1} );
var_dump( ${$test1} );
?hr?
var_dump( $test2 );
var_dump( ${'_SERVER'} );
var_dump( ${$test2} );
var_dump( ${$test2} );
?/prehr?
}
foolme();
--
I found that, while writing a class for processing html forms:
function __wakeup() {
$method = $this-_method;
$this-_FORM = ${_$method};
}
--
Edit bug report at http://bugs.php.net/?id=15730edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15730r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15730r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15730r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15730r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15730r=support
Expected behavior: http://bugs.php.net/fix.php?id=15730r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15730r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15730r=submittedtwice
Bug #15592: misc - exit - missing line break
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.1.1 PHP Bug Type: Documentation problem Bug description: misc - exit - missing line break - Miscellaneous functions - exit missing líne break in description: void exit ( [string status])void exit ( int status) (http://www.php.net/manual/en/function.exit.php) -- Edit bug report at http://bugs.php.net/?id=15592edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15592r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15592r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15592r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15592r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15592r=support Expected behavior: http://bugs.php.net/fix.php?id=15592r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15592r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15592r=submittedtwice
Bug #15551: unset($_SESSION['var']) problem with register_globals=on
From: [EMAIL PROTECTED]
Operating system: Win32
PHP version: 4.1.1
PHP Bug Type: Session related
Bug description: unset($_SESSION['var']) problem with register_globals=on
Hi F0lks,
when I use the $_SESSION array while register_globals is enabled, I can't
unregister variables as described in the documentation (
unset($_SESSION['var']); ), except in the script call where 'var' was used
first time.
I wrote demonstration script hoping it shows you what I mean.
(register_globals must be enabled!)
?
session_name('testsession');
session_start();
echo 'pre';
if( ! $_SESSION['c'] ) $_SESSION['c'] = 1;
echo === unregistering variables from session with register_globals=On
under PHP 4.1.1 ===\n;
echo Current step: $_SESSION[c] of 5\n\n;
switch( $_SESSION['c'] ) {
case 1:
echo Checking, if 'var' is registered - ;
if( session_is_registered('var') ) {
session_destroy();
echo yes. Killed session. END. (reload this page!)\n;
die();
} else {
echo no. Good.\n;
}
echo Setting \$_SESSION['var'] to 'test1' ...\n;
$_SESSION['var'] = 'test1';
varcheck( true );
break;
case 2:
varcheck( true );
echo Trying to unregister 'var' with unset(\$_SESSION['var']) ...\n;
unset( $_SESSION['var'] );
varcheck( false );
echo \$_SESSION['var'] isn't anymore now, so it shouldn't exist on the
next step.\n;
break;
case 3:
varcheck( true );
echo Here it is again, damn!\n;
echo Trying to get rid of it with session_unregister('var') ...\n;
session_unregister('var');
varcheck( false );
echo Maybe, this time, it won't come back ...\n;
break;
case 4:
varcheck( false );
echo It worked, \$_SESSION['var'] is dead ...\n;
echo so let's try registering and unregistering in one (this) script
call.\n\n;
echo Setting \$_SESSION['var'] to 'test2' ...\n;
$_SESSION['var'] = 'test2';
varcheck( true );
echo Trying to unregister 'var' with unset(\$_SESSION['var'])...\n;
unset( $_SESSION['var'] );
varcheck( false );
break;
case 5:
varcheck( false );
echo No \$_SESSION['var'] ...\n\n;
echo
'I think, I can explain this behaviour.
When you register a variable by $_SESSION[\'varname\']=\'something\';
$_SESSION[\'varname\'] is a string. When the script reacheas its end, it
sees no $GLOBALS[\'varname\'] to save (register_globals=On!) so it takes
$_SESSION[\'varname\'].
When calling the script again, \'varname\' will be restored from session
to $GLOBALS[\'varname\']. Then a reference to $GLOBALS[\'varname\'] will
be created in $_SESSION[\'varname\']. unset($_SESSION[\'varname\'] would
only delete the reference to $GLOBALS[\'varname\'] ...
My suggestion to the php developers:
When register_globals=On restore variables from session to
$_SESSION[\'varname\'] and store a reference to it in
$GLOBALS[\'varname\'].
';
// don't need break; here ...
default:
session_destroy();
echo \n- - -\nSession killed. END. (reload to start again)\n;
die();
}
$_SESSION['c'] += 1;
echo /prea href=\$PHP_SELF\next/a;
function varcheck( $y, $ignore=false )
{
$x = isset( $_SESSION['var'] );
if( $x ) {
echo \$_SESSION['var'] is now: ;
var_dump( $_SESSION['var'] );
} else
echo \$_SESSION['var'] is not set.\n;
if( $x != $y and !$ignore ) {
echo ... this shouldn't happen, maybe your php.ini differs from
mine.\n;
echo feel free to contact me
lt;[EMAIL PROTECTED]gt;\n;
die();
}
}
--
Edit bug report at http://bugs.php.net/?id=15551edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15551r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15551r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15551r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15551r=oldversion
Not developer
