#26836 [NEW]: Unable to load modules / some missing
From: scottfurry at telusplanet dot net Operating system: Windows NT4 SP6a PHP version: 5CVS-2004-01-08 (dev) PHP Bug Type: Dynamic loading Bug description: Unable to load modules / some missing Description: Unable to load dynamic dll's. PHP.INI file will correctly identify path to php_*.dll. Error message returned by OS that entry point to dll cannot be found. Also, some DLL's appear to be missing? i.e. php_GD.dll / php_GD2.dll -- Edit bug report at http://bugs.php.net/?id=26836edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26836r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26836r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26836r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26836r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26836r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26836r=needscript Try newer version: http://bugs.php.net/fix.php?id=26836r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26836r=support Expected behavior: http://bugs.php.net/fix.php?id=26836r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26836r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26836r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26836r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26836r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26836r=dst IIS Stability: http://bugs.php.net/fix.php?id=26836r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26836r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26836r=float
#26807 [Csd]: No entry point GetLongPathNamesA Kernel32.dll
ID: 26807 User updated by: scottfurry at telusplanet dot net Reported By: scottfurry at telusplanet dot net Status: Closed Bug Type: *Configuration Issues Operating System: Windows NT4 SP6a PHP Version: 5CVS-2004-01-06 (dev) Assigned To: wez New Comment: Apache 2.0.48 will now load PHP correctly. Process was extremely painless. Manual install of PHP similar to install.txt was almost exact (exception of path's and names of a couple of dll's). Kudo's on moving php*apache*.dll's to php folder and the file rename. PHP can now be configured on the fly from the PHP.ini file extremely well. Most appreciated, thank you. HOWEVER,... dynamic modules cannot be loaded. See bug #26836 Previous Comments: [2004-01-07 19:54:54] [EMAIL PROTECTED] Fixed about an hour ago when we moved to new win32 build on snaps.php.net. [2004-01-07 19:44:19] [EMAIL PROTECTED] Assigned to Wez who claimed this was fixed in snapshots in bug #26692 [2004-01-06 02:13:27] scottfurry at telusplanet dot net Description: Have tried file renames, latest CVS, moving dll's, etc. (Just about every suggestion I could find on PHP.net) Using Apache 2.0.48 and installing PHP using SAPI *.dll's, I continue to receive No Entry point to GetLongPathNamesA in kernel32.dll error message. The LoadModule directive with php5_module did not resolve the issue. Description of problem similar to bugs 26692/24749 but remains unresolved with new/latest CVS. Issue is either... a) problem with Win32 PHP5 build b) missing WinNT4 files not cited in installation instructions c) incompatibility with latest/greatest from Microsoft (note updated NT with MDAC 2.8 prior to install of PHP as directed in the Windows Install instructions) d) missing step in installation instructions (unlikely) but the instructions do not reflect PHP5 Please help!!! -- Edit this bug report at http://bugs.php.net/?id=26807edit=1
#26834 [Fbk-Opn]: php-4.3.4-installer.exe fails because iisext.vbs not present
ID: 26834 User updated by: kim at sj dot co dot uk Reported By: kim at sj dot co dot uk -Status: Feedback +Status: Open Bug Type: IIS related Operating System: Windows XP Professional PHP Version: 4.3.4 New Comment: Yes, PHP now working with IIS on my system after manual install. Bug is just with installer. Previous Comments: [2004-01-07 19:47:32] [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 [2004-01-07 19:31:06] kim at sj dot co dot uk Description: Running php-4.3.4-installer.exe fails at a late hurdle, because (afaict) Windows XP Professional runs IIS 5.1, which release appears not to include iisext.vbs. At least, that file is not present anywhere on my system. -- Edit this bug report at http://bugs.php.net/?id=26834edit=1
#26837 [NEW]: mhash seems not loading on PHP as ISAPI
From: webmaster at sparovcek dot net Operating system: Win2k server/IIS5 PHP version: 4.3.4 PHP Bug Type: mhash related Bug description: mhash seems not loading on PHP as ISAPI Description: I was trying to install php_mhash.dll with bundled libmhash.dll library on my Windows 2000 server, but it simply did not start! Everytime I called mhash() function, I get error: Call to undefined function mhash() ... After some exercise with checking /extensions dir, and PHP.INI, and after I found 0 (ZERO) configuration mistakes (all other extensions and modules loaded with no problem), I did the following: I copied the PHP installation from server to my local machine, and installed it. And mhash() function WORKED WITH NO PROBLEM! Now, where are the diferences? MHASH is NOT WORKING on this machine: - Windows 2000 server - IIS 5 - PHP 4.3.4 loaded as ISAPI MHASH is WORKING on this machine: - Windows XP pro - Apache 1.3.23 - PHP 4.3.4 loaded as CGI/EXE My opinion is that running PHP as ISAPI module has something to do with it. But I did not experiment too much, because I have only *working* server, not for development purposes. -- Edit bug report at http://bugs.php.net/?id=26837edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26837r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26837r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26837r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26837r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26837r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26837r=needscript Try newer version: http://bugs.php.net/fix.php?id=26837r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26837r=support Expected behavior: http://bugs.php.net/fix.php?id=26837r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26837r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26837r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26837r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26837r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26837r=dst IIS Stability: http://bugs.php.net/fix.php?id=26837r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26837r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26837r=float
#23508 [Com]: Segmentation fault with data type in mssql
ID: 23508 Comment by: sebastian dot wiehe at qmarketing dot de Reported By: alietss at yahoo dot com Status: No Feedback Bug Type: MSSQL related Operating System: RedHat 9.0 PHP Version: 4CVS-2003-05-06 (stable) New Comment: Anyone found a solution for that prob? I'm having exactly the same problems running mandrake 9.2, freeTDS 0.61, php 4.3.3. By now, I found no one who could deal with this strange behaviour. If you need further information concerning that possible bug, please contact me via email Thanks Previous Comments: [2003-05-14 11:02:54] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2003-05-06 12:11:02] [EMAIL PROTECTED] Can you provide me with a small code sample to reproduce this error. I think it is a bug in FreeTDS, and would like to trace it. [2003-05-06 11:14:30] alietss at yahoo dot com Hi PHP people: I have found a segmentation fault with httpd-2.0.45 php-4.3.2 freetds-0.62-dev on RedHat 9.0 TDS 7.0 against a Microsoft SQL Server 2000, the problem is when some of the queries field is of type datetime 8... I'm using freetds-0.62-dev with mssql native php extension Here the apache error log... httpd: read.c:365: tds_get_char_data: Assertion `in_left 4' failed. [Tue May 06 11:05:27 2003] [notice] child pid 9064 exit signal Segmentation fault (11) [Tue May 06 11:05:27 2003] [notice] child pid 9065 exit signal Segmentation fault (11) I report this to freetds people too since I don't know who belongs the problem... Any Ideas, Regards Aliet -- Edit this bug report at http://bugs.php.net/?id=23508edit=1
#26836 [Opn-Fbk]: Unable to load modules / some missing
ID: 26836 Updated by: [EMAIL PROTECTED] Reported By: scottfurry at telusplanet dot net -Status: Open +Status: Feedback Bug Type: Dynamic loading Operating System: Windows NT4 SP6a PHP Version: 5CVS-2004-01-08 (dev) New Comment: Please be more specific; which extensions are you trying to load and which entry point cannot be found? php_gd2.dll is in the ext folder of the zip file. (fetch latest snapshot) Previous Comments: [2004-01-08 03:05:47] scottfurry at telusplanet dot net Description: Unable to load dynamic dll's. PHP.INI file will correctly identify path to php_*.dll. Error message returned by OS that entry point to dll cannot be found. Also, some DLL's appear to be missing? i.e. php_GD.dll / php_GD2.dll -- Edit this bug report at http://bugs.php.net/?id=26836edit=1
#26838 [NEW]: signals make STDIN become EOF
From: xuefer at 21cn dot com
Operating system: linux
PHP version: 4.3.4
PHP Bug Type: Filesystem function related
Bug description: signals make STDIN become EOF
Description:
code
shell ./test.php
don't press CTRL+D to end input. but program exists in 3 seconds because
feof() return true
uncomment line 7 will works ok, exit only when i press CTRL+D
Reproduce code:
---
file ./test.php:
#!/usr/bin/php
?php
function sig_handler($signo) {
global $stdin;
print Caught SIGALM...\n;
pcntl_alarm(3);
// line7 // $stdin = fopen(php://stdin, 'r') or die('1');
}
print Installing signal handler...\n;
pcntl_signal(SIGALRM, sig_handler);
print Generating signal SIGTERM to self...\n;
declare(ticks=1);
pcntl_alarm(3);
$stdin = fopen(php://stdin, 'r') or die('1');
while (!feof($stdin)) {
echo fgets($stdin);
}
print Done\n
?
--
Edit bug report at http://bugs.php.net/?id=26838edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26838r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26838r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26838r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26838r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26838r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26838r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26838r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26838r=support
Expected behavior: http://bugs.php.net/fix.php?id=26838r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26838r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26838r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26838r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26838r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26838r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26838r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26838r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26838r=float
#23220 [Com]: fgets() causes warning while reading data via SSL channel (HTTPS)
ID: 23220 Comment by: a at anseljh dot com Reported By: storozhilov at mail dot ru Status: No Feedback Bug Type: Filesystem function related Operating System: FreeBSD 4.8 PHP Version: 4-STABLE-200307070330 Assigned To: wez New Comment: Red Hat 9 PHP 4.3.4, Apache 2.0.48, OpenSSL 0.9.7c (built from source) Also happens with either fread() or feof() on an SSL socket connection opened with fsockopen ($request): while (!feof($request)) $response .= fread($request, 4096); This code works flawlessly on a non-SSL socket connection. Previous Comments: [2003-12-29 14:31:32] Roger dot Schweppe at cbsks dot com I have been having the same problem with IIS 5. So if you ever find a solution I would be very happy to hear from you. Thanks, Roger [2003-12-23 14:02:46] pta at interkan dot net Forgot to include this info: PHP 4.3.4 (cli) (built: Dec 4 2003 11:17:45) Copyright (c) 1997-2003 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies [2003-12-23 14:01:39] pta at interkan dot net I've been experiencing the same problem with PHP 4.3.4 running on a Linux Slackware/Apache server. The problem did initially crop up inside the PEAR Socket class which I'm trying to use to connect to Authorize.Net's gateway. Here's the exact message returned (with path changes): Warning: fread(): SSL: fatal protocol error in /path/to/Net/Socket.php on line 243 [2003-12-12 20:59:12] tim at timcrider dot com oh by the way. I am trying this with https:// as wez requested and am reproducing the same error: PHP 5.0.0b2 (cli) (built: Dec 7 2003 18:04:51) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St. Petersburg, by Dmitry Stogov [2003-12-12 20:54:11] tim at timcrider dot com I am having the same problem on Red Hat 9.0 with PHP 5.0 B2. It's coming from Net/Socket.php 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/23220 -- Edit this bug report at http://bugs.php.net/?id=23220edit=1
#26837 [Opn-Bgs]: mhash seems not loading on PHP as ISAPI
ID: 26837 Updated by: [EMAIL PROTECTED] Reported By: webmaster at sparovcek dot net -Status: Open +Status: Bogus Bug Type: mhash related Operating System: Win2k server/IIS5 PHP Version: 4.3.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. You were just doing something wrong... Previous Comments: [2004-01-08 04:19:25] webmaster at sparovcek dot net Description: I was trying to install php_mhash.dll with bundled libmhash.dll library on my Windows 2000 server, but it simply did not start! Everytime I called mhash() function, I get error: Call to undefined function mhash() ... After some exercise with checking /extensions dir, and PHP.INI, and after I found 0 (ZERO) configuration mistakes (all other extensions and modules loaded with no problem), I did the following: I copied the PHP installation from server to my local machine, and installed it. And mhash() function WORKED WITH NO PROBLEM! Now, where are the diferences? MHASH is NOT WORKING on this machine: - Windows 2000 server - IIS 5 - PHP 4.3.4 loaded as ISAPI MHASH is WORKING on this machine: - Windows XP pro - Apache 1.3.23 - PHP 4.3.4 loaded as CGI/EXE My opinion is that running PHP as ISAPI module has something to do with it. But I did not experiment too much, because I have only *working* server, not for development purposes. -- Edit this bug report at http://bugs.php.net/?id=26837edit=1
#26839 [NEW]: unexpected results from simple array routine
From: dweller at devonweller dot com
Operating system: Linux Intel (Redhat)
PHP version: 4.3.4
PHP Bug Type: Arrays related
Bug description: unexpected results from simple array routine
Description:
The attached simple array routine produces unexpected
results when the loop count is greater than approx.
33000. Perhaps this is some kind of reference counting
bug.
Reproduce code:
---
// causes unexpected *RECURSION* references
$var1 = 1;
$array = array();
for($i=0;$i33000;++$i) {
$var2 = $var1;
$array[] = array(
'var1' = $var1,
'var2' = $var2,
);
}
print_r($array[0]);
Expected result:
Array
(
[var1] = 1
[var2] = 1
)
Actual result:
--
Array
(
[var1] = Array
(
[var1] = Array
*RECURSION*
[var2] = Array
*RECURSION*
)
[var2] = Array
(
[var1] = Array
*RECURSION*
[var2] = Array
*RECURSION*
)
)
--
Edit bug report at http://bugs.php.net/?id=26839edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26839r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26839r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26839r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26839r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26839r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26839r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26839r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26839r=support
Expected behavior: http://bugs.php.net/fix.php?id=26839r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26839r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26839r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26839r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26839r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26839r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26839r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26839r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26839r=float
#26840 [NEW]: ru.php.net gets row php pages!!!
From: apermyakov at soludium dot com Operating system: Your PHP version: 4.3.4 PHP Bug Type: Unknown/Other Function Bug description: ru.php.net gets row php pages!!! Description: ru.php.net gets row php pages!!! Please, check and fix it, otherwise you are at great risk! http://ru.php.net/FAQ.php section contains links like http://ru.php.net/manual/en/faq.html.php Try them and you will see what i mean. -- Edit bug report at http://bugs.php.net/?id=26840edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26840r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26840r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26840r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26840r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26840r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26840r=needscript Try newer version: http://bugs.php.net/fix.php?id=26840r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26840r=support Expected behavior: http://bugs.php.net/fix.php?id=26840r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26840r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26840r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26840r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26840r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26840r=dst IIS Stability: http://bugs.php.net/fix.php?id=26840r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26840r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26840r=float
#26841 [NEW]: Child class cannot see protected member var from parent
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 5CVS-2004-01-08 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description: Child class cannot see protected member var from parent
Description:
Hello,..
today I tried the code which I post as reproduce code. I expect in
public_func2() the property which is declared as protected in the base
class to be visible. However PHP bails out with message :
PHP Fatal error: Cannot access protected property base::$a in
/home/andrey/test/t.php on line 16 . Use of parent:: does not help also.
AFAIK protected member vars should be visible in the generalization
classes.
As a side note please refer to bug #18024, for an additional effect which
can be seen when using the reproduce code - shadowing of the variable
declared in the base class. Method public_func1() of the base class uses
the variable $a of child which is shadowing $a of base. Is this an
expected behaviour?
Thanks
Reproduce code:
---
?php
class base {
protected $a = array();
public function public_func1() {
var_dump($this-a);
}
}
class child extends base {
public $a = 2;
public function public_func2() {
var_dump($this-a);
var_dump(parent::$a);
}
}
$a = new child();
$a-public_func1();
$a-public_func2();
?
Expected result:
int(2)
int(2)
array(0) {
}
Actual result:
--
int(2)
int(2)
PHP Fatal error: Cannot access protected property base::$a in
/home/andrey/test/t.php on line 16
--
Edit bug report at http://bugs.php.net/?id=26841edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26841r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26841r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26841r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26841r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26841r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26841r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26841r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26841r=support
Expected behavior: http://bugs.php.net/fix.php?id=26841r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26841r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26841r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26841r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26841r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26841r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26841r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26841r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26841r=float
#26788 [Com]: Concurrent upload ignored when processing is synchronized
ID: 26788 Comment by: t at t dot org Reported By: d-alvarez at gmx dot de Status: Open Bug Type: *General Issues Operating System: GNU/Linux 2.4.21-144-default PHP Version: 4.3.4 New Comment: BCiao/B Previous Comments: [2004-01-07 14:37:00] d-alvarez at gmx dot de Apache is version 2.0.48 But I am not sure at all that this bug has to do with apache or php. It could as well be an issue with the internet explorer getting confused about which page the authorization dialog caused by the .htaccess file belongs to. Maybe it posts the file only once in consequence. But this idea would not explain why the second script also fails occassionally. [2004-01-06 17:51:51] [EMAIL PROTECTED] What apache version? [2004-01-04 18:18:40] d-alvarez at gmx dot de Description: Take any html page that uploads a file using HTTP post. It does not matter what the receiving script does, because this issue is only related to the interpreter. A page as simple as the following suffices to reproduce the problem: htmlbody form method=post enctype=multipart/form-data action=http://www.somesite.org/somescript.php; input name=somefile type=fileinput type=submit /form /body /html Change the form's action to some script on a php server. I have placed an echo in it, so I can see more easily if the script is run. And, of course, it should use the file posted, so that we can get an error if it does not find it. You can use this: ?php echo the script has been started; is_uploaded_file ($somefile); ? Now use the html page to upload a file sufficiently large enough for the upload to take several seconds to complete. While the data is being submitted, load the script a second time in another instance of your browser, and post the same file again (in parallel to the first post running in the background). I use a file 824 kb in size. Transmitted over ISDN, the two posts take like two minutes of time to complete. The file was a zip archive. Now, while the server is handling the two uploads concurrently, get a listing of the directory it uses to store the temporary files. You can watch the two uploading files growing until both uploads complete. [EMAIL PROTECTED]:~/html/wcopy/datenaustausch ls -l ~/phptmp insgesamt 228 -rw---1 wwwrun www114688 2004-01-04 23:09 phpHh9HQ9 -rw---1 wwwrun www110592 2004-01-04 23:09 phpp9QIDj [EMAIL PROTECTED]:~/html/wcopy/datenaustausch ls -l ~/phptmp insgesamt 360 -rw---1 wwwrun www180224 2004-01-04 23:10 phpHh9HQ9 -rw---1 wwwrun www180224 2004-01-04 23:10 phpp9QIDj [EMAIL PROTECTED]:~/html/wcopy/datenaustausch ls -l ~/phptmp insgesamt 572 -rw---1 wwwrun www299008 2004-01-04 23:10 phpHh9HQ9 -rw---1 wwwrun www278528 2004-01-04 23:10 phpp9QIDj [EMAIL PROTECTED]:~/html/wcopy/datenaustausch ls -l ~/phptmp insgesamt 1528 -rw---1 wwwrun www790528 2004-01-04 23:12 phpHh9HQ9 -rw---1 wwwrun www765952 2004-01-04 23:12 phpp9QIDj [EMAIL PROTECTED]:~/html/wcopy/datenaustausch ls -l ~/phptmp insgesamt 1664 -rw---1 wwwrun www844067 2004-01-04 23:13 phpHh9HQ9 -rw---1 wwwrun www844067 2004-01-04 23:13 phpp9QIDj Now, with both files being uploaded, two scripts begin to execute, one for each file. Subsequent directory listings will show the temporary files being deleted as the php scripts complete. [EMAIL PROTECTED]:~/html/wcopy/datenaustausch ls -l ~/phptmp insgesamt 832 -rw---1 wwwrun www844067 2004-01-04 23:13 phpp9QIDj (first file has been deleted automatically, because script started first has completed processing) [EMAIL PROTECTED]:~/html/wcopy/datenaustausch ls -l ~/phptmp insgesamt 0 (second file has been deleted automatically, because script started last has completed processing) This is the situation as it should be. Now place an .htaccess file into a directoy above the directory containing your script. The .htaccess file should usually cause your browser to ask you for some realm and password, and then ask you to commit, e.g. by clicking an OK button. Again, start two posts in parallel, but do not yet commit the authorization dialogue shown to you in response to the .htaccess file. The files are uploaded, probably to some temporary location in memory. While the files get uploaded, get some listings of your temporary directory, as before. Neither the system-global /tmp directory, nor the location used to store temporary php files have any entries, but the line is busy for exactly as much time as during the post when there was no .htaccess file yet. Probably the upload is handled differently by Apache.
#26842 [NEW]: localeconv gives wrong decimal place values for locale it_IT
From: marko at oblo dot com
Operating system: linux
PHP version: 4.3.4
PHP Bug Type: *Languages/Translation
Bug description: localeconv gives wrong decimal place values for locale it_IT
Description:
localeconv() function returns the wrong values for int_frac_digits and
frac_digits. they should be 2 and not 0 (which was correct in the time
of the Lira)
Reproduce code:
---
?php
setlocale(LC_ALL, it_IT);
var_dump(localeconv());
Expected result:
array(18) {
[decimal_point]=
string(1) .
snip
[int_frac_digits]=
int(2)
[frac_digits]=
int(2)
snip
[mon_grouping]=
array(2) {
[0]=
int(3)
[1]=
int(3)
}
}
Actual result:
--
array(18) {
[decimal_point]=
string(1) .
snip
[int_frac_digits]=
int(0)
[frac_digits]=
int(0)
snip
[mon_grouping]=
array(2) {
[0]=
int(3)
[1]=
int(3)
}
}
--
Edit bug report at http://bugs.php.net/?id=26842edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26842r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26842r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26842r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26842r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26842r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26842r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26842r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26842r=support
Expected behavior: http://bugs.php.net/fix.php?id=26842r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26842r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26842r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26842r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26842r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26842r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26842r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26842r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26842r=float
#26843 [Com]: PHP doesn't work...
ID: 26843 Comment by: admin at onet dot pl Reported By: admin at wp dot pl Status: Open Bug Type: *General Issues Operating System: DOS PHP Version: 5CVS-2004-01-08 (dev) New Comment: Yeah, it doesn't work also at my system... Previous Comments: [2004-01-08 08:34:38] admin at wp dot pl Description: I installed PHP but it doesn't work... Reproduce code: --- ?php //null ? (null) Expected result: null Actual result: -- ?php //null ? (null) -- Edit this bug report at http://bugs.php.net/?id=26843edit=1
#26843 [Opn-Bgs]: PHP doesn't work...
ID: 26843 Updated by: [EMAIL PROTECTED] Reported By: admin at wp dot pl -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: DOS PHP Version: 5CVS-2004-01-08 (dev) New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . Previous Comments: [2004-01-08 08:35:37] admin at onet dot pl Yeah, it doesn't work also at my system... [2004-01-08 08:34:38] admin at wp dot pl Description: I installed PHP but it doesn't work... Reproduce code: --- ?php //null ? (null) Expected result: null Actual result: -- ?php //null ? (null) -- Edit this bug report at http://bugs.php.net/?id=26843edit=1
#26844 [NEW]: Problems with --with-mime-magic
From: php at humbapa dot ch Operating system: Linux 2.4.22 (Debian unstable) PHP version: 5CVS-2004-01-08 (dev) PHP Bug Type: PHP options/info functions Bug description: Problems with --with-mime-magic Description: When I start apache2 with php5cvs as SAPI module the error_log contains: PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:22) '' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:59) 'audio/x-aiff ' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:270) 'text/plain8bit' is not a valid mimetype, etry skipped in Unknown on line 0 I use the latest PHP5 from CVS and build with: --with-mime-magic=/usr/local/apache2/conf/magic (the magicfile that comes with apache2) - is it not possible to use the magicfile from apache2? - why do the startuperros show up when I set display_startup_errors = Off in php.ini? - Apache2 exit with segmentation fault when I call the function phpinfo() - etry should be entry :-) -- Edit bug report at http://bugs.php.net/?id=26844edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26844r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26844r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26844r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26844r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26844r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26844r=needscript Try newer version: http://bugs.php.net/fix.php?id=26844r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26844r=support Expected behavior: http://bugs.php.net/fix.php?id=26844r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26844r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26844r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26844r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26844r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26844r=dst IIS Stability: http://bugs.php.net/fix.php?id=26844r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26844r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26844r=float
#26842 [Opn-Bgs]: localeconv gives wrong decimal place values for locale it_IT
ID: 26842
Updated by: [EMAIL PROTECTED]
Reported By: marko at oblo dot com
-Status: Open
+Status: Bogus
Bug Type: *Languages/Translation
Operating System: linux
PHP Version: 4.3.4
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
This is an issue with the locale installed on your computer. Please
consult the support of your Linux distribution.
Previous Comments:
[2004-01-08 07:32:00] marko at oblo dot com
Description:
localeconv() function returns the wrong values for int_frac_digits and
frac_digits. they should be 2 and not 0 (which was correct in the
time of the Lira)
Reproduce code:
---
?php
setlocale(LC_ALL, it_IT);
var_dump(localeconv());
Expected result:
array(18) {
[decimal_point]=
string(1) .
snip
[int_frac_digits]=
int(2)
[frac_digits]=
int(2)
snip
[mon_grouping]=
array(2) {
[0]=
int(3)
[1]=
int(3)
}
}
Actual result:
--
array(18) {
[decimal_point]=
string(1) .
snip
[int_frac_digits]=
int(0)
[frac_digits]=
int(0)
snip
[mon_grouping]=
array(2) {
[0]=
int(3)
[1]=
int(3)
}
}
--
Edit this bug report at http://bugs.php.net/?id=26842edit=1
#26839 [Opn-Ver]: unexpected results from simple array routine
ID: 26839
Updated by: [EMAIL PROTECTED]
Reported By: dweller at devonweller dot com
-Status: Open
+Status: Verified
Bug Type: Arrays related
Operating System: Linux Intel (Redhat)
-PHP Version: 4.3.4
+PHP Version: 4CVS-2004-01-08 (dev)
New Comment:
$i 32768 results in
array(2) {
[var1]=
UNKNOWN:0
[var2]=
UNKNOWN:0
}
$i 32767 results in
array(2) {
[var1]=
int(1)
[var2]=
int(1)
}
Previous Comments:
[2004-01-08 07:01:49] dweller at devonweller dot com
Description:
The attached simple array routine produces unexpected
results when the loop count is greater than approx.
33000. Perhaps this is some kind of reference counting
bug.
Reproduce code:
---
// causes unexpected *RECURSION* references
$var1 = 1;
$array = array();
for($i=0;$i33000;++$i) {
$var2 = $var1;
$array[] = array(
'var1' = $var1,
'var2' = $var2,
);
}
print_r($array[0]);
Expected result:
Array
(
[var1] = 1
[var2] = 1
)
Actual result:
--
Array
(
[var1] = Array
(
[var1] = Array
*RECURSION*
[var2] = Array
*RECURSION*
)
[var2] = Array
(
[var1] = Array
*RECURSION*
[var2] = Array
*RECURSION*
)
)
--
Edit this bug report at http://bugs.php.net/?id=26839edit=1
#25803 [Csd-Opn]: xml_get_current_byte_index() always returns 0 on PHP 5.x
ID: 25803
User updated by: j dot spit at uptime dot nl
Reported By: j dot spit at uptime dot nl
-Status: Closed
+Status: Open
Bug Type: XML related
Operating System: Irrelevant
PHP Version: 5CVS-2003-10-10
Assigned To: moriyoshi
New Comment:
Hello,
I am trying to find out what the current behaviour of
xml_get_current_byte_index() is in PHP5 version beta3 and above. Is
this documented somewhere ? I am developing software that is highly
dependant on this function.
Thanks !
Previous Comments:
[2003-11-26 16:07:41] j dot spit at uptime dot nl
Hi,
I noticed that in the latest CVS version it does not return zero
anymore, which is good, but on the other hand it does return different
values compared to php5.0.0b1. Can you enlighten me as to what value it
currently returns ?
Thanks.
[2003-11-24 01:10:02] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Behaviour of xml_get_current_byte_index() is subject to
change in php 5.0. It would probably return the end
position of the portion that has just been parsed, by
contrast to the old behaviour in 4.x, where it returns
the start position of the portion being parsed.
[2003-11-19 11:30:31] j dot spit at uptime dot nl
Have the same problem on Linux as well now, when using PHP5.0.0b2.
Any update yet ?
[2003-10-09 09:11:55] j dot spit at uptime dot nl
Description:
xml_get_current_byte_index always returns 0 on windows xp, it works
fine on Linux systems. Using PHP5 beta 1 on both platforms.
Reproduce code:
---
?php
function startElement($parser,$name,$attribs) {
echo Start : .xml_get_current_byte_index( $parser ).br;
}
function endElement($parser,$name) {
echo End : .xml_get_current_byte_index( $parser ).br;
}
$parser = xml_parser_create();
xml_set_element_handler($parser,'startElement','endElement');
xml_parser_set_option($parser,XML_OPTION_CASE_FOLDING,0);
xml_parse($parser,
a b=\x\testcblaat/c/a);
xml_parser_free($parser);
?
Expected result:
Start : 0
Start : 13
End : 21
End : 25
This is the output on a Linux system.
Actual result:
--
Start : 0
Start : 0
End : 0
End : 0
This is the output on a Windows XP system.
--
Edit this bug report at http://bugs.php.net/?id=25803edit=1
#26845 [NEW]: Very Seriously Bug!!!!
From: calmman dot yang at 163 dot com Operating system: Win2000Pro SP4 PHP version: 4.3.4 PHP Bug Type: Session related Bug description: Very Seriously Bug Description: Please Look at the screen shot! http://www.ltclan.net/bug.jpg very import!!! PHP Version 4.3.4 you can also use the mail: [EMAIL PROTECTED] -- Edit bug report at http://bugs.php.net/?id=26845edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26845r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26845r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26845r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26845r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26845r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26845r=needscript Try newer version: http://bugs.php.net/fix.php?id=26845r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26845r=support Expected behavior: http://bugs.php.net/fix.php?id=26845r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26845r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26845r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26845r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26845r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26845r=dst IIS Stability: http://bugs.php.net/fix.php?id=26845r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26845r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26845r=float
#26845 [Opn-Bgs]: Very Seriously Bug!!!!
ID: 26845 Updated by: [EMAIL PROTECTED] Reported By: calmman dot yang at 163 dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: Win2000Pro SP4 PHP Version: 4.3.4 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php $com-ComRType != $com-ComRTime Next time post a proper bugreport, screenshots are not an option. Previous Comments: [2004-01-08 11:35:44] calmman dot yang at 163 dot com Description: Please Look at the screen shot! http://www.ltclan.net/bug.jpg very import!!! PHP Version 4.3.4 you can also use the mail: [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=26845edit=1
#26206 [Fbk-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: No dice using php5-win32-200401081130 Previous Comments: [2004-01-07 21:38:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Please try the latest snapshot. [2003-12-01 13:57:39] danielc at analysisandsolutions dot com Everything worked fine until I switched from php5-win32-200310010230.zip to php5-win32-200311040330.zip I will track down exactly which snapshot in this time period started causing the problem. Then someone can examine the changes made in order to isolate the problem. Please inform me where I can find old snapshots to do this. http://snaps.php.net/win32/ only has the most recent few. [2003-12-01 13:31:20] [EMAIL PROTECTED] Well, I can't reproduce this with either CLI or CGI, using either php.ini-dist or php.ini-recommended. So there's something wrong with your system, not PHP. [2003-12-01 12:04:35] danielc at analysisandsolutions dot com 100% certain. New PHP installs on this system are by moving the entirety of the old install aside, extracting the contents of a new snapshot .zip file then copying the exact files/structure over to the php directory. The system finds the DLLS via the %path%, in which C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls; are the first two entries. The PHP DLL's have never been copied to any other location on this computer. [2003-12-01 03:25:23] [EMAIL PROTECTED] And you're absolutely sure you don't have ANY old PHP related dlls in your system before you installed the snapshot? (delete all php4ts.dll files..) 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/26206 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26847 [NEW]: memory leak with to_r and subject_r in mail() function
From: nutbar at innocent dot com Operating system: any - source code issue PHP version: 4.3.4 PHP Bug Type: Mail related Bug description: memory leak with to_r and subject_r in mail() function Description: In the actual source code for the PHP mail() function (ext/standard/mail.c), it sets some variables up to hold the To: and Subject: headers up, and other stuff. The problem is that if you look at the initial code that checks if the to_len count is greater than 0, it duplicates the to string to to_r and does some stuff to it. It does the same sort of thing with subject_len, subject, and subject_r in the exact same fashion. After the new to_r and subject_r strings are used, it goes to free them, but it does an if () test to see if it should or not - the if test compares to_len and subject_len to see if they are greater than 0 and if so, efree()'s them. The problem is that in the code that does stuff with to_r and subject_r, there are for loops which decrement to_len and subject_len so it can walk the strings. By doing this, you bring the to_len and subject_len variables to 0, thus nothing is ever efree()'d in the end, and you've got a memory leak. The leak is small and not noticable typically, but with mass mailing scripts that loop using mail(), it could be huge. Reproduce code: --- See mail.c - lines 106 to 113, 129 to 136, and then 160 to 165. Actual result: -- I have not tested for an actual memory leak by calling mail() in a loop - I was just going to write my own mail() function and was using the code in mail.c to do it with, and came across this. If this is a false report, I am sorry, but I do believe it's real. -- Edit bug report at http://bugs.php.net/?id=26847edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26847r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26847r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26847r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26847r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26847r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26847r=needscript Try newer version: http://bugs.php.net/fix.php?id=26847r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26847r=support Expected behavior: http://bugs.php.net/fix.php?id=26847r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26847r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26847r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26847r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26847r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26847r=dst IIS Stability: http://bugs.php.net/fix.php?id=26847r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26847r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26847r=float
#26791 [Opn]: mssql.textlimit and mssql.textsize can't be set via ini_set()
ID: 26791
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Know what? The problem was where the ini_set() calls are made. They
must be done BEFORE the connection is established. Once it's made, it
can't be changed.
Oddly, it doesn't matter when one calls ini_set() for
mssql.datetimeconvert.
So, I'm not sure this bug report should be closed, called bogus or not.
It might be nice to have these work regardless of where they are
called. If no change is made, the behavior needs to be documented.
Couple things to keep in mind about my config:
Using CGI
Loading mssql via php.ini extensions
Versions 4.3.4 and php5-win32-200401081130 snapshot
Previous Comments:
[2004-01-08 00:12:28] [EMAIL PROTECTED]
This seams to be related to how the extension is loaded.
ini_set() works fine in php4 whn the extension is loaded from php.ini,
but not when dl() is used.
The dl() will also cause the output from phpinfo() to be incomplete!
[2004-01-06 18:56:04] [EMAIL PROTECTED]
Frank, nothing has changed in that function. Are you sure this really
works with PHP 5..?
[2004-01-05 02:44:12] [EMAIL PROTECTED]
This works in PHP5 but not in PHP4.3.x (tested on the cvs version). Did
something happen to the ini_set() funtion ?
[2004-01-05 01:34:58] danielc at analysisandsolutions dot com
Description:
The mssql.textlimit and mssql.textsize configuration options
can't be set via ini_set(). Changing them in php.ini works.
This is also the case in a recent PHP 5 snapshot
(500rc1-dev--php5-win32-200401022330).
This is the same issue as bug 20797 which was closed due to no
feedback.
SCRIPT CAN CHANGE LIMIT
===
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
SET TEXTSIZE 20
SCRIPT CAN'T CHANGE LIMIT
=
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
ini_set('mssql.textlimit', 2147483647);
ini_set('mssql.textsize', 2147483647);
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
ini_set('mssql.textlimit', 20);
ini_set('mssql.textsize', 20);
php.ini
; mssql.textlimit = 2147483647
; mssql.textsize = 2147483647
script
SET TEXTSIZE 2147483647
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
SET TEXTSIZE 2147483647
--
Edit this bug report at http://bugs.php.net/?id=26791edit=1
#26839 [Ver]: unexpected results from simple array routine
ID: 26839
Updated by: [EMAIL PROTECTED]
Reported By: dweller at devonweller dot com
Status: Verified
Bug Type: Arrays related
Operating System: Linux Intel (Redhat)
PHP Version: 4CVS-2004-01-08 (dev)
New Comment:
Works fine with PHP 5, crashes for me with PHP 4 (latest CVS):
#0 0x407884ec in mempcpy () from /lib/i686/libc.so.6
#1 0x4077a850 in _IO_new_file_xsputn () from /lib/i686/libc.so.6
#2 0x4076ff9f in fwrite () from /lib/i686/libc.so.6
#3 0x082b0f75 in sapi_cli_single_write (str=0x0,
str_length=1515870810) at /usr/src/web/php/php4/sapi/cli/php_cli.c:190
#4 0x082afb2e in sapi_cli_ub_write (str=0x0, str_length=1515870810) at
/usr/src/web/php/php4/sapi/cli/php_cli.c:203
#5 0x082699fd in php_ub_body_write_no_header (str=0x0,
str_length=1515870810)
at /usr/src/web/php/php4/main/output.c:689
#6 0x0826863a in php_body_write (str=0x0, str_length=1515870810) at
/usr/src/web/php/php4/main/output.c:121
#7 0x08254dc0 in php_body_write_wrapper (str=0x0,
str_length=1515870810) at /usr/src/web/php/php4/main/main.c:1022
#8 0x0828c2d8 in zend_print_zval_ex (write_func=0x8254d9f
php_body_write_wrapper, expr=0xbfffd330, indent=0)
at /usr/src/web/php/php4/Zend/zend.c:211
#9 0x0828c256 in zend_print_zval (expr=0x864e2cc, indent=0) at
/usr/src/web/php/php4/Zend/zend.c:192
#10 0x0828bd0f in zend_print_variable (var=0x864e2cc) at
/usr/src/web/php/php4/Zend/zend_variables.c:147
#11 0x0828c45a in zend_print_zval_r_ex (write_func=0x8254d9f
php_body_write_wrapper, expr=0x864e2cc, indent=8)
at /usr/src/web/php/php4/Zend/zend.c:253
#12 0x0828c335 in zend_print_zval_r (expr=0x864e2cc, indent=8) at
/usr/src/web/php/php4/Zend/zend.c:221
#13 0x0828bf6f in print_hash (ht=0x865337c, indent=4) at
/usr/src/web/php/php4/Zend/zend.c:130
#14 0x0828c3c8 in zend_print_zval_r_ex (write_func=0x8254d9f
php_body_write_wrapper, expr=0x86534e4, indent=0)
at /usr/src/web/php/php4/Zend/zend.c:235
#15 0x0828c335 in zend_print_zval_r (expr=0x86534e4, indent=0) at
/usr/src/web/php/php4/Zend/zend.c:221
#16 0x081e082d in zif_print_r (ht=1, return_value=0x962c23c,
this_ptr=0x0, return_value_used=0)
at /usr/src/web/php/php4/ext/standard/basic_functions.c:2488
#17 0x0829ed0e in execute (op_array=0x864e9f4) at
/usr/src/web/php/php4/Zend/zend_execute.c:1616
#18 0x0828d76a in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/web/php/php4/Zend/zend.c:884
#19 0x08256573 in php_execute_script (primary_file=0xbbc0) at
/usr/src/web/php/php4/main/main.c:1727
#20 0x082b0da3 in main (argc=2, argv=0xbc54) at
/usr/src/web/php/php4/sapi/cli/php_cli.c:820
Previous Comments:
[2004-01-08 10:04:42] [EMAIL PROTECTED]
$i 32768 results in
array(2) {
[var1]=
UNKNOWN:0
[var2]=
UNKNOWN:0
}
$i 32767 results in
array(2) {
[var1]=
int(1)
[var2]=
int(1)
}
[2004-01-08 07:01:49] dweller at devonweller dot com
Description:
The attached simple array routine produces unexpected
results when the loop count is greater than approx.
33000. Perhaps this is some kind of reference counting
bug.
Reproduce code:
---
// causes unexpected *RECURSION* references
$var1 = 1;
$array = array();
for($i=0;$i33000;++$i) {
$var2 = $var1;
$array[] = array(
'var1' = $var1,
'var2' = $var2,
);
}
print_r($array[0]);
Expected result:
Array
(
[var1] = 1
[var2] = 1
)
Actual result:
--
Array
(
[var1] = Array
(
[var1] = Array
*RECURSION*
[var2] = Array
*RECURSION*
)
[var2] = Array
(
[var1] = Array
*RECURSION*
[var2] = Array
*RECURSION*
)
)
--
Edit this bug report at http://bugs.php.net/?id=26839edit=1
#26839 [Ver]: unexpected results from simple array routine
ID: 26839
Updated by: [EMAIL PROTECTED]
Reported By: dweller at devonweller dot com
Status: Verified
Bug Type: Arrays related
Operating System: Linux Intel (Redhat)
PHP Version: 4CVS-2004-01-08 (dev)
New Comment:
Without the print_r() call no crash but this:
---
/usr/src/web/php/php4/Zend/zend_execute.h(44) : Block 0x0864E478
status:
Beginning: Overrun (magic=0x40847B54, expected=0x7312F8DC)
End: Unknown
---
Previous Comments:
[2004-01-08 14:28:14] [EMAIL PROTECTED]
Works fine with PHP 5, crashes for me with PHP 4 (latest CVS):
#0 0x407884ec in mempcpy () from /lib/i686/libc.so.6
#1 0x4077a850 in _IO_new_file_xsputn () from /lib/i686/libc.so.6
#2 0x4076ff9f in fwrite () from /lib/i686/libc.so.6
#3 0x082b0f75 in sapi_cli_single_write (str=0x0,
str_length=1515870810) at /usr/src/web/php/php4/sapi/cli/php_cli.c:190
#4 0x082afb2e in sapi_cli_ub_write (str=0x0, str_length=1515870810) at
/usr/src/web/php/php4/sapi/cli/php_cli.c:203
#5 0x082699fd in php_ub_body_write_no_header (str=0x0,
str_length=1515870810)
at /usr/src/web/php/php4/main/output.c:689
#6 0x0826863a in php_body_write (str=0x0, str_length=1515870810) at
/usr/src/web/php/php4/main/output.c:121
#7 0x08254dc0 in php_body_write_wrapper (str=0x0,
str_length=1515870810) at /usr/src/web/php/php4/main/main.c:1022
#8 0x0828c2d8 in zend_print_zval_ex (write_func=0x8254d9f
php_body_write_wrapper, expr=0xbfffd330, indent=0)
at /usr/src/web/php/php4/Zend/zend.c:211
#9 0x0828c256 in zend_print_zval (expr=0x864e2cc, indent=0) at
/usr/src/web/php/php4/Zend/zend.c:192
#10 0x0828bd0f in zend_print_variable (var=0x864e2cc) at
/usr/src/web/php/php4/Zend/zend_variables.c:147
#11 0x0828c45a in zend_print_zval_r_ex (write_func=0x8254d9f
php_body_write_wrapper, expr=0x864e2cc, indent=8)
at /usr/src/web/php/php4/Zend/zend.c:253
#12 0x0828c335 in zend_print_zval_r (expr=0x864e2cc, indent=8) at
/usr/src/web/php/php4/Zend/zend.c:221
#13 0x0828bf6f in print_hash (ht=0x865337c, indent=4) at
/usr/src/web/php/php4/Zend/zend.c:130
#14 0x0828c3c8 in zend_print_zval_r_ex (write_func=0x8254d9f
php_body_write_wrapper, expr=0x86534e4, indent=0)
at /usr/src/web/php/php4/Zend/zend.c:235
#15 0x0828c335 in zend_print_zval_r (expr=0x86534e4, indent=0) at
/usr/src/web/php/php4/Zend/zend.c:221
#16 0x081e082d in zif_print_r (ht=1, return_value=0x962c23c,
this_ptr=0x0, return_value_used=0)
at /usr/src/web/php/php4/ext/standard/basic_functions.c:2488
#17 0x0829ed0e in execute (op_array=0x864e9f4) at
/usr/src/web/php/php4/Zend/zend_execute.c:1616
#18 0x0828d76a in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/web/php/php4/Zend/zend.c:884
#19 0x08256573 in php_execute_script (primary_file=0xbbc0) at
/usr/src/web/php/php4/main/main.c:1727
#20 0x082b0da3 in main (argc=2, argv=0xbc54) at
/usr/src/web/php/php4/sapi/cli/php_cli.c:820
[2004-01-08 10:04:42] [EMAIL PROTECTED]
$i 32768 results in
array(2) {
[var1]=
UNKNOWN:0
[var2]=
UNKNOWN:0
}
$i 32767 results in
array(2) {
[var1]=
int(1)
[var2]=
int(1)
}
[2004-01-08 07:01:49] dweller at devonweller dot com
Description:
The attached simple array routine produces unexpected
results when the loop count is greater than approx.
33000. Perhaps this is some kind of reference counting
bug.
Reproduce code:
---
// causes unexpected *RECURSION* references
$var1 = 1;
$array = array();
for($i=0;$i33000;++$i) {
$var2 = $var1;
$array[] = array(
'var1' = $var1,
'var2' = $var2,
);
}
print_r($array[0]);
Expected result:
Array
(
[var1] = 1
[var2] = 1
)
Actual result:
--
Array
(
[var1] = Array
(
[var1] = Array
*RECURSION*
[var2] = Array
*RECURSION*
)
[var2] = Array
(
[var1] = Array
*RECURSION*
[var2] = Array
*RECURSION*
)
)
--
Edit this bug report at http://bugs.php.net/?id=26839edit=1
#26846 [Opn-Fbk]: fpassthru() segfaults on certain files
ID: 26846 Updated by: [EMAIL PROTECTED] Reported By: djones at xtreme-eda dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE PHP Version: 4.3.4 New Comment: Thank you for this bug report. To properly diagnose the problem, 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. Thank you for helping us make PHP better. Previous Comments: [2004-01-08 13:16:54] djones at xtreme-eda dot com Description: PHP configuration: http://www.inode.org/test.php I am running an application that sends files to the user using fpassthru(). With certain files, Apache exits with signal 11. There does not seem to be any distinguishing characteristic between files that are sent OK and files that are not. Reproduce code: --- See http://www.inode.org/passthru.php_ The trailing underscore prevents execution so you can view the source. The code contains paths to two files; one of which can be transferred and one that cannot. You may transfer these files to your system to attempt reproduction. (Instructions for said transfer are provided in passthru.php) Running the BAD file from the PHP command line appears to work correctly so this might be a PHP-Apache interaction issue. Expected result: With the GOOD file: you can save the document and view it. With the BAD file: I would expect to be able to save it too. Actual result: -- With the BAD file: Apache segfaults signal 11. I'm not sure how I can get a GDB backtrace from a running Apache instance. -- Edit this bug report at http://bugs.php.net/?id=26846edit=1
#26848 [NEW]: Make highlight functions XHTML 1.0 Strict compliant
From: phpman at fosketts dot co dot uk Operating system: Win XP PHP version: 4.3.4 PHP Bug Type: Feature/Change Request Bug description: Make highlight functions XHTML 1.0 Strict compliant Description: Will the highlight functions (highlight_string() and highlight_file()) be modified to produce valid XHTML 1.0 Strict output? This has already been done in other functions, e.g. nl2br(). A simple solution would be to edit zend_highlight.c as follows: 1) Replace font color=\%s\ with span style=\color: %s\ on lines 106 and 155 2) Replace /font with /span on lines 151, 191 and 193 Thanks Sean :) -- Edit bug report at http://bugs.php.net/?id=26848edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26848r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26848r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26848r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26848r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26848r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26848r=needscript Try newer version: http://bugs.php.net/fix.php?id=26848r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26848r=support Expected behavior: http://bugs.php.net/fix.php?id=26848r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26848r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26848r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26848r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26848r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26848r=dst IIS Stability: http://bugs.php.net/fix.php?id=26848r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26848r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26848r=float
#25640 [Asn-Bgs]: simplexml element object properties return empty objects
ID: 25640
Updated by: [EMAIL PROTECTED]
Reported By: tater at potatoe dot com
-Status: Assigned
+Status: Bogus
Bug Type: XML related
Operating System: *
-PHP Version: 5CVS-2003-09-23 (dev)
+PHP Version: 5*
Assigned To: sterling
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
A property access returns the element (as an object).
Using __tostring() or conversion by (string) returns the text content.
If an element contains multiple elements of the same name then
accessing those by proeprty returns an array of eleemnt objects. So all
is fine.
Previous Comments:
[2003-12-16 08:52:10] tim at timcrider dot com
I have been able to produce a similar problem, but I'm not sure if it's
exactly the same bug or a variant of this one.
-[ XML Field ]-
?xml version=1.0 encoding=UTF-8?
test
fields
myFielda/myField
myFieldb/myField
myFieldc/myField
/fields
/test
-[ Script ]-
#!/usr/local/bin/php -q
?php
$sx = simplexml_load_file(_example.xml);
print_r($sx);
for ($i = 0; $i count($sx-fields-myField); $i++)
{
$v = $sx-fields-myField[$i];
print True Value: {$v}\n;
$tmp[] = $v;
$tmp2[] = $v;
}
print Trying to view 'tmp' array:\n\n;
print_r($tmp);
print Trying to view 'tmp2' array:\n\n;
print_r($tmp2);
?
-[ Output ]-
simplexml_element Object
(
[fields] = simplexml_element Object
(
[myField] = Array
(
[0] = a
[1] = b
[2] = c
)
)
)
True Value: a
True Value: b
True Value: c
Trying to view 'tmp' array:
Array
(
[0] = simplexml_element Object
(
)
[1] = simplexml_element Object
(
)
[2] = simplexml_element Object
(
)
)
Trying to view 'tmp2' array:
Array
(
[0] = a
[1] = b
[2] = c
)
-[ PHP Version Info ]-
PHP 5.0.0b2 (cli) (built: Dec 7 2003 18:04:51)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies
with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St.
Petersburg, by Dmitry Stogov
I tried the latest CVS, at the time of this posting, and it would not
build because of a mysqli compile problem.
[2003-09-23 21:25:25] tater at potatoe dot com
Description:
I guess this is related to the recent toString() stuff -
simplexml_element object properties can't be printed or
assigned, they all come out as 'Object #x'. the string
values turn into empty simplexml_element objects.
Reproduce code:
---
?php
$xml = 'wrapperfoos1/foobars2/barbars3/bar/wrapper';
$t = simplexml_load_string($xml);
var_dump($t,$t-foo,$t-bar);
?
Expected result:
object(simplexml_element)#1 (2) {
[foo]=
string(2) s1
[bar]=
array(2) {
[0]=
string(2) s2
[1]=
string(2) s3
}
}
string(2) s1
array(2) {
[0]=
string(2) s2
[1]=
string(2) s3
}
Actual result:
--
object(simplexml_element)#1 (2) {
[foo]=
string(2) s1
[bar]=
array(2) {
[0]=
string(2) s2
[1]=
string(2) s3
}
}
object(simplexml_element)#2 (0) {
}
array(2) {
[0]=
object(simplexml_element)#3 (0) {
}
[1]=
object(simplexml_element)#4 (0) {
}
}
--
Edit this bug report at http://bugs.php.net/?id=25640edit=1
#26847 [Opn]: memory leak with to_r and subject_r in mail() function
ID: 26847
User updated by: nutbar at innocent dot com
Reported By: nutbar at innocent dot com
Status: Open
Bug Type: Mail related
Operating System: any - source code issue
PHP Version: 4.3.4
New Comment:
By the way, very simple fix:
Add this to the variable declarations:
int j = 0;
Then the lines of code as mentioned before, but fixed:
if (to_len 0) {
to_r = estrndup(to, to_len);
for (j = to_len; j 0; j--) {
if (!isspace((unsigned char) to_r[j - 1])) {
break;
}
to_r[j - 1] = '\0';
}
and:
if (subject_len 0) {
subject_r = estrndup(subject, subject_len);
for (j = subject_len; j 0; j--) {
if (!isspace((unsigned char) subject_r[j - 1]))
{
break;
}
subject_r[j - 1] = '\0';
}
I just initialized j in the for loop to be the value of to_len and
subject_len, then I use j everywhere rather than to_len or subject_len
so that they stay unmodified.
Previous Comments:
[2004-01-08 13:22:55] nutbar at innocent dot com
Description:
In the actual source code for the PHP mail() function
(ext/standard/mail.c), it sets some variables up to hold the To: and
Subject: headers up, and other stuff.
The problem is that if you look at the initial code that checks if the
to_len count is greater than 0, it duplicates the to string to
to_r and does some stuff to it.
It does the same sort of thing with subject_len, subject, and subject_r
in the exact same fashion.
After the new to_r and subject_r strings are used, it goes to free
them, but it does an if () test to see if it should or not - the if
test compares to_len and subject_len to see if they are greater than 0
and if so, efree()'s them.
The problem is that in the code that does stuff with to_r and
subject_r, there are for loops which decrement to_len and subject_len
so it can walk the strings. By doing this, you bring the to_len and
subject_len variables to 0, thus nothing is ever efree()'d in the end,
and you've got a memory leak.
The leak is small and not noticable typically, but with mass mailing
scripts that loop using mail(), it could be huge.
Reproduce code:
---
See mail.c - lines 106 to 113, 129 to 136, and then 160 to 165.
Actual result:
--
I have not tested for an actual memory leak by calling mail() in a loop
- I was just going to write my own mail() function and was using the
code in mail.c to do it with, and came across this.
If this is a false report, I am sorry, but I do believe it's real.
--
Edit this bug report at http://bugs.php.net/?id=26847edit=1
#25640 [Bgs]: simplexml element object properties return empty objects
ID: 25640
User updated by: tater at potatoe dot com
Reported By: tater at potatoe dot com
Status: Bogus
Bug Type: XML related
Operating System: *
PHP Version: 5*
Assigned To: sterling
New Comment:
This bug was not bogus - assignments did not work, nor did printing.
There now seems to be some implicit string conversions that fix that.
Which is fine, I guess.
It's still very odd, at the least, that a property access returns an
empty object. Nothing else works like this. If it's intentional, it's a
very peculiar and questionable intention.
Run this code:
?php
$xml = 'wrapperfoos1/foobars2/barbars3/bar/wrapper';
$t = simplexml_load_string($xml);
$x = new stdClass;
$x-foo = 's1';
$x-bar = array('s2','s3');
var_dump($t,$t-foo,$t-bar);
var_dump($x,$x-foo,$x-bar);
?
and you really think the results are fine?? Whatever.
That word, bogus, is like pissing on the people entering bugs. (Ask a
native English speaker what they would think you meant if you called
something they did bogus.) If you'd rather just have a broken
product, then why allow bug entries at all?
Previous Comments:
[2004-01-08 14:55:40] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
A property access returns the element (as an object).
Using __tostring() or conversion by (string) returns the text content.
If an element contains multiple elements of the same name then
accessing those by proeprty returns an array of eleemnt objects. So all
is fine.
[2003-12-16 08:52:10] tim at timcrider dot com
I have been able to produce a similar problem, but I'm not sure if it's
exactly the same bug or a variant of this one.
-[ XML Field ]-
?xml version=1.0 encoding=UTF-8?
test
fields
myFielda/myField
myFieldb/myField
myFieldc/myField
/fields
/test
-[ Script ]-
#!/usr/local/bin/php -q
?php
$sx = simplexml_load_file(_example.xml);
print_r($sx);
for ($i = 0; $i count($sx-fields-myField); $i++)
{
$v = $sx-fields-myField[$i];
print True Value: {$v}\n;
$tmp[] = $v;
$tmp2[] = $v;
}
print Trying to view 'tmp' array:\n\n;
print_r($tmp);
print Trying to view 'tmp2' array:\n\n;
print_r($tmp2);
?
-[ Output ]-
simplexml_element Object
(
[fields] = simplexml_element Object
(
[myField] = Array
(
[0] = a
[1] = b
[2] = c
)
)
)
True Value: a
True Value: b
True Value: c
Trying to view 'tmp' array:
Array
(
[0] = simplexml_element Object
(
)
[1] = simplexml_element Object
(
)
[2] = simplexml_element Object
(
)
)
Trying to view 'tmp2' array:
Array
(
[0] = a
[1] = b
[2] = c
)
-[ PHP Version Info ]-
PHP 5.0.0b2 (cli) (built: Dec 7 2003 18:04:51)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies
with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St.
Petersburg, by Dmitry Stogov
I tried the latest CVS, at the time of this posting, and it would not
build because of a mysqli compile problem.
[2003-09-23 21:25:25] tater at potatoe dot com
Description:
I guess this is related to the recent toString() stuff -
simplexml_element object properties can't be printed or
assigned, they all come out as 'Object #x'. the string
values turn into empty simplexml_element objects.
Reproduce code:
---
?php
$xml = 'wrapperfoos1/foobars2/barbars3/bar/wrapper';
$t = simplexml_load_string($xml);
var_dump($t,$t-foo,$t-bar);
?
Expected result:
object(simplexml_element)#1 (2) {
[foo]=
string(2) s1
[bar]=
array(2) {
[0]=
string(2) s2
[1]=
string(2) s3
}
}
string(2) s1
array(2) {
[0]=
string(2) s2
[1]=
string(2) s3
}
Actual result:
--
object(simplexml_element)#1 (2) {
[foo]=
string(2) s1
[bar]=
array(2) {
[0]=
string(2) s2
[1]=
string(2) s3
}
}
object(simplexml_element)#2 (0) {
}
array(2) {
[0]=
object(simplexml_element)#3 (0) {
}
[1]=
object(simplexml_element)#4 (0) {
}
}
--
Edit this bug report at http://bugs.php.net/?id=25640edit=1
#26847 [Opn]: memory leak with to_r and subject_r in mail() function
ID: 26847
User updated by: nutbar at innocent dot com
Reported By: nutbar at innocent dot com
Status: Open
Bug Type: Mail related
Operating System: any - source code issue
PHP Version: 4.3.4
New Comment:
I guess an alternate fix would also be when the efree()'s are called.
If you init all your char *'s to NULL, then you can simply do:
if (to_r != NULL) {
efree(to_r);
}
if (subject_r != NULL) {
efree(subject_r);
}
Previous Comments:
[2004-01-08 15:31:12] nutbar at innocent dot com
By the way, very simple fix:
Add this to the variable declarations:
int j = 0;
Then the lines of code as mentioned before, but fixed:
if (to_len 0) {
to_r = estrndup(to, to_len);
for (j = to_len; j 0; j--) {
if (!isspace((unsigned char) to_r[j - 1])) {
break;
}
to_r[j - 1] = '\0';
}
and:
if (subject_len 0) {
subject_r = estrndup(subject, subject_len);
for (j = subject_len; j 0; j--) {
if (!isspace((unsigned char) subject_r[j - 1]))
{
break;
}
subject_r[j - 1] = '\0';
}
I just initialized j in the for loop to be the value of to_len and
subject_len, then I use j everywhere rather than to_len or subject_len
so that they stay unmodified.
[2004-01-08 13:22:55] nutbar at innocent dot com
Description:
In the actual source code for the PHP mail() function
(ext/standard/mail.c), it sets some variables up to hold the To: and
Subject: headers up, and other stuff.
The problem is that if you look at the initial code that checks if the
to_len count is greater than 0, it duplicates the to string to
to_r and does some stuff to it.
It does the same sort of thing with subject_len, subject, and subject_r
in the exact same fashion.
After the new to_r and subject_r strings are used, it goes to free
them, but it does an if () test to see if it should or not - the if
test compares to_len and subject_len to see if they are greater than 0
and if so, efree()'s them.
The problem is that in the code that does stuff with to_r and
subject_r, there are for loops which decrement to_len and subject_len
so it can walk the strings. By doing this, you bring the to_len and
subject_len variables to 0, thus nothing is ever efree()'d in the end,
and you've got a memory leak.
The leak is small and not noticable typically, but with mass mailing
scripts that loop using mail(), it could be huge.
Reproduce code:
---
See mail.c - lines 106 to 113, 129 to 136, and then 160 to 165.
Actual result:
--
I have not tested for an actual memory leak by calling mail() in a loop
- I was just going to write my own mail() function and was using the
code in mail.c to do it with, and came across this.
If this is a false report, I am sorry, but I do believe it's real.
--
Edit this bug report at http://bugs.php.net/?id=26847edit=1
#26847 [Opn-Bgs]: memory leak with to_r and subject_r in mail() function
ID: 26847
Updated by: [EMAIL PROTECTED]
Reported By: nutbar at innocent dot com
-Status: Open
+Status: Bogus
Bug Type: Mail related
Operating System: any - source code issue
PHP Version: 4.3.4
New Comment:
Impossible leak.
if (to_len 0) {
efree(to_r);
}
if (subject_len 0) {
efree(subject_r);
}
Is what the code in CVS does. If to_len or subject_len are
1 then no allocation happens in the 1st place.
Previous Comments:
[2004-01-08 15:34:23] nutbar at innocent dot com
I guess an alternate fix would also be when the efree()'s are called.
If you init all your char *'s to NULL, then you can simply do:
if (to_r != NULL) {
efree(to_r);
}
if (subject_r != NULL) {
efree(subject_r);
}
[2004-01-08 15:31:12] nutbar at innocent dot com
By the way, very simple fix:
Add this to the variable declarations:
int j = 0;
Then the lines of code as mentioned before, but fixed:
if (to_len 0) {
to_r = estrndup(to, to_len);
for (j = to_len; j 0; j--) {
if (!isspace((unsigned char) to_r[j - 1])) {
break;
}
to_r[j - 1] = '\0';
}
and:
if (subject_len 0) {
subject_r = estrndup(subject, subject_len);
for (j = subject_len; j 0; j--) {
if (!isspace((unsigned char) subject_r[j - 1]))
{
break;
}
subject_r[j - 1] = '\0';
}
I just initialized j in the for loop to be the value of to_len and
subject_len, then I use j everywhere rather than to_len or subject_len
so that they stay unmodified.
[2004-01-08 13:22:55] nutbar at innocent dot com
Description:
In the actual source code for the PHP mail() function
(ext/standard/mail.c), it sets some variables up to hold the To: and
Subject: headers up, and other stuff.
The problem is that if you look at the initial code that checks if the
to_len count is greater than 0, it duplicates the to string to
to_r and does some stuff to it.
It does the same sort of thing with subject_len, subject, and subject_r
in the exact same fashion.
After the new to_r and subject_r strings are used, it goes to free
them, but it does an if () test to see if it should or not - the if
test compares to_len and subject_len to see if they are greater than 0
and if so, efree()'s them.
The problem is that in the code that does stuff with to_r and
subject_r, there are for loops which decrement to_len and subject_len
so it can walk the strings. By doing this, you bring the to_len and
subject_len variables to 0, thus nothing is ever efree()'d in the end,
and you've got a memory leak.
The leak is small and not noticable typically, but with mass mailing
scripts that loop using mail(), it could be huge.
Reproduce code:
---
See mail.c - lines 106 to 113, 129 to 136, and then 160 to 165.
Actual result:
--
I have not tested for an actual memory leak by calling mail() in a loop
- I was just going to write my own mail() function and was using the
code in mail.c to do it with, and came across this.
If this is a false report, I am sorry, but I do believe it's real.
--
Edit this bug report at http://bugs.php.net/?id=26847edit=1
#25640 [Bgs]: simplexml element object properties return empty objects
ID: 25640
Updated by: [EMAIL PROTECTED]
Reported By: tater at potatoe dot com
Status: Bogus
Bug Type: XML related
Operating System: *
PHP Version: 5*
Assigned To: sterling
New Comment:
The word bogus may be bogus but hey that's an automatic reply - sorry
if you get pissed of by an autoreply.
Previous Comments:
[2004-01-08 15:33:49] tater at potatoe dot com
This bug was not bogus - assignments did not work, nor did printing.
There now seems to be some implicit string conversions that fix that.
Which is fine, I guess.
It's still very odd, at the least, that a property access returns an
empty object. Nothing else works like this. If it's intentional, it's a
very peculiar and questionable intention.
Run this code:
?php
$xml = 'wrapperfoos1/foobars2/barbars3/bar/wrapper';
$t = simplexml_load_string($xml);
$x = new stdClass;
$x-foo = 's1';
$x-bar = array('s2','s3');
var_dump($t,$t-foo,$t-bar);
var_dump($x,$x-foo,$x-bar);
?
and you really think the results are fine?? Whatever.
That word, bogus, is like pissing on the people entering bugs. (Ask a
native English speaker what they would think you meant if you called
something they did bogus.) If you'd rather just have a broken
product, then why allow bug entries at all?
[2004-01-08 14:55:40] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
A property access returns the element (as an object).
Using __tostring() or conversion by (string) returns the text content.
If an element contains multiple elements of the same name then
accessing those by proeprty returns an array of eleemnt objects. So all
is fine.
[2003-12-16 08:52:10] tim at timcrider dot com
I have been able to produce a similar problem, but I'm not sure if it's
exactly the same bug or a variant of this one.
-[ XML Field ]-
?xml version=1.0 encoding=UTF-8?
test
fields
myFielda/myField
myFieldb/myField
myFieldc/myField
/fields
/test
-[ Script ]-
#!/usr/local/bin/php -q
?php
$sx = simplexml_load_file(_example.xml);
print_r($sx);
for ($i = 0; $i count($sx-fields-myField); $i++)
{
$v = $sx-fields-myField[$i];
print True Value: {$v}\n;
$tmp[] = $v;
$tmp2[] = $v;
}
print Trying to view 'tmp' array:\n\n;
print_r($tmp);
print Trying to view 'tmp2' array:\n\n;
print_r($tmp2);
?
-[ Output ]-
simplexml_element Object
(
[fields] = simplexml_element Object
(
[myField] = Array
(
[0] = a
[1] = b
[2] = c
)
)
)
True Value: a
True Value: b
True Value: c
Trying to view 'tmp' array:
Array
(
[0] = simplexml_element Object
(
)
[1] = simplexml_element Object
(
)
[2] = simplexml_element Object
(
)
)
Trying to view 'tmp2' array:
Array
(
[0] = a
[1] = b
[2] = c
)
-[ PHP Version Info ]-
PHP 5.0.0b2 (cli) (built: Dec 7 2003 18:04:51)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies
with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St.
Petersburg, by Dmitry Stogov
I tried the latest CVS, at the time of this posting, and it would not
build because of a mysqli compile problem.
[2003-09-23 21:25:25] tater at potatoe dot com
Description:
I guess this is related to the recent toString() stuff -
simplexml_element object properties can't be printed or
assigned, they all come out as 'Object #x'. the string
values turn into empty simplexml_element objects.
Reproduce code:
---
?php
$xml = 'wrapperfoos1/foobars2/barbars3/bar/wrapper';
$t = simplexml_load_string($xml);
var_dump($t,$t-foo,$t-bar);
?
Expected result:
object(simplexml_element)#1 (2) {
[foo]=
string(2) s1
[bar]=
array(2) {
[0]=
string(2) s2
[1]=
string(2) s3
}
}
string(2) s1
array(2) {
[0]=
string(2) s2
[1]=
string(2) s3
}
Actual result:
--
object(simplexml_element)#1 (2) {
[foo]=
string(2) s1
[bar]=
array(2) {
[0]=
string(2) s2
[1]=
string(2) s3
}
}
object(simplexml_element)#2 (0) {
}
array(2) {
[0]=
object(simplexml_element)#3 (0) {
}
[1]=
object(simplexml_element)#4 (0) {
}
}
--
Edit this bug report at http://bugs.php.net/?id=25640edit=1
#25640 [Bgs]: simplexml element object properties return empty objects
ID: 25640
Updated by: [EMAIL PROTECTED]
Reported By: tater at potatoe dot com
Status: Bogus
Bug Type: XML related
Operating System: *
PHP Version: 5*
Assigned To: sterling
New Comment:
The objects are empty because they only use dynamic properties and do
not declare any objects. Those properties can be seen as if they were
handled by __get() and __set() in user defined classes.
Previous Comments:
[2004-01-08 15:41:23] [EMAIL PROTECTED]
The word bogus may be bogus but hey that's an automatic reply - sorry
if you get pissed of by an autoreply.
[2004-01-08 15:33:49] tater at potatoe dot com
This bug was not bogus - assignments did not work, nor did printing.
There now seems to be some implicit string conversions that fix that.
Which is fine, I guess.
It's still very odd, at the least, that a property access returns an
empty object. Nothing else works like this. If it's intentional, it's a
very peculiar and questionable intention.
Run this code:
?php
$xml = 'wrapperfoos1/foobars2/barbars3/bar/wrapper';
$t = simplexml_load_string($xml);
$x = new stdClass;
$x-foo = 's1';
$x-bar = array('s2','s3');
var_dump($t,$t-foo,$t-bar);
var_dump($x,$x-foo,$x-bar);
?
and you really think the results are fine?? Whatever.
That word, bogus, is like pissing on the people entering bugs. (Ask a
native English speaker what they would think you meant if you called
something they did bogus.) If you'd rather just have a broken
product, then why allow bug entries at all?
[2004-01-08 14:55:40] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
A property access returns the element (as an object).
Using __tostring() or conversion by (string) returns the text content.
If an element contains multiple elements of the same name then
accessing those by proeprty returns an array of eleemnt objects. So all
is fine.
[2003-12-16 08:52:10] tim at timcrider dot com
I have been able to produce a similar problem, but I'm not sure if it's
exactly the same bug or a variant of this one.
-[ XML Field ]-
?xml version=1.0 encoding=UTF-8?
test
fields
myFielda/myField
myFieldb/myField
myFieldc/myField
/fields
/test
-[ Script ]-
#!/usr/local/bin/php -q
?php
$sx = simplexml_load_file(_example.xml);
print_r($sx);
for ($i = 0; $i count($sx-fields-myField); $i++)
{
$v = $sx-fields-myField[$i];
print True Value: {$v}\n;
$tmp[] = $v;
$tmp2[] = $v;
}
print Trying to view 'tmp' array:\n\n;
print_r($tmp);
print Trying to view 'tmp2' array:\n\n;
print_r($tmp2);
?
-[ Output ]-
simplexml_element Object
(
[fields] = simplexml_element Object
(
[myField] = Array
(
[0] = a
[1] = b
[2] = c
)
)
)
True Value: a
True Value: b
True Value: c
Trying to view 'tmp' array:
Array
(
[0] = simplexml_element Object
(
)
[1] = simplexml_element Object
(
)
[2] = simplexml_element Object
(
)
)
Trying to view 'tmp2' array:
Array
(
[0] = a
[1] = b
[2] = c
)
-[ PHP Version Info ]-
PHP 5.0.0b2 (cli) (built: Dec 7 2003 18:04:51)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies
with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St.
Petersburg, by Dmitry Stogov
I tried the latest CVS, at the time of this posting, and it would not
build because of a mysqli compile problem.
[2003-09-23 21:25:25] tater at potatoe dot com
Description:
I guess this is related to the recent toString() stuff -
simplexml_element object properties can't be printed or
assigned, they all come out as 'Object #x'. the string
values turn into empty simplexml_element objects.
Reproduce code:
---
?php
$xml = 'wrapperfoos1/foobars2/barbars3/bar/wrapper';
$t = simplexml_load_string($xml);
var_dump($t,$t-foo,$t-bar);
?
Expected result:
object(simplexml_element)#1 (2) {
[foo]=
string(2) s1
[bar]=
array(2) {
[0]=
string(2) s2
[1]=
string(2) s3
}
}
string(2) s1
array(2) {
[0]=
string(2) s2
[1]=
string(2) s3
}
Actual result:
--
object(simplexml_element)#1 (2) {
[foo]=
string(2) s1
[bar]=
array(2) {
[0]=
string(2) s2
[1]=
string(2) s3
}
}
#26847 [Bgs]: memory leak with to_r and subject_r in mail() function
ID: 26847
User updated by: nutbar at innocent dot com
Reported By: nutbar at innocent dot com
Status: Bogus
Bug Type: Mail related
Operating System: any - source code issue
PHP Version: 4.3.4
New Comment:
I know they check to_len and subject_len - that's not really the
problem.
The problem is that the for loops above that decrement to_len and
subject_len - thus modifying them from their original values.
to_len and subject_len will always be 0, even if they weren't 0 to
begin with. Do you see what I'm referring to?
Previous Comments:
[2004-01-08 15:38:41] [EMAIL PROTECTED]
Impossible leak.
if (to_len 0) {
efree(to_r);
}
if (subject_len 0) {
efree(subject_r);
}
Is what the code in CVS does. If to_len or subject_len are
1 then no allocation happens in the 1st place.
[2004-01-08 15:34:23] nutbar at innocent dot com
I guess an alternate fix would also be when the efree()'s are called.
If you init all your char *'s to NULL, then you can simply do:
if (to_r != NULL) {
efree(to_r);
}
if (subject_r != NULL) {
efree(subject_r);
}
[2004-01-08 15:31:12] nutbar at innocent dot com
By the way, very simple fix:
Add this to the variable declarations:
int j = 0;
Then the lines of code as mentioned before, but fixed:
if (to_len 0) {
to_r = estrndup(to, to_len);
for (j = to_len; j 0; j--) {
if (!isspace((unsigned char) to_r[j - 1])) {
break;
}
to_r[j - 1] = '\0';
}
and:
if (subject_len 0) {
subject_r = estrndup(subject, subject_len);
for (j = subject_len; j 0; j--) {
if (!isspace((unsigned char) subject_r[j - 1]))
{
break;
}
subject_r[j - 1] = '\0';
}
I just initialized j in the for loop to be the value of to_len and
subject_len, then I use j everywhere rather than to_len or subject_len
so that they stay unmodified.
[2004-01-08 13:22:55] nutbar at innocent dot com
Description:
In the actual source code for the PHP mail() function
(ext/standard/mail.c), it sets some variables up to hold the To: and
Subject: headers up, and other stuff.
The problem is that if you look at the initial code that checks if the
to_len count is greater than 0, it duplicates the to string to
to_r and does some stuff to it.
It does the same sort of thing with subject_len, subject, and subject_r
in the exact same fashion.
After the new to_r and subject_r strings are used, it goes to free
them, but it does an if () test to see if it should or not - the if
test compares to_len and subject_len to see if they are greater than 0
and if so, efree()'s them.
The problem is that in the code that does stuff with to_r and
subject_r, there are for loops which decrement to_len and subject_len
so it can walk the strings. By doing this, you bring the to_len and
subject_len variables to 0, thus nothing is ever efree()'d in the end,
and you've got a memory leak.
The leak is small and not noticable typically, but with mass mailing
scripts that loop using mail(), it could be huge.
Reproduce code:
---
See mail.c - lines 106 to 113, 129 to 136, and then 160 to 165.
Actual result:
--
I have not tested for an actual memory leak by calling mail() in a loop
- I was just going to write my own mail() function and was using the
code in mail.c to do it with, and came across this.
If this is a false report, I am sorry, but I do believe it's real.
--
Edit this bug report at http://bugs.php.net/?id=26847edit=1
#26846 [Fbk-Opn]: fpassthru() segfaults on certain files
ID: 26846
User updated by: djones at xtreme-eda dot com
Reported By: djones at xtreme-eda dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: FreeBSD 4.8-RELEASE
PHP Version: 4.3.4
New Comment:
Backtrace and autopsy:
Program received signal SIGSEGV, Segmentation fault.
0x282d0261 in memcpy () from /usr/lib/libc.so.4
(gdb) bt
#0 0x282d0261 in memcpy () from /usr/lib/libc.so.4
#1 0x41001 in ?? ()
#2 0x284705d0 in php_apache_sapi_ub_write (str=0x285f5000
ÐÏ\021ࡱ\032á,
str_length=266240)
at /usr/ports/lang/php4/work/php-4.3.4/sapi/
apache2handler/sapi_apache2.c:84
#3 0x28438404 in php_ub_body_write_no_header
(str=0x285f5000 ÐÏ\021ࡱ\032á,
str_length=266240) at /usr/ports/lang/php4/work/
php-4.3.4/main/output.c:689
#4 0x284384c3 in php_ub_body_write (str=0x285f5000 ÐÏ
\021ࡱ\032á,
str_length=266240) at /usr/ports/lang/php4/work/
php-4.3.4/main/output.c:719
#5 0x284372b6 in php_body_write (str=0x285f5000 ÐÏ\021à¡
±\032á,
str_length=266240) at /usr/ports/lang/php4/work/
php-4.3.4/main/output.c:121
#6 0x28432ecc in _php_stream_passthru (stream=0x818a624,
__php_stream_call_depth=0,
__zend_filename=0x2847c180 /usr/ports/lang/php4/work/
php-4.3.4/ext/standard/file.c, __zend_lineno=1867,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/ports/lang/php4/work/php-4.3.4/main/
streams.c:1088
#7 0x283d752f in zif_fpassthru (ht=1,
return_value=0x81a2ca4, this_ptr=0x0,
return_value_used=0)
at /usr/ports/lang/php4/work/php-4.3.4/ext/standard/
file.c:1867
#8 0x28469298 in execute (op_array=0x81a3d24)
at /usr/ports/lang/php4/work/php-4.3.4/Zend/
zend_execute.c:1618
#9 0x284550b2 in zend_execute_scripts (type=8,
retval=0x0, file_count=3)
at /usr/ports/lang/php4/work/php-4.3.4/Zend/zend.c:884
#10 0x28428ce9 in php_execute_script
(primary_file=0xbfbff648)
at /usr/ports/lang/php4/work/php-4.3.4/main/
main.c:1729
#11 0x2847119a in php_handler (r=0x8197050)
at /usr/ports/lang/php4/work/php-4.3.4/sapi/
apache2handler/sapi_apache2.c:537
#12 0x806379c in ap_run_handler ()
#13 0x8063cc9 in ap_invoke_handler ()
#14 0x8060fca in ap_process_request ()
#15 0x805cd66 in ap_process_http_connection ()
#16 0x806bc78 in ap_run_process_connection ()
#17 0x806bf0c in ap_process_connection ()
#18 0x8062443 in child_main ()
#19 0x8062500 in make_child ()
#20 0x80625f2 in startup_children ()
#21 0x8062927 in ap_mpm_run ()
#22 0x8067e36 in main ()
#23 0x805c99e in _start ()
(gdb) f 6
#6 0x28432ecc in _php_stream_passthru (stream=0x80d9924,
__php_stream_call_depth=0,
__zend_filename=0x2847c180 /usr/ports/lang/php4/work/
php-4.3.4/ext/standard/file.c, __zend_lineno=1867,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/ports/lang/php4/work/php-4.3.4/main/
streams.c:1088
1088PHPWRITE(p, len);
(gdb) p p
$1 = (void *) 0x285cd000
(gdb) p len
$2 = 266240
(gdb) p fd
$3 = 15
(gdb) p off
$4 = 4430856216
(gdb) p/x off
$5 = 0x108198018
(gdb) p *stream
$8 = {ops = 0x284a9a00, abstract = 0x8190a64, filterhead =
0x0,
filtertail = 0x0, wrapper = 0x284a9a9c, wrapperthis =
0x0, wrapperdata = 0x0,
fgetss_state = 0, is_persistent = 0, mode = rb, '\000'
repeats 13 times,
rsrc_id = 2, in_free = 0, fclose_stdiocast = 0,
stdiocast = 0x0,
__exposed = 1,
__orig_path = 0x8191b24 /usr/local/www/data/
RECORD_OF_DECISIONS_TEMPLATE_20030812.24.doc, context
= 0x0, flags = 0, position = 0, readbuf = 0x0,
readbuflen = 0, readpos = 0, writepos = 0, chunk_size =
8192, eof = 0}
(gdb) p *$8.ops
$9 = {write = 0x2843385c php_stdiop_write,
read = 0x284338f4 php_stdiop_read, close = 0x284339cc
php_stdiop_close,
flush = 0x28433b00 php_stdiop_flush, label =
0x2848ad45 STDIO,
seek = 0x28433b5c php_stdiop_seek, cast = 0x28433c1c
php_stdiop_cast,
stat = 0x28433d14 php_stdiop_stat,
set_option = 0x28433d78 php_stdiop_set_option}
(gdb) p {php_stdio_stream_data}0x8190a64
$11 = {file = 0x0, fd = 15, is_process_pipe = 0, is_pipe =
0,
temp_file_name = 0x0, last_op = 0 '\000'}
off looks, well, a little off. :-)
Previous Comments:
[2004-01-08 14:34:59] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, 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. Thank you for helping
us make PHP better.
[2004-01-08 13:16:54] djones at xtreme-eda dot com
Description:
PHP configuration:
http://www.inode.org/test.php
I am running an application
#26847 [Bgs-Opn]: memory leak with to_r and subject_r in mail() function
ID: 26847
User updated by: nutbar at innocent dot com
Reported By: nutbar at innocent dot com
-Status: Bogus
+Status: Open
Bug Type: Mail related
Operating System: any - source code issue
PHP Version: 4.3.4
New Comment:
Here, maybe this will help a bit... Here it assigns values to to_len
and subject_len (among others):
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, sss|ss,
to,
to_len,
subject,
subject_len,
message,
message_len,
headers,
headers_len,
extra_cmd,
extra_cmd_len
) == FAILURE)
{
return;
}
Then, they check to_len and do stuff if it's greater than 0:
if (to_len 0) {
to_r = estrndup(to, to_len);
for (; to_len; to_len--) {
if (!isspace((unsigned char) to_r[to_len - 1]))
{
break;
}
to_r[to_len - 1] = '\0';
}
...
Do you see the for loop in there... this one:
for (; to_len; to_len--) {...}
It is modifying to_len itself, which means that to_len, although was
NOT 0 to begin with (and thus, to_r was estrndup()'d and we have to
efree() it later), but IS 0 in the end once the for loop is finished.
Either the for loop must be changed to not modify to_len, or the
efree() statement must be changed to test to_r, not to_len.
Or am I just really out of my mind? I'm not anywhere near as good as
you programmers, but this seems to be sticking out for me quite a bit
(I'm not trying to come off rude! I just think I found something here
and it's not bogus).
Previous Comments:
[2004-01-08 16:07:29] nutbar at innocent dot com
I know they check to_len and subject_len - that's not really the
problem.
The problem is that the for loops above that decrement to_len and
subject_len - thus modifying them from their original values.
to_len and subject_len will always be 0, even if they weren't 0 to
begin with. Do you see what I'm referring to?
[2004-01-08 15:38:41] [EMAIL PROTECTED]
Impossible leak.
if (to_len 0) {
efree(to_r);
}
if (subject_len 0) {
efree(subject_r);
}
Is what the code in CVS does. If to_len or subject_len are
1 then no allocation happens in the 1st place.
[2004-01-08 15:34:23] nutbar at innocent dot com
I guess an alternate fix would also be when the efree()'s are called.
If you init all your char *'s to NULL, then you can simply do:
if (to_r != NULL) {
efree(to_r);
}
if (subject_r != NULL) {
efree(subject_r);
}
[2004-01-08 15:31:12] nutbar at innocent dot com
By the way, very simple fix:
Add this to the variable declarations:
int j = 0;
Then the lines of code as mentioned before, but fixed:
if (to_len 0) {
to_r = estrndup(to, to_len);
for (j = to_len; j 0; j--) {
if (!isspace((unsigned char) to_r[j - 1])) {
break;
}
to_r[j - 1] = '\0';
}
and:
if (subject_len 0) {
subject_r = estrndup(subject, subject_len);
for (j = subject_len; j 0; j--) {
if (!isspace((unsigned char) subject_r[j - 1]))
{
break;
}
subject_r[j - 1] = '\0';
}
I just initialized j in the for loop to be the value of to_len and
subject_len, then I use j everywhere rather than to_len or subject_len
so that they stay unmodified.
[2004-01-08 13:22:55] nutbar at innocent dot com
Description:
In the actual source code for the PHP mail() function
(ext/standard/mail.c), it sets some variables up to hold the To: and
Subject: headers up, and other stuff.
The problem is that if you look at the initial code that checks if the
to_len count is greater than 0, it duplicates the to string to
to_r and does some stuff to it.
It does the same sort of thing with subject_len, subject, and subject_r
in the exact same fashion.
After the new to_r and subject_r strings are used, it goes to free
them, but it does an if () test to see if
#26849 [NEW]: domXPath object returns array instead of nodeList
From: adam at trachtenberg dot com
Operating system: *
PHP version: 5CVS-2004-01-08 (dev)
PHP Bug Type: DOM XML related
Bug description: domXPath object returns array instead of nodeList
Description:
The domXPath object still returns nodes in an array
instead of as a nodeList object.
Reproduce code:
---
$dom = new domDocument::load($xml);
$xpath = new domXPath($dom);
$results = $xpath-query('/');
var_dump($results);
Expected result:
object(domnodelist)#14 (0) {
...
}
Actual result:
--
array(1) {
...
}
--
Edit bug report at http://bugs.php.net/?id=26849edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26849r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26849r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26849r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26849r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26849r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26849r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26849r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26849r=support
Expected behavior: http://bugs.php.net/fix.php?id=26849r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26849r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26849r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26849r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26849r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26849r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26849r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26849r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26849r=float
#26849 [Opn]: domXPath object returns array instead of nodeList
ID: 26849
User updated by: adam at trachtenberg dot com
Reported By: adam at trachtenberg dot com
Status: Open
Bug Type: DOM XML related
Operating System: *
PHP Version: 5CVS-2004-01-08 (dev)
New Comment:
That should be domXpath::query(), but you get the point.
:)
Previous Comments:
[2004-01-08 16:18:28] adam at trachtenberg dot com
Description:
The domXPath object still returns nodes in an array
instead of as a nodeList object.
Reproduce code:
---
$dom = new domDocument::load($xml);
$xpath = new domXPath($dom);
$results = $xpath-query('/');
var_dump($results);
Expected result:
object(domnodelist)#14 (0) {
...
}
Actual result:
--
array(1) {
...
}
--
Edit this bug report at http://bugs.php.net/?id=26849edit=1
#26847 [Opn]: memory leak with to_r and subject_r in mail() function
ID: 26847
User updated by: nutbar at innocent dot com
Reported By: nutbar at innocent dot com
Status: Open
Bug Type: Mail related
Operating System: any - source code issue
PHP Version: 4.3.4
New Comment:
Ok, maybe I am wrong?
I wrote a PHP script which *should* leak memory if this is indeed not
efree()'ing stuff, but it doesn't seem to.
I noticed it would only potentially (if I was right!) leak ram if say,
the subject was entirely space characters, so I made a script that
called mail() 1000 times roughly, and made a subject that was all
spaces that was 1k long - it should have set me off by 1mb, but instead
I see nothing of the sort.
I'm running the script from the command line (CGI, not CLI though!) if
it makes any difference (I don't believe it does).
Either way, I can't seem to leak the ram, so I guess I was wrong - but
can someone explain to me why it wouldn't? What am I missing here that
wouldn't allow it to leak ram?
Previous Comments:
[2004-01-08 16:17:25] nutbar at innocent dot com
Here, maybe this will help a bit... Here it assigns values to to_len
and subject_len (among others):
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, sss|ss,
to,
to_len,
subject,
subject_len,
message,
message_len,
headers,
headers_len,
extra_cmd,
extra_cmd_len
) == FAILURE)
{
return;
}
Then, they check to_len and do stuff if it's greater than 0:
if (to_len 0) {
to_r = estrndup(to, to_len);
for (; to_len; to_len--) {
if (!isspace((unsigned char) to_r[to_len - 1]))
{
break;
}
to_r[to_len - 1] = '\0';
}
...
Do you see the for loop in there... this one:
for (; to_len; to_len--) {...}
It is modifying to_len itself, which means that to_len, although was
NOT 0 to begin with (and thus, to_r was estrndup()'d and we have to
efree() it later), but IS 0 in the end once the for loop is finished.
Either the for loop must be changed to not modify to_len, or the
efree() statement must be changed to test to_r, not to_len.
Or am I just really out of my mind? I'm not anywhere near as good as
you programmers, but this seems to be sticking out for me quite a bit
(I'm not trying to come off rude! I just think I found something here
and it's not bogus).
[2004-01-08 16:07:29] nutbar at innocent dot com
I know they check to_len and subject_len - that's not really the
problem.
The problem is that the for loops above that decrement to_len and
subject_len - thus modifying them from their original values.
to_len and subject_len will always be 0, even if they weren't 0 to
begin with. Do you see what I'm referring to?
[2004-01-08 15:38:41] [EMAIL PROTECTED]
Impossible leak.
if (to_len 0) {
efree(to_r);
}
if (subject_len 0) {
efree(subject_r);
}
Is what the code in CVS does. If to_len or subject_len are
1 then no allocation happens in the 1st place.
[2004-01-08 15:34:23] nutbar at innocent dot com
I guess an alternate fix would also be when the efree()'s are called.
If you init all your char *'s to NULL, then you can simply do:
if (to_r != NULL) {
efree(to_r);
}
if (subject_r != NULL) {
efree(subject_r);
}
[2004-01-08 15:31:12] nutbar at innocent dot com
By the way, very simple fix:
Add this to the variable declarations:
int j = 0;
Then the lines of code as mentioned before, but fixed:
if (to_len 0) {
to_r = estrndup(to, to_len);
for (j = to_len; j 0; j--) {
if (!isspace((unsigned char) to_r[j - 1])) {
break;
}
to_r[j - 1] = '\0';
}
and:
if (subject_len 0) {
subject_r = estrndup(subject, subject_len);
for (j = subject_len; j 0; j--) {
if (!isspace((unsigned char) subject_r[j - 1]))
{
break;
}
subject_r[j - 1] = '\0';
}
I just initialized
#26847 [Opn-Csd]: memory leak with to_r and subject_r in mail() function
ID: 26847
Updated by: [EMAIL PROTECTED]
Reported By: nutbar at innocent dot com
-Status: Open
+Status: Closed
Bug Type: Mail related
Operating System: any - source code issue
PHP Version: 4.3.4
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
The bug was real, you were right. The reason you did not
see the leak is because Zend's memory manager automatically
handles such leaks. If you were to compile a debug build of
PHP you'd see some leak messages printed.
Previous Comments:
[2004-01-08 17:14:34] nutbar at innocent dot com
Ok, maybe I am wrong?
I wrote a PHP script which *should* leak memory if this is indeed not
efree()'ing stuff, but it doesn't seem to.
I noticed it would only potentially (if I was right!) leak ram if say,
the subject was entirely space characters, so I made a script that
called mail() 1000 times roughly, and made a subject that was all
spaces that was 1k long - it should have set me off by 1mb, but instead
I see nothing of the sort.
I'm running the script from the command line (CGI, not CLI though!) if
it makes any difference (I don't believe it does).
Either way, I can't seem to leak the ram, so I guess I was wrong - but
can someone explain to me why it wouldn't? What am I missing here that
wouldn't allow it to leak ram?
[2004-01-08 16:17:25] nutbar at innocent dot com
Here, maybe this will help a bit... Here it assigns values to to_len
and subject_len (among others):
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, sss|ss,
to,
to_len,
subject,
subject_len,
message,
message_len,
headers,
headers_len,
extra_cmd,
extra_cmd_len
) == FAILURE)
{
return;
}
Then, they check to_len and do stuff if it's greater than 0:
if (to_len 0) {
to_r = estrndup(to, to_len);
for (; to_len; to_len--) {
if (!isspace((unsigned char) to_r[to_len - 1]))
{
break;
}
to_r[to_len - 1] = '\0';
}
...
Do you see the for loop in there... this one:
for (; to_len; to_len--) {...}
It is modifying to_len itself, which means that to_len, although was
NOT 0 to begin with (and thus, to_r was estrndup()'d and we have to
efree() it later), but IS 0 in the end once the for loop is finished.
Either the for loop must be changed to not modify to_len, or the
efree() statement must be changed to test to_r, not to_len.
Or am I just really out of my mind? I'm not anywhere near as good as
you programmers, but this seems to be sticking out for me quite a bit
(I'm not trying to come off rude! I just think I found something here
and it's not bogus).
[2004-01-08 16:07:29] nutbar at innocent dot com
I know they check to_len and subject_len - that's not really the
problem.
The problem is that the for loops above that decrement to_len and
subject_len - thus modifying them from their original values.
to_len and subject_len will always be 0, even if they weren't 0 to
begin with. Do you see what I'm referring to?
[2004-01-08 15:38:41] [EMAIL PROTECTED]
Impossible leak.
if (to_len 0) {
efree(to_r);
}
if (subject_len 0) {
efree(subject_r);
}
Is what the code in CVS does. If to_len or subject_len are
1 then no allocation happens in the 1st place.
[2004-01-08 15:34:23] nutbar at innocent dot com
I guess an alternate fix would also be when the efree()'s are called.
If you init all your char *'s to NULL, then you can simply do:
if (to_r != NULL) {
efree(to_r);
}
if (subject_r != NULL) {
efree(subject_r);
}
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/26847
--
Edit this bug report at http://bugs.php.net/?id=26847edit=1
#26838 [Opn-Bgs]: signals make STDIN become EOF
ID: 26838
Updated by: [EMAIL PROTECTED]
Reported By: xuefer at 21cn dot com
-Status: Open
+Status: Bogus
Bug Type: Filesystem function related
Operating System: linux
PHP Version: 4.3.4
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
signals can and will interrupt readings from files
sockets.
Previous Comments:
[2004-01-08 05:50:30] xuefer at 21cn dot com
Description:
code
shell ./test.php
don't press CTRL+D to end input. but program exists in 3 seconds
because feof() return true
uncomment line 7 will works ok, exit only when i press CTRL+D
Reproduce code:
---
file ./test.php:
#!/usr/bin/php
?php
function sig_handler($signo) {
global $stdin;
print Caught SIGALM...\n;
pcntl_alarm(3);
// line7 // $stdin = fopen(php://stdin, 'r') or die('1');
}
print Installing signal handler...\n;
pcntl_signal(SIGALRM, sig_handler);
print Generating signal SIGTERM to self...\n;
declare(ticks=1);
pcntl_alarm(3);
$stdin = fopen(php://stdin, 'r') or die('1');
while (!feof($stdin)) {
echo fgets($stdin);
}
print Done\n
?
--
Edit this bug report at http://bugs.php.net/?id=26838edit=1
#26846 [Opn-Fbk]: fpassthru() segfaults on certain files
ID: 26846
Updated by: [EMAIL PROTECTED]
Reported By: djones at xtreme-eda dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: FreeBSD 4.8-RELEASE
PHP Version: 4.3.4
New Comment:
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
Cannot verify crash with latest CVS.
Previous Comments:
[2004-01-08 16:09:36] djones at xtreme-eda dot com
Backtrace and autopsy:
Program received signal SIGSEGV, Segmentation fault.
0x282d0261 in memcpy () from /usr/lib/libc.so.4
(gdb) bt
#0 0x282d0261 in memcpy () from /usr/lib/libc.so.4
#1 0x41001 in ?? ()
#2 0x284705d0 in php_apache_sapi_ub_write (str=0x285f5000
ÐÏ\021ࡱ\032á,
str_length=266240)
at /usr/ports/lang/php4/work/php-4.3.4/sapi/
apache2handler/sapi_apache2.c:84
#3 0x28438404 in php_ub_body_write_no_header
(str=0x285f5000 ÐÏ\021ࡱ\032á,
str_length=266240) at /usr/ports/lang/php4/work/
php-4.3.4/main/output.c:689
#4 0x284384c3 in php_ub_body_write (str=0x285f5000 ÐÏ
\021ࡱ\032á,
str_length=266240) at /usr/ports/lang/php4/work/
php-4.3.4/main/output.c:719
#5 0x284372b6 in php_body_write (str=0x285f5000 ÐÏ\021à¡
±\032á,
str_length=266240) at /usr/ports/lang/php4/work/
php-4.3.4/main/output.c:121
#6 0x28432ecc in _php_stream_passthru (stream=0x818a624,
__php_stream_call_depth=0,
__zend_filename=0x2847c180 /usr/ports/lang/php4/work/
php-4.3.4/ext/standard/file.c, __zend_lineno=1867,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/ports/lang/php4/work/php-4.3.4/main/
streams.c:1088
#7 0x283d752f in zif_fpassthru (ht=1,
return_value=0x81a2ca4, this_ptr=0x0,
return_value_used=0)
at /usr/ports/lang/php4/work/php-4.3.4/ext/standard/
file.c:1867
#8 0x28469298 in execute (op_array=0x81a3d24)
at /usr/ports/lang/php4/work/php-4.3.4/Zend/
zend_execute.c:1618
#9 0x284550b2 in zend_execute_scripts (type=8,
retval=0x0, file_count=3)
at /usr/ports/lang/php4/work/php-4.3.4/Zend/zend.c:884
#10 0x28428ce9 in php_execute_script
(primary_file=0xbfbff648)
at /usr/ports/lang/php4/work/php-4.3.4/main/
main.c:1729
#11 0x2847119a in php_handler (r=0x8197050)
at /usr/ports/lang/php4/work/php-4.3.4/sapi/
apache2handler/sapi_apache2.c:537
#12 0x806379c in ap_run_handler ()
#13 0x8063cc9 in ap_invoke_handler ()
#14 0x8060fca in ap_process_request ()
#15 0x805cd66 in ap_process_http_connection ()
#16 0x806bc78 in ap_run_process_connection ()
#17 0x806bf0c in ap_process_connection ()
#18 0x8062443 in child_main ()
#19 0x8062500 in make_child ()
#20 0x80625f2 in startup_children ()
#21 0x8062927 in ap_mpm_run ()
#22 0x8067e36 in main ()
#23 0x805c99e in _start ()
(gdb) f 6
#6 0x28432ecc in _php_stream_passthru (stream=0x80d9924,
__php_stream_call_depth=0,
__zend_filename=0x2847c180 /usr/ports/lang/php4/work/
php-4.3.4/ext/standard/file.c, __zend_lineno=1867,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/ports/lang/php4/work/php-4.3.4/main/
streams.c:1088
1088PHPWRITE(p, len);
(gdb) p p
$1 = (void *) 0x285cd000
(gdb) p len
$2 = 266240
(gdb) p fd
$3 = 15
(gdb) p off
$4 = 4430856216
(gdb) p/x off
$5 = 0x108198018
(gdb) p *stream
$8 = {ops = 0x284a9a00, abstract = 0x8190a64, filterhead =
0x0,
filtertail = 0x0, wrapper = 0x284a9a9c, wrapperthis =
0x0, wrapperdata = 0x0,
fgetss_state = 0, is_persistent = 0, mode = rb, '\000'
repeats 13 times,
rsrc_id = 2, in_free = 0, fclose_stdiocast = 0,
stdiocast = 0x0,
__exposed = 1,
__orig_path = 0x8191b24 /usr/local/www/data/
RECORD_OF_DECISIONS_TEMPLATE_20030812.24.doc, context
= 0x0, flags = 0, position = 0, readbuf = 0x0,
readbuflen = 0, readpos = 0, writepos = 0, chunk_size =
8192, eof = 0}
(gdb) p *$8.ops
$9 = {write = 0x2843385c php_stdiop_write,
read = 0x284338f4 php_stdiop_read, close = 0x284339cc
php_stdiop_close,
flush = 0x28433b00 php_stdiop_flush, label =
0x2848ad45 STDIO,
seek = 0x28433b5c php_stdiop_seek, cast = 0x28433c1c
php_stdiop_cast,
stat = 0x28433d14 php_stdiop_stat,
set_option = 0x28433d78 php_stdiop_set_option}
(gdb) p {php_stdio_stream_data}0x8190a64
$11 = {file = 0x0, fd = 15, is_process_pipe = 0, is_pipe =
0,
temp_file_name = 0x0, last_op = 0 '\000'}
off looks, well, a little off. :-)
[2004-01-08 14:34:59] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, 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
#26839 [Ver-Csd]: unexpected results from simple array routine
ID: 26839
Updated by: [EMAIL PROTECTED]
Reported By: dweller at devonweller dot com
-Status: Verified
+Status: Closed
Bug Type: Arrays related
Operating System: Linux Intel (Redhat)
PHP Version: 4CVS-2004-01-08 (dev)
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
This is fixed in PHP 5.0. This will not be fixed in PHP 4
as that would require an API change. The bug is the result
of a refcount being defined as a short.
Previous Comments:
[2004-01-08 14:29:09] [EMAIL PROTECTED]
Without the print_r() call no crash but this:
---
/usr/src/web/php/php4/Zend/zend_execute.h(44) : Block 0x0864E478
status:
Beginning: Overrun (magic=0x40847B54, expected=0x7312F8DC)
End: Unknown
---
[2004-01-08 14:28:14] [EMAIL PROTECTED]
Works fine with PHP 5, crashes for me with PHP 4 (latest CVS):
#0 0x407884ec in mempcpy () from /lib/i686/libc.so.6
#1 0x4077a850 in _IO_new_file_xsputn () from /lib/i686/libc.so.6
#2 0x4076ff9f in fwrite () from /lib/i686/libc.so.6
#3 0x082b0f75 in sapi_cli_single_write (str=0x0,
str_length=1515870810) at /usr/src/web/php/php4/sapi/cli/php_cli.c:190
#4 0x082afb2e in sapi_cli_ub_write (str=0x0, str_length=1515870810) at
/usr/src/web/php/php4/sapi/cli/php_cli.c:203
#5 0x082699fd in php_ub_body_write_no_header (str=0x0,
str_length=1515870810)
at /usr/src/web/php/php4/main/output.c:689
#6 0x0826863a in php_body_write (str=0x0, str_length=1515870810) at
/usr/src/web/php/php4/main/output.c:121
#7 0x08254dc0 in php_body_write_wrapper (str=0x0,
str_length=1515870810) at /usr/src/web/php/php4/main/main.c:1022
#8 0x0828c2d8 in zend_print_zval_ex (write_func=0x8254d9f
php_body_write_wrapper, expr=0xbfffd330, indent=0)
at /usr/src/web/php/php4/Zend/zend.c:211
#9 0x0828c256 in zend_print_zval (expr=0x864e2cc, indent=0) at
/usr/src/web/php/php4/Zend/zend.c:192
#10 0x0828bd0f in zend_print_variable (var=0x864e2cc) at
/usr/src/web/php/php4/Zend/zend_variables.c:147
#11 0x0828c45a in zend_print_zval_r_ex (write_func=0x8254d9f
php_body_write_wrapper, expr=0x864e2cc, indent=8)
at /usr/src/web/php/php4/Zend/zend.c:253
#12 0x0828c335 in zend_print_zval_r (expr=0x864e2cc, indent=8) at
/usr/src/web/php/php4/Zend/zend.c:221
#13 0x0828bf6f in print_hash (ht=0x865337c, indent=4) at
/usr/src/web/php/php4/Zend/zend.c:130
#14 0x0828c3c8 in zend_print_zval_r_ex (write_func=0x8254d9f
php_body_write_wrapper, expr=0x86534e4, indent=0)
at /usr/src/web/php/php4/Zend/zend.c:235
#15 0x0828c335 in zend_print_zval_r (expr=0x86534e4, indent=0) at
/usr/src/web/php/php4/Zend/zend.c:221
#16 0x081e082d in zif_print_r (ht=1, return_value=0x962c23c,
this_ptr=0x0, return_value_used=0)
at /usr/src/web/php/php4/ext/standard/basic_functions.c:2488
#17 0x0829ed0e in execute (op_array=0x864e9f4) at
/usr/src/web/php/php4/Zend/zend_execute.c:1616
#18 0x0828d76a in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/web/php/php4/Zend/zend.c:884
#19 0x08256573 in php_execute_script (primary_file=0xbbc0) at
/usr/src/web/php/php4/main/main.c:1727
#20 0x082b0da3 in main (argc=2, argv=0xbc54) at
/usr/src/web/php/php4/sapi/cli/php_cli.c:820
[2004-01-08 10:04:42] [EMAIL PROTECTED]
$i 32768 results in
array(2) {
[var1]=
UNKNOWN:0
[var2]=
UNKNOWN:0
}
$i 32767 results in
array(2) {
[var1]=
int(1)
[var2]=
int(1)
}
[2004-01-08 07:01:49] dweller at devonweller dot com
Description:
The attached simple array routine produces unexpected
results when the loop count is greater than approx.
33000. Perhaps this is some kind of reference counting
bug.
Reproduce code:
---
// causes unexpected *RECURSION* references
$var1 = 1;
$array = array();
for($i=0;$i33000;++$i) {
$var2 = $var1;
$array[] = array(
'var1' = $var1,
'var2' = $var2,
);
}
print_r($array[0]);
Expected result:
Array
(
[var1] = 1
[var2] = 1
)
Actual result:
--
Array
(
[var1] = Array
(
[var1] = Array
*RECURSION*
[var2] = Array
*RECURSION*
)
[var2] = Array
(
[var1] = Array
*RECURSION*
[var2] = Array
*RECURSION*
)
)
--
Edit this bug report at http://bugs.php.net/?id=26839edit=1
#26797 [Opn]: 64 bit pointer again
ID: 26797
Updated by: [EMAIL PROTECTED]
Reported By: yu at fstrf dot org
Status: Open
Bug Type: Compile Warning
Operating System: solaris 8/sparcv9
PHP Version: 4.3.4
New Comment:
SAPI.c warning has been fixed, thanks.
Previous Comments:
[2004-01-05 13:13:06] yu at fstrf dot org
Description:
I met more compiling warnings during the PHP compilation under solaris
8 /sparcv9 64-bit environment besides bug#26769.
1. ingres_ii
warning messages:
=
php-4.3.4/ext/ingres_ii/ii.c: In function `php_ii_do_connect':
php-4.3.4/ext/ingres_ii/ii.c:602: warning: cast from pointer to integer
of different size
php-4.3.4/ext/ingres_ii/ii.c:604: warning: cast from pointer to integer
of different size
php-4.3.4/ext/ingres_ii/ii.c:605: warning: cast from pointer to integer
of different size
php-4.3.4/ext/ingres_ii/ii.c:607: warning: cast from pointer to integer
of different size
code:
=
line# 601: link = (II_LINK *) index_ptr-ptr;
line# 602: ptr = zend_list_find((int) link, type);/* check if
the link is still there */
line# 603: if (ptr (type == le_ii_link || type == le_ii_plink)) {
line# 604: zend_list_addref((int) link);
line# 605: Z_LVAL_P(return_value) = (int) link;
line# 606:
line# 607: php_ii_set_default_link((int) link TSRMLS_CC);
line# 608:
line# 609: Z_TYPE_P(return_value) = IS_RESOURCE;
line# 610:efree(hashed_details);
line# 611:return;
line# 612: } else {
line# 613: zend_hash_del(EG(regular_list), hashed_details,
hashed_details_length + 1);
line# 614: }
2. SAPI
warning messages:
=
php-4.3.4/main/SAPI.c: In function `sapi_header_op':
php-4.3.4/main/SAPI.c:510: warning: cast from pointer to integer of
different size
code:
=
line# 509: case SAPI_HEADER_SET_STATUS:
line# 510: sapi_update_response_code((int) arg TSRMLS_CC);
line# 511: return SUCCESS;
In the 64-bit environment, pointers are defined in 64-bit. Would these
assignments of 64-bit pointers to a 32-bit integer cause any memory
problems?
Thanks in advance for looking into these.
Maggie
--
Edit this bug report at http://bugs.php.net/?id=26797edit=1
#26835 [Fbk-Csd]: wrong data type returned by mssql_fetch_array
ID: 26835 User updated by: skissane at ics dot mq dot edu dot au Reported By: skissane at ics dot mq dot edu dot au -Status: Feedback +Status: Closed Bug Type: MSSQL related Operating System: Solaris 2.6 PHP Version: 4.3.4 New Comment: Upon closer investigation, the problem was not with Solaris at all, it was that the Solaris box was using the mssql_* functions with PHP configured with --with-sybase=path to freetds, and the Linux box was using the mssql_* functions with --with-mssql=path to freetds. Recompiling PHP on the Solaris box using --with-mssql solved the problem. This probably relates to the bugs with the sybase extension which have been reported in other bug reports. Sorry about wasting your time. (I would mark this bug as Bogus, not Closed, but it won't let me do that.) Previous Comments: [2004-01-08 01:07:35] [EMAIL PROTECTED] This seams to be a problem on Solaris or FreeTDS. I've tested the code on Linux and Win32 and can't reproduce the problem. The code is designed to return NULL if the db-api returns zero length data. For some reson NULL bust be translated into a non zero length value on Solaris. [2004-01-07 22:17:35] skissane at ics dot mq dot edu dot au Description: The following script returns an empty string on Solaris, when it should return a NULL (which it does, correctly, on Linux.) This is using FreeTDS 0.61.2 (same problem occurs with FreeTDS 0.52). This is talking to a SQL Server 2000 using TDS version 7.0 (switching to 8.0 made no difference). I've checked, and: mssql.compatability_mode = Off in php.ini. Reproduce code: --- ? $id = mssql_connect(servername,username,password); $q = mssql_query(SELECT NULL,$id); $f = mssql_fetch_array($q); echo gettype($f[0]); Expected result: NULL Actual result: -- string -- Edit this bug report at http://bugs.php.net/?id=26835edit=1
#25803 [Opn-Csd]: xml_get_current_byte_index() always returns 0 on PHP 5.x
ID: 25803
Updated by: [EMAIL PROTECTED]
Reported By: j dot spit at uptime dot nl
-Status: Open
+Status: Closed
Bug Type: XML related
Operating System: *
PHP Version: 5CVS-2003-10-10
Assigned To: moriyoshi
New Comment:
current behaviour is the correct one as Moriyoshi said in his closing
comment..
Previous Comments:
[2004-01-08 11:25:00] j dot spit at uptime dot nl
Hello,
I am trying to find out what the current behaviour of
xml_get_current_byte_index() is in PHP5 version beta3 and above. Is
this documented somewhere ? I am developing software that is highly
dependant on this function.
Thanks !
[2003-11-26 16:07:41] j dot spit at uptime dot nl
Hi,
I noticed that in the latest CVS version it does not return zero
anymore, which is good, but on the other hand it does return different
values compared to php5.0.0b1. Can you enlighten me as to what value it
currently returns ?
Thanks.
[2003-11-24 01:10:02] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Behaviour of xml_get_current_byte_index() is subject to
change in php 5.0. It would probably return the end
position of the portion that has just been parsed, by
contrast to the old behaviour in 4.x, where it returns
the start position of the portion being parsed.
[2003-10-09 09:11:55] j dot spit at uptime dot nl
Description:
xml_get_current_byte_index always returns 0 on windows xp, it works
fine on Linux systems. Using PHP5 beta 1 on both platforms.
Reproduce code:
---
?php
function startElement($parser,$name,$attribs) {
echo Start : .xml_get_current_byte_index( $parser ).br;
}
function endElement($parser,$name) {
echo End : .xml_get_current_byte_index( $parser ).br;
}
$parser = xml_parser_create();
xml_set_element_handler($parser,'startElement','endElement');
xml_parser_set_option($parser,XML_OPTION_CASE_FOLDING,0);
xml_parse($parser,
a b=\x\testcblaat/c/a);
xml_parser_free($parser);
?
Expected result:
Start : 0
Start : 13
End : 21
End : 25
This is the output on a Linux system.
Actual result:
--
Start : 0
Start : 0
End : 0
End : 0
This is the output on a Windows XP system.
--
Edit this bug report at http://bugs.php.net/?id=25803edit=1
#26791 [Opn-Bgs]: mssql.textlimit and mssql.textsize can't be set via ini_set()
ID: 26791
Updated by: [EMAIL PROTECTED]
Reported By: danielc at analysisandsolutions dot com
-Status: Open
+Status: Bogus
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Of course the ini_set() has to be called before anything else is what
might be using the setting. (this is the case for ANY setting, not just
these mssql.* settings, see e.g. session stuff for examples)
Previous Comments:
[2004-01-08 13:51:48] danielc at analysisandsolutions dot com
Know what? The problem was where the ini_set() calls are made. They
must be done BEFORE the connection is established. Once it's made, it
can't be changed.
Oddly, it doesn't matter when one calls ini_set() for
mssql.datetimeconvert.
So, I'm not sure this bug report should be closed, called bogus or not.
It might be nice to have these work regardless of where they are
called. If no change is made, the behavior needs to be documented.
Couple things to keep in mind about my config:
Using CGI
Loading mssql via php.ini extensions
Versions 4.3.4 and php5-win32-200401081130 snapshot
[2004-01-08 00:12:28] [EMAIL PROTECTED]
This seams to be related to how the extension is loaded.
ini_set() works fine in php4 whn the extension is loaded from php.ini,
but not when dl() is used.
The dl() will also cause the output from phpinfo() to be incomplete!
[2004-01-06 18:56:04] [EMAIL PROTECTED]
Frank, nothing has changed in that function. Are you sure this really
works with PHP 5..?
[2004-01-05 02:44:12] [EMAIL PROTECTED]
This works in PHP5 but not in PHP4.3.x (tested on the cvs version). Did
something happen to the ini_set() funtion ?
[2004-01-05 01:34:58] danielc at analysisandsolutions dot com
Description:
The mssql.textlimit and mssql.textsize configuration options
can't be set via ini_set(). Changing them in php.ini works.
This is also the case in a recent PHP 5 snapshot
(500rc1-dev--php5-win32-200401022330).
This is the same issue as bug 20797 which was closed due to no
feedback.
SCRIPT CAN CHANGE LIMIT
===
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
SET TEXTSIZE 20
SCRIPT CAN'T CHANGE LIMIT
=
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
ini_set('mssql.textlimit', 2147483647);
ini_set('mssql.textsize', 2147483647);
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
ini_set('mssql.textlimit', 20);
ini_set('mssql.textsize', 20);
php.ini
; mssql.textlimit = 2147483647
; mssql.textsize = 2147483647
script
SET TEXTSIZE 2147483647
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
SET TEXTSIZE 2147483647
--
Edit this bug report at http://bugs.php.net/?id=26791edit=1
#26791 [Bgs]: mssql.textlimit and mssql.textsize can't be set via ini_set()
ID: 26791 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Bogus Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.3.4 New Comment: Sniper: Don't be so dismissive. Most ini_set()'s work just fine regardless of when they're called. Sessions aren't a good example because all of the session stuff has to be processed before any output. If the team doesn't want to spend time fixing this, please turn this into a documentation bug for ref.mssql.php, where a note should be made about the need to set these before connecting to a db. Previous Comments: [2004-01-08 23:21:09] [EMAIL PROTECTED] Of course the ini_set() has to be called before anything else is what might be using the setting. (this is the case for ANY setting, not just these mssql.* settings, see e.g. session stuff for examples) [2004-01-08 13:51:48] danielc at analysisandsolutions dot com Know what? The problem was where the ini_set() calls are made. They must be done BEFORE the connection is established. Once it's made, it can't be changed. Oddly, it doesn't matter when one calls ini_set() for mssql.datetimeconvert. So, I'm not sure this bug report should be closed, called bogus or not. It might be nice to have these work regardless of where they are called. If no change is made, the behavior needs to be documented. Couple things to keep in mind about my config: Using CGI Loading mssql via php.ini extensions Versions 4.3.4 and php5-win32-200401081130 snapshot [2004-01-08 00:12:28] [EMAIL PROTECTED] This seams to be related to how the extension is loaded. ini_set() works fine in php4 whn the extension is loaded from php.ini, but not when dl() is used. The dl() will also cause the output from phpinfo() to be incomplete! [2004-01-06 18:56:04] [EMAIL PROTECTED] Frank, nothing has changed in that function. Are you sure this really works with PHP 5..? [2004-01-05 02:44:12] [EMAIL PROTECTED] This works in PHP5 but not in PHP4.3.x (tested on the cvs version). Did something happen to the ini_set() funtion ? 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/26791 -- Edit this bug report at http://bugs.php.net/?id=26791edit=1
