Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?
On Thu, May 17, 2001 at 11:10:57PM -0700, Rasmus Lerdorf wrote: Perhaps automatic detection could be option? if (filesize X) blockread else mmap? It seems like the most intuitive way to implement it... Sounds a bit magical. Why not just a block_readfile() function? Mainly the bloat factor, we already have a large core, imho, functions shouldn't be added unless there are no workarounds. Also, it requires a little too much thought, into what sizes are good for mmap() and what sizes are good for block read's (it also requires knowledge of mmap(), because many people might automatically assume that block_read would always be faster). I'm pretty sure if we polled php-general and php-qa (the more knowledgable user bases), most people wouldn't really understand what mmap does, or what it is for or when it is beneficial to use it. As for magical, well a bit, but good magic and internal magic (not syntactical magic). I'd assume that most systems have a certain point where mmap is no longer more beneficial than reading a file by chunks. If we can find a reasonable number (or have a user specify that in a configuration option if really necessary), it saves the user the trouble of thinking about something which is pretty low-level and it reduces bloat. I don't really see a downside to this magic. But, the issue here isn't one of which is faster. The issue here is one of memory usage. If you have a 600M iso image that you decide to readfile() for a download page of some sort, then you are going to end up with a 600M httpd process. And soon you will have lots of those as more people hit the page. mmap will not increase the size of your process as it doesn't call sbrk(). So to be truely magical here, PHP would have to check the amount of spare RAM on the system, divide that by MaxClients and set that as the largest filesize to mmap() because anything larger could result in the box going into swap. I obviously don't think such a check is feasible. The only real question here is whether to add a user configurable max-mmap setting or to add a second function that never mmaps. question is: do we really need this mmap stuff at all? with readfile we should easyly be able to saturate a pipe of any size using just read and write. tc -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?
Rasmus Lerdorf wrote: Perhaps automatic detection could be option? if (filesize X) blockread else mmap? It seems like the most intuitive way to implement it... Sounds a bit magical. Why not just a block_readfile() function? Mainly the bloat factor, we already have a large core, imho, functions shouldn't be added unless there are no workarounds. Also, it requires a little too much thought, into what sizes are good for mmap() and what sizes are good for block read's (it also requires knowledge of mmap(), because many people might automatically assume that block_read would always be faster). I'm pretty sure if we polled php-general and php-qa (the more knowledgable user bases), most people wouldn't really understand what mmap does, or what it is for or when it is beneficial to use it. As for magical, well a bit, but good magic and internal magic (not syntactical magic). I'd assume that most systems have a certain point where mmap is no longer more beneficial than reading a file by chunks. If we can find a reasonable number (or have a user specify that in a configuration option if really necessary), it saves the user the trouble of thinking about something which is pretty low-level and it reduces bloat. I don't really see a downside to this magic. But, the issue here isn't one of which is faster. The issue here is one of memory usage. If you have a 600M iso image that you decide to readfile() for a download page of some sort, then you are going to end up with a 600M httpd process. And soon you will have lots of those as more people hit the page. So to be truely magical here, PHP would have to check the amount of spare RAM on the system, divide that by MaxClients and set that as the largest filesize to mmap() because anything larger could result in the box going into swap. point taken :) I obviously don't think such a check is feasible. The only real question here is whether to add a user configurable max-mmap setting or to add a second function that never mmaps. +1 for the configuration option. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?
At 10:40 PM 5/17/2001 -0700, Rasmus Lerdorf wrote: True. But I guess my main issue is still that the behaviour changes radically based on a hidden configure check (ie. whether mmap is there or not) and that ensuring a block-by-block read in user space is inefficient for huge files. good point... hrrmmm it seems like this is an option that should be available (somehow), yet I don't really like adding another option to the function, as it requires too much smarts on the behalf of the user (at what point does mmap() slow things down instead of speed them up, what is mmap(), etc.) Well, we do check and only do the mmap() for files larger than the block size. Perhaps automatic detection could be option? if (filesize X) blockread else mmap? It seems like the most intuitive way to implement it... Sounds a bit magical. Why not just a block_readfile() function? Why is it magical? It's an internal optimization and the developer will never know. I wouldn't add another file but make it a bit smarted only to mmap() small files and use fread() (the C version) for the rest). Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?
At 11:10 PM 5/17/2001 -0700, Rasmus Lerdorf wrote: Perhaps automatic detection could be option? if (filesize X) blockread else mmap? It seems like the most intuitive way to implement it... Sounds a bit magical. Why not just a block_readfile() function? Mainly the bloat factor, we already have a large core, imho, functions shouldn't be added unless there are no workarounds. Also, it requires a little too much thought, into what sizes are good for mmap() and what sizes are good for block read's (it also requires knowledge of mmap(), because many people might automatically assume that block_read would always be faster). I'm pretty sure if we polled php-general and php-qa (the more knowledgable user bases), most people wouldn't really understand what mmap does, or what it is for or when it is beneficial to use it. As for magical, well a bit, but good magic and internal magic (not syntactical magic). I'd assume that most systems have a certain point where mmap is no longer more beneficial than reading a file by chunks. If we can find a reasonable number (or have a user specify that in a configuration option if really necessary), it saves the user the trouble of thinking about something which is pretty low-level and it reduces bloat. I don't really see a downside to this magic. But, the issue here isn't one of which is faster. The issue here is one of memory usage. If you have a 600M iso image that you decide to readfile() for a download page of some sort, then you are going to end up with a 600M httpd process. And soon you will have lots of those as more people hit the page. So to be truely magical here, PHP would have to check the amount of spare RAM on the system, divide that by MaxClients and set that as the largest filesize to mmap() because anything larger could result in the box going into swap. I obviously don't think such a check is feasible. The only real question here is whether to add a user configurable max-mmap setting or to add a second function that never mmaps. I think we are getting carried away here. Why start bloating with configuration options and possible new functions? It's not as if the developer needs great control over this. I'd either nuke mmap() completely and use regular file functions (it's usually not a big loss and I don't think it's a big deal) or take an arbitrary number which we think should be considered a large file (something like 256KB) and use mmap() only for smaller files. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] sockets extension
Stig Venaas wrote: On Thu, May 17, 2001 at 01:48:06AM -0400, Sterling Hughes wrote: Well, it probably could be done anyway (abstract it another step). However, I don't see it really being that beneficial. The socket functions provide *low level* access to the system socket features. There's no real point in abstracting that (I think it gets a bit to confusing if you do) any further. The only thing I would want, is that the type of the socket is stored in some internal datastructure. That is if the socket is PF_INET, PF_INET6 or PF_LOCAL. The old code and maybe yours, used getsockname() to check the type, but you can't really trust getsockname() to get the appropriate info unless the socket has been bound. I've checked this on a few systems some months ago. that shouldn't be a problem. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?
On Fri, 18 May 2001, Andi Gutmans wrote: of thinking about something which is pretty low-level and it reduces bloat. I don't really see a downside to this magic. But, the issue here isn't one of which is faster. The issue here is one of memory usage. If you have a 600M iso image that you decide to readfile() for a download page of some sort, then you are going to end up with a 600M httpd process. And soon you will have lots of those as more people hit the page. So to be truely magical here, PHP would have to check the amount of spare RAM on the system, divide that by MaxClients and set that as the largest filesize to mmap() because anything larger could result in the box going into swap. I obviously don't think such a check is feasible. The only real question here is whether to add a user configurable max-mmap setting or to add a second function that never mmaps. I think we are getting carried away here. Why start bloating with configuration options and possible new functions? It's not as if the developer needs great control over this. I'd either nuke mmap() completely and use regular file functions (it's usually not a big loss and I don't think it's a big deal) or take an arbitrary number which we think should be considered a large file (something like 256KB) and use mmap() only for smaller files. I'm for nuking the mmap() from readfile(). readfile() is supposed to be used also on remote files and IIRC mmap() is meant to be used only with regular files. Do ftell()/fstat() work for remote files? --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?
And then I find the magical 'if(!issock) {' line.. :)
But still I'd rather nuke mmap..HOW fast is it anyway
compared to reading/writing in chunks?
--Jani
On Fri, 18 May 2001, Jani Taskinen wrote:
On Fri, 18 May 2001, Andi Gutmans wrote:
of thinking about something which is pretty low-level and it reduces
bloat. I don't really see a downside to this magic.
But, the issue here isn't one of which is faster. The issue here is one
of memory usage. If you have a 600M iso image that you decide to
readfile() for a download page of some sort, then you are going to end up
with a 600M httpd process. And soon you will have lots of those as more
people hit the page.
So to be truely magical here, PHP would have to check the amount of spare
RAM on the system, divide that by MaxClients and set that as the largest
filesize to mmap() because anything larger could result in the box going
into swap.
I obviously don't think such a check is feasible. The only real question
here is whether to add a user configurable max-mmap setting or to add a
second function that never mmaps.
I think we are getting carried away here. Why start bloating with
configuration options and possible new functions? It's not as if the
developer needs great control over this.
I'd either nuke mmap() completely and use regular file functions (it's
usually not a big loss and I don't think it's a big deal) or take an
arbitrary number which we think should be considered a large file
(something like 256KB) and use mmap() only for smaller files.
I'm for nuking the mmap() from readfile().
readfile() is supposed to be used also on remote files and
IIRC mmap() is meant to be used only with regular files.
Do ftell()/fstat() work for remote files?
--Jani
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?
Jani Taskinen wrote: On Fri, 18 May 2001, Andi Gutmans wrote: of thinking about something which is pretty low-level and it reduces bloat. I don't really see a downside to this magic. But, the issue here isn't one of which is faster. The issue here is one of memory usage. If you have a 600M iso image that you decide to readfile() for a download page of some sort, then you are going to end up with a 600M httpd process. And soon you will have lots of those as more people hit the page. So to be truely magical here, PHP would have to check the amount of spare RAM on the system, divide that by MaxClients and set that as the largest filesize to mmap() because anything larger could result in the box going into swap. I obviously don't think such a check is feasible. The only real question here is whether to add a user configurable max-mmap setting or to add a second function that never mmaps. I think we are getting carried away here. Why start bloating with configuration options and possible new functions? It's not as if the developer needs great control over this. I'd either nuke mmap() completely and use regular file functions (it's usually not a big loss and I don't think it's a big deal) or take an arbitrary number which we think should be considered a large file (something like 256KB) and use mmap() only for smaller files. I'm for nuking the mmap() from readfile(). readfile() is supposed to be used also on remote files and IIRC mmap() is meant to be used only with regular files. Do ftell()/fstat() work for remote files? Huh? If its a remote url, or mmap() isn't found, then its not used, otherwise it is. There's no difference as far as compatibility is concerned, using mmap() when its available is simply an optimization. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?
On Thu, 17 May 2001, Sterling Hughes wrote: If its a remote url, or mmap() isn't found, then its not used, otherwise it is. There's no difference as far as compatibility is concerned, Yeah, I noticed that just after sending the email. :) using mmap() when its available is simply an optimization. How much does it really optimize? And what's the use of any optimization if the web server dies because of it? :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?
At 09:19 AM 5/18/2001 +0200, Jani Taskinen wrote:
And then I find the magical 'if(!issock) {' line.. :)
But still I'd rather nuke mmap..HOW fast is it anyway
compared to reading/writing in chunks?
I think it probably isn't really faster (at least not noticeably) because
we are anyway writing to network which I think is our bottleneck. Also it
is not necessarily faster on all systems (it is system independent).
I agree with you and think we should just nuke it from there. There is no
good reason I can think of which justifies it in that code.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?
On Fri, 18 May 2001, Andi Gutmans wrote:
At 09:19 AM 5/18/2001 +0200, Jani Taskinen wrote:
And then I find the magical 'if(!issock) {' line.. :)
But still I'd rather nuke mmap..HOW fast is it anyway
compared to reading/writing in chunks?
I think it probably isn't really faster (at least not noticeably) because
we are anyway writing to network which I think is our bottleneck. Also it
is not necessarily faster on all systems (it is system independent).
I agree with you and think we should just nuke it from there. There is no
good reason I can think of which justifies it in that code.
Agreed. Rather have a new function that uses mmap() ie. mmap_readfile()
or whatever the name would be for it.
I'd like to hear Sascha's reasoning for adding mmap() in the first place.
Maybe he had something special in his mind?
date: 1999/09/11 18:15:39; author: sas; state: Exp; lines: +57 -19
optimize fpassthru/readfile to use mmap instead of fread
which especially increases speed on large files.
--Jani
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?
At 09:29 AM 5/18/2001 +0200, Jani Taskinen wrote:
On Fri, 18 May 2001, Andi Gutmans wrote:
At 09:19 AM 5/18/2001 +0200, Jani Taskinen wrote:
And then I find the magical 'if(!issock) {' line.. :)
But still I'd rather nuke mmap..HOW fast is it anyway
compared to reading/writing in chunks?
I think it probably isn't really faster (at least not noticeably) because
we are anyway writing to network which I think is our bottleneck. Also it
is not necessarily faster on all systems (it is system independent).
I agree with you and think we should just nuke it from there. There is no
good reason I can think of which justifies it in that code.
Agreed. Rather have a new function that uses mmap() ie. mmap_readfile()
or whatever the name would be for it.
There is no need for a new function IMO.
I'd like to hear Sascha's reasoning for adding mmap() in the first place.
Maybe he had something special in his mind?
date: 1999/09/11 18:15:39; author: sas; state: Exp; lines: +57 -19
optimize fpassthru/readfile to use mmap instead of fread
which especially increases speed on large files.
OK but I really don't think it's such a big deal. Especially with the
slower network pipe it is hard for me to believe that it really makes a
performance difference on most systems.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] bug or feature?
Zeev/Andi,
Right now you can replace the object returned by new Foo by
assigning $this in the Foo constructor, like this:
class Foo extends PEAR
{
function Foo()
{
if (!init_foo_resource()) {
$this = $this-raiseError(could not initialize foo resource);
return;
}
}
}
This is a cool feature, and doing what the example above does would be
very nice, but PEAR coders still have the decency not to. The
alternative is to have dumb constructors that don't do anything that
may go wrong, and use a second method call for the rest. That's twice
the number of lines!
Anyway, I'd like to see $this assignment in constructor:
1. dismissed as a bug
2. documented as a feature, or
3. subject to discussion resulting in (1) or (2)
- Stig
--
Stig Sæther Bakken [EMAIL PROTECTED]
Fast Search Transfer ASA, Trondheim, Norway
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10890 Updated: Segmentation fault when using mcrypt function in Apache
ID: 10890 User Update by: [EMAIL PROTECTED] Old-Status: Closed Status: Open Bug Type: mcrypt related Operating system: FreeBSD 4.1.1 PHP Version: 4.0.5 Description: Segmentation fault when using mcrypt function in Apache I downloaded and compiled this one: php4-200105172345 But im still getting this in my Apache error log when i try to use Mcrypt: [Fri May 18 09:56:24 2001] [notice] child pid 50599 exit signal Segmentation fault (11) [Fri May 18 09:56:25 2001] [notice] child pid 50595 exit signal Segmentation fault (11) Previous Comments: --- [2001-05-17 17:43:40] [EMAIL PROTECTED] This should be fixed in CVS. Can you please try a snapshot in about two hours? (The snapshots have to be generated, and are available on snaps.php.net) If this does not fix the problem for you, please reopen this report. --- [2001-05-17 17:02:29] [EMAIL PROTECTED] Hello, I'm on this, probably found the bug already. I'll commit the fix as soon as I tested it and my connection works 100%. Derick --- [2001-05-17 16:48:40] [EMAIL PROTECTED] I tried today with libmcrypt-2.4.11 both with --disable-posix-threads and without. In both cases i get the segmentation fault in the apache log. --- [2001-05-15 17:48:17] [EMAIL PROTECTED] If i try to run this script: ?php $key = this is a very secret key; $input = Let us meet at 9 o'clock at the secret place.; $td = mcrypt_module_open (MCRYPT_TripleDES, , MCRYPT_MODE_ECB, ); $iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td), MCRYPT_RAND); mcrypt_generic_init ($td, $key, $iv); $encrypted_data = mcrypt_generic ($td, $input); mcrypt_generic_end ($td); echo $encrypted_data; ? I get this in my Apache log file: [Tue May 15 23:30:13 2001] [notice] child pid 22372 exit signal Segmentation fault (11) [Tue May 15 23:30:13 2001] [notice] child pid 22371 exit signal Segmentation fault (11) I did configure libmcrypt 2.4.9 with: ./configure --disable-posix-threads And PHP 4.0.5 with: ./configure --with-mysql=/usr/local/mysql --with-gd=/usr/local --with-t1lib --with-ttf --with-jpeg-dir --with-png-dir --with-tiff-dir --with-zlib-dir --with-xpm-dir --with-imap --with-gettext --with-zlib --with-pdflib --enable-exif --enable-ftp --enable-bcmath --with-mcrypt --with-config-file-path=/usr/local/etc --with-apxs=/usr/local/apache/bin/apxs --- Full Bug description available at: http://bugs.php.net/?id=10890 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10948: Apache can't load with php_interbase.dll
From: [EMAIL PROTECTED] Operating system: Win2K PHP version: 4.0.5 PHP Bug Type: InterBase related Bug description: Apache can't load with php_interbase.dll I have Apache 1.3.19 running as an NT service on Win2K sp1 with php loaded as a module. If I try to enable interbase support by uncommenting the line extension=php_interbase.dll then apache cannot start. if i try and start it through the Services panel, i get the following message: Could not start the Apache service on Local Computer. The service did not return an error. This could be an internal Windows error or an internal service error if i do it on the command line, i get: [Fri May 18 04:04:02 2001] [emerg] 2The system cannot find the file specified: OpenEvent on ap2024_restart event -- Edit Bug report at: http://bugs.php.net/?id=10948edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10928 Updated: Loading PHP as a DSO fails - garbled
ID: 10928 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Dynamic loading Operating system: PHP Version: 4.0.5 Assigned To: Comments: You're most likely using wrong apxs here. Try using the full path for it. ie. --with-apxs=/httpd/bin/apxs --Jani Previous Comments: --- [2001-05-17 11:31:44] [EMAIL PROTECTED] I've built PHP 4.0.5 as a DSO with config: ./configure --with-apxs --with-mysql=no I'm running Apache V1.3-14 with SSL patches and the config: ./configure --enable-module=info --enable-module=so --prefix=/httpd When I start apache and try to add PHP I get: Starting httpsd: Syntax error on line 225 of /httpd/conf/httpd.conf: API module structure `php4_module' in file /httpd/libexec/libphp4.so is garbled - perhaps this is not an Apache module DSO? /httpd/bin/httpsdctl start: httpsd could not be started I've read through the previous responses on this topic and I've tried 'make clean' and deleting the config.cache in PHP before the build - this doesn't make any difference. Dave. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10928edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Zdnet Article
At 08:07 18/5/2001, Rasmus Lerdorf wrote: Responding to this article only prolongs its life. Treat PC Magazine/ZDNET's reviews as you would a 3rd grader's book report. These are not technical publications; they are the Popular Mechanics of the PC world. When considering languages/environments to use when building an application, very few people will read ZDNET publications to help them decide. I agree. It is so poorly researched that I think people will see it for what it is. I think that the main problem is that people won't see it for what it is... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9688 Updated: FTP_PUT / FOPEN
ID: 9688 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: IIS related Operating system: PHP Version: 4.0.4 Assigned To: Comments: The problem here seems that PHP cant access the drive or file. Have you checked permissions? Is G:\ a mapped network drive? Is the path correct?? Please check these, then try latest CVS (snapshots for win32 are avalible here: http://www.zend.com/snapshots ) - James Previous Comments: --- [2001-03-11 17:49:57] [EMAIL PROTECTED] I'm working against a IIS web server with PHP 4.0.4 It seems that both ftp_up and fopen causes the same problem, not allowing you to upload files. On the attempt to open sourcefile/submited file I get following errors; with ftp_up: Warning: error opening G:\mysite\mysite\gfx\icon_editor_url.gif in ftp.php on line 19 with fopen: Warning: fopen(G:\mysite\mysite\gfx\icon_editor_list.gif,rb) - No such file or directory in uploadfile.php on line 7 hence under linux, I have tested the fopen with php4.0.b3 and it seems to work. Question me for samplecode if needed. Regards, IN. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9688edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Zdnet Article
I actually don't think that understating the importance of the article, or mocking its authors, is going to do us any good. Fact is that people do read it, and worse, very often they only look at the bottom line, without even looking for the reasoning. I'd happily reply to some of their invalid points, but I couldn't even find a place to do that in. Zeev At 08:56 18/5/2001, Michael Loftis wrote: They were actually considering Windows as a viable platform for a server at all. *shudder* John Donagher wrote: Responding to this article only prolongs its life. Treat PC Magazine/ZDNET's reviews as you would a 3rd grader's book report. These are not technical publications; they are the Popular Mechanics of the PC world. When considering languages/environments to use when building an application, very few people will read ZDNET publications to help them decide. John On Fri, 18 May 2001, Gavin Sherry wrote: There is a disappointing trend in 'mainstream' commentary on open source projects. This is an example of one. In the last year of so I have had a lot of experience with poor media coverage of projects I am either involved in or follow closely. One of the worst being an all out attack on PostgreSQL by an indian online magazine resently which seemed to be directed at an entirely different project. I think the short-comings of this article should be addressed in a civil manner. An open letter to ZDNet and the author, for example. This could be posted on the front page of php.net and would probably get coverage on places such as slashdot and perhaps ZDNet itself. I would recommend against personal and emotion emails to the author or to ZDNet as has happened in other cases. Such an open letter could be arranged on this list or by some of the top developers. I think it unfortunate that especially in the case of Open Source journalists are not doing any research -- I say especially because there is such a large amount of information and support for open source projects such as PHP. I would be happy to draft a response if everyone else would like to move in that direction. Gavin On Fri, 18 May 2001, Emmanuel FAIVRE wrote: http://www.zdnet.com/products/stories/reviews/0,4161,2711724,00.html no word to comment that ! just see a adbanner for ColdFusion on the same page ! Manu -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
At 11:21 18/5/2001, Jani Taskinen wrote: As long as these extensions are in there, I think changing any of their API's is a justification for 4.x release. This is simply not the way we decided to work in. Can it be changed? Sure. Should it be changed? In my humble opinion, no, it shouldn't. The thing I'm trying to state, not very successfully I guess, is that whether it's 4.0.7 or 4.666.3, we should be avoiding API changes as much as at all possible. Sure, sometimes there's just no alternative than to break downwards compatibility, but we should not get into the state of mind that breaking downwards compatibility is ok, as long as you increment some digit in the version number. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10946 Updated: mail() Failed: Server Error
ID: 10946 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: IIS related Operating system: PHP Version: 4.0.5 Assigned To: Comments: I dont get what the problem is here. Please give more information. - James Previous Comments: --- [2001-05-17 22:46:15] [EMAIL PROTECTED] i have installed php and iis in 2 servers. one is ok, when i run the mail(). but another is failed. so i changed the smtp to the right one in php.ini. it's ok! both server have some software enviroment, except one is installed msq, another not.does it the problem? i don't think so. why? --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10946edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10946 Updated: mail() Failed: Server Error
ID: 10946 Updated by: jmoore Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: IIS related Operating system: PHP Version: 4.0.5 Assigned To: Comments: I dont get what the problem is here. Please give more information. - James Previous Comments: --- [2001-05-18 04:35:10] [EMAIL PROTECTED] I dont get what the problem is here. Please give more information. - James --- [2001-05-17 22:46:15] [EMAIL PROTECTED] i have installed php and iis in 2 servers. one is ok, when i run the mail(). but another is failed. so i changed the smtp to the right one in php.ini. it's ok! both server have some software enviroment, except one is installed msq, another not.does it the problem? i don't think so. why? --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10946edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9810 Updated: Apache 1.3.17 19 crash at shutdown
ID: 9810 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Old-Bug Type: Reproducible Crash Bug Type: *General Issues Operating system: PHP Version: 4.0 Latest CVS (17/03/2001) Assigned To: Comments: This should be fixed in Apache 1.3.20. Please ugrade to this version when it is released. Reopen if the crash still occurs. - James Previous Comments: --- [2001-03-31 10:58:00] [EMAIL PROTECTED] yes. I'm running 1.3.20-dev and it's ok. --- [2001-03-31 10:56:30] [EMAIL PROTECTED] Hi cynic! Do you mean this annoying problem won't occur with the next release of Apache? Greaaat :) Thanks for your reply, Loïc --- [2001-03-31 10:40:23] [EMAIL PROTECTED] this one was actually an Apache bug, and is fixed now. --- [2001-03-17 12:01:44] [EMAIL PROTECTED] Hi! I'm under win 98SE, Apache 1.3.17 or 19, php4.0.5-RC1 from php4win.de as an Apache module (no problem with php as a CGI). Each time I shut down Apache, it crashes twices. I can't produce a backtrace (winwin fault) but here is the failure messages I can grab (french messages, sorry): APACHE a causé une défaillance de page dans le module OLEAUT32.DLL à 016f:65352c3c. Registres : EAX=00bd CS=016f EIP=65352c3c EFLGS=00010212 EBX=0008 SS=0177 ESP=0159f7a4 EBP=653c9048 ECX=653c7030 DS=0177 ESI=00a8 FS=67f7 EDX=0008 ES=0177 EDI=00a8 GS= Octets à CS : EIP : 8b 47 04 8b 0f 3b c2 89 4c 24 14 8b f1 8d 9f f8 État de la pile : 653c7048 00a8 653c9048 0008 65352c0c 00a8 00bd 0008 bff76ec4 0080 653c7030 65352aff 0008 APACHE a causé une défaillance de page dans le module KERNEL32.DLL à 016f:bff8ac13. Registres : EAX= CS=016f EIP=bff8ac13 EFLGS=0246 EBX=0001 SS=0177 ESP=0159fc2c EBP=0159fc70 ECX=7ffd3058 DS=0177 ESI=7ffd3038 FS=67f7 EDX=bffc9490 ES=0177 EDI=0001 GS= Octets à CS : EIP : a1 10 9d fc bf 50 e8 96 95 fe ff ff 76 04 e8 35 État de la pile : 7ffd3510 7ff2a1ed 7ffd3038 7ff49d83 818a1b78 7ff49d45 0001 7ff42092 7ff4203d 7ff2 0001 Moreover FileMon produces these lines (don't know if it helps...): snip Filemon ReadC:WINDOWSSYSTEMOLEAUT32.DLL SUCCESS Offset: 40960 Length: 1024 Filemon Ioctl C: INVALIDFUNC Subfunction: 0Dh Filemon Ioctl D: INVALIDFUNC Subfunction: 0Dh Filemon Ioctl E: INVALIDFUNC Subfunction: 0Dh Filemon Ioctl E: SUCCESS Subfunction: 0Dh Filemon Ioctl F: INVALIDFUNC Subfunction: 0Dh Filemon Ioctl F: GENFAILURE Subfunction: 0Dh Filemon Ioctl F: GENFAILURE Subfunction: 0Dh Filemon Ioctl G: INVALIDFUNC Subfunction: 0Dh Filemon Ioctl G: GENFAILURE Subfunction: 0Dh Filemon Ioctl G: GENFAILURE Subfunction: 0Dh Filemon ReadC:EASYPHPAPACHEPHP.INI SUCCESS Offset: 303104 Length: 4096 snip Thanks in advance, Loïc PS: These crashes already occurs with the previous 4.0.5-dev release. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9810edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10434 Updated: Can not read memory
ID: 10434
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Old-Bug Type: Reproducible Crash
Bug Type: *General Issues
Operating system:
PHP Version: 4.0.4pl1
Assigned To:
Comments:
Are you using ISAPI or CGI module? If ISAPI does the CGI exectuable crash too? Please
also upgrade to 4.0.5 or latest cvs and try with these.
(http://www.zend.com/snapshots)
- James
Previous Comments:
---
[2001-04-21 15:48:21] [EMAIL PROTECTED]
Error message is generated saying The instruction at 0x78003abf referenced at
0x00bc8000. The memory could not be read.
Because it seems that the problem is memory leak I am providing a part of the php code
where I am accumulating a large string width data (separated with |) which I am
going to pass later on javascript for further manipultion.
The number of records passed by the SQL query is about 900.
While developing the script, to avoid the error I raised the memory limit consumed by
script (in php.ini) first to 16M, later 32Mb, now it is 64M.
The strange thing for me is that after I raised to 16M, the error stopped, than
sudenly apperred again; when I put it on 64M it stopped again, and now it comes back
again without realy modifying this part of the script!
// the code
$sql = select GROUPID, SUBGROUPID, MATERIALID, DESCRIPTIONEN, DESCRIPTIONBG,
COSTPRICE from MATERIALS;
$h = ibase_query($sql);
while($row = ibase_fetch_object($h)) {
if ($lang_selected == en) {
$dsc = $row-DESCRIPTIONEN;
if ($dsc == ) { $dsc = $row-DESCRIPTIONBG; }
} else {
$dsc = $row-DESCRIPTIONBG;
if ($dsc == ) { $dsc = $row-DESCRIPTIONEN; }
}
$mats .=
trim($row-SUBGROUPID).|.trim($row-MATERIALID).|.trim($dsc).|.$row-COSTPRICE.|;
$qq++;
}
ibase_free_result($h);
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10434edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10459 Updated: can't find function then crush
ID: 10459
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Old-Bug Type: Reproducible Crash
Bug Type: *General Issues
Operating system:
PHP Version: 4.0.4pl1
Assigned To:
Comments:
Please provide a generic script that is as simple as possible that we can just copy
and paste into our text editors for testing. This script should have no external
dependencies unless it is one of these the causes the crash.
This will help us fix the bug.
Thanks,
- James
Previous Comments:
---
[2001-04-23 11:39:12] [EMAIL PROTECTED]
BTW, function sorted_keys included and must be found..
---
[2001-04-23 11:36:38] [EMAIL PROTECTED]
Configuration: see bug #9819
Output:
X-Powered-By: PHP/4.0.4pl1
Content-type: text/html
HTMLBODY
br
bFatal error/b: Call to undefined function: sorted_keys() in b../action.
class.php/b on line b52/bbr
then Windows says (language is russian):
Ïðîãðàììà PHP âûçâàëà ñáîé ïðè îáðàùåíèè ê ñòðàíèöå ïàìÿòè
â ìîäóëå íåò äàííûõ ïî àäðåñó 0084:1f82cf20.
Ðåãèñòðû:
EAX=00d70094 CS=0167 EIP=1f82cf20 EFLGS=00010202
EBX=00d705e0 SS=016f ESP=0063fc58 EBP=0063fc78
ECX= DS=016f ESI=00d70b80 FS=610f
EDX=0080 ES=016f EDI=0001 GS=
Áàéòû ïî àäðåñó CS:EIP:
Ñîäåðæèìîå ñòåêà:
1f702718 0003 006ae6c8 00d7 007bcd70 0063fd10
1f702505 00d70b80 0001 0010 00761adc 007bcd70 10037cb1
Source fragment:
class Action
{
var $ID;
var $Name;
var $Parameters;
var $Done=false;
var $events=array();
var $Result;
function Action($Type,$Parameters)
{
global $base;
// Find this action in table
switch(gettype($Type)){
case 'integer': $where='ID='.$Type;break;
case 'string':$where='Name='.$base-qstr($Type);break;
default: trigger_error('Incorrect Type parameter in
Action()',E_USER_ERROR);
}
if(!$action=$base-Execute('SELECT * From Actions WHERE '.$where))
trigger_error('Unknown Type in Action()',E_USER_ERROR); //
-- line 52 is here!
$sk=sorted_keys($Parameters);
while(!$action-EOF())
{
$sorted_params=sort(split(',',$action-Parameters));
$sorted_params=merge(',',$sorted_params);
if($sorted_params==$sk) break;
$action-MoveNext();
}
Sorry, but I can't provide the full sources for this case!
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10459edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10500 Updated: Misbehaving function
ID: 10500 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Old-Bug Type: Reproducible Crash Bug Type: *General Issues Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: can you check that your php.ini file is actaully being read? This works fine for me. Also please upgrade to 4.0.5 or latest CVS and check that this is still the case. Thanks. - James Previous Comments: --- [2001-04-25 17:49:49] [EMAIL PROTECTED] It appears to be that 5884001 bytes (or so) is the upper limit of the file size -- doesn't matter what the php.ini options are. I tried even rebooting the whole machine after the applied changes (well, Microsoft tactics) -- no luck. --- [2001-04-25 17:42:40] [EMAIL PROTECTED] This is exactly the same problem as bug #3627. OS: Win98 SE Running Apache Server 1.3.9 with PHP 4.0.4pl1. I'm trying to upload a 10MB file onto the FTP server. PHP 4.0.4pl1 has been downloaded precompiled from www.php.net. PHP.INI fraction: max_execution_time=2400 memory_limit=60M post_max_size=20M upload_max_filesize=20M The apache server will dump two lines into the error.log and ftp file transfer will die (server stays intact): Premature end of script headers: c:/bin/php/php.exe FATAL: erealloc(): Unable to allocate 5884001 bytes If I try to send the file = 5M it is working fine and fast. Thanks, Dragan --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10500edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10938 Updated: internal_functions.c:32: `#include' expects FILENAME or FILENAME
ID: 10938 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Compile Failure Operating system: PHP Version: 4.0.5 Assigned To: Comments: This should be fixed in CVS. Please try the latest snapshot from http://snaps.php.net/ --Jani Previous Comments: --- [2001-05-17 14:47:59] [EMAIL PROTECTED] After configuring with mysql and apxs (./configure --with-mysql=/usr/local --with-apxs=/usr/sbin/apxs), I ran make and eventually got this: Making all in main /bin/sh /Users/will/Documents/php-4.0.5/libtool --silent --mode=compile cc -I. -I/Users/will/Documents/php-4.0.5/main -I/Users/will/Documents/php-4.0.5/main -I/Users/will/Documents/php-4.0.5 -I/usr/include/httpd -I/Users/will/Documents/php-4.0.5/Zend -I/usr/local/include/mysql -I/Users/will/Documents/php-4.0.5/ext/xml/expat/xmltok -I/Users/will/Documents/php-4.0.5/ext/xml/expat/xmlparse -I/Users/will/Documents/php-4.0.5/TSRM -traditional-cpp -DDARWIN -DUSE_HSREGEX -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2 -c main.c /bin/sh /Users/will/Documents/php-4.0.5/libtool --silent --mode=compile cc -I. -I/Users/will/Documents/php-4.0.5/main -I/Users/will/Documents/php-4.0.5/main -I/Users/will/Documents/php-4.0.5 -I/usr/include/httpd -I/Users/will/Documents/php-4.0.5/Zend -I/usr/local/include/mysql -I/Users/will/Documents/php-4.0.5/ext/xml/expat/xmltok -I/Users/will/Documents/php-4.0.5/ext/xml/expat/xmlparse -I/Users/will/Documents/php-4.0.5/TSRM -traditional-cpp -DDARWIN -DUSE_HSREGEX -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2 -c internal_functions.c internal_functions.c:32: `#include' expects FILENAME or FILENAME make[2]: *** [internal_functions.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 After searching the web, I found that my problem seems identical to bug id #9716. That bug was closed and supposedly fixed March 30th, a full month before PHP 4.0.5 was released, but the bug appears to persist. I edited internal_functions.c, changed the erroneous n characters (I suspect they were supposed to be n rather than n) to line breaks, did make again, and the problem went away. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10938edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10904 Updated: php.exe accesses unreadable memory and crashes
ID: 10904
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Reproducible crash
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
Can reproduce this.. what SAPI are you using (ISAPI or CGI?).
- James
Previous Comments:
---
[2001-05-16 11:44:25] [EMAIL PROTECTED]
This script reproduces the bug on my machine:
?php
print html;
print head;
printtitlebug/title;
print /head;
print body;
for ($i=0; $i1000; $i++) {
print BRhello ;
}
print /body;
print /html;
?
Change 1000 to 333 and the bug disappears,
Change 1000 to 2 and the bug disappears.
---
[2001-05-16 11:02:35] [EMAIL PROTECTED]
WINNT SP4, APACHE 1.3.14, PHP 4.0.4 and 4.0.5
I cannot make a gdb backtrace, but I can give you the following:
1) It is an access violation -- the instruction at 0x0dsd5973 referenced 0x.
the memory could not be read.
2) It always occurs near the end of a script and is not related to what HTML happens
to be generated. Most scripts do not show the error at all, but when one does only
changing the size of the output (either very small or very large) will suppress it.
3) After clearing the error (by clicking OK on the error message on the server), the
full HTML is always produced correctly. However, until OK is clicked, the client is
left waiting for the last 1K or so of output).
4) It is defintely related to the size of the output. Scripts that make output
smaller then 1K never show the error. Larger scripts may or may not show the error,
but when they do, the error can always be removed by making the script generate a very
large output (~100K). I just repeated the same content x times. Once x is large
enough, the bug goes away.
5) On my system, calling phpinfo causes it -- ?php phpinfo() ? -- but only on the
second and subsequent calls after rebooting the server. Just starting and stopping
Apache does not allow the first good call to succeed--the server must be rebooted.
6) changing imlicit_flush, output_buffering, and memory_limit in php.ini do not fix
it, but might(???) alter the size of output that exhibts the problem. flush() in the
code does not fix it.
7) I theorize it is related to some final cleanup or garbage collection code.
8) I first saw it in 4.0.4 and upgraded to 4.0.5 hoping to see it go away. It did
not, but again the size of output that shows the error might(???) have changed. One
point about the upgrade, I could not copy msvcrt.dll to the system root because it was
always locked by the OS, even after closing all closable services. My msvcrt.dll is
dated three days earlier than the one distributed with PHP 4.0.4 and 4.0.5. There
appears to be no way to change it.
--This bug could easily exist under another OS, but be invisible (and harmless) if the
OS does not generate an error message for the address violation.
Hope this is helpful. Feel free to contact me.
Steve
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10904edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #7761 Updated: checkdnsrr not work
ID: 7761 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old-Status: Duplicate Status: Closed Bug Type: Network related Operating system: PHP Version: 4.0.3pl1 Assigned To: Comments: This function is not avalible under Win32. PHP now returns correct notice to the user. - James Previous Comments: --- [2001-01-22 22:17:15] [EMAIL PROTECTED] duplicate of 5311. --- [2000-11-20 12:13:24] [EMAIL PROTECTED] reclassified --- [2000-11-11 13:30:58] [EMAIL PROTECTED] i have a big problem with nt 4.0 / iis 4. i will check several domains with checkdnsrr(domain.com, MX) and i will always get back false. but the domain exist. the same script works on a linux system. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7761edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9554 Updated: mcrypt algorithms not functioning, see bug#9163 description
ID: 9554 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old-Status: Duplicate Status: Closed Bug Type: mcrypt related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: Parent bug closed. See information and explination in bug 9163. - James Previous Comments: --- [2001-03-04 22:31:35] [EMAIL PROTECTED] --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9554edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10074 Updated: checkdnsrr always returns false
ID: 10074 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old-Status: Duplicate Status: Assigned Bug Type: Network related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: This function is not avalible under win32. PHP now returns the correct error to the user. It may be implemented at some point in the future. - James Previous Comments: --- [2001-04-28 23:16:35] [EMAIL PROTECTED] Duplicate of #5311 --- [2001-03-30 14:40:26] [EMAIL PROTECTED] This is because of this line in ext/standard/dns.c: #if HAVE_RES_SEARCH !(defined(__BEOS__)||defined(PHP_WIN32)) I don't know whether windows has the necessary functions to get this work. Possibly. --Jani --- [2001-03-29 23:58:41] [EMAIL PROTECTED] Every call I make to checkdnsrr returns false on Win2k/IIS. Same code behaves properly in linux. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10074edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10187 Updated: Warning: mcrypt module initialization failed
ID: 10187 Updated by: jmoore Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: mcrypt related Operating system: PHP Version: 4.0 Latest CVS (05/04/2001) Assigned To: derick Comments: Derick: Bug 10281 reports this on Linux. Probably not platform specific. Previous Comments: --- [2001-05-01 03:37:44] [EMAIL PROTECTED] I guess this could be an OS specific problem. I've no access to a Mac OS X machine unfortunately. --- [2001-04-05 11:48:59] [EMAIL PROTECTED] Incidentally, I tried the new-style mcrypt functions as Colin suggested, and got a similar warning: Could not open encryption module. --- [2001-04-05 11:30:47] [EMAIL PROTECTED] analysed assigned --- [2001-04-05 11:30:06] [EMAIL PROTECTED] Another mcrypt bug, I'll check this one out. It may be a platform depended bug BTW. --- [2001-04-05 11:29:52] [EMAIL PROTECTED] First, the --disable-posix-threads requirement for libmcrypt isn't a requirement anymore. As of libmcrypt 2.4.x, you don't need it. Second, I think you should be using the 2.4.x-style mcrypt functions. Look at example 2 at http://www.php.net/manual/en/ref.mcrypt.php Third, blowfish is broken in libmcrypt. It will encode/decode internally, but don't rely on it if you need to pass data to a non-PHP application (e.g. Perl). - Colin --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10187edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Fri, 18 May 2001, Zeev Suraski wrote: At 11:21 18/5/2001, Jani Taskinen wrote: As long as these extensions are in there, I think changing any of their API's is a justification for 4.x release. This is simply not the way we decided to work in. Can it be changed? Sure. Should it be changed? In my humble opinion, no, it shouldn't. The thing I'm trying to state, not very successfully I guess, is that whether it's 4.0.7 or 4.666.3, we should be avoiding API changes as much as at all possible. Sure, sometimes there's just no alternative than to break downwards compatibility, but we should not get into the state of mind that breaking downwards compatibility is ok, as long as you increment some digit in the version number. You must understand that I don't like changing the API either. But sometimes it just HAS to be changed. And one thing that should happen when such changes are made, is to change the version number. Why is it so sacred to you? I didn't suggest either that if the version number is changed it's okay to break BC.. There are now _two_ extensions that break BC. (sockets/domxml) So is it okay to break BC in extensions? And like that one user said, if we had pumped up the minor number he would have expected to see some major changes. But as long as you continue this 'this is how we have always done things' way, people WILL get pissed. Not only me. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
At 12:05 18/5/2001, Jani Taskinen wrote: You must understand that I don't like changing the API either. But sometimes it just HAS to be changed. And one thing that should happen when such changes are made, is to change the version number. Why is it so sacred to you? Each and his own religion :) More seriously, yes, I realize that sometimes the API *HAS* to be changed. Those cases are relatively rare, and should remain as such. In cases where the main reason for 'HAVING to change' the API is code bloat (e.g. the mysql_db_query() function), I'd argue that keeping it makes much more sense, with or without version changes. I didn't suggest either that if the version number is changed it's okay to break BC.. There are now _two_ extensions that break BC. (sockets/domxml) So is it okay to break BC in extensions? And like that one user said, if we had pumped up the minor number he would have expected to see some major changes. But as long as you continue this 'this is how we have always done things' way, people WILL get pissed. Not only me. Could be. To be honest, I'm not sure what the best solution would be here. Coming out with an API that later changes is simply a bad thing, but it's all too common in PHP. IMO the problem is with the initial design, i.e., we should perhaps invest more time in designing the API to begin with, instead of just coming out with something, and later improving on it (sometimes by changing it completely). I don't mind using the middle version number to signify major changes in the API. Judging by other projects, though, people would probably expect substantial functionality improvement from such version changes, while in practice, they'd be the same. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?
On 2001-05-18 05:43:50, Rasmus Lerdorf [EMAIL PROTECTED] wrote: Obviously the mmap will be faster, but if as in bug #10701, someone is Ignore my last post regarding this bug... --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #10701 Updated: readfile usage on large files
On 2001-05-18 05:28:19, [EMAIL PROTECTED] wrote: ID: 10701 Status: Closed But a hint. Don't use readfile(), fopen() the file and read it a bit at a time instead of sticking the entire thing in memory. Does readfile() really read the whole thing into memory first?? Perhaps we should change it so that it reads chunks and then spits them out; it won't break any scripts and will make PHP more memory efficient as that guy suggested. Or am I missing something? --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10890 Updated: Segmentation fault when using mcrypt function in Apache
ID: 10890 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: mcrypt related Operating system: PHP Version: 4.0.5 Assigned To: derick Comments: Can you make a backtrace of it, and possible try it with libmcrypt 2.4.11 (or .12 if it's out yet)? Derick Previous Comments: --- [2001-05-18 03:58:29] [EMAIL PROTECTED] I downloaded and compiled this one: php4-200105172345 But im still getting this in my Apache error log when i try to use Mcrypt: [Fri May 18 09:56:24 2001] [notice] child pid 50599 exit signal Segmentation fault (11) [Fri May 18 09:56:25 2001] [notice] child pid 50595 exit signal Segmentation fault (11) --- [2001-05-17 17:43:40] [EMAIL PROTECTED] This should be fixed in CVS. Can you please try a snapshot in about two hours? (The snapshots have to be generated, and are available on snaps.php.net) If this does not fix the problem for you, please reopen this report. --- [2001-05-17 17:02:29] [EMAIL PROTECTED] Hello, I'm on this, probably found the bug already. I'll commit the fix as soon as I tested it and my connection works 100%. Derick --- [2001-05-17 16:48:40] [EMAIL PROTECTED] I tried today with libmcrypt-2.4.11 both with --disable-posix-threads and without. In both cases i get the segmentation fault in the apache log. --- [2001-05-15 17:48:17] [EMAIL PROTECTED] If i try to run this script: ?php $key = this is a very secret key; $input = Let us meet at 9 o'clock at the secret place.; $td = mcrypt_module_open (MCRYPT_TripleDES, , MCRYPT_MODE_ECB, ); $iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td), MCRYPT_RAND); mcrypt_generic_init ($td, $key, $iv); $encrypted_data = mcrypt_generic ($td, $input); mcrypt_generic_end ($td); echo $encrypted_data; ? I get this in my Apache log file: [Tue May 15 23:30:13 2001] [notice] child pid 22372 exit signal Segmentation fault (11) [Tue May 15 23:30:13 2001] [notice] child pid 22371 exit signal Segmentation fault (11) I did configure libmcrypt 2.4.9 with: ./configure --disable-posix-threads And PHP 4.0.5 with: ./configure --with-mysql=/usr/local/mysql --with-gd=/usr/local --with-t1lib --with-ttf --with-jpeg-dir --with-png-dir --with-tiff-dir --with-zlib-dir --with-xpm-dir --with-imap --with-gettext --with-zlib --with-pdflib --enable-exif --enable-ftp --enable-bcmath --with-mcrypt --with-config-file-path=/usr/local/etc --with-apxs=/usr/local/apache/bin/apxs --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10890edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10949: LAN directory in function opendir()
From: [EMAIL PROTECTED] Operating system: NT 4.0 Server PHP version: 4.0.5 PHP Bug Type: Directory function related Bug description: LAN directory in function opendir() $test=computer\\test\\vb; $dir=opendir($test); closedir($dir); -- Edit Bug report at: http://bugs.php.net/?id=10949edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10950: GetImageSize doesn't work with some jpeg types
From: [EMAIL PROTECTED] Operating system: Linux 2.2.19 PHP version: 4.0.5 PHP Bug Type: GetImageSize related Bug description: GetImageSize doesn't work with some jpeg types hi i tried to use the GetImageSize function on jpeg coming from a CASIO QV-2800UX digital camera it can't get the image size ! looking at the file with an hex viewer, i saw un-standard header (no JFIF at the beginning), and extra-infos related to the camera other programs such as acdsee or photoshop handle the files quite well is this special features of jpeg? should it or will it be support by this function? i'm ready to send you such a file if needed thanks, regards -- Edit Bug report at: http://bugs.php.net/?id=10950edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10950 Updated: GetImageSize doesn't work with some jpeg types
ID: 10950 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: GetImageSize related Operating system: PHP Version: 4.0.5 Assigned To: Comments: Fixed already. Will be in 4.0.6. --Jani Previous Comments: --- [2001-05-18 06:21:35] [EMAIL PROTECTED] hi i tried to use the GetImageSize function on jpeg coming from a CASIO QV-2800UX digital camera it can't get the image size ! looking at the file with an hex viewer, i saw un-standard header (no JFIF at the beginning), and extra-infos related to the camera other programs such as acdsee or photoshop handle the files quite well is this special features of jpeg? should it or will it be support by this function? i'm ready to send you such a file if needed thanks, regards --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10950edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10950 Updated: GetImageSize doesn't work with some jpeg types
ID: 10950 Updated by: derick Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: GetImageSize related Operating system: PHP Version: 4.0.5 Assigned To: Comments: Should be fixed in CVS now, and will be in PHP 4.0.6. Previous Comments: --- [2001-05-18 06:26:26] [EMAIL PROTECTED] Fixed already. Will be in 4.0.6. --Jani --- [2001-05-18 06:21:35] [EMAIL PROTECTED] hi i tried to use the GetImageSize function on jpeg coming from a CASIO QV-2800UX digital camera it can't get the image size ! looking at the file with an hex viewer, i saw un-standard header (no JFIF at the beginning), and extra-infos related to the camera other programs such as acdsee or photoshop handle the files quite well is this special features of jpeg? should it or will it be support by this function? i'm ready to send you such a file if needed thanks, regards --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10950edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10949 Updated: LAN directory in function opendir()
ID: 10949 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Directory function related Operating system: PHP Version: 4.0.5 Assigned To: Comments: UNC path support is in PHP 4.0.6 which will be released in near future. So please wait. You could try latest snapshot build from http://www.zend.com/snapshots/ if you wish. --Jani Previous Comments: --- [2001-05-18 06:21:13] [EMAIL PROTECTED] $test=\\computer\test\vb; $dir=opendir($test); closedir($dir); --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10949edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Fw: ssl support
On Tue, 15 May 2001, Chuck Hagenbuch wrote: Well, that's nice for him to say, but if you want php to support c-client's ssl features, you need to build c-client with ssl. That's a dependancy. Anyway, this is getting into build issues that are a little over my head, so I'm passing it off to php-dev... This is not a build issue. Is that auth_ssl() call in php_imap.c really necessary? As that does not exist in IMAP-2001 anymore.. --Jani Quoting Ilya Krel [EMAIL PROTECTED]: - Original Message - From: Mark Crispin [EMAIL PROTECTED] To: Ilya [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, May 15, 2001 4:30 PM Subject: re: ssl support On Tue, 15 May 2001 16:05:24 -0400, Ilya wrote: Is ssl support in c-client 2000 broken? there is no auth_ssl files in distribution, and php for example cant compile properly if i want it to support imap-ssl through cclinet All UW-distributed versions of imap-2000 had auth_ssl. Note that in imap-2001, the SSL support files are now called ssl_unix, ssl_w2k, etc. PHP should not in any way depend upon how c-client is built (whether with or without SSL). If it does, this is a bug in PHP. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Black and white and grey, all the shades of truth. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10778 Updated: ext/pdf does not work with pdflib 4.0
ID: 10778 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: PDF related Operating system: PHP Version: 4.0.5 Assigned To: Comments: PHP 4.0.5 supports pdflib 4.0 just fine. --Jani Previous Comments: --- [2001-05-10 03:36:49] [EMAIL PROTECTED] ext/pdf is written to detect and work with pdflib 3.x; unfortunately it is pdflib 4.x that is available for download from the pdflib Web site - leading to PHP failing to compile/link with pdflib. The fix is simple enough (it'd be nice if this was to be incorporated directly into PHP as standard for those systems whereby installing autoconf isn't really necessary); simply replace the ext/pdf contents of PHP with that supplied by pdflib 4.0, then rebuild configure. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10778edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Command line processing and php.ini loading
Hello!
1. I made a patch to solve a minor problem: php.ini loading was done before
-c path command line options processing. You will find a patch bellow. I'd
like someone to review and commit if it's Ok.
2. Will I have problems if I enable command line options processing in CGI
mode. My php binary is installed outside of cgi-bin directory and is being run
with suexec wrapper? If not, then I will create a patch to add
configure option which will allow command line processing in cgi mode. Will
you argue?
Please CC: your replies to my e-mail ([EMAIL PROTECTED]), I will greatly appreciate
that.
--- php-4.0.5/sapi/cgi/cgi_main.c Wed Mar 7 16:24:12 2001
+++ php-4.0.5.fix/sapi/cgi/cgi_main.c Fri May 18 14:48:27 2001
@@ -413,10 +413,6 @@
setmode(_fileno(stderr), O_BINARY); /* make the stdio mode be
binary */
#endif
- if (php_module_startup(cgi_sapi_module)==FAILURE) {
- return FAILURE;
- }
-
/* Make sure we detect we are a cgi - a bit redundancy here,
but the default case is that we have to check only the first one. */
if (getenv(SERVER_SOFTWARE)
@@ -470,6 +466,10 @@
}
ap_php_optind = orig_optind;
ap_php_optarg = orig_optarg;
+ }
+
+ if (php_module_startup(cgi_sapi_module)==FAILURE) {
+ return FAILURE;
}
#ifdef ZTS
--
Oleg Sharoiko.
Software and Network Engineer
Computer Center of Rostov State University.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10776 Updated: Externally set LDFLAGS not exported by configure
ID: 10776 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Compile Problem Operating system: PHP Version: 4.0.5 Assigned To: Comments: Any examples? Like which libraries are missing? Which runtime paths? --Jani Previous Comments: --- [2001-05-10 02:34:53] [EMAIL PROTECTED] If you set CC, CFLAGS and LDFLAGS prior to running configure, CC and CFLAGS will be used by and exported through configure such that it works for the remainder of the build - but LDFLAGS is only used by configure (then ignored, not exported to the remaining build scripts). This causes some runtime paths and libraries to be missing from the resultant PHP binary, leading to execution failure. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10776edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10951: Patch for PHP4.0.5 for crypt() ???
From: [EMAIL PROTECTED] Operating system: Win 98 PHP version: 4.0.5 PHP Bug Type: Feature/Change Request Bug description: Patch for PHP4.0.5 for crypt() ??? Hi, I really need this crypt() function to work in php4.0.5 and was if there was anyway or anyplace that has maybe a patch or a file to replace to have crypt() to work. I know you guys are working on php4.0.6 and when is that going to be released. Also, is crypt being added to the new version? Please, I need a way, any way, to get crypt to work in php4.0.5 without replacing the whole directory. Also, how can I downgrade to php4.0.4. Whenever i try to, it says something about php4apache not being attached or something, though the directory it sees it in and the name of the file is correct. How can I downgrade, and where do I place files to get it to work. All help will be appreciated. Thanks. -- Edit Bug report at: http://bugs.php.net/?id=10951edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10952: Crash during interaction with a COM object
From: [EMAIL PROTECTED] Operating system: Win NT PHP version: 4.0.5 PHP Bug Type: Reproducible crash Bug description: Crash during interaction with a COM object I tried a basic example provided by php programming manual: 1. $word=new COM(word.application) or die(Cannot start 2. word for you); 3. print Loaded word version ($word-Version)\n; 4. $word-visible =1 ; 5. $word-Documents-Add(); 6. $word-Selection-Typetext(Dit is een test); 7. $word-Documents[1]-SaveAs(burb ofzo.doc); 8. $word-Quit(); I get an error prompt on line 4 (memory access fault). I think COM support is very weak... -- Edit Bug report at: http://bugs.php.net/?id=10952edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10890 Updated: Segmentation fault when using mcrypt function in Apache
ID: 10890 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: mcrypt related Operating system: FreeBSD 4.1.1 PHP Version: 4.0.5 Description: Segmentation fault when using mcrypt function in Apache This is a backtrack with: apache-1.3.19 php4-200105172345 libmcrypt-2.4.11 #0 permute ( inblock=0x827dda4 Let us meet at 9 o'clock at the secret place., perm=0x1980, outblock=0xbfbfe2a8 ) at tripledes.c:628 #1 0x2859de9d in tripledes_LTX__mcrypt_encrypt () at tripledes.c:454 #2 0x285a1711 in ecb_LTX__mcrypt () at ecb.c:76 #3 0x2851b8ba in mcrypt_enc_get_algorithms_name () at mcrypt_modules.c:178 #4 0x2851ae09 in mcrypt_generic () at mcrypt.c:136 #5 0x282d1cc8 in php_if_mcrypt_generic () at mcrypt.c:391 #6 0x28264dd7 in execute () at ./zend_execute.c:863 #7 0x282762b0 in zend_execute_scripts () at zend.c:260 #8 0x2828e60b in php_execute_script () at main.c:1138 #9 0x28289ba6 in apache_php_module_main () at sapi_apache.c:98 #10 0x2828a8f4 in send_php (r=0x8279034, display_source_mode=0, filename=0x8279b3c /usr/home/hoise/www/www.larsson.as/php/test/mcrypt.php) at mod_php4.c:536 #11 0x2828a93b in send_parsed_php (r=0x8279034) at mod_php4.c:547 #12 0x28073809 in ap_invoke_handler () from /usr/local/apache/libexec/libhttpd.so #13 0x2808adc0 in process_request_internal () from /usr/local/apache/libexec/libhttpd.so #14 0x2808ae39 in ap_process_request () from /usr/local/apache/libexec/libhttpd.so #15 0x28080b90 in child_main () from /usr/local/apache/libexec/libhttpd.so #16 0x28080e58 in make_child () from /usr/local/apache/libexec/libhttpd.so #17 0x28080f2b in startup_children () from /usr/local/apache/libexec/libhttpd.so #18 0x2808166a in standalone_main () from /usr/local/apache/libexec/libhttpd.so #19 0x2808208b in ap_main () from /usr/local/apache/libexec/libhttpd.so #20 0x80485cb in main () #21 0x8048541 in _start () Please let me know if this is what you needed. Or tell me what else to give you. Im not that experienced in debuggin, so please give me clear instructions :-) Previous Comments: --- [2001-05-18 06:20:38] [EMAIL PROTECTED] Can you make a backtrace of it, and possible try it with libmcrypt 2.4.11 (or .12 if it's out yet)? Derick --- [2001-05-18 03:58:29] [EMAIL PROTECTED] I downloaded and compiled this one: php4-200105172345 But im still getting this in my Apache error log when i try to use Mcrypt: [Fri May 18 09:56:24 2001] [notice] child pid 50599 exit signal Segmentation fault (11) [Fri May 18 09:56:25 2001] [notice] child pid 50595 exit signal Segmentation fault (11) --- [2001-05-17 17:43:40] [EMAIL PROTECTED] This should be fixed in CVS. Can you please try a snapshot in about two hours? (The snapshots have to be generated, and are available on snaps.php.net) If this does not fix the problem for you, please reopen this report. --- [2001-05-17 17:02:29] [EMAIL PROTECTED] Hello, I'm on this, probably found the bug already. I'll commit the fix as soon as I tested it and my connection works 100%. Derick --- [2001-05-17 16:48:40] [EMAIL PROTECTED] I tried today with libmcrypt-2.4.11 both with --disable-posix-threads and without. In both cases i get the segmentation fault in the apache log. --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=10890 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] bug or feature?
On Fri, 18 May 2001, Stig Bakken wrote: Anyway, I'd like to see $this assignment in constructor: 1. dismissed as a bug 2. documented as a feature, or +1 from me on this one. -Andrei Hacker: Any person who derives joy from discovering ways to circumvent limitations. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] bug or feature?
At 16:08 18/5/2001, Andrei Zmievski wrote: On Fri, 18 May 2001, Stig Bakken wrote: Anyway, I'd like to see $this assignment in constructor: 1. dismissed as a bug 2. documented as a feature, or +1 from me on this one. +1 on what? :) It's generally a side effect of the implementation, so I wouldn't be too keen on documenting as a feature, but as an undefined behavior. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10953: PHP WinHelp bug
From: [EMAIL PROTECTED] Operating system: Win98 PHP version: 4.0.5 PHP Bug Type: Documentation problem Bug description: PHP WinHelp bug Inside PHP WinHelp Index click on [+]-Appendixes book opened it; but next click don't close it and next clicks change icon to firing book, closed folder, opened folder etc. That is this? I'm surprised. In addition of this books Migrating from ..., PHP development etc (six books A-F) must be INSIDE Appendixes, don't outside of it. Any comments? -- Edit Bug report at: http://bugs.php.net/?id=10953edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10954: Can't connect to AS/400 via Client Access
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.0.5 PHP Bug Type: ODBC related Bug description: Can't connect to AS/400 via Client Access I have PHP 4.0.5 running on a Windows 2000 machine. My web server is apache 1.3.17 (1.3.19 don't work neither) I try to access to my AS/400 database via ODBC provide by Client Access. ODBC works well with Access and Excel Apache and PHP works well (phpinfo() for example) But when I try to connect to AS/400 via $connection=odbc_connect($nomodbc,$user,$iden); nothing happens. I was running with php3. Thanks [PHP] ;;; ; About this file ; ;;; ; This file controls many aspects of PHP's behavior. In order for PHP to ; read it, it must be named 'php.ini'. PHP looks for it in the current ; working directory, in the path designated by the environment variable ; PHPRC, and in the path that was defined in compile time (in that order). ; Under Windows, the compile-time path is the Windows directory. The ; path in which the php.ini file is looked for can be overriden using ; the -c argument in command line mode. ; ; The syntax of the file is extremely simple. Whitespace and Lines ; beginning with a semicolon are silently ignored (as you probably guessed). ; Section headers (e.g. [Foo]) are also silently ignored, even though ; they might mean something in the future. ; ; Directives are specified using the following syntax: ; directive = value ; Directive names are *case sensitive* - foo=bar is different from FOO=bar. ; ; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one ; of the INI constants (On, Off, True, False, Yes, No and None) or an expression ; (e.g. E_ALL ~E_NOTICE), or a quoted string (foo). ; ; Expressions in the INI file are limited to bitwise operators and parentheses: ; | bitwise OR ; bitwise AND ; ~ bitwise NOT ; ! boolean NOT ; ; Boolean flags can be turned on using the values 1, On, True or Yes. ; They can be turned off using the values 0, Off, False or No. ; ; An empty string can be denoted by simply not writing anything after the equal ; sign, or by using the None keyword: ; ; foo = ; sets foo to an empty string ; foo = none ; sets foo to an empty string ; foo = none; sets foo to the string 'none' ; ; If you use constants in your value, and these constants belong to a dynamically ; loaded extension (either a PHP extension or a Zend extension), you may only ; use these constants *after* the line that loads the extension. ; ; All the values in the php.ini-dist file correspond to the builtin ; defaults (that is, if no php.ini is used, or if you delete these lines, ; the builtin defaults will be identical). ; Language Options ; engine = On ; Enable the PHP scripting language engine under Apache short_open_tag = On ; allow the ? tag. otherwise, only ?php and script tags are recognized. asp_tags= Off ; allow ASP-style % % tags precision = 14 ; number of significant digits displayed in floating point numbers y2k_compliance = Off ; whether to be year 2000 compliant (will cause problems with non y2k compliant browsers) output_buffering= Off ; Output buffering allows you to send header lines (including cookies) ; even after you send body content, in the price of slowing PHP's ; output layer a bit. ; You can enable output buffering by in runtime by calling the output ; buffering functions, or enable output buffering for all files ; by setting this directive to On. output_handler = ; You can redirect all of the output of your scripts to a function, ; that can be responsible to process or log it. For example, ; if you set the output_handler to ob_gzhandler, than output ; will be transparently compressed for browsers that support gzip or ; deflate encoding. Setting an output handler automatically turns on ; output buffering. implicit_flush = Off ; Implicit flush tells PHP to tell the output layer to flush itself ; automatically after every output block. This is equivalent to
Re: [PHP-DEV] bug or feature?
On Fri, 18 May 2001, Zeev Suraski wrote: It's generally a side effect of the implementation, so I wouldn't be too keen on documenting as a feature, but as an undefined behavior. A very useful side effect, perhaps? -Andrei Computers are useless. They can only give you answers. --Pablo Picasso -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] bug or feature?
* Zeev Suraski [EMAIL PROTECTED] | | At 16:08 18/5/2001, Andrei Zmievski wrote: | On Fri, 18 May 2001, Stig Bakken wrote: | Anyway, I'd like to see $this assignment in constructor: | | 1. dismissed as a bug | 2. documented as a feature, or | | +1 from me on this one. | | +1 on what? :) From me: +1 on documenting/making it a feature. | It's generally a side effect of the implementation, so I wouldn't be too | keen on documenting as a feature, but as an undefined behavior. Could the current behaviour be hard to keep in the future, with the $this assignment in constructor syntax? The feature, though currently unintended, is certainly handy enough to warrant being kept alive in one way or another. -- Øyvind Møll [EMAIL PROTECTED] Initio IT-løsninger AS URL: http://www.initio.no/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10952 Updated: Crash during interaction with a COM object
ID: 10952 Updated by: phanto Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Reproducible crash Operating system: PHP Version: 4.0.5 Assigned To: Comments: com support in 4.0.5 is broken, you have to wait for 4.0.6 Previous Comments: --- [2001-05-18 08:29:56] [EMAIL PROTECTED] I tried a basic example provided by php programming manual: 1. $word=new COM(word.application) or die(Cannot start 2. word for you); 3. print Loaded word version ($word-Version)n; 4. $word-visible =1 ; 5. $word-Documents-Add(); 6. $word-Selection-Typetext(Dit is een test); 7. $word-Documents[1]-SaveAs(burb ofzo.doc); 8. $word-Quit(); I get an error prompt on line 4 (memory access fault). I think COM support is very weak... --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10952edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Thu, 17 May 2001, Rasmus Lerdorf wrote: I don't agree. Have you noticed the thread about domxml currently running in php-dev@? Wouldn't that justify a 4.1? What would? No, I don't think a single extension should affect the PHP version number to that extent. But I do think we should be moving towards versioning the extensions individually. Could you explain how having separate version numbers for extensions would help at all? As long as the extensions are distributed with the main PHP package, that is. There will be more and more extensions that are not bundled with PHP, and having a standard way to check the version of an extension is going to be required. This should also apply to the bundled extensions. You also have to consider that people build bundled extensions as shared extensions. For example, once upon a time I built the ftp extension as shared and I have not updated my ftp.so for quite a while even though I have updated my libphp4.so many times. So I am effectively using an old bundled extension with a new version of PHP. Right now there is no real way to detect this, and if my code used the PHP version number and determined that the API for the ftp extension is different now and tried to call the ftp functions differently then my app would break as my particular ftp extension definitely has not changed. As long as these extensions are in there, I think changing any of their API's is a justification for 4.x release. I disagree. Since optional extensions are not a core part of the language and can be built and maintained separately, changes to them should not be the main cause for bumping the major version number of PHP. Major Changes to the core of PHP or to any non-optional components should however. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Fri, 18 May 2001, Rasmus Lerdorf wrote: As long as these extensions are in there, I think changing any of their API's is a justification for 4.x release. I disagree. Since optional extensions are not a core part of the language and can be built and maintained separately, changes to them should not be the main cause for bumping the major version number of PHP. Major Changes to the core of PHP or to any non-optional components should however. Do you really think that average PHP user makes any difference between extensions and the core? I don't think so. As long as they come in same package..it's the same for them. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Fri, 18 May 2001, Jani Taskinen wrote: On Fri, 18 May 2001, Rasmus Lerdorf wrote: As long as these extensions are in there, I think changing any of their API's is a justification for 4.x release. I disagree. Since optional extensions are not a core part of the language and can be built and maintained separately, changes to them should not be the main cause for bumping the major version number of PHP. Major Changes to the core of PHP or to any non-optional components should however. Do you really think that average PHP user makes any difference between extensions and the core? I don't think so. As long as they come in same package..it's the same for them. That still doesn't change the fact that it is imprecise to tie the PHP version number to extensions when there is no 1:1 relationship here and the possibility exists that an older version of the extension can be used with a newer version of PHP. And more and more, the average PHP user does not build PHP themselves but use it on a server where PHP was built by an admin. On these servers it is getting more common for the admin to enable extensions as shared extensions from user requests which increases the likelihood of old versions of extensions sticking around and not being in synch with the PHP installation. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10904 Updated: php.exe accesses unreadable memory and crashes
ID: 10904
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Reproducible crash
Operating system: WINNT SP4
PHP Version: 4.0.5
Description: php.exe accesses unreadable memory and crashes
I believe it is CGI. Httpd.conf contains
ScriptAlias /php/ C:/phpdev3/php/
ScriptAlias /php2/ C:/phpdev3/php/
ScriptAlias /php3/ C:/phpdev3/php/
AddType application/x-httpd-php4 .phtml .pwml .htm
AddType application/x-httpd-php4 .php4 .php .php3 .php2 .htm
Action application/x-httpd-php4 /php/php.exe
---
I just performed a complete reinstallation, but the bug is still there.
I downloaded and installed the phpdev3 installation package from www.firepages.com.au.
This package installs Apache 1.3.19 , PHP 4.0.4pl, and MySQL. My application talks to
Oracle and I don't use the MySQL.
I completely removed my old installation.
I made these configurations to the fresh installation.
In PHP.INI (which I copied to c:\winnt)
- changed the memory limit to 16M
- set the include path to .
- enabled the php_mhash extension
- enabled the php_imap extension (can't recall if I actually use this)
in httpd.conf
- changed the document root to D:\www
I copied all the dlls for php\dlls and php\extensions to my system32 directory (except
I got he usual error with msvcrt.dll --- mine is 12/7/99 and the dist version is
12/10/99).
Then I verified that my application still works and that the little demonstration app
still shows the bug.
Steve
Previous Comments:
---
[2001-05-18 04:48:55] [EMAIL PROTECTED]
Can reproduce this.. what SAPI are you using (ISAPI or CGI?).
- James
---
[2001-05-16 11:44:25] [EMAIL PROTECTED]
This script reproduces the bug on my machine:
?php
print html;
print head;
printtitlebug/title;
print /head;
print body;
for ($i=0; $i1000; $i++) {
print BRhello ;
}
print /body;
print /html;
?
Change 1000 to 333 and the bug disappears,
Change 1000 to 2 and the bug disappears.
---
[2001-05-16 11:02:35] [EMAIL PROTECTED]
WINNT SP4, APACHE 1.3.14, PHP 4.0.4 and 4.0.5
I cannot make a gdb backtrace, but I can give you the following:
1) It is an access violation -- the instruction at 0x0dsd5973 referenced 0x.
the memory could not be read.
2) It always occurs near the end of a script and is not related to what HTML happens
to be generated. Most scripts do not show the error at all, but when one does only
changing the size of the output (either very small or very large) will suppress it.
3) After clearing the error (by clicking OK on the error message on the server), the
full HTML is always produced correctly. However, until OK is clicked, the client is
left waiting for the last 1K or so of output).
4) It is defintely related to the size of the output. Scripts that make output
smaller then 1K never show the error. Larger scripts may or may not show the error,
but when they do, the error can always be removed by making the script generate a very
large output (~100K). I just repeated the same content x times. Once x is large
enough, the bug goes away.
5) On my system, calling phpinfo causes it -- ?php phpinfo() ? -- but only on the
second and subsequent calls after rebooting the server. Just starting and stopping
Apache does not allow the first good call to succeed--the server must be rebooted.
6) changing imlicit_flush, output_buffering, and memory_limit in php.ini do not fix
it, but might(???) alter the size of output that exhibts the problem. flush() in the
code does not fix it.
7) I theorize it is related to some final cleanup or garbage collection code.
8) I first saw it in 4.0.4 and upgraded to 4.0.5 hoping to see it go away. It did
not, but again the size of output that shows the error might(???) have changed. One
point about the upgrade, I could not copy msvcrt.dll to the system root because it was
always locked by the OS, even after closing all closable services. My msvcrt.dll is
dated three days earlier than the one distributed with PHP 4.0.4 and 4.0.5. There
appears to be no way to change it.
--This bug could easily exist under another OS, but be invisible (and harmless) if the
OS does not generate an error message for the address violation.
Hope this is helpful. Feel free to contact me.
Steve
---
Full Bug description available at: http://bugs.php.net/?id=10904
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Fri, 18 May 2001, Rasmus Lerdorf wrote: That still doesn't change the fact that it is imprecise to tie the PHP version number to extensions when there is no 1:1 relationship here and the possibility exists that an older version of the extension can be used with a newer version of PHP. And more and more, the average PHP user does not build PHP themselves but use it on a server where PHP was built by an admin. On these servers it is getting more common for the admin to enable extensions as shared extensions from user requests which increases the likelihood of old versions of extensions sticking around and not being in synch with the PHP installation. Hmm..I'm not really sure how it's possible to use older API version extensions with newer PHP as the Zend boys pump up their API version number on every release..and afaik that prevents you from using the old extensions..? --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Fri, 18 May 2001, Jani Taskinen wrote: Hmm..I'm not really sure how it's possible to use older API version extensions with newer PHP as the Zend boys pump up their API version number on every release..and afaik that prevents you from using the old extensions..? They hardly bump Zend API version with every point release. -Andrei Music expresses that which can not be said and on which it is impossible to be silent. -Victor Hugo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10955: session configured with session_set_save_handler and a database
From: [EMAIL PROTECTED] Operating system: Red Hat Linux release 6.2 (Zoot) PHP version: 4.0.5 PHP Bug Type: Unknown/Other Function Bug description: session configured with session_set_save_handler and a database The problem is that when i'm using session_set_save_handler to store session data on an oracle base with php4.0.5, the 'write' function is never called, whereas on a 4.0.4pl1 it works fine ! The 4.0.4pl1 PHP (the good one) is running on a 2000 system, with the same php.ini as below php4.0.5 (the bad one ?) was installed on a linux like this: Configure Command: './configure' '--with-oci8' '--with-apache=../apache_1.3.19' '--enable-track-vars' with this php.ini: [PHP] ;;; ; About this file ; ;;; ; This file controls many aspects of PHP's behavior. In order for PHP to ; read it, it must be named 'php.ini'. PHP looks for it in the current ; working directory, in the path designated by the environment variable ; PHPRC, and in the path that was defined in compile time (in that order). ; Under Windows, the compile-time path is the Windows directory. The ; path in which the php.ini file is looked for can be overriden using ; the -c argument in command line mode. ; ; The syntax of the file is extremely simple. Whitespace and Lines ; beginning with a semicolon are silently ignored (as you probably guessed). ; Section headers (e.g. [Foo]) are also silently ignored, even though ; they might mean something in the future. ; ; Directives are specified using the following syntax: ; directive = value ; Directive names are *case sensitive* - foo=bar is different from FOO=bar. ; ; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one ; of the INI constants (On, Off, True, False, Yes, No and None) or an expression ; (e.g. E_ALL ~E_NOTICE), or a quoted string (foo). ; ; Expressions in the INI file are limited to bitwise operators and parentheses: ; | bitwise OR ; bitwise AND ; ~ bitwise NOT ; ! boolean NOT ; ; Boolean flags can be turned on using the values 1, On, True or Yes. ; They can be turned off using the values 0, Off, False or No. ; ; An empty string can be denoted by simply not writing anything after the equal ; sign, or by using the None keyword: ; ; foo = ; sets foo to an empty string ; foo = none ; sets foo to an empty string ; foo = none; sets foo to the string 'none' ; ; If you use constants in your value, and these constants belong to a dynamically ; loaded extension (either a PHP extension or a Zend extension), you may only ; use these constants *after* the line that loads the extension. ; ; All the values in the php.ini-dist file correspond to the builtin ; defaults (that is, if no php.ini is used, or if you delete these lines, ; the builtin defaults will be identical). ; Language Options ; engine = On ; Enable the PHP scripting language engine under Apache short_open_tag = On ; allow the ? tag. otherwise, only ?php and script tags are recognized. asp_tags= Off ; allow ASP-style % % tags precision = 14 ; number of significant digits displayed in floating point numbers y2k_compliance = Off ; whether to be year 2000 compliant (will cause problems with non y2k compliant browsers) output_buffering= Off ; Output buffering allows you to send header lines (including cookies) ; even after you send body content, in the price of slowing PHP's ; output layer a bit. ; You can enable output buffering by in runtime by calling the output ; buffering functions, or enable output buffering for all files ; by setting this directive to On. output_handler = ; You can redirect all of the output of your scripts to a function, ; that can be responsible to process or log it. For example, ; if you set the output_handler to ob_gzhandler, than output ; will be transparently compressed for browsers that support gzip or ; deflate encoding. Setting an output handler automatically turns on ; output buffering. implicit_flush = Off ; Implicit flush tells PHP to tell the output layer to flush itself
[PHP-DEV] Bug #10701 Updated: readfile usage on large files
ID: 10701
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: Filesystem function related
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
Reopened. This is not fixed.
--Jani
Previous Comments:
---
[2001-05-18 00:51:27] [EMAIL PROTECTED]
You are kidding right? Nice way to take down a server.
load average: 66.52, 33.25, 15.76
$fp = fopen(/web/sites/contentsite/.$f);
while(!feof($fp))
{
echo fgets($fd, 4096);
}
fclose($fp);
---
[2001-05-18 00:28:19] [EMAIL PROTECTED]
What's to claim. This is a support question that belongs on one of the mailing lists
and not in the bug database.
But a hint. Don't use readfile(), fopen() the file and read it a bit at a time
instead of sticking the entire thing in memory.
---
[2001-05-17 17:29:33] [EMAIL PROTECTED]
Anyone plan on claiming this?
---
[2001-05-07 07:34:13] [EMAIL PROTECTED]
Ok, this is a pretty intersting one, and I'm not even sure if it's a bug or just a
memory limit thing. I am using a php wrapper for content files
(.jpg|.gif|.asf|.mov|.ram), as you can guess, the movie files can be pretty large,
upwards of 10MB, all getting read into memory, then spit back out. Couple that with a
site that gets 10K+ visits a day and the server is on its knees with a load average of
about 10 (when it gets to 25/30 things start swapping and it will dies not long after
that.)
here's the code used to wrap the content:
?php
$mime_type = strtolower(strrchr($f,'.'));
$mime_type_array = array(
'.asf' = 'application/vnd.ms-asf',
'.jpg' = 'image/jpeg',
'.gif' = 'image/gif'
);
if(!in_array($mime_type,array_keys($mime_type_array)))
{
header(Location: /error.php);
}
$offset = 86400 * 3;
header(Expires: .gmdate(D, d M Y H:i:s GMT, time() + $offset));
header(Cache-Control: max-age=.$offset., must-revalidate);
header(Last-modified : .gmdate(D, d M Y H:i:s GMT,
filemtime(/web/sites/contentsite/.$f)));
header(Content-type: .$mime_type_array[$mime_type]);
header(Content-length: .filesize(/web/sites/contentsite/.$f));
@readfile(/web/sites/contentsite/.$f);
?
so, I would pass an image or movie to the content file with a url like so:
http://contentsite.com/content.php?f=movies/bigmovie.asf
This is really just a heads up at this point, I know it will take you guys a little
while to sort through this one, I'm not even sure it's a bug considering readfile is
SUPPOSED to read a file into memory and spit it back out. I dunno, for now I'm going
to do some .htaccess tricks where I force php to parse .htaccess files. If anyone has
come across this or has any insight on wrapping content in php files, please email me
at [EMAIL PROTECTED]
Thanks!
Stephen VanDyke
PS - aside from that, great language, I love PHP :)
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10701edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
That still doesn't change the fact that it is imprecise to tie the PHP version number to extensions when there is no 1:1 relationship here and the possibility exists that an older version of the extension can be used with a newer version of PHP. And more and more, the average PHP user does not build PHP themselves but use it on a server where PHP was built by an admin. On these servers it is getting more common for the admin to enable extensions as shared extensions from user requests which increases the likelihood of old versions of extensions sticking around and not being in synch with the PHP installation. Hmm..I'm not really sure how it's possible to use older API version extensions with newer PHP as the Zend boys pump up their API version number on every release..and afaik that prevents you from using the old extensions..? ZEND_MODULE_API_NO last changed in December of last year. If you look through CVS you will find that there have been many releases without a change in ZEND_MODULE_API_NO. Right now an extension built 5 months ago still loads perfectly into a current snapshot. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10954 Updated: Can't connect to AS/400 via Client Access
ID: 10954 Updated by: kalowsky Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: ODBC related Operating system: PHP Version: 4.0.5 Assigned To: Comments: can you try to provide a bit more information? maybe try the $connection = odbc_connect($nomodbc, $user, $iden) or die(My ODBC connection doesn't exist); Previous Comments: --- [2001-05-18 09:25:50] [EMAIL PROTECTED] I have PHP 4.0.5 running on a Windows 2000 machine. My web server is apache 1.3.17 (1.3.19 don't work neither) I try to access to my AS/400 database via ODBC provide by Client Access. ODBC works well with Access and Excel Apache and PHP works well (phpinfo() for example) But when I try to connect to AS/400 via $connection=odbc_connect($nomodbc,$user,$iden); nothing happens. I was running with php3. Thanks [PHP] ;;; ; About this file ; ;;; ; This file controls many aspects of PHP's behavior. In order for PHP to ; read it, it must be named 'php.ini'. PHP looks for it in the current ; working directory, in the path designated by the environment variable ; PHPRC, and in the path that was defined in compile time (in that order). ; Under Windows, the compile-time path is the Windows directory. The ; path in which the php.ini file is looked for can be overriden using ; the -c argument in command line mode. ; ; The syntax of the file is extremely simple. Whitespace and Lines ; beginning with a semicolon are silently ignored (as you probably guessed). ; Section headers (e.g. [Foo]) are also silently ignored, even though ; they might mean something in the future. ; ; Directives are specified using the following syntax: ; directive = value ; Directive names are *case sensitive* - foo=bar is different from FOO=bar. ; ; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one ; of the INI constants (On, Off, True, False, Yes, No and None) or an expression ; (e.g. E_ALL ~E_NOTICE), or a quoted string (foo). ; ; Expressions in the INI file are limited to bitwise operators and parentheses: ; | bitwise OR ; bitwise AND ; ~ bitwise NOT ; ! boolean NOT ; ; Boolean flags can be turned on using the values 1, On, True or Yes. ; They can be turned off using the values 0, Off, False or No. ; ; An empty string can be denoted by simply not writing anything after the equal ; sign, or by using the None keyword: ; ; foo = ; sets foo to an empty string ; foo = none ; sets foo to an empty string ; foo = none; sets foo to the string 'none' ; ; If you use constants in your value, and these constants belong to a dynamically ; loaded extension (either a PHP extension or a Zend extension), you may only ; use these constants *after* the line that loads the extension. ; ; All the values in the php.ini-dist file correspond to the builtin ; defaults (that is, if no php.ini is used, or if you delete these lines, ; the builtin defaults will be identical). ; Language Options ; engine = On ; Enable the PHP scripting language engine under Apache short_open_tag = On ; allow the ? tag. otherwise, only ?php and script tags are recognized. asp_tags= Off ; allow ASP-style % % tags precision = 14 ; number of significant digits displayed in floating point numbers y2k_compliance = Off ; whether to be year 2000 compliant (will cause problems with non y2k compliant browsers) output_buffering= Off ; Output buffering allows you to send header lines (including cookies) ; even after you send body content, in the price of slowing PHP's ; output layer a bit. ; You can enable output buffering by in runtime by calling the output ; buffering functions, or enable output buffering for all files ; by setting this directive to On. output_handler = ; You can redirect all of the output of your scripts to a function, ; that can be responsible to process or log it. For example, ; if you set the output_handler to ob_gzhandler, than output ; will be transparently compressed for browsers that support gzip or ; deflate
[PHP-DEV] Bug #10580 Updated: Access Violation using ADODB
ID: 10580
Updated by: phanto
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: COM related
Operating system:
PHP Version: 4.0.7-dev (dated 16-May-2001)
Assigned To:
Comments:
is it ? i was able to run your ado script successfully. are you using the isapi or the
cgi version of php. isapi isn't stable yet.
-harald
Previous Comments:
---
[2001-05-16 08:42:01] [EMAIL PROTECTED]
COM broken in PHP version 4.0.7-dev
---
[2001-05-16 08:34:57] [EMAIL PROTECTED]
Bug reopened, CVS dated 16 May 2001,
message when accessing database:
PHP has encountered an Access Violation at 011CD614
---
[2001-05-08 20:12:03] [EMAIL PROTECTED]
works here.
the only mistake i found was, that if either the connect string or the query was wrong
$conn-execute() returned a nullpointer instead of a valid recordset.
this only produced a warning so there was a nullpointer exception at the first attempt
to access $rs-...
now i produce an error (unfortunatelly this causes the script to stop).
i'll fix this in the code and switch back to a warning, but i think it's ok for now.
---
[2001-05-08 19:18:07] [EMAIL PROTECTED]
Here is a code snippet for testing ADODB:
?php
define (DSN_USER, sa);
define (DSN_PWD, );
define (DB_SERVERNAME, localhost);
define (DATABASENAME, Northwind);
define (OLEDB_CONNECTION_STRING, Provider=SQLOLEDB; Data Source=.DB_SERVERNAME.;
Initial Catalog=.DATABASENAME.; User ID=.DSN_USER.; Password=.DSN_PWD);
$conn = new COM(ADODB.Connection) or die(Cannot start ADO);
$conn-Open(OLEDB_CONNECTION_STRING);
$command = SELECT * from employees;
$rs = $conn-Execute($command); // Recordset
$num_columns = $rs-Fields-Count();
$this-set_arr($num_columns);
for ($i=0; $i $num_columns; $i++) {
$fld[$i] = $rs-Fields($i);
}
$rowcount = 0;
while (!$rs-EOF) {
for ($i=0; $i $num_columns; $i++) {
$arr[$i][$rowcount] = $fld[$i]-value;
}
$rowcount++;// increments rowcount
$rs-MoveNext();
}
$rs-Close();
$conn-Close();
$rs = NULL;
$conn = NULL;
?
This produces the error: PHP has encountered an Access Violation at 2474FF04
You can also produce an Access Violation by trying to use MSXML Parser 3.0,
and by calling the loadXML() method.
I downloaded php 4.0.6-dev [2001-05-04] build from
php4win32.sourceforge.net/releases/php-4.0.6-dev-20010504.exe
---
[2001-05-08 16:30:55] [EMAIL PROTECTED]
could you provide a short snippet, i can't reproduce this.
are you using the cgi or the isapi version ?
---
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10580edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Fri, 18 May 2001, Rasmus Lerdorf wrote: That still doesn't change the fact that it is imprecise to tie the PHP version number to extensions when there is no 1:1 relationship here and the possibility exists that an older version of the extension can be used with a newer version of PHP. And more and more, the average PHP user does not build PHP themselves but use it on a server where PHP was built by an admin. On these servers it is getting more common for the admin to enable extensions as shared extensions from user requests which increases the likelihood of old versions of extensions sticking around and not being in synch with the PHP installation. Hmm..I'm not really sure how it's possible to use older API version extensions with newer PHP as the Zend boys pump up their API version number on every release..and afaik that prevents you from using the old extensions..? ZEND_MODULE_API_NO last changed in December of last year. If you look through CVS you will find that there have been many releases without a change in ZEND_MODULE_API_NO. Right now an extension built 5 months ago still loads perfectly into a current snapshot. Ah. I must have been dreaming then.. :) I remember that someone submitted some bug report about this very issue. Anyway, now I see that there really is good reason having that version (PHP_#ext#_API_NO ?) after all. And having that..we should propable start moving those extensions one by one into PEAR? Maybe we could then roll out two packages, one for core and one for the extensions? And btw. Why not have a function in PHP core that can be used to get the desired extensions remotely from pear.php.net? If we have a PHP_#ext#_API_NO, running a 'update_php_extensions()' would go and grab the updated (if the extension HAS been updated) one..etc.. (I'm just thinking out loud..ignore me :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Rasmus Lerdorf wrote: [...] which increases the likelihood of old versions of extensions sticking around and not being in synch with the PHP installation. not to likely nowadays due to the API number changes that made binary extensions not being loaded by other php versions then the ones they were compiled for (with the only exception of php 4.0.2 and 4.0.3 which had no api changes between releases) but as the api was said to be most likely stable now this will be an upcomming problem again in the (near?) future -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Andrei Zmievski wrote: They hardly bump Zend API version with every point release. not with every release, somehow they missed 4.0.3 on this ;) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Ah. I must have been dreaming then.. :) I remember that someone submitted some bug report about this very issue. Anyway, now I see that there really is good reason having that version (PHP_#ext#_API_NO ?) after all. And having that..we should propable start moving those extensions one by one into PEAR? That has been the plan for a while now. Not necessarily moving all the optional extensions, but some of them. And new fringe extensions would go straight to PEAR. And btw. Why not have a function in PHP core that can be used to get the desired extensions remotely from pear.php.net? If we have a PHP_#ext#_API_NO, running a 'update_php_extensions()' would go and grab the updated (if the extension HAS been updated) one..etc.. (I'm just thinking out loud..ignore me :) There is the start of a set of command line tools for doing this. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Andrei Zmievski wrote: They hardly bump Zend API version with every point release. not with every release, somehow they missed 4.0.3 on this ;) No bump in 4.0.6 either, and it doesn't look like there will be one for 4.0.7 either. About 5 months since the last bump. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Jani Taskinen wrote: Anyway, now I see that there really is good reason having that version (PHP_#ext#_API_NO ?) after all. And having that..we should propable start moving those extensions one by one into PEAR? do we have the infrastructure in PEAR for C code yet ? Maybe we could then roll out two packages, one for core and one for the extensions? this wouldn't really solve the problem as you still have different versions of packages at least in the extension part while it adds more complexity leading to users trying to get core version x together with extensions version y where x and y do not fit And btw. Why not have a function in PHP core that can be used to get the desired extensions remotely from pear.php.net? If we have a PHP_#ext#_API_NO, running a 'update_php_extensions()' would go and grab the updated (if the extension HAS been updated) one..etc.. nice idea, but once again: we are talking about C-code and shared libraries here, how do you get a system to compile things automaticly from within a webserver process (which usually does not have the access rights needed to update things in the filesystem) and how do you force php to exchange .so versions on the fly, especially in a multi- threaded server, while keeping php and the server running ? -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Jani Taskinen wrote: Anyway, now I see that there really is good reason having that version (PHP_#ext#_API_NO ?) after all. And having that..we should propable start moving those extensions one by one into PEAR? do we have the infrastructure in PEAR for C code yet ? Not yet, so this isn't something that is going to happen tomorrow. And we also have to be very careful about how it is done. One of the big strengths of PHP is that you don't generally have to run around looking for the right versions of extensions to match a certain version of PHP. It just works. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Fri, 18 May 2001, Rasmus Lerdorf wrote: Ah. I must have been dreaming then.. :) I remember that someone submitted some bug report about this very issue. Anyway, now I see that there really is good reason having that version (PHP_#ext#_API_NO ?) after all. And having that..we should propable start moving those extensions one by one into PEAR? That has been the plan for a while now. Not necessarily moving all the optional extensions, but some of them. And new fringe extensions would go straight to PEAR. Too bad it seems not to be going anywhere.. And btw. Why not have a function in PHP core that can be used to get the desired extensions remotely from pear.php.net? If we have a PHP_#ext#_API_NO, running a 'update_php_extensions()' would go and grab the updated (if the extension HAS been updated) one..etc.. (I'm just thinking out loud..ignore me :) There is the start of a set of command line tools for doing this. I don't think having those separately is a good idea. More like a function set in PHP would make more sense. As you have to have the core PHP anyway? --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
And btw. Why not have a function in PHP core that can be used to get the desired extensions remotely from pear.php.net? If we have a PHP_#ext#_API_NO, running a 'update_php_extensions()' would go and grab the updated (if the extension HAS been updated) one..etc.. (I'm just thinking out loud..ignore me :) There is the start of a set of command line tools for doing this. I don't think having those separately is a good idea. More like a function set in PHP would make more sense. As you have to have the core PHP anyway? I don't see how that would work. The command-line tool would pull down the tarball, phpize it to pull in the local configuration settings, then build the extension. Doing all this from an internal PHP call doesn't make any sense to me. That's like saying that phpize should be an internal PHP function instead of the current shell script that it is now. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] bug or feature?
Oyvind Moll wrote: Could the current behaviour be hard to keep in the future, with the $this assignment in constructor syntax? Assignments to self (to $this) are a very useful features and common in other OO languages as well. I'd vote for keeping the feature, document it as such and making it legal. Kristian -- Kristian Köhntopp, NetUSE AG Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
Rasmus Lerdorf wrote: There will be more and more extensions that are not bundled with PHP, and having a standard way to check the version of an extension is going to be required. This should also apply to the bundled extensions. Currently there is a number of self-description functions in PHP, such as the name of the current SAPI, tests for existing (loaded) extensions and similar. I'd second your request for a function or a number of functions that report properties of a loaded extension, and I'd like to see section in a manual that deals with analyzing your PHP environment from a program. So 1. how would I get a list of all currently loaded modules and their version number? 2. how would I get a list of functions names, constants and magic variables and internal objects created by this module? 3. what information can I get about the PHP core (version, SAPI, other information). Question is, would it be possible write phpinfo() as a user function? If yes, the set of self description of PHP would be fairly complete - the list of function names etc actually transcends phpino(). This could be interpreted as a shortcoming of phpinfo(): module names should be clickable in phpinfo() and lead to a page describing that module in detail. Kristian -- Kristian Köhntopp, NetUSE AG Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Open issues for 4.0.6
I think there are two main open issues for 4.0.6. The crash in mcrypt (if it is a general problem) and the rollback of domxml. Am I correct? Is there anything else crucial which needs to be added? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10956: move_uploaded_file()
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0.5
PHP Bug Type: Filesystem function related
Bug description: move_uploaded_file()
move_uploaded_file (string filename, string destination)
if string filename is in array then function don't work and return false but if string
filename is in normal variable then work.
here is example(this not work):
?
if ($go==1) {
move_uploaded_file($ARR[foto],/home/dziadek/public_html/webmind/temp/aaa.jpg);}
? FORM ENCTYPE=multipart/form-data method=post
INPUT TYPE=file name=ARR[foto]
INPUt TYPE=hidden name=go value=1
INPUT TYPE=submit
/FORM
this example work:
?
if ($go==1) {
move_uploaded_file($foto,/home/dziadek/public_html/webmind/temp/aaa.jpg);}
? FORM ENCTYPE=multipart/form-data method=post
INPUT TYPE=file name=foto
INPUt TYPE=hidden name=go value=1
INPUT TYPE=submit
/FORM
I don't understand why fisrt example don't work.
Sorry for my broken and easy English.
--
Edit Bug report at: http://bugs.php.net/?id=10956edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Open issues for 4.0.6
Hello Andi, Friday, May 18, 2001, 5:07:46 PM, you wrote: AG I think there are two main open issues for 4.0.6. AG The crash in mcrypt (if it is a general problem) and the rollback of domxml. AG Am I correct? Is there anything else crucial which needs to be added? AG Andi I re-verified the mcrypt problem late last night by upgrading a redundant linux server to 4.0.6 and the mcrypt functions immediately started to fail - interestingly all platforms this has been tested on return DNS/Server not found errors in MSIE 5.0 under Win32. I fully expect it to do the same on other platforms/browser configurations but don't have the time to go through them all. The immediate workaround is of course to comment out / remove the appropriate calls to the mcrypt functions but clearly for applications where data integrity is important this isn't a long term fix. I understand that Derek was going to have a look at this issue last night, and would appreciate any information on progress as and when it arises; we have 3 applications relying on this functionality to secure user data and each of them is now using alternative methods which I am keen to bin at the earliest opportunity. -- Best regards, Chris Operations Director, Gameshrine Limited mailto:[EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Open issues for 4.0.6
Andi Gutmans wrote: I think there are two main open issues for 4.0.6. The crash in mcrypt (if it is a general problem) and the rollback of domxml. Am I correct? Is there anything else crucial which needs to be added? Yup, and after Colin's message, I'm still deciding whether to rollback the DOM-XML commit in the branch. Right now I'm going through the source and doing a bit of cleanup (removing confusing commented portions, adding some debugging features). I'm basically waiting to the last minute to see if I can get enough cleaned up and working for the next release (crash bugs, functionality, documentation, etc.) I probably won't be able to finish, and end up just reverting the commit in the branch, but its worth a try. ;) -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Open issues for 4.0.6
On Fri, 18 May 2001, Sterling Hughes wrote: Yup, and after Colin's message, I'm still deciding whether to rollback the DOM-XML commit in the branch. Right now I'm going through the source and doing a bit of cleanup (removing confusing commented portions, adding some debugging features). I'm basically waiting to the last minute to see if I can get enough cleaned up and working for the next release (crash bugs, functionality, documentation, etc.) I probably won't be able to finish, and end up just reverting the commit in the branch, but its worth a try. ;) The extension is pretty broken right now. I think he tried to emulate what I did in PHP-GTK and at the same time preserve backwards compatibility to the old API and that's just not possible. Example, domxml_children() crashes because it's an alias for $root-children and for the former case this_ptr is NULL. In PHP-GTK all functions are methods, but it wouldn't help here. -Andrei * UNIX, isn't that some archaic form of DOS? - our job applicant * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] bug or feature?
Kristian Köhntopp wrote: Assignments to self (to $this) are a very useful features and common in other OO languages as well. I'd vote for keeping the feature, document it as such and making it legal. +1 -- sebastian bergmann[EMAIL PROTECTED] http://www.sebastian-bergmann.de bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] mass virtual hosting
In the archives I found just a few posts about patches for setting open_basedir and other core globals dynamically, as needed in a mass virtual hosting environment with Apache. Have any of these patches been applied, or is anyone working on this? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10957: define_syslog_variables
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.0.4pl1 PHP Bug Type: Documentation problem Bug description: define_syslog_variables the word variables spelled wrong right after the void. http://www.php.net/manual/en/function.define-syslog-variables.php define_syslog_variables (PHP 3, PHP 4 ) define_syslog_variables -- Initializes all syslog related constants Description void define_syslog_varaibles () Initializes all constants used in the syslog functions. -- Edit Bug report at: http://bugs.php.net/?id=10957edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10957 Updated: define_syslog_variables
ID: 10957 Updated by: rasmus Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Documentation problem Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: Fixed in CVS Previous Comments: --- [2001-05-18 12:25:35] [EMAIL PROTECTED] the word variables spelled wrong right after the void. http://www.php.net/manual/en/function.define-syslog-variables.php define_syslog_variables (PHP 3, PHP 4 ) define_syslog_variables -- Initializes all syslog related constants Description void define_syslog_varaibles () Initializes all constants used in the syslog functions. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10957edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: Bug #10580 Updated: Access Violation using ADODB
I was testing under the isapi, and I noticed that what worked before broke
when the version number changed from 4.0.6-dev to 4.0.7-dev.
Give me a chance to try a newer version, and I'll let you know how it goes.
Noticed that the error changed from
PHP has encountered an Access Violation at 2474FF04
to
PHP has encountered an Access Violation at 011CD614
-Original Message-
From: Bug Database [mailto:[EMAIL PROTECTED]]
Sent: Saturday, 19 May 2001 1:24 AM
To: [EMAIL PROTECTED]
Subject: Bug #10580 Updated: Access Violation using ADODB
ID: 10580
Updated by: phanto
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: COM related
Operating system:
PHP Version: 4.0.7-dev (dated 16-May-2001)
Assigned To:
Comments:
is it ? i was able to run your ado script successfully. are you using the
isapi or the cgi version of php. isapi isn't stable yet. -harald
Previous Comments:
---
[2001-05-16 08:42:01] [EMAIL PROTECTED]
COM broken in PHP version 4.0.7-dev
---
[2001-05-16 08:34:57] [EMAIL PROTECTED]
Bug reopened, CVS dated 16 May 2001, message when accessing database: PHP
has encountered an Access Violation at 011CD614
---
[2001-05-08 20:12:03] [EMAIL PROTECTED]
works here. the only mistake i found was, that if either the connect string
or the query was wrong $conn-execute() returned a nullpointer instead of a
valid recordset. this only produced a warning so there was a nullpointer
exception at the first attempt to access $rs-... now i produce an error
(unfortunatelly this causes the script to stop). i'll fix this in the code
and switch back to a warning, but i think it's ok for now.
---
[2001-05-08 19:18:07] [EMAIL PROTECTED]
Here is a code snippet for testing ADODB: ?php define (DSN_USER, sa);
define (DSN_PWD, ); define (DB_SERVERNAME, localhost); define
(DATABASENAME, Northwind); define (OLEDB_CONNECTION_STRING,
Provider=SQLOLEDB; Data Source=.DB_SERVERNAME.; Initial
Catalog=.DATABASENAME.; User ID=.DSN_USER.; Password=.DSN_PWD); $conn
= new COM(ADODB.Connection) or die(Cannot start ADO);
$conn-Open(OLEDB_CONNECTION_STRING); $command = SELECT * from employees;
$rs = $conn-Execute($command); // Recordset $num_columns =
$rs-Fields-Count(); $this-set_arr($num_columns); for ($i=0; $i
$num_columns; $i++) { $fld[$i] = $rs-Fields($i); } $rowcount = 0; while
(!$rs-EOF) { for ($i=0; $i $num_columns; $i++) { $arr[$i][$rowcount] =
$fld[$i]-value;} $rowcount++;// increments rowcount
$rs-MoveNext(); } $rs-Close(); $conn-Close(); $rs = NULL; $conn =
NULL; ? This produces the error: PHP has encountered an Access Violation
at 2474FF04 You can also produce an Access Violation by trying to use MSXML
Parser 3.0, and by calling the loadXML() method. I downloaded php 4.0.6-dev
[2001-05-04] build from
php4win32.sourceforge.net/releases/php-4.0.6-dev-20010504.exe
---
[2001-05-08 16:30:55] [EMAIL PROTECTED]
could you provide a short snippet, i can't reproduce this. are you using the
cgi or the isapi version ?
---
The remainder of the comments for this report are too long. To view the
rest of the comments, please view the bug report online.
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=10580edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10958: ltconfig in infinite loop looking for echo
From: [EMAIL PROTECTED]
Operating system: HPUX 10.20
PHP version: 4.0.5
PHP Bug Type: *Install and Config
Bug description: ltconfig in infinite loop looking for echo
I had to comment out the following lines in ltconfig and
hardcode my choice for echo:
# IFS=${IFS= }; save_ifs=$IFS;
IFS=${IFS}${PATH_SEPARATOR}
# for dir in $PATH /usr/ucb; do
#if (test -f $dir/echo || test -f $dir/echo$ac_exeext)
# test X`($dir/echo '\t') 2/dev/null` = 'X\t'
# test X`($dir/echo $echo_test_string)2/dev/null`
= X$echo_test_string; then
# echo=$dir/echo
# break
#fi
# done
# IFS=$save_ifs
echo=/usr/bin/echo
Not doing so keeps ltconfig in an infinite loop.
--
Edit Bug report at: http://bugs.php.net/?id=10958edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Open issues for 4.0.6
Andi Gutmans wrote: I think there are two main open issues for 4.0.6. The crash in mcrypt (if it is a general problem) and the rollback of domxml. Am I correct? Is there anything else crucial which needs to be added? i'd like to remove my SAP extension from the 4.0.6RC branch as it has no production functionality as of yet ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] bug or feature?
At 16:27 18/5/2001, Andrei Zmievski wrote: On Fri, 18 May 2001, Zeev Suraski wrote: It's generally a side effect of the implementation, so I wouldn't be too keen on documenting as a feature, but as an undefined behavior. A very useful side effect, perhaps? Yes, but still, a side effect. Could end up changing in the future, and we don't want to have to limit ourselves to implementations that have this side effect. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] bug or feature?
On Fri, 18 May 2001, Zeev Suraski wrote: Yes, but still, a side effect. Could end up changing in the future, and we don't want to have to limit ourselves to implementations that have this side effect. Well, if we define it as a feature, wouldn't you be able to support it in the future implementations as well? -Andrei Computers are useless. They can only give you answers. --Pablo Picasso -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] bug or feature?
At 16:31 18/5/2001, Oyvind Moll wrote: Could the current behaviour be hard to keep in the future, with the $this assignment in constructor syntax? Yes, it is. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] bug or feature?
Guys, This isn't up for a vote... It's a side effect of implementation, and other implementations may invalidate it. We can't document it as a feature, because it may bite us big time in the future. Zeev At 19:21 18/5/2001, Sebastian Bergmann wrote: Kristian Köhntopp wrote: Assignments to self (to $this) are a very useful features and common in other OO languages as well. I'd vote for keeping the feature, document it as such and making it legal. +1 -- sebastian bergmann[EMAIL PROTECTED] http://www.sebastian-bergmann.de bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] bug or feature?
At 20:00 18/5/2001, Andrei Zmievski wrote: On Fri, 18 May 2001, Zeev Suraski wrote: Yes, but still, a side effect. Could end up changing in the future, and we don't want to have to limit ourselves to implementations that have this side effect. Well, if we define it as a feature, wouldn't you be able to support it in the future implementations as well? What we define it as doesn't really change how difficult or easy it is to implement it :) So no, defining it as a feature may very well limit ourselves at what we can do with the object model in the future, so I'm against it. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10959: include' expects FILENAME or FILENAME
From: [EMAIL PROTECTED] Operating system: Mac OS X PHP version: 4.0.5 PHP Bug Type: Compile Failure Bug description: include' expects FILENAME or lt;FILENAMEgt; After running ./configure --with-xml --with-apxs=/usr/sbin/apxs --disable-pear --enable-track-vars --with-mysql=/usr/local, I get: internal_functions.c:32: `#include' expects FILENAME or FILENAME make[2]: *** [internal_functions.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 in the Making all in main step. Michael -- Edit Bug report at: http://bugs.php.net/?id=10959edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] bug or feature?
Zeev Suraski wrote: Guys, This isn't up for a vote... It's a side effect of implementation, and other implementations may invalidate it. We can't document it as a feature, because it may bite us big time in the future. Is it just me, or are you refering to very different people by 'we' and 'us' in your last sentence? ;) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?
Obviously the mmap will be faster, but if as in bug #10701, someone is adding headers or doing something else to really large files, things are going to break. There seem to be some misconceptions about what we are really doing. We map a shared(*1), read-only copy of the file into our address space, we don't allocate any memory, we don't operate on the mmap'ed area, and this does not change when you add headers or do something else to really large files. The process of mapping does not cause a read of the whole file at once nor does it allocate memory for the whole file. When pages are accessed, a memory fault is generated and the data is fetched from the disk. When there is not enough free physical RAM for storing the contents of a new page, old pages get thrown away (they are read-only, so there is no reason to swap them out). (*2) For delivering a 600MB ISO image, the simple read/write approach with a 2KB buffer will cause about 600,000 context switches. The mmap implementation will need less than 10. This can significantly decrease the load on busy web-servers. By leveraging the power of the underlying OS's buffer cache, we enable the OS to handle the dirty aspects of writing huge amounts of disk data to the network. Most modern OS have certain optimizations to deal with that task in the most efficient way (i.e. zero-copy, sendfile()). The simple read/write approach circumvents all possible optimizations by OS designers. I just ran a quick test with a 400MB ISO image, Apache 1.3 CVS, PHP 4.0 CVS on a system with 256MB RAM. The results of http_load are below. 40 fetches, 20 max parallel, 1.68437e+10 bytes, in 361.079 seconds 4.21093e+08 mean bytes/connection 0.110779 fetches/sec, 4.66484e+07 bytes/sec msecs/connect: 18.0746 mean, 692.648 max, 0.072 min msecs/first-response: 1116.32 mean, 3546.76 max, 48.349 min *1 There is a bug in the current code, as we should be using MAP_SHARED. This might be contributing to what the user is describing in #10701. *2 Some Linux 2.4.x trees seem to be broken in that respect and don't free pages quickly enough (or not at all). This causes the system to freeze. Linux 2.2 works as expected. I experienced this effect on 2.4.4-ac1 (TUX patch). - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10959 Updated: include' expects FILENAME or FILENAME
ID: 10959 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating system: Mac OS X PHP Version: 4.0.5 Description: include' expects FILENAME or FILENAME Sounds as if this bug is related to # 9716 Michael Previous Comments: --- [2001-05-18 13:13:43] [EMAIL PROTECTED] After running ./configure --with-xml --with-apxs=/usr/sbin/apxs --disable-pear --enable-track-vars --with-mysql=/usr/local, I get: internal_functions.c:32: `#include' expects FILENAME or FILENAME make[2]: *** [internal_functions.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 in the Making all in main step. Michael --- Full Bug description available at: http://bugs.php.net/?id=10959 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] bug or feature?
At 20:39 18/5/2001, Hartmut Holzgraefe wrote: Zeev Suraski wrote: Guys, This isn't up for a vote... It's a side effect of implementation, and other implementations may invalidate it. We can't document it as a feature, because it may bite us big time in the future. Is it just me, or are you refering to very different people by 'we' and 'us' in your last sentence? ;) Yep - we as the development guys. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
