Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?

[Sterling Hughes]

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 
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]

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 
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]

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 
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

[Sterling Hughes]

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 
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 ?

[Andi Gutmans]

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 
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 ?

[Andi Gutmans]

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 
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 ?

[Sterling Hughes]

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 
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 ?

[Thies C. Arntzen]

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 
> 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 
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]

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.

Stig

-- 
PHP Development Mailing List 
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]

> >>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.

-Rasmus


-- 
PHP Development Mailing List 
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 #10945 Updated: Apache core dumps when PHP4.0.5 is activated via LoadModule

[morgan]

ID: 10945
User Update by: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Apache related
Operating system: AIX 4.3.3 (MU8)
PHP Version: 4.0.5
Description: Apache core dumps when PHP4.0.5 is activated via LoadModule

Somehow, I'd guessed that AIX would finish low on the "supported list".  One note, for 
anyone that's stuck with this config -> I installed iPlanet Web Server 4.1SP7, to see 
if maybe NSAPI would work, and I got problems that were much like the ones with 
Apache.  BUT -> when I didn't specify a web server to support, I got a "normal" binary 
for PHP, which I could use as a CGI interpreter.  One comment about this though, when 
a script starts with "#!/opt/php4/bin/php", that was displayed at the top of the web 
page, but what was below worked fine (in this case, "").

Any idea how to get rid of that ??  (removing the text broke the script, and I got 
nothing but the content of the php file with no execution).  That would give a "valid" 
solution for AIX people.  (I guess installing Linux on the RS6000 would work too, but 
that's such a pain...)

--Morgan
[EMAIL PROTECTED]

Previous Comments:
---

[2001-05-18 01:36:47] [EMAIL PROTECTED]
There is no "supported list".  But, obviously operating systems that are more common 
end up getting more attention and more testing.  AIX is near the bottom of that list.

---

[2001-05-18 01:29:51] [EMAIL PROTECTED]
Tried recompiling everything with IBM Visual Age C v5.01.  No change.  I also tried 
linking with the pthread library for the httpd binary, like [EMAIL PROTECTED] said to 
try, but no luck.  Quick question: is AIX on the "supported" list ??  Is this supposed 
to work ??

--Morgan
[EMAIL PROTECTED]

---

[2001-05-17 21:49:55] [EMAIL PROTECTED]
On systems that use glibc-2.1.x there is a bug in glibc that prevents a binary not 
linked against pthreads to dynamically load a shared library that is linked against 
pthreads.  Perhaps this problem also exists on AIX?  Try linking your Apache httpd 
against libpthreads.

---

[2001-05-17 20:57:44] [EMAIL PROTECTED]
Apache-1.3.19 compiles clean under gcc-2.95.3 with:

$ ./configure --prefix=/opt/apache --enable-module=so

$ make

# make install


Apache starts cleanly and generally works fine.

PHP4.0.5 compiles clean under gcc-2.95.3 with:

$ ./configure --prefix=/opt/php --with-apxs=/opt/apache/bin/apxs 
--with-mysql=/opt/mysql

$ make

# make install


Howver when I stop Apache and start it back up again, it doesn't start.  It dumps 
core.  When I rem out the LoadModule directive for the php module in httpd.conf, 
Apache starts up fine.

[ FYI: it's MySQL 3.23.34a (--prefix=/opt/mysql --with-pthreads) ]

Any suggections on how to troubleshoot it ?  If you have a use for the core, I can 
send it to you.  More info:

RS/6000-43P/132
AIX 4.3.3 (maintenance update 8)
gcc-2.95.3

Only other software installed on the system is GNU make-3.79.1 and bash-2.04.

Any help is greatly appreciated.

---


Full Bug description available at: http://bugs.php.net/?id=10945


-- 
PHP Development Mailing List 
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 ?

[Sterling Hughes]

> 
>>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.

-Sterling






-- 
PHP Development Mailing List 
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

[Michael Loftis]

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 
> 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 
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]

> > 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?

-Rasmus


-- 
PHP Development Mailing List 
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 #10945 Updated: Apache core dumps when PHP4.0.5 is activated via LoadModule

[rasmus]

ID: 10945
Updated by: rasmus
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Apache related
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

There is no "supported list".  But, obviously operating systems that are more common 
end up getting more attention and more testing.  AIX is near the bottom of that list.

Previous Comments:
---

[2001-05-18 01:29:51] [EMAIL PROTECTED]
Tried recompiling everything with IBM Visual Age C v5.01.  No change.  I also tried 
linking with the pthread library for the httpd binary, like [EMAIL PROTECTED] said to 
try, but no luck.  Quick question: is AIX on the "supported" list ??  Is this supposed 
to work ??

--Morgan
[EMAIL PROTECTED]

---

[2001-05-17 21:49:55] [EMAIL PROTECTED]
On systems that use glibc-2.1.x there is a bug in glibc that prevents a binary not 
linked against pthreads to dynamically load a shared library that is linked against 
pthreads.  Perhaps this problem also exists on AIX?  Try linking your Apache httpd 
against libpthreads.

---

[2001-05-17 20:57:44] [EMAIL PROTECTED]
Apache-1.3.19 compiles clean under gcc-2.95.3 with:

$ ./configure --prefix=/opt/apache --enable-module=so

$ make

# make install


Apache starts cleanly and generally works fine.

PHP4.0.5 compiles clean under gcc-2.95.3 with:

$ ./configure --prefix=/opt/php --with-apxs=/opt/apache/bin/apxs 
--with-mysql=/opt/mysql

$ make

# make install


Howver when I stop Apache and start it back up again, it doesn't start.  It dumps 
core.  When I rem out the LoadModule directive for the php module in httpd.conf, 
Apache starts up fine.

[ FYI: it's MySQL 3.23.34a (--prefix=/opt/mysql --with-pthreads) ]

Any suggections on how to troubleshoot it ?  If you have a use for the core, I can 
send it to you.  More info:

RS/6000-43P/132
AIX 4.3.3 (maintenance update 8)
gcc-2.95.3

Only other software installed on the system is GNU make-3.79.1 and bash-2.04.

Any help is greatly appreciated.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10945&edit=2


-- 
PHP Development Mailing List 
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 ?

[Sterling Hughes]

>>fread() should handle this, no?
>>
> 
> 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.)

Perhaps automatic detection could be option?  if (filesize > X) 
blockread else mmap?  It seems like the most intuitive way to implement 
it...

I also wrestled with a configure option use_mmap (which might be good in 
general), however, that really doesn't solve the problem at hand.

-Sterling



-- 
PHP Development Mailing List 
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 #10945 Updated: Apache core dumps when PHP4.0.5 is activated via LoadModule

[morgan]

ID: 10945
User Update by: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Apache related
Operating system: AIX 4.3.3 (MU8)
PHP Version: 4.0.5
Description: Apache core dumps when PHP4.0.5 is activated via LoadModule

Tried recompiling everything with IBM Visual Age C v5.01.  No change.  I also tried 
linking with the pthread library for the httpd binary, like [EMAIL PROTECTED] said to 
try, but no luck.  Quick question: is AIX on the "supported" list ??  Is this supposed 
to work ??

--Morgan
[EMAIL PROTECTED]

Previous Comments:
---

[2001-05-17 21:49:55] [EMAIL PROTECTED]
On systems that use glibc-2.1.x there is a bug in glibc that prevents a binary not 
linked against pthreads to dynamically load a shared library that is linked against 
pthreads.  Perhaps this problem also exists on AIX?  Try linking your Apache httpd 
against libpthreads.

---

[2001-05-17 20:57:44] [EMAIL PROTECTED]
Apache-1.3.19 compiles clean under gcc-2.95.3 with:

$ ./configure --prefix=/opt/apache --enable-module=so

$ make

# make install


Apache starts cleanly and generally works fine.

PHP4.0.5 compiles clean under gcc-2.95.3 with:

$ ./configure --prefix=/opt/php --with-apxs=/opt/apache/bin/apxs 
--with-mysql=/opt/mysql

$ make

# make install


Howver when I stop Apache and start it back up again, it doesn't start.  It dumps 
core.  When I rem out the LoadModule directive for the php module in httpd.conf, 
Apache starts up fine.

[ FYI: it's MySQL 3.23.34a (--prefix=/opt/mysql --with-pthreads) ]

Any suggections on how to troubleshoot it ?  If you have a use for the core, I can 
send it to you.  More info:

RS/6000-43P/132
AIX 4.3.3 (maintenance update 8)
gcc-2.95.3

Only other software installed on the system is GNU make-3.79.1 and bash-2.04.

Any help is greatly appreciated.

---


Full Bug description available at: http://bugs.php.net/?id=10945


-- 
PHP Development Mailing List 
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]

> >>>If a system has mmap() a readfile() will mmap the entire file to memory
> >>>and then dump that while without mmap it will read it one block at a time.
> >>>That's a siginificant memory difference and one that may not be expected.
> >>>
> >>>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.  Since readfile() already has an opotional argument I
> >>>think the right approach is a separate function that turns the mmap off
> >>>and reads the file block by block.  fpassthru() doesn't have an optional
> >>>arg, so we could toggle it there for that function.
> >>>
> >>>Comments?
> >>>
> >>>
> >>
> >>Well, out of the solutions, I think the optional argument to fpassthru()
> >>would be the best.  However, why not, as you stated in response to the
> >>bug report, read the file with a custom function and output it,
> >>therefore avoiding the mmap() as well?
> >>
> >
> > Well, the one problem with that is that it can be very inefficient because
> > it stops reading when it hits a newline and you end up always reading
> > partial buffers if the file has newlines in it.  Having a function that
> > quickly reads/dumps a file block by block would make this much more
> > efficient.
> >
>
> fread() should handle this, no?

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.

-Rasmus


-- 
PHP Development Mailing List 
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 ?

[Sterling Hughes]

Rasmus Lerdorf wrote:

>>>If a system has mmap() a readfile() will mmap the entire file to memory
>>>and then dump that while without mmap it will read it one block at a time.
>>>That's a siginificant memory difference and one that may not be expected.
>>>
>>>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.  Since readfile() already has an opotional argument I
>>>think the right approach is a separate function that turns the mmap off
>>>and reads the file block by block.  fpassthru() doesn't have an optional
>>>arg, so we could toggle it there for that function.
>>>
>>>Comments?
>>>
>>>
>>
>>Well, out of the solutions, I think the optional argument to fpassthru()
>>would be the best.  However, why not, as you stated in response to the
>>bug report, read the file with a custom function and output it,
>>therefore avoiding the mmap() as well?
>>
> 
> Well, the one problem with that is that it can be very inefficient because
> it stops reading when it hits a newline and you end up always reading
> partial buffers if the file has newlines in it.  Having a function that
> quickly reads/dumps a file block by block would make this much more
> efficient.
> 


fread() should handle this, no?

-Sterling



-- 
PHP Development Mailing List 
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

[Rasmus Lerdorf]

> Well, the reason I stayed away from trying to use fgets for a single block
> at a time were because of some of the comments from
> http://php.net/manual/en/function.fgets.php
>
> Anyways, an offtopic question if I may, I've tried making .htaccess
> parseable by PHP using AddType and also attempting to do it by making
> .htaccess a PHP-CGI file, to no avail. Is this something that is possible to
> do with PHP? I have seen examples where mod_perl is used to generate
> .htaccess files on the fly but nothing when it comes to PHP. If there is any
> documentation in this are I would really be keen to see it.

Why would you have PHP parse a .htaccess file?  That makes no sense.
.htaccess files are parsed by Apache even on php requests.

What I was saying is that you would generate the .htacess whenever the
header information needs to change and when the user requests a file, it
will be sent directly by Apache with mod_headers applying the custom
headers.  There is no PHP involved in this.

-Rasmus


-- 
PHP Development Mailing List 
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

[Rasmus Lerdorf]

> 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.

-Rasmus


-- 
PHP Development Mailing List 
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

[Stephen VanDyke]

Well, the reason I stayed away from trying to use fgets for a single block
at a time were because of some of the comments from
http://php.net/manual/en/function.fgets.php

Anyways, an offtopic question if I may, I've tried making .htaccess
parseable by PHP using AddType and also attempting to do it by making
.htaccess a PHP-CGI file, to no avail. Is this something that is possible to
do with PHP? I have seen examples where mod_perl is used to generate
.htaccess files on the fly but nothing when it comes to PHP. If there is any
documentation in this are I would really be keen to see it.

-Stephen

-Original Message-
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 12:56 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Bug #10701 Updated: readfile usage on large files


Well, you'd want to do it one block at a time.  But yes, if you are going
to be reading the files with PHP that's what you'll end up doing at some
level anyway.  Otherwise look at Apache's mod_header and perhaps
dynamically generate the header information and write the appropriate
.htaccess files or something...  But now we are well beyond having
anything to do with PHP.

-Rasmus

On 18 May 2001 [EMAIL PROTECTED] wrote:

> ID: 10701
> User Update by: [EMAIL PROTECTED]
> Status: Closed
> Bug Type: Filesystem function related
> Operating system: Linux 2.4.x
> PHP Version: 4.0.5
> Description: readfile usage on large files
>
> 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);
>
> Previous Comments:
> --
-
>
> [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:
>
>  $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 :)
>
> --
-
>
>
> Full Bug description available at: http://bugs.php.net/?id=10701
>
>
>



-- 
PHP Development Mailing List 
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]

> > If a system has mmap() a readfile() will mmap the entire file to memory
> > and then dump that while without mmap it will read it one block at a time.
> > That's a siginificant memory difference and one that may not be expected.
> >
> > 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.  Since readfile() already has an opotional argument I
> > think the right approach is a separate function that turns the mmap off
> > and reads the file block by block.  fpassthru() doesn't have an optional
> > arg, so we could toggle it there for that function.
> >
> > Comments?
> >
>
>
> Well, out of the solutions, I think the optional argument to fpassthru()
> would be the best.  However, why not, as you stated in response to the
> bug report, read the file with a custom function and output it,
> therefore avoiding the mmap() as well?

Well, the one problem with that is that it can be very inefficient because
it stops reading when it hits a newline and you end up always reading
partial buffers if the file has newlines in it.  Having a function that
quickly reads/dumps a file block by block would make this much more
efficient.

-Rasmus


-- 
PHP Development Mailing List 
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

[John Donagher]

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 
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 ?

[Sterling Hughes]

Rasmus Lerdorf wrote:

> If a system has mmap() a readfile() will mmap the entire file to memory
> and then dump that while without mmap it will read it one block at a time.
> That's a siginificant memory difference and one that may not be expected.
> 
> 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.  Since readfile() already has an opotional argument I
> think the right approach is a separate function that turns the mmap off
> and reads the file block by block.  fpassthru() doesn't have an optional
> arg, so we could toggle it there for that function.
> 
> Comments?
> 


Well, out of the solutions, I think the optional argument to fpassthru() 
would be the best.  However, why not, as you stated in response to the 
bug report, read the file with a custom function and output it, 
therefore avoiding the mmap() as well?

-Sterling


-- 
PHP Development Mailing List 
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

[Rasmus Lerdorf]

Well, you'd want to do it one block at a time.  But yes, if you are going
to be reading the files with PHP that's what you'll end up doing at some
level anyway.  Otherwise look at Apache's mod_header and perhaps
dynamically generate the header information and write the appropriate
.htaccess files or something...  But now we are well beyond having
anything to do with PHP.

-Rasmus

On 18 May 2001 [EMAIL PROTECTED] wrote:

> ID: 10701
> User Update by: [EMAIL PROTECTED]
> Status: Closed
> Bug Type: Filesystem function related
> Operating system: Linux 2.4.x
> PHP Version: 4.0.5
> Description: readfile usage on large files
>
> 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);
>
> Previous Comments:
> ---
>
> [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:
>
>  $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 :)
>
> ---
>
>
> Full Bug description available at: http://bugs.php.net/?id=10701
>
>
>


-- 
PHP Development Mailing List 
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 #10701 Updated: readfile usage on large files

[stephen]

ID: 10701
User Update by: [EMAIL PROTECTED]
Status: Closed
Bug Type: Filesystem function related
Operating system: Linux 2.4.x
PHP Version: 4.0.5
Description: readfile usage on large files

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);

Previous Comments:
---

[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:

 '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 :)

---


Full Bug description available at: http://bugs.php.net/?id=10701


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] mmap in php_passthru_fd in file.c ?

[Rasmus Lerdorf]

If a system has mmap() a readfile() will mmap the entire file to memory
and then dump that while without mmap it will read it one block at a time.
That's a siginificant memory difference and one that may not be expected.

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.  Since readfile() already has an opotional argument I
think the right approach is a separate function that turns the mmap off
and reads the file block by block.  fpassthru() doesn't have an optional
arg, so we could toggle it there for that function.

Comments?

-Rasmus


-- 
PHP Development Mailing List 
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

[Gavin Sherry]

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
> 
> 
> 
> 



-- 
PHP Development Mailing List 
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 #10701 Updated: readfile usage on large files

[rasmus]

ID: 10701
Updated by: rasmus
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Filesystem function related
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

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.

Previous Comments:
---

[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:

 '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=10701&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] New: MLM SURVEY RESULTS

[mlm_update20049s]

Choose From Any Of The Following:
Promote your Existing Business Or Make Money With One Of Our!

Choose From The 2 Below If You Have An Existing Business

Choice 1: GUARANTEEd ... 1,000,000 Banner IMPRESSIONS!!
FIND OUT WHAT THE PROS HAVE BEEN DOING FOR YEARS!!
NOW AVAILABLE TO EVERYONE!! Promote Your Existing Site To Millions!!
http://www.geocities.com/banner1011b/


Choice 2: PRE-QULIFIED NETWORK MARKETER LEADS FOR YOUR BUSINESS!
SALE PRICES ALL THIS WEEK!
SHARE WITH YOUR ENTIRE DOWNLINE FOR GUARANTEED SUCCESS!
http://www.geocities.com/leadorders1011b/

OR...

Choose From The Following 2 If You Are Looking For A New Business Opportunity:

PLUG INTO THE PROVEN SYSTEM, THEY GUARANTEE YOU SUCCESS, 
AND PROVIDE YOU WITH FREE LEADS TO BUILD YOUR GROUP!!
http://www.geocities.com/netmarket1011b/

$4000 Your First Week, Following Our Lead, And Letting Us Do All Your
Sales Calls With YOu.  Leverage Just $500 Into $4000 YOur First Week,
To Well Over $40,000 Your First Month!!
http://www.geocities.com/gifting1011b/







*
THIS EMAIL COMPLIES WITH ALL REGULATIONS.  TO BE REMOVED WITHIN 
24 Hours, SIMPLYEMAIL [EMAIL PROTECTED] FOR IMMEDIATE 
REMOVAL FROM ANY FUTURE EMAILS FROM OUR COMPANY.
*


-- 
PHP Development Mailing List 
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 #10947: socket compile error for apache compiling

[konlo]

From: [EMAIL PROTECTED]
Operating system: SunOS 5.6
PHP version:  4.0.5
PHP Bug Type: Apache related
Bug description:  socket compile error for apache compiling

I compile php with --enable-sockets . The compile is finished successfully, but on 
compiling apache , 

this error message is reported in console 

how do I resolve this problem ?  

===> src/modules/php4
gcc -c  -I../../os/unix -I../../include   -DSOLARIS2=260 
-I/user1/konlo/install_apache/php-4.0.5 -I/user1/konlo/install_apache/php-4.0.5/main 
-I/user1/konlo/install_apache/php-4.0.5/main 
-I/user1/konlo/install_apache/php-4.0.5/Zend 
-I/user1/konlo/install_apache/php-4.0.5/Zend 
-I/user1/konlo/install_apache/php-4.0.5/TSRM 
-I/user1/konlo/install_apache/php-4.0.5/TSRM -I/user1/konlo/install_apache/php-4.0.5 
-DUSE_EXPAT -I../../lib/expat-lite -DNO_DL_NEEDED `../../apaci`  mod_php4.c
cp libmodphp4.a libphp4.a
ar r libphp4.a mod_php4.o
ranlib libphp4.a
<=== src/modules/php4
<=== src/modules
gcc -c  -I./os/unix -I./include   -DSOLARIS2=260 
-I/user1/konlo/install_apache/php-4.0.5 -I/user1/konlo/install_apache/php-4.0.5/main 
-I/user1/konlo/install_apache/php-4.0.5/main 
-I/user1/konlo/install_apache/php-4.0.5/Zend 
-I/user1/konlo/install_apache/php-4.0.5/Zend 
-I/user1/konlo/install_apache/php-4.0.5/TSRM 
-I/user1/konlo/install_apache/php-4.0.5/TSRM -I/user1/konlo/install_apache/php-4.0.5 
-DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci` modules.c
gcc -c  -I./os/unix -I./include   -DSOLARIS2=260 
-I/user1/konlo/install_apache/php-4.0.5 -I/user1/konlo/install_apache/php-4.0.5/main 
-I/user1/konlo/install_apache/php-4.0.5/main 
-I/user1/konlo/install_apache/php-4.0.5/Zend 
-I/user1/konlo/install_apache/php-4.0.5/Zend 
-I/user1/konlo/install_apache/php-4.0.5/TSRM 
-I/user1/konlo/install_apache/php-4.0.5/TSRM -I/user1/konlo/install_apache/php-4.0.5 
-DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci` buildmark.c
gcc  -DSOLARIS2=260 -I/user1/konlo/install_apache/php-4.0.5 
-I/user1/konlo/install_apache/php-4.0.5/main 
-I/user1/konlo/install_apache/php-4.0.5/main 
-I/user1/konlo/install_apache/php-4.0.5/Zend 
-I/user1/konlo/install_apache/php-4.0.5/Zend 
-I/user1/konlo/install_apache/php-4.0.5/TSRM 
-I/user1/konlo/install_apache/php-4.0.5/TSRM -I/user1/konlo/install_apache/php-4.0.5 
-DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci`\
  -o httpd buildmark.o modules.o  modules/php4/libphp4.a  
modules/standard/libstandard.a  main/libmain.a  ./os/unix/libos.a  ap/libap.a  
lib/expat-lite/libexpat.a  -R/usr/ucblib 
-R/usr/local/lib/gcc-lib/sparc-sun-sunos5.6/2.95.2  -L/usr/ucblib 
-L/usr/local/lib/gcc-lib/sparc-sun-sunos5.6/2.95.2 -Lmodules/php4 -L../modules/php4 
-L../../modules/php4 -lmodphp4  -lpam  -ldl -lresolv -lresolv -lm -ldl -lcrypt -lnsl 
-lsocket  -lsocket -lgcc   -lsocket -lnsl
Undefined   first referenced
 symbol in file
hstrerror   modules/php4/libphp4.a(sockets.o)
ld: Ä¡¸íÀû: ±âÈ£ ÂüÁ¶ ¿À·ù. httpd¿¡ Ãâ·ÂÀÌ ±â·ÏµÇÁö ¾ÊÀ½
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `target_static'
Current working directory /user1/konlo/install_apache/apache_1.3.19/src
*** Error code 1
make: Fatal error: Command failed for target `build-std'
Current working directory /user1/konlo/install_apache/apache_1.3.19
*** Error code 1
make: Fatal error: Command failed for target `build'



-- 
Edit Bug report at: http://bugs.php.net/?id=10947&edit=1



-- 
PHP Development Mailing List 
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

[Brian Moon]

That may be the worst done article I have ever read.  I could rewrite every
paragraph and turn it on ASP or Perl or any language.  He obviously did not
put much effort into it.

My Take:

"The Unix version of ASP, unfortunately, cannot be taken seriously as it
does not exist except in a very expensive form from ChiliSoft.  We scanned
the web for comments on IIS and commonly found that there are built in back
doors that allow everyone in the world to see your code.

"ASP uses some sort of home rolled database abstraction layer that limits
the use of key features of most databases and turns them all into simplified
useless tools."

Brian Moon
--
dealnews.com, Inc.
Makers of dealnews, dealmac
http://dealnews.com/ | http://dealmac.com/


- Original Message -
From: "Emmanuel FAIVRE" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 17, 2001 5:22 PM
Subject: [PHP-DEV] Zdnet Article


> 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
>
>
>
> --
> PHP Development Mailing List 
> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS Account Request

[CVS Account Request]

Full name: liujian
Email: [EMAIL PROTECTED]
ID: xliu
Purpose: learn php

-- 
PHP Development Mailing List 
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: mail() Failed: Server Error

[Jeff . Zhu]

From: [EMAIL PROTECTED]
Operating system: Win2000
PHP version:  4.0.5
PHP Bug Type: IIS related
Bug description:  mail() Failed: Server Error

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?


-- 
Edit Bug report at: http://bugs.php.net/?id=10946&edit=1



-- 
PHP Development Mailing List 
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 #10945 Updated: Apache core dumps when PHP4.0.5 is activated via LoadModule

[rasmus]

ID: 10945
Updated by: rasmus
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Analyzed
Bug Type: Apache related
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

On systems that use glibc-2.1.x there is a bug in glibc that prevents a binary not 
linked against pthreads to dynamically load a shared library that is linked against 
pthreads.  Perhaps this problem also exists on AIX?  Try linking your Apache httpd 
against libpthreads.

Previous Comments:
---

[2001-05-17 20:57:44] [EMAIL PROTECTED]
Apache-1.3.19 compiles clean under gcc-2.95.3 with:

$ ./configure --prefix=/opt/apache --enable-module=so

$ make

# make install


Apache starts cleanly and generally works fine.

PHP4.0.5 compiles clean under gcc-2.95.3 with:

$ ./configure --prefix=/opt/php --with-apxs=/opt/apache/bin/apxs 
--with-mysql=/opt/mysql

$ make

# make install


Howver when I stop Apache and start it back up again, it doesn't start.  It dumps 
core.  When I rem out the LoadModule directive for the php module in httpd.conf, 
Apache starts up fine.

[ FYI: it's MySQL 3.23.34a (--prefix=/opt/mysql --with-pthreads) ]

Any suggections on how to troubleshoot it ?  If you have a use for the core, I can 
send it to you.  More info:

RS/6000-43P/132
AIX 4.3.3 (maintenance update 8)
gcc-2.95.3

Only other software installed on the system is GNU make-3.79.1 and bash-2.04.

Any help is greatly appreciated.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10945&edit=2


-- 
PHP Development Mailing List 
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 #10929 Updated: got "segmentation fault" after successful compile

[sniper]

ID: 10929
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Apache related
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

Try getting fresh sources for Apache
and try again..

--Jani


Previous Comments:
---

[2001-05-17 12:05:13] [EMAIL PROTECTED]
cd /usr/src/apache_1.3.19
./configure --prefix=/www
cd  ../php-4.0.5
./configure --with-mysql=/usr/local/ --with-oracle=/home/oracle/OraHome1/ 
--with-apache=../apache_1.3.19 --enable-sigchild --enable-track-vars
make
make install
cd ../apache_1.3.19
./configure --activate-module=src/modules/php4/libphp4.a
make
make install

All of this didn't produce any errors. After trying to start apache (it was down all 
the time) with
/usr/local/apache/bin/apachectl start
I got "segmentation fault"
I checked, that was newly compiled apache.

Just for reference, version 4.0.4 with same parameters is compiled and it is runing 
just OK


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10929&edit=2


-- 
PHP Development Mailing List 
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 #10945: Apache core dumps when PHP4.0.5 is activated via LoadModule

[morgan]

From: [EMAIL PROTECTED]
Operating system: AIX 4.3.3 (MU8)
PHP version:  4.0.5
PHP Bug Type: Apache related
Bug description:  Apache core dumps when PHP4.0.5 is activated via LoadModule

Apache-1.3.19 compiles clean under gcc-2.95.3 with:

$ ./configure --prefix=/opt/apache --enable-module=so

$ make

# make install


Apache starts cleanly and generally works fine.

PHP4.0.5 compiles clean under gcc-2.95.3 with:

$ ./configure --prefix=/opt/php --with-apxs=/opt/apache/bin/apxs 
--with-mysql=/opt/mysql

$ make

# make install


Howver when I stop Apache and start it back up again, it doesn't start.  It dumps 
core.  When I rem out the LoadModule directive for the php module in httpd.conf, 
Apache starts up fine.

[ FYI: it's MySQL 3.23.34a (--prefix=/opt/mysql --with-pthreads) ]

Any suggections on how to troubleshoot it ?  If you have a use for the core, I can 
send it to you.  More info:

RS/6000-43P/132
AIX 4.3.3 (maintenance update 8)
gcc-2.95.3

Only other software installed on the system is GNU make-3.79.1 and bash-2.04.

Any help is greatly appreciated.


-- 
Edit Bug report at: http://bugs.php.net/?id=10945&edit=1



-- 
PHP Development Mailing List 
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 #10917: deal with the BLOB data

[Brian Foddy]

What I've found works very well for my apps is to
Base64 encode the data then store it in a text field.
It expands by a few percent but compared to the Sybase
inefficiency of using the Blob/Text fields in the first
place (they only allocate in 2K chunks) its not too serious.



On 17 May 2001 04:36:50 -, [EMAIL PROTECTED] wrote:

>From: [EMAIL PROTECTED]
>Operating system: AIX4.3
>PHP version:  4.0.4
>PHP Bug Type: Sybase (dblib) related
>Bug description:  deal with the BLOB data
>
>PHP has some functon to deal with BLOB data for Oracle,but
>how can I deal with BLOB data for Sybase? Are there  some functions?
>I tried with Sybase's function,but after that ,there are some error message like 
>"Cannot add header information--
headers already sent by ".How can I do now?
>
>
>-- 
>Edit Bug report at: http://bugs.php.net/?id=10917&edit=1
>
>
>
>-- 
>PHP Development Mailing List 
>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 
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 #10944: hw_info() prints garbage for server string

[torben]

From: [EMAIL PROTECTED]
Operating system: Linux 2.2.14/Mandrake 7
PHP version:  4.0 Latest CVS (2001-05-17)
PHP Bug Type: Hyperwave related
Bug description:  hw_info() prints garbage for server string

hw_info() is printing some random garbage for the server string:

„̏***, localhost, 717, anonymous, 7175, 0

Looking at the source it seems that the server string is never getting set properly 
when the connection is made
in hg_comm.c, but I don't have time to track this down today.

Torben


-- 
Edit Bug report at: http://bugs.php.net/?id=10944&edit=1



-- 
PHP Development Mailing List 
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 #10936 Updated: DOMXML crash with CDATA

[matthew . kane]

ID: 10936
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: Reproducible crash
Operating system: Win2K Pro
PHP Version: 4.0.5
Description: DOMXML crash with CDATA

Not in the binaries in 
http://www.php.net/do_download.php?download_file=php-4.0.5-Win32.zip&source_site=www.php.net.


The children property returns NULL in all cases. The children method works correctly 
unless one of the children is a CDATA node.

The source code in 
http://www.php.net/do_download.php?download_file=php-4.0.5.tar.gz&source_site=www.php.net
 shows children as a method and not as a property.

Previous Comments:
---

[2001-05-17 17:59:27] [EMAIL PROTECTED]
domxml has changed from children being a method to being a member. Try $children = 
$root->children

---

[2001-05-17 13:21:56] [EMAIL PROTECTED]
I am running the latest Win32 binaries from the php.net download page. I am using the 
ISAPI module on IIS5. In php.ini I enabled DOMXML by uncommenting the appropriate 
line.

Calling the children function on a node that has a CDATA node as a child results in an 
access violation. Here's a script that reproduces the problem:

$doc = xmldocfile('http://tbhbuilding.blogspot.com');
$root = $doc->root();
$children = $root->children();
$children = $children[1]->children();
print_r($children[1]->children());

I would have generated a gdb backtrace if the instructions for doing so explained how 
to do it with the ISAPI module.


---


Full Bug description available at: http://bugs.php.net/?id=10936


-- 
PHP Development Mailing List 
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

[Nick Loman]

"get some skills" please ZDNet - that has to be one of the poorest reviews
of anything on any platform ever.

No comments system either -- probably using BroadVision :/

Is there a php-advocacy list? I'm getting sick of having to explain
exactly why PHP is better than ColdFusion et al. It would be good to
co-ordinate efforts :)

Nick.



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
> 
> 
> 
> -- 
> PHP Development Mailing List 
> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] setting open_basedir and include_path from environment variables

[Egan]

Hi,

In main.c there are some comments about setting include_path from an
environment variable called PHP_INCLUDE_PATH, but it appears this is a
future todo.

I need to patch my local source to do that, but I don't see in the
source where the values are being read from the .ini file; presumably
I need to read my environment variable and override the .ini values
immediately after that.

Can anyone tell me where to look in the source to find the values
being set from the .ini file?



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Zdnet Article

[Emmanuel FAIVRE]

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



-- 
PHP Development Mailing List 
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 #10943 Updated: After a migration from php4.0.4 to php4.0.5

[derick]

ID: 10943
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: PWS related
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

You need to provide some more information, so that we can
see what goes wrong, and how to fix it.

Previous Comments:
---

[2001-05-17 17:57:25] [EMAIL PROTECTED]
After a migration from php 4.0.4 to php 4.0.5, my personal web server(PWS)doesn't work 
with php pages. Is there any solutions to this problem ?

Thank you for your answers.


 Impossible d'afficher la page
Il y a un problème avec la page que vous essayez d'atteindre ; elle ne peut
pas être affichée.


Essayez de la manière suivante :
Ouvrez la page de démarrage localhost et recherchez des liens vers les
informations voulues.
Cliquez sur le bouton  Actualiser ou réessayez ultérieurement.

Cliquez sur  Rechercher pour trouver des informations sur Internet.
Vous pouvez également voir une liste de sites apparentés.

HTTP 500 - Erreur interne de serveur
Internet Explorer










---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10943&edit=2


-- 
PHP Development Mailing List 
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 #10936 Updated: DOMXML crash with CDATA

[lyric]

ID: 10936
Updated by: lyric
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Reproducible crash
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

domxml has changed from children being a method to being a member. Try $children = 
$root->children

Previous Comments:
---

[2001-05-17 13:21:56] [EMAIL PROTECTED]
I am running the latest Win32 binaries from the php.net download page. I am using the 
ISAPI module on IIS5. In php.ini I enabled DOMXML by uncommenting the appropriate 
line.

Calling the children function on a node that has a CDATA node as a child results in an 
access violation. Here's a script that reproduces the problem:

$doc = xmldocfile('http://tbhbuilding.blogspot.com');
$root = $doc->root();
$children = $root->children();
$children = $children[1]->children();
print_r($children[1]->children());

I would have generated a gdb backtrace if the instructions for doing so explained how 
to do it with the ISAPI module.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10936&edit=2


-- 
PHP Development Mailing List 
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 #10943: After a migration from php4.0.4 to php4.0.5

[bmarty]

From: [EMAIL PROTECTED]
Operating system: WINDOWS 98
PHP version:  4.0.5
PHP Bug Type: PWS related
Bug description:  After a migration from php4.0.4 to php4.0.5

After a migration from php 4.0.4 to php 4.0.5, my personal web server(PWS)doesn't work 
with php pages. Is there any solutions to this problem ?

Thank you for your answers.


 Impossible d'afficher la page
Il y a un problème avec la page que vous essayez d'atteindre ; elle ne peut
pas être affichée.


Essayez de la manière suivante :
Ouvrez la page de démarrage localhost et recherchez des liens vers les
informations voulues.
Cliquez sur le bouton  Actualiser ou réessayez ultérieurement.

Cliquez sur  Rechercher pour trouver des informations sur Internet.
Vous pouvez également voir une liste de sites apparentés.

HTTP 500 - Erreur interne de serveur
Internet Explorer











-- 
Edit Bug report at: http://bugs.php.net/?id=10943&edit=1



-- 
PHP Development Mailing List 
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

[derick]

ID: 10890
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Analyzed
Status: Closed
Bug Type: mcrypt related
Operating system: 
PHP Version: 4.0.5
Assigned To: derick
Comments:

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.

Previous Comments:
---

[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:


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

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10890&edit=2


-- 
PHP Development Mailing List 
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 #9801 Updated: mcrypt_encrypt dumps core

[derick]

ID: 9801
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Analyzed
Status: Closed
Bug Type: mcrypt related
Operating system: 
PHP Version: 4.0 Latest CVS (16/03/2001)
Assigned To: derick
Comments:

Ok, this was indeed the problem. Thanks for this excellent help!

Derick

Previous Comments:
---

[2001-05-17 16:37:11] [EMAIL PROTECTED]
Hello,

looks all ok. I'll check it out, and apply the patch (if ok) so that it will be fixed 
in PHP 4.0.6

Derick

---

[2001-05-17 16:16:59] [EMAIL PROTECTED]
I think I've found the problem (and the solution).

Let's look at some functions found in mcrypt first...

File: mcrypt_modules.c

int mcrypt_module_close(MCRYPT td)
{

lt_dlclose(td->algorithm_handle);
lt_dlclose(td->mode_handle);
lt_dlexit();

td->algorithm_handle = NULL;
td->mode_handle = NULL;

td->m_encrypt = NULL;
td->a_encrypt = NULL;
td->a_decrypt = NULL;
td->m_decrypt = NULL;

free(td);

return 0;
}

File: mcrypt.c

int mcrypt_generic_end(const MCRYPT td)
{
internal_end_mcrypt(td);
mcrypt_module_close(td);
return 0;
}

The crash occurs when the call free(td) is made in mcrypt_module_close(MCRYPT td)

Notice that mcrypt_generic_end(const MCRYPT td) calls mcrypt_module_close(MCRYPT td) 
in the end.

Let's look at the mcrypt.c file from PHP (NOT the same one as above). It has a 
function called

php_mcrypt_do_crypt(char* cipher, zval **key, zval **data, char *mode, zval **iv, int 
argc, int dencrypt, zval* return_value)

At the end of the function, we find the following:

/* freeing vars */
mcrypt_generic_end (td);
if (key_s != NULL)
efree (key_s);
if (iv_s != NULL)
efree (iv_s);
efree (data_s);
mcrypt_module_close (td);
}

The crash occurs when the final mcrypt_module_close is called.

The reason is that the call to mcrypt_generic_end (td) also calls 
mcrypt_module_close(td) that again calls free (td). When we later call 
mcrypt_module_close (td) we try to free td again, and that sometimes gives us a 
segmentation fault.

The solution is simply to delete the last line in the php_mcrypt_do_crypt function 
(mcrypt_module_close (td);) found in mcrypt.c. This is ok, since we have already freed 
td in the call to mcrypt_generic_end (td) a few lines above.

That solved the problems for me. Finally no more crashes :)

---

[2001-04-10 13:58:16] [EMAIL PROTECTED]
Crashes for me too, possibly a bug in mcrypt it self. Trying more things...

---

[2001-04-10 13:01:24] [EMAIL PROTECTED]
Actually, the script only seems to dump core if I do:

echo bin2hex($output);

after the encryption.  Just a simple:

echo $output;

seems to work just fine (i.e. it outputs stuff).

- Colin

---

[2001-04-10 12:59:24] [EMAIL PROTECTED]
This happens for me too with today's CVS and the latest CVS of mcrypt.

Backtrace says:

#0  0x402c89bc in chunk_free (ar_ptr=0x40369680, p=0x81f7f00) at malloc.c:3152
3152malloc.c: No such file or directory.
(gdb) bt
#0  0x402c89bc in chunk_free (ar_ptr=0x40369680, p=0x81f7f00) at malloc.c:3152
#1  0x402c8828 in __libc_free (mem=0x81f7f08) at malloc.c:3054
#2  0x400a650d in mcrypt_module_close (td=0x81f7f08) at mcrypt_modules.c:48
#3  0x807c1e7 in php_mcrypt_do_crypt (cipher=0x81f7e94 "rijndael-256", key=0x81f2118, 
data=0x81f211c, 
mode=0x818174c "cbc", iv=0x81f2124, argc=5, dencrypt=0, return_value=0x81f7ef4) at 
mcrypt.c:1317
#4  0x807c576 in php_if_mcrypt_encrypt (ht=5, return_value=0x81f7ef4, this_ptr=0x0, 
return_value_used=1)
at mcrypt.c:1334
#5  0x81228e6 in execute (op_array=0x81f37dc) at ./zend_execute.c:1494
#6  0x80f3fcd in zend_execute_scripts (type=8, file_count=3) at zend.c:743
#7  0x8069c8f in php_execute_script (primary_file=0xba60) at main.c:1196
#8  0x8067fa4 in main (argc=2, argv=0xbb04) at cgi_main.c:731
#9  0x4026ab5c in __libc_start_main (main=0x8067830 , argc=2, ubp_av=0xbb04, 
init=0x8064b8c <_init>, 
fini=0x81362ec <_fini>, rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xbafc)
at ../sysdeps/generic/libc-start.c:129

Assigning it to the expert ... :)

---

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=9801&edit=2


-- 
PHP Developme

[PHP-DEV] Bug #10701 Updated: readfile usage on large files

[stephen]

ID: 10701
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Filesystem function related
Operating system: Linux 2.4.x
PHP Version: 4.0.5
Description: readfile usage on large files

Anyone plan on claiming this?

Previous Comments:
---

[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:

 '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 :)

---


Full Bug description available at: http://bugs.php.net/?id=10701


-- 
PHP Development Mailing List 
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 #10942 Updated:

[derick]

ID: 10942
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: GetImageSize related
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

Hello,

please provide some more information about this. And there
has been some fix for the GetImageSize function again (broken
jpeg size detection). Can you please check a snapshot from
snaps.php.net?)

Derick

Previous Comments:
---

[2001-05-17 17:23:44] [EMAIL PROTECTED]


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10942&edit=2


-- 
PHP Development Mailing List 
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 #10942:

[eschein]

From: [EMAIL PROTECTED]
Operating system: redhat 7
PHP version:  4.0.5
PHP Bug Type: GetImageSize related
Bug description:  




-- 
Edit Bug report at: http://bugs.php.net/?id=10942&edit=1



-- 
PHP Development Mailing List 
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

[derick]

ID: 10890
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Analyzed
Bug Type: mcrypt related
Operating system: 
PHP Version: 4.0.5
Assigned To: derick
Comments:

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

Previous Comments:
---

[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:


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

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10890&edit=2


-- 
PHP Development Mailing List 
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

[henrik_l]

ID: 10890
User Update by: [EMAIL PROTECTED]
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 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.

Previous Comments:
---

[2001-05-15 17:48:17] [EMAIL PROTECTED]
If i try to run this script:


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 
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 #9801 Updated: mcrypt_encrypt dumps core

[derick]

ID: 9801
Updated by: derick
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: mcrypt related
Operating system: 
PHP Version: 4.0 Latest CVS (16/03/2001)
Assigned To: derick
Comments:

Hello,

looks all ok. I'll check it out, and apply the patch (if ok) so that it will be fixed 
in PHP 4.0.6

Derick

Previous Comments:
---

[2001-05-17 16:16:59] [EMAIL PROTECTED]
I think I've found the problem (and the solution).

Let's look at some functions found in mcrypt first...

File: mcrypt_modules.c

int mcrypt_module_close(MCRYPT td)
{

lt_dlclose(td->algorithm_handle);
lt_dlclose(td->mode_handle);
lt_dlexit();

td->algorithm_handle = NULL;
td->mode_handle = NULL;

td->m_encrypt = NULL;
td->a_encrypt = NULL;
td->a_decrypt = NULL;
td->m_decrypt = NULL;

free(td);

return 0;
}

File: mcrypt.c

int mcrypt_generic_end(const MCRYPT td)
{
internal_end_mcrypt(td);
mcrypt_module_close(td);
return 0;
}

The crash occurs when the call free(td) is made in mcrypt_module_close(MCRYPT td)

Notice that mcrypt_generic_end(const MCRYPT td) calls mcrypt_module_close(MCRYPT td) 
in the end.

Let's look at the mcrypt.c file from PHP (NOT the same one as above). It has a 
function called

php_mcrypt_do_crypt(char* cipher, zval **key, zval **data, char *mode, zval **iv, int 
argc, int dencrypt, zval* return_value)

At the end of the function, we find the following:

/* freeing vars */
mcrypt_generic_end (td);
if (key_s != NULL)
efree (key_s);
if (iv_s != NULL)
efree (iv_s);
efree (data_s);
mcrypt_module_close (td);
}

The crash occurs when the final mcrypt_module_close is called.

The reason is that the call to mcrypt_generic_end (td) also calls 
mcrypt_module_close(td) that again calls free (td). When we later call 
mcrypt_module_close (td) we try to free td again, and that sometimes gives us a 
segmentation fault.

The solution is simply to delete the last line in the php_mcrypt_do_crypt function 
(mcrypt_module_close (td);) found in mcrypt.c. This is ok, since we have already freed 
td in the call to mcrypt_generic_end (td) a few lines above.

That solved the problems for me. Finally no more crashes :)

---

[2001-04-10 13:58:16] [EMAIL PROTECTED]
Crashes for me too, possibly a bug in mcrypt it self. Trying more things...

---

[2001-04-10 13:01:24] [EMAIL PROTECTED]
Actually, the script only seems to dump core if I do:

echo bin2hex($output);

after the encryption.  Just a simple:

echo $output;

seems to work just fine (i.e. it outputs stuff).

- Colin

---

[2001-04-10 12:59:24] [EMAIL PROTECTED]
This happens for me too with today's CVS and the latest CVS of mcrypt.

Backtrace says:

#0  0x402c89bc in chunk_free (ar_ptr=0x40369680, p=0x81f7f00) at malloc.c:3152
3152malloc.c: No such file or directory.
(gdb) bt
#0  0x402c89bc in chunk_free (ar_ptr=0x40369680, p=0x81f7f00) at malloc.c:3152
#1  0x402c8828 in __libc_free (mem=0x81f7f08) at malloc.c:3054
#2  0x400a650d in mcrypt_module_close (td=0x81f7f08) at mcrypt_modules.c:48
#3  0x807c1e7 in php_mcrypt_do_crypt (cipher=0x81f7e94 "rijndael-256", key=0x81f2118, 
data=0x81f211c, 
mode=0x818174c "cbc", iv=0x81f2124, argc=5, dencrypt=0, return_value=0x81f7ef4) at 
mcrypt.c:1317
#4  0x807c576 in php_if_mcrypt_encrypt (ht=5, return_value=0x81f7ef4, this_ptr=0x0, 
return_value_used=1)
at mcrypt.c:1334
#5  0x81228e6 in execute (op_array=0x81f37dc) at ./zend_execute.c:1494
#6  0x80f3fcd in zend_execute_scripts (type=8, file_count=3) at zend.c:743
#7  0x8069c8f in php_execute_script (primary_file=0xba60) at main.c:1196
#8  0x8067fa4 in main (argc=2, argv=0xbb04) at cgi_main.c:731
#9  0x4026ab5c in __libc_start_main (main=0x8067830 , argc=2, ubp_av=0xbb04, 
init=0x8064b8c <_init>, 
fini=0x81362ec <_fini>, rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xbafc)
at ../sysdeps/generic/libc-start.c:129

Assigning it to the expert ... :)

---

[2001-03-16 20:58:56] [EMAIL PROTECTED]
When I run .php files under Apache (1.3.19) PHP sometimes crash. I can run the same 
file several times, and only sometimes is crashes.

This is what is recorded in the apache log (a lot of them):

[Fri Mar  9 19:24:51 2001] [notice] child pid 22845 exit signal Segmentation fault 
(11)

The following code can reproduce the crash:

$input = "Teststring";
$key = "gQ8V(|!kQ§lmJ8*~/HajI~lNM.-HzJqy";
$iv = "w81kaMfJq(1lcJaQ+m Bsjed

[PHP-DEV] Bug #10941: php4-200105171245/ext/standard/dns.c:281: undefined reference to `__res_search'

[klashma]

From: [EMAIL PROTECTED]
Operating system: RedHat7.1&Kernel 2.4.4
PHP version:  4.0 Latest CVS (2001-05-17)
PHP Bug Type: Compile Failure
Bug description:  php4-200105171245/ext/standard/dns.c:281: undefined reference to 
`__res_search'

This bug is basically the same as bug #10150:

Here's my info:

[root@klashma klashma]# gcc -v   
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81)
[root@klashma klashma]# make --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i386-redhat-linux-gnu
---
Here's what I type to compile:
[root@klashma klashma]# ./configure --with-mysql --with-imap
[root@klashma klashma]# make

And I get this:
<...CUT...>
/bin/sh /home/klashma/php4-200105171245/libtool --silent --mode=link gcc  -I. 
-I/home/klashma/php4-200105171245/ -I/home/klashma/php4-200105171245/main 
-I/home/klashma/php4-200105171245 -I/home/klashma/php4-200105171245/Zend 
-I/home/klashma/php4-200105171245/ext/mysql/libmysql 
-I/home/klashma/php4-200105171245/ext/xml/expat -I/home/klashma/php4-200105171245/TSRM 
 -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2 -prefer-non-pic -static   -o php 
-export-dynamic   stub.lo libphp4.la 
gcc: unrecognized option `-prefer-non-pic'
./.libs/libphp4.a(dns.o): In function `php_if_checkdnsrr':
/home/klashma/php4-200105171245/ext/standard/dns.c:212: undefined reference to 
`__res_search'
./.libs/libphp4.a(dns.o): In function `php_if_getmxrr':
/home/klashma/php4-200105171245/ext/standard/dns.c:281: undefined reference to 
`__res_search'
/home/klashma/php4-200105171245/ext/standard/dns.c:308: undefined reference to 
`__dn_expand'
collect2: ld returned 1 exit status
make[1]: *** [php] Error 1
make[1]: Leaving directory `/home/klashma/php4-200105171245'
make: *** [all-recursive] Error 1
[root@klashma php4-200105171245]#

Et voilà, there's nothing to do, it just won't compile :(



-- 
Edit Bug report at: http://bugs.php.net/?id=10941&edit=1



-- 
PHP Development Mailing List 
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 #9801 Updated: mcrypt_encrypt dumps core

[michael]

ID: 9801
User Update by: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: mcrypt related
Operating system: Linux 2.4.1
PHP Version: 4.0 Latest CVS (16/03/2001)
Description: mcrypt_encrypt dumps core

I think I've found the problem (and the solution).

Let's look at some functions found in mcrypt first...

File: mcrypt_modules.c

int mcrypt_module_close(MCRYPT td)
{

lt_dlclose(td->algorithm_handle);
lt_dlclose(td->mode_handle);
lt_dlexit();

td->algorithm_handle = NULL;
td->mode_handle = NULL;

td->m_encrypt = NULL;
td->a_encrypt = NULL;
td->a_decrypt = NULL;
td->m_decrypt = NULL;

free(td);

return 0;
}

File: mcrypt.c

int mcrypt_generic_end(const MCRYPT td)
{
internal_end_mcrypt(td);
mcrypt_module_close(td);
return 0;
}

The crash occurs when the call free(td) is made in mcrypt_module_close(MCRYPT td)

Notice that mcrypt_generic_end(const MCRYPT td) calls mcrypt_module_close(MCRYPT td) 
in the end.

Let's look at the mcrypt.c file from PHP (NOT the same one as above). It has a 
function called

php_mcrypt_do_crypt(char* cipher, zval **key, zval **data, char *mode, zval **iv, int 
argc, int dencrypt, zval* return_value)

At the end of the function, we find the following:

/* freeing vars */
mcrypt_generic_end (td);
if (key_s != NULL)
efree (key_s);
if (iv_s != NULL)
efree (iv_s);
efree (data_s);
mcrypt_module_close (td);
}

The crash occurs when the final mcrypt_module_close is called.

The reason is that the call to mcrypt_generic_end (td) also calls 
mcrypt_module_close(td) that again calls free (td). When we later call 
mcrypt_module_close (td) we try to free td again, and that sometimes gives us a 
segmentation fault.

The solution is simply to delete the last line in the php_mcrypt_do_crypt function 
(mcrypt_module_close (td);) found in mcrypt.c. This is ok, since we have already freed 
td in the call to mcrypt_generic_end (td) a few lines above.

That solved the problems for me. Finally no more crashes :)

Previous Comments:
---

[2001-04-10 13:58:16] [EMAIL PROTECTED]
Crashes for me too, possibly a bug in mcrypt it self. Trying more things...

---

[2001-04-10 13:01:24] [EMAIL PROTECTED]
Actually, the script only seems to dump core if I do:

echo bin2hex($output);

after the encryption.  Just a simple:

echo $output;

seems to work just fine (i.e. it outputs stuff).

- Colin

---

[2001-04-10 12:59:24] [EMAIL PROTECTED]
This happens for me too with today's CVS and the latest CVS of mcrypt.

Backtrace says:

#0  0x402c89bc in chunk_free (ar_ptr=0x40369680, p=0x81f7f00) at malloc.c:3152
3152malloc.c: No such file or directory.
(gdb) bt
#0  0x402c89bc in chunk_free (ar_ptr=0x40369680, p=0x81f7f00) at malloc.c:3152
#1  0x402c8828 in __libc_free (mem=0x81f7f08) at malloc.c:3054
#2  0x400a650d in mcrypt_module_close (td=0x81f7f08) at mcrypt_modules.c:48
#3  0x807c1e7 in php_mcrypt_do_crypt (cipher=0x81f7e94 "rijndael-256", key=0x81f2118, 
data=0x81f211c, 
mode=0x818174c "cbc", iv=0x81f2124, argc=5, dencrypt=0, return_value=0x81f7ef4) at 
mcrypt.c:1317
#4  0x807c576 in php_if_mcrypt_encrypt (ht=5, return_value=0x81f7ef4, this_ptr=0x0, 
return_value_used=1)
at mcrypt.c:1334
#5  0x81228e6 in execute (op_array=0x81f37dc) at ./zend_execute.c:1494
#6  0x80f3fcd in zend_execute_scripts (type=8, file_count=3) at zend.c:743
#7  0x8069c8f in php_execute_script (primary_file=0xba60) at main.c:1196
#8  0x8067fa4 in main (argc=2, argv=0xbb04) at cgi_main.c:731
#9  0x4026ab5c in __libc_start_main (main=0x8067830 , argc=2, ubp_av=0xbb04, 
init=0x8064b8c <_init>, 
fini=0x81362ec <_fini>, rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xbafc)
at ../sysdeps/generic/libc-start.c:129

Assigning it to the expert ... :)

---

[2001-03-16 20:58:56] [EMAIL PROTECTED]
When I run .php files under Apache (1.3.19) PHP sometimes crash. I can run the same 
file several times, and only sometimes is crashes.

This is what is recorded in the apache log (a lot of them):

[Fri Mar  9 19:24:51 2001] [notice] child pid 22845 exit signal Segmentation fault 
(11)

The following code can reproduce the crash:

$input = "Teststring";
$key = "gQ8V(|!kQ§lmJ8*~/HajI~lNM.-HzJqy";
$iv = "w81kaMfJq(1lcJaQ+m BsjedLq!§230?";
$output = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $input, MCRYPT_MODE_CBC, $iv);

The configure line is: --enable-track-vars --with-mysql=/usr/local/mysql --with-mhash 
--with-mcrypt
--with-apxs=/usr/local/apache/bin/

[PHP-DEV] Bug #10933 Updated: make failure after successfull configuration

[fb33550]

ID: 10933
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Operating system: Solaris 8
PHP Version: 4.0 Latest CVS (2001-05-17)
Description: make failure after successfull configuration

Sorry about it... shame on me

Previous Comments:
---

[2001-05-17 12:47:11] [EMAIL PROTECTED]
Opening these, bogusifying the other...

---

[2001-05-17 12:42:16] [EMAIL PROTECTED]
Sorry,

I was wrong in the version I mentionned... this was to help...

Florent.

---

[2001-05-17 12:38:17] [EMAIL PROTECTED]
... of 10932

---

[2001-05-17 12:32:25] [EMAIL PROTECTED]
Hi,

I've got a problem making the latest version of php (source is php4-200105170745).

My configure line : ./configure --prefix=/users/produits/php4.0.5 --enable-sysvsem 
--enable-sysvshm --with-imap=/users/produits/include/imap 
--with-nsapi=/users/produits/ns-home/4.1 --with-mysql


Here the "make" command result : 


Making all in Zend
/bin/sh ../libtool --silent --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I../main   
-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DSUPPORT_UTF8 
-DXML_BYTE_ORDER=21 -I../TSRM -DTHREAD=1  -pthreads -prefer-pic -c 
zend_language_scanner_cc.cc
In file included from zend.h:51,
 from zend_language_scanner_cc.cc:2661:
/usr/local/include/unix.h:182: syntax error before `*'
/usr/local/include/unix.h:193: syntax error before `*'
/usr/local/include/unix.h:196: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:196: `stream' was not declared in this scope
/usr/local/include/unix.h:196: parse error before `*'
/usr/local/include/unix.h:197: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:197: `stream' was not declared in this scope
/usr/local/include/unix.h:197: parse error before `*'
/usr/local/include/unix.h:198: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:198: `stream' was not declared in this scope
/usr/local/include/unix.h:198: parse error before `*'
/usr/local/include/unix.h:199: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:199: `stream' was not declared in this scope
/usr/local/include/unix.h:199: parse error before `*'
/usr/local/include/unix.h:200: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:200: `stream' was not declared in this scope
/usr/local/include/unix.h:200: parse error before `*'
/usr/local/include/unix.h:201: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:201: `stream' was not declared in this scope
/usr/local/include/unix.h:201: parse error before `*'
/usr/local/include/unix.h:202: syntax error before `*'
/usr/local/include/unix.h:203: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:203: `stream' was not declared in this scope
/usr/local/include/unix.h:203: parse error before `)'
/usr/local/include/unix.h:204: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:204: `stream' was not declared in this scope
/usr/local/include/unix.h:204: parse error before `long'
/usr/local/include/unix.h:206: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:206: `stream' was not declared in this scope
/usr/local/include/unix.h:206: parse error before `long'
..
.
.
*** Error code 1
make : Fatal error : Command failed for target `zend_language_scanner_cc.lo'
Current working directory /users/produits/temp/php4-200105170745/Zend
*** Error code 1
make : Fatal error : Command failed for target `all-recursive'


Can anyone help me... I configured and tried to compile it several time, without any 
success...

Many thanks for your help

Best regards

Florent


---


Full Bug description available at: http://bugs.php.net/?id=10933


-- 
PHP Development Mailing List 
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 #10940: ((true) && (true)) to return bool

[fabiankessler]

From: [EMAIL PROTECTED]
Operating system: win2k
PHP version:  4.0.5
PHP Bug Type: Feature/Change Request
Bug description:  ((true) && (true)) to return bool

(true) 
returns a bool while
((true) && (true)) 
returns an int. 
so

(((true) && (true)) == true)
"works" while
(((true) && (true)) === true)
doesnt. 

i really don't like this behavior. 

maybe you can forward also that 
http://www.php.net/manual/en/function.gettype.php 
doesn't document the NULL datatype you get (on null and unset values).

thanx
fab



-- 
Edit Bug report at: http://bugs.php.net/?id=10940&edit=1



-- 
PHP Development Mailing List 
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 #10939: Segmentation Fault in trigger_error()

[dzoll]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.5
PHP Bug Type: Reproducible crash
Bug description:  Segmentation Fault in trigger_error()

PHP 4.0.5 running as an apache module (Apache startup
string: "Apache/1.3.19 (Unix) mod_auth_pam/1.0a PHP/4.0.5
mod_ssl/2.8.1 OpenSSL/0.9.6 configured -- resuming normal
operations").  This is a Debian 2.2 box, with manually
compiled Apache and PHP.

Usually, when I call trigger_error(), PHP segmentation
faults during the trigger_error command.  This occurs
regardless of whether I'm using E_USER_ERROR or
E_USER_NOTICE (haven't tested E_USER_WARNING).

Here is a backtrace from one such crash (E_USER_ERROR in
this case):
# gdb /opt/apache-1.3.19/sbin/httpd   
GNU gdb 19990928
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) run -X
Starting program: /opt/apache-1.3.19/sbin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x401ee144 in SSL_write () from
/opt/apache-1.3.19/libexec/libssl.so
(gdb) bt
#0  0x401ee144 in SSL_write () from
/opt/apache-1.3.19/libexec/libssl.so
#1  0x40813f78 in __DTOR_END__ () from
/opt/postgresql/lib/libpq.so.2
#2  0x40786ef9 in PQsetnonblocking (conn=0x81dc7c8, arg=0)
at fe-exec.c:2192
#3  0x40785dab in PQexec (conn=0x81dc7c8, query=0x4042fcdd
"BEGIN;ROLLBACK;") at fe-exec.c:1197
#4  0x40367d71 in _rollback_transactions (rsrc=0x81de278) at
pgsql.c:168
#5  0x402e4e77 in zend_hash_apply (ht=0x404825c0,
apply_func=0x40367d34 <_rollback_transactions>) at
zend_hash.c:692
#6  0x40368059 in php_rshutdown_pgsql (type=1,
module_number=13) at pgsql.c:246
#7  0x402e2033 in module_registry_cleanup (module=0x817c238)
at zend_API.c:785
#8  0x402e4e77 in zend_hash_apply (ht=0x40482780,
apply_func=0x402e1fe8 ) at
zend_hash.c:692
#9  0x402df3d5 in zend_deactivate_modules () at zend.c:522
#10 0x402f6eac in php_request_shutdown (dummy=0x0) at main.c:670
#11 0x402f3b47 in php_apache_request_shutdown (dummy=0x0) at
mod_php4.c:290
#12 0x8051e59 in run_cleanups (c=0x81b0294) at alloc.c:1947
#13 0x80504f5 in ap_clear_pool (a=0x80eaa3c) at alloc.c:690
#14 0x8050577 in ap_destroy_pool (a=0x80eaa3c) at alloc.c:720
#15 0x80610be in child_main (child_num_arg=0) at
http_main.c:4306
#16 0x8061241 in make_child (s=0x80b32a4, slot=0,
now=990124608) at http_main.c:4411
#17 0x80613bc in startup_children (number_to_start=5) at
http_main.c:4493
#18 0x8061a2c in standalone_main (argc=2, argv=0xbd1c)
at http_main.c:4781
#19 0x806227c in main (argc=2, argv=0xbd1c) at
http_main.c:5123
(gdb) 

Odd note: the backtrace shows it dying in SSL_write, but the
site is not using SSL.

Bug is intermittent, but common enough so I can readily
reproduce it.

PHP Configure line:
./configure  --prefix=/opt/php-4.0.5
--with-apxs=/opt/apache/sbin/apxs
--with-openssl=/opt/openssl/ --with-bcmath --enable-calendar
--enable-ctype --with-curl --with-db --with-db2 --with-dbm
--with-dom --enable-ftp --with-gd --with-gmp --with-imap
--with-ldap --with-mcap --with-mcrypt --with-mysql=/usr
--with-unixODBC=/opt/unixodbc --with-pgsql=/opt/postgresql
--with-readline --with-recode --with-sablot --with-mm
--enable-shmop --with-snmp --enable-sockets --enable-wddx
--with-zlib --enable-inline-optimization --enable-debug




-- 
Edit Bug report at: http://bugs.php.net/?id=10939&edit=1



-- 
PHP Development Mailing List 
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: Solaris gcc issues with socket.c, design change recommendation

[Sterling Hughes]

Jason Greene wrote:

> Sterling,
> Did you ever get a chance to read the email about the change I suggested
> to /ext/sockets that would improve compatibility with Solaris?
> 


No, I don't believe I even recieved it.

could you resend it to me?

thanks,

Sterling



-- 
PHP Development Mailing List 
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: Solaris gcc issues with socket.c, design change recommendation

[Jason Greene]

Sterling,
Did you ever get a chance to read the email about the change I suggested
to /ext/sockets that would improve compatibility with Solaris?

-Jason




-- 
PHP Development Mailing List 
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: internal_functions.c:32: `#include' expects "FILENAME" or

[php]

From: [EMAIL PROTECTED]
Operating system: Mac OS X 10.0.2
PHP version:  4.0.5
PHP Bug Type: Compile Failure
Bug description:  internal_functions.c:32: `#include' expects "FILENAME" or 


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 
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.


-- 
Edit Bug report at: http://bugs.php.net/?id=10938&edit=1



-- 
PHP Development Mailing List 
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

[Sterling Hughes]

Daniel Beulshausen wrote:

> At 21:23 16.05.2001 +0100, Wez Furlong wrote:
> 
>> I'm not sure that the sockets extension would benefit from php_streams as
>> much as php_streams would benefit from the sockets extension, if you see
>> what I mean.
>>
>> I would like to see it using php_streams, as that would result in PHP 
>> being
>> much more flexible for the person coding in PHP; they needn't worry about
>> the type of the file handle they pass to any function.
>>
>> To integrate php_streams properly, ext/sockets should converge with 
>> fsock.c
>> and use the same underlying sockets implemented as php_streams (it's not
>> too much work).
>>
>> I think it's a good idea to get it done.
> 
> 
> i had a quick look at it, but i think it can't be done, due to the 
> simple fact that under windows socket descriptors are not file 
> descriptors like under unix.
> it could work under NT (file I/O is similiar to unix), but not under the 
> 9.x family.
> (but maybe i'm missing somehing)
> 


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.


-Sterling


-- 
PHP Development Mailing List 
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] Repost : Recursive Calls on EG(regular_list)

[Andi Gutmans]

Clayton,

This used to not work a few months ago but we made a general fix in the 
hash tables which should allow your code to run fine.
In case you encounter any problems let us know.

Andi

At 01:36 PM 5/17/2001 -0400, clayton collie wrote:
>the list has been busy as of late, so i suppose this got lost in the
>shuffle. anyways, here goes again :
>
>
>im creating an extension which exposes classes which may act as containers
>to other classes. These contained classes also get exposed via the
>extension. Now when the container class gets destructed by the user
>  $container->close(), called before RSHUTDOWN ), i need to ensure that all
>resources allocated by the contained objects are released, otherwise
>nastiness can occur is the user tries to access the contained objects later
>in the script.
>
>  to that end, ive written something like the following. i just wanted to
>know if it will cause any problems, since it accesses EG(regular_list) from
>a resource destructor. BTW the list destructor is
>destroy_container_resource .
>
>
>static int _kill_contained_objects(zend_rsrc_list *le,void *argument)
>{
> container_t *cont = (container_t *)argument;
> if (le->type == le_contained_object) {
> contained_t *field = (contained_t *)le->ptr;
> return (field->container == cont);
> }
> return 0;
>}
>
>static void kill_kids(apply_func_arg_t func, void *parent)
>{
> EGLS_FETCH();
> zend_hash_apply_with_argument(  &EG(regular_list), func, parent );
>}
>
>static void destroy_container_resource(zend_rsrc_list_entry *rsrc) {
> container_t *cont = (container_t *)rsrc->ptr;
> kill_kids( (apply_func_t) _kill_contained_objects, cont );
> container_free(cont);
>}
>
>
>
>
>--
>_
>"Fried Ice-Cream is a reality !" - George Clinton
>
>
>
>--
>PHP Development Mailing List 
>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 
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 #10937: Interface to execl() library call

[kc834]

From: [EMAIL PROTECTED]
Operating system: Linux 2.2
PHP version:  4.0.5
PHP Bug Type: Feature/Change Request
Bug description:  Interface to execl() library call

It would be very helpful if you implemented a command that could be used to execute an 
external program without using the shell.  Such a feature would be useful in the 
following cases:

1) if another hole is discovered in EscapeShellCmd()
2) if the web server is being run in a chrooted environment, or in another situation 
in which /bin/sh access is forbidden or undesirable
3) if the user wishes to avoid the overhead of running the shell when a simple execl() 
would suffice
4) when individual arguments to a user program contain spaces or other characters that 
could be mangled by the shell and require special treatment (ex. execl("/bin/foo", 
"foo", "hello \"world", NULL) is a pain in the neck to do right now)
5) if for no other reason, than to make PHP more competitive with Perl, which does 
have this feature.  it's not too hard to do.


-- 
Edit Bug report at: http://bugs.php.net/?id=10937&edit=1



-- 
PHP Development Mailing List 
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 #10793 Updated: session variables are not passed correctly to the user defined write function

[kronos]

ID: 10793
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: *Session related
Operating system: Linux 2.2.16
PHP Version: 4.0.4pl1
Description: session variables are not passed correctly to the user defined write 
function

The strange behavior is caused by a call to set_magic_quotes_runtime(1) in another 
script on another virtual server on the same machine. I was not aware of the fact that 
this function call globally sets magic_quotes_runtime to 1 as if it were set in 
php.ini.

But the problem still remains: The wrong values are passed to the session write 
function with magic_quotes_runtime enabled. And it does not happen every time I run 
the above script. So I guess it is a bug anyway.


Previous Comments:
---

[2001-05-10 12:05:32] [EMAIL PROTECTED]
Hi !

I have the following problem:

I'm using php4 session management with user defined functions to read/write
session data from/to a mysql database. Sometimes session variables are not
written correctly to the database, although they are read correctly and not
changed on the page. I have logged the values the read function returns as
well as the values passed to the write function:

This is the correct output:

(w) 6ab3322c74ba731179b210dc4401a928:
(r) 6ab3322c74ba731179b210dc4401a928:
(w) 6ab3322c74ba731179b210dc4401a928: auth_name|s:4:"test";auth_flags|s:1:"1";
(r) 6ab3322c74ba731179b210dc4401a928: auth_name|s:4:"test";auth_flags|s:1:"1";
(w) 6ab3322c74ba731179b210dc4401a928: auth_name|s:4:"test";auth_flags|s:1:"1";
(r) 6ab3322c74ba731179b210dc4401a928: auth_name|s:4:"test";auth_flags|s:1:"1";
(w) 6ab3322c74ba731179b210dc4401a928: auth_name|s:4:"test";auth_flags|s:1:"1";
(r) 6ab3322c74ba731179b210dc4401a928: auth_name|s:4:"test";auth_flags|s:1:"1";
(w) 6ab3322c74ba731179b210dc4401a928: auth_name|s:4:"test";auth_flags|s:1:"1";

This is the wrong output:

(w) 3e8eab99d3e33bfe8393a0c4d0b8e987:
(r) 3e8eab99d3e33bfe8393a0c4d0b8e987:
(w) 3e8eab99d3e33bfe8393a0c4d0b8e987: auth_name|s:4:"test";auth_flags|s:1:"1";
(r) 3e8eab99d3e33bfe8393a0c4d0b8e987: auth_name|s:4:"test";auth_flags|s:1:"1";
(w) 3e8eab99d3e33bfe8393a0c4d0b8e987: auth_name|s:4:"test";auth_flags|s:1:"1";
(r) 3e8eab99d3e33bfe8393a0c4d0b8e987: auth_name|s:4:"test";auth_flags|s:1:"1";
(w) 3e8eab99d3e33bfe8393a0c4d0b8e987: auth_name|N;!:"test";auth_flags|
(r) 3e8eab99d3e33bfe8393a0c4d0b8e987: auth_name|N;!:"test";auth_flags|
(w) 3e8eab99d3e33bfe8393a0c4d0b8e987: auth_name|N;!:"test";auth_flags|

The above example is the output of a simple frameset with 3 frames.
Sometimes I get the correct output and sometimes I get the wrong one
on exactly the same set of pages. Both variables are never changed.

There should be no programming errors in my read/write functions...
In the read function I simply read from db, output the result into
a logfile and return the result. The example above shows reading works
perfectly. And the write function outputs the passed value into the
logfile before writing it to the database and as the above example
shows the passed value is not correct.

Configuration:

Linux: Linux 2.2.16 (Suse Distribution)
Apache: Apache/1.3.19 (Unix) PHP/4.0.4pl1 mod_ssl/2.8.1 OpenSSL/0.9.6
MYSQL: 3.22.32
PHP: PHP4.04pl1 with Zend Optimizer

Relevant settings from php.ini:

variables_order =   "EGPCS"
register_globals=   On
register_argc_argv  =   On
post_max_size   =   8M
gpc_order   =   "GPC"

; Magic quotes
magic_quotes_gpc=   On
magic_quotes_runtime=   Off
magic_quotes_sybase =   Off

session.save_handler  = user
session.save_path = /tmp
session.use_cookies   = 1
session.name  = PHPSESSID
session.auto_start= 0
session.cookie_lifetime   = 0
session.cookie_path   = /
session.cookie_domain =
session.serialize_handler = php
session.gc_probability= 1
session.gc_maxlifetime= 1440
session.referer_check =
session.entropy_length= 0
session.entropy_file  =
; session.entropy_length= 16
; session.entropy_file  = /dev/urandom
session.cache_limiter = nocache
session.cache_expire  = 180
session.use_trans_sid = 1
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

any .htacces files I used only change include path or auto prepend file.


---


Full Bug description available at: http://bugs.php.net/?id=10793


-- 
PHP Development Mailing List 
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 #10935 Updated: GetImageSize fails on some JPEG files

[derick]

ID: 10935
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Function Specific
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

This should be fixed in CVS, please try a snapshot from snaps.php.net and see if it 
works for you.

Previous Comments:
---

[2001-05-17 13:17:35] [EMAIL PROTECTED]
After upgrading from 4.0.4 to 4.0.5 the getimagesize function seems to have problems 
with some JPEG files, where it returns no result (empty array or something like that). 
In my short tests this happened with the two biggest pictures in the series.

I put my sample files sorted by "success/fail" to:

http://www.student.informatik.tu-darmstadt.de/~akrauss/imagesizebug.tar.gz



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10935&edit=2


-- 
PHP Development Mailing List 
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

[Daniel Beulshausen]

At 21:23 16.05.2001 +0100, Wez Furlong wrote:
>I'm not sure that the sockets extension would benefit from php_streams as
>much as php_streams would benefit from the sockets extension, if you see
>what I mean.
>
>I would like to see it using php_streams, as that would result in PHP being
>much more flexible for the person coding in PHP; they needn't worry about
>the type of the file handle they pass to any function.
>
>To integrate php_streams properly, ext/sockets should converge with fsock.c
>and use the same underlying sockets implemented as php_streams (it's not
>too much work).
>
>I think it's a good idea to get it done.

i had a quick look at it, but i think it can't be done, due to the simple 
fact that under windows socket descriptors are not file descriptors like 
under unix.
it could work under NT (file I/O is similiar to unix), but not under the 
9.x family.
(but maybe i'm missing somehing)

daniel

/*--
daniel beulshausen - [EMAIL PROTECTED]
using php on windows? http://www.php4win.de


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Repost : Recursive Calls on EG(regular_list)

[clayton collie]

the list has been busy as of late, so i suppose this got lost in the
shuffle. anyways, here goes again :


im creating an extension which exposes classes which may act as containers
to other classes. These contained classes also get exposed via the
extension. Now when the container class gets destructed by the user
 $container->close(), called before RSHUTDOWN ), i need to ensure that all
resources allocated by the contained objects are released, otherwise
nastiness can occur is the user tries to access the contained objects later
in the script.

 to that end, ive written something like the following. i just wanted to
know if it will cause any problems, since it accesses EG(regular_list) from
a resource destructor. BTW the list destructor is
destroy_container_resource .


static int _kill_contained_objects(zend_rsrc_list *le,void *argument)
{
container_t *cont = (container_t *)argument;
if (le->type == le_contained_object) {
contained_t *field = (contained_t *)le->ptr;
return (field->container == cont);
}
return 0;
}

static void kill_kids(apply_func_arg_t func, void *parent)
{
EGLS_FETCH();
zend_hash_apply_with_argument(  &EG(regular_list), func, parent );
}

static void destroy_container_resource(zend_rsrc_list_entry *rsrc) {
container_t *cont = (container_t *)rsrc->ptr;
kill_kids( (apply_func_t) _kill_contained_objects, cont );
container_free(cont);
}




--
_
"Fried Ice-Cream is a reality !" - George Clinton



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: Fwd: [PHP-DEV] mcrypt failure under PHP 4.0.5 -> more info.

[derick]

On Thu, 17 May 2001, Andi Gutmans wrote:

> Sascha,
>
> Can you please check this out? It should probably be fixed for 4.0.6.

The code he pasted gives me a nice segfault:

Program received signal SIGSEGV, Segmentation fault.
permute (inblock=0x81ac1e4 "6866206b\204Ì\217*", perm=0x1980,
outblock=0xbfffe424 "") at tripledes.c:628
628 *ob++ |= *p++ | *q++;
(gdb) bt
#0  permute (inblock=0x81ac1e4 "6866206b\204Ì\217*", perm=0x1980,
outblock=0xbfffe424 "") at tripledes.c:628
#1  0x405b32da in tripledes_LTX__mcrypt_encrypt (key=0x0,
block=0x81ac1e4 "6866206b\204Ì\217*") at tripledes.c:319
#2  0x400189da in ecb_LTX__mcrypt (ign=0x0, plaintext=0x81ac1e4, len=8,
blocksize=8, akey=0x0, func=0x405b32ac
,
func2=0x405b37d8 ) at ecb.c:55
#3  0x40161a09 in mcrypt (td=0x8235ac0, buf=0x0, a=0x81ac1e4, b=8)
at mcrypt_modules.c:377
#4  0x401610ee in mcrypt_generic (td=0x8235ac0, plaintext=0x81ac1e4,
len=8)
at mcrypt.c:152
#5  0x80743d8 in php_if_mcrypt_generic (ht=2, return_value=0x82358a4,
this_ptr=0x0, return_value_used=1) at mcrypt.c:518
#6  0x814f211 in execute (op_array=0x8203a24) at ./zend_execute.c:1504
#7  0x8114b3b in zend_execute_scripts (type=8, file_count=3) at zend.c:748
#8  0x8066fec in php_execute_script (primary_file=0xbac4) at
main.c:1206
#9  0x8065291 in main (argc=1, argv=0xbb24) at cgi_main.c:717
#10 0x402fb9cb in __libc_start_main (main=0x8064bf4 , argc=1,
argv=0xbb24, init=0x8062e88 <_init>, fini=0x8154b2c <_fini>,
rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbb1c)
at ../sysdeps/generic/libc-start.c:92

It seems to me that a NULL pointer as key is passed to mcrypt.

I'll have a look at the code later this evening.

Derick

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-


-- 
PHP Development Mailing List 
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 #10936: DOMXML crash with CDATA

[matthew . kane]

From: [EMAIL PROTECTED]
Operating system: Win2K Pro
PHP version:  4.0.5
PHP Bug Type: Reproducible crash
Bug description:  DOMXML crash with CDATA

I am running the latest Win32 binaries from the php.net download page. I am using the 
ISAPI module on IIS5. In php.ini I enabled DOMXML by uncommenting the appropriate line.

Calling the children function on a node that has a CDATA node as a child results in an 
access violation. Here's a script that reproduces the problem:

$doc = xmldocfile('http://tbhbuilding.blogspot.com');
$root = $doc->root();
$children = $root->children();
$children = $children[1]->children();
print_r($children[1]->children());

I would have generated a gdb backtrace if the instructions for doing so explained how 
to do it with the ISAPI module.



-- 
Edit Bug report at: http://bugs.php.net/?id=10936&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] US$5,000

[Michelle Jones]

 親愛的网友, 

 网上商務和技術發展在特飛猛進, 你對其發展有些什的看法? 請輸入你的意見, 同時你有机會贏得US$5000. 

 香港和台湾的用户:
漢語請按這里: http://www.haveattitude.com/email/chinese_t
 大陆的用户:
漢語請按這里: http://www.haveattitude.com/email/chinese_s/
 Click Here for English: 
http://www.haveattitude.com/english
 謝謝你的參与!

[PHP-DEV] Bug #10935: GetImageSize fails on some JPEG files

[aks]

From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.0.5
PHP Bug Type: *Function Specific
Bug description:  GetImageSize fails on some JPEG files

After upgrading from 4.0.4 to 4.0.5 the getimagesize function seems to have problems 
with some JPEG files, where it returns no result (empty array or something like that). 
In my short tests this happened with the two biggest pictures in the series.

I put my sample files sorted by "success/fail" to:

http://www.student.informatik.tu-darmstadt.de/~akrauss/imagesizebug.tar.gz




-- 
Edit Bug report at: http://bugs.php.net/?id=10935&edit=1



-- 
PHP Development Mailing List 
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 #10934: set_error_handler () is not catching all errors

[melissa]

From: [EMAIL PROTECTED]
Operating system: Solaris 8
PHP version:  4.0.5
PHP Bug Type: *Function Specific
Bug description:  set_error_handler () is not catching all errors

Short, sample function listed to quickly illustrate issue:

[root@helpdesk bin]# more err.php 


[root@helpdesk bin]# ./php -q err.php 
USER ERROR HANDLER: -- errno:256 -- errmsg:E_USER_ERROR -- filename:err.php -- 
linenum:13
USER ERROR HANDLER: -- errno:512 -- errmsg:E_USER_WARNING -- filename:err.php -- 
linenum:14
USER ERROR HANDLER: -- errno:1024 -- errmsg:E_USER_NOTICE -- filename:err.php -- 
linenum:15

Fatal error:  Call to undefined function:  this_function_does_not_exist() in 
err.php on line 16
[root@helpdesk bin]# 




-- 
Edit Bug report at: http://bugs.php.net/?id=10934&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Fwd: [PHP-DEV] mcrypt failure under PHP 4.0.5 -> more info.

[Andi Gutmans]

Sascha,

Can you please check this out? It should probably be fixed for 4.0.6.

Andi

>Delivered-To: [EMAIL PROTECTED]
>Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
>list-post: 
>Delivered-To: mailing list [EMAIL PROTECTED]
>Date: Thu, 17 May 2001 16:48:36 +0100
>From: Chris Walker <[EMAIL PROTECTED]>
>X-Mailer: The Bat! (v1.51) Personal
>Reply-To: Chris Walker <[EMAIL PROTECTED]>
>Organization: Gameshrine
>To: [EMAIL PROTECTED]
>Subject: [PHP-DEV] mcrypt failure under PHP 4.0.5 -> more info.
>
>Hi fellow developers,
>
>RE: mcrypt functionality failure since PHP 4.0.5 upgrade.
>
>This is a snippet taken from the class that handles the addition of
>new users into the users table. It shows the way we *were
>successfully* using mcrypt to encrypt user's passwords:
>
>//--- Begin code paste.
>
>$password_key = md5($username);
>
>// Actual passwords are randomly generated.
>// User may change later.
>
>srand((double)microtime()*100);
>$password = substr(md5(rand(0,999)),0,8);
>
>// Encrypt password using md5 string above.
>
>$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, $password_key, $iv);
>$encrypted_password = mcrypt_generic ($td,$password);
>mcrypt_generic_end ($td);
>
>// Do database insert using $encrypted_password value.
>
>//--- End code paste.
>
>The rest is irrelevant. Up until the upgrade to PHP 4.0.5, the above
>method worked without any issue, each time returning properly
>encrypted passwords which were then stored in the database.
>
>At the moment passwords are now being stored unencrypted but since its
>currently on an internal development server the security implications
>are negligible, BUT I would appreciate any feedback, similar
>encounters, etc from the development community since this clearly
>needs fixing.
>
>Many thanks,
>
>Chris.
>
>
>
>--
>PHP Development Mailing List 
>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 
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: [PHP-DOC] Rename list to php-doc?

[Hojtsy Gabor]

> We're there plans to rename the [EMAIL PROTECTED] mailing list
> to [EMAIL PROTECTED], for consistency with the other mailing
> lists?  What ever happened to that idea?

Maybe an alias would be enough for the sort term.
The mail subject says: [PHP-DOC] :)

Goba
... . . .  .  .
Editor of the Hungarian PHP manual, Admin of the Hungarian PHP mirror


-- 
PHP Development Mailing List 
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 #10932 Updated: make failure after successfull configuration

[derick]

ID: 10932
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Compile Failure
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:



Previous Comments:
---

[2001-05-17 12:30:03] [EMAIL PROTECTED]
Hi,

I've got a problem making the latest version of php (source is php4-200105170745).

My configure line : ./configure --prefix=/users/produits/php4.0.5 --enable-sysvsem 
--enable-sysvshm --with-imap=/users/produits/include/imap 
--with-nsapi=/users/produits/ns-home/4.1 --with-mysql


Here the "make" command result : 


Making all in Zend
/bin/sh ../libtool --silent --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I../main   
-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DSUPPORT_UTF8 
-DXML_BYTE_ORDER=21 -I../TSRM -DTHREAD=1  -pthreads -prefer-pic -c 
zend_language_scanner_cc.cc
In file included from zend.h:51,
 from zend_language_scanner_cc.cc:2661:
/usr/local/include/unix.h:182: syntax error before `*'
/usr/local/include/unix.h:193: syntax error before `*'
/usr/local/include/unix.h:196: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:196: `stream' was not declared in this scope
/usr/local/include/unix.h:196: parse error before `*'
/usr/local/include/unix.h:197: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:197: `stream' was not declared in this scope
/usr/local/include/unix.h:197: parse error before `*'
/usr/local/include/unix.h:198: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:198: `stream' was not declared in this scope
/usr/local/include/unix.h:198: parse error before `*'
/usr/local/include/unix.h:199: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:199: `stream' was not declared in this scope
/usr/local/include/unix.h:199: parse error before `*'
/usr/local/include/unix.h:200: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:200: `stream' was not declared in this scope
/usr/local/include/unix.h:200: parse error before `*'
/usr/local/include/unix.h:201: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:201: `stream' was not declared in this scope
/usr/local/include/unix.h:201: parse error before `*'
/usr/local/include/unix.h:202: syntax error before `*'
/usr/local/include/unix.h:203: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:203: `stream' was not declared in this scope
/usr/local/include/unix.h:203: parse error before `)'
/usr/local/include/unix.h:204: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:204: `stream' was not declared in this scope
/usr/local/include/unix.h:204: parse error before `long'
/usr/local/include/unix.h:206: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:206: `stream' was not declared in this scope
/usr/local/include/unix.h:206: parse error before `long'
..
.
.
*** Error code 1
make : Fatal error : Command failed for target `zend_language_scanner_cc.lo'
Current working directory /users/produits/temp/php4-200105170745/Zend
*** Error code 1
make : Fatal error : Command failed for target `all-recursive'


Can anyone help me... I configured and tried to compile it several time, without any 
success...

Many thanks for your help

Best regards

Florent


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10932&edit=2


-- 
PHP Development Mailing List 
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 #10933 Updated: make failure after successfull configuration

[derick]

ID: 10933
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Duplicate
Status: Open
Bug Type: Compile Failure
Operating system: 
PHP Version: 4.0 Latest CVS (2001-05-17)
Assigned To: 
Comments:

Opening these, bogusifying the other...

Previous Comments:
---

[2001-05-17 12:42:16] [EMAIL PROTECTED]
Sorry,

I was wrong in the version I mentionned... this was to help...

Florent.

---

[2001-05-17 12:38:17] [EMAIL PROTECTED]
... of 10932

---

[2001-05-17 12:32:25] [EMAIL PROTECTED]
Hi,

I've got a problem making the latest version of php (source is php4-200105170745).

My configure line : ./configure --prefix=/users/produits/php4.0.5 --enable-sysvsem 
--enable-sysvshm --with-imap=/users/produits/include/imap 
--with-nsapi=/users/produits/ns-home/4.1 --with-mysql


Here the "make" command result : 


Making all in Zend
/bin/sh ../libtool --silent --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I../main   
-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DSUPPORT_UTF8 
-DXML_BYTE_ORDER=21 -I../TSRM -DTHREAD=1  -pthreads -prefer-pic -c 
zend_language_scanner_cc.cc
In file included from zend.h:51,
 from zend_language_scanner_cc.cc:2661:
/usr/local/include/unix.h:182: syntax error before `*'
/usr/local/include/unix.h:193: syntax error before `*'
/usr/local/include/unix.h:196: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:196: `stream' was not declared in this scope
/usr/local/include/unix.h:196: parse error before `*'
/usr/local/include/unix.h:197: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:197: `stream' was not declared in this scope
/usr/local/include/unix.h:197: parse error before `*'
/usr/local/include/unix.h:198: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:198: `stream' was not declared in this scope
/usr/local/include/unix.h:198: parse error before `*'
/usr/local/include/unix.h:199: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:199: `stream' was not declared in this scope
/usr/local/include/unix.h:199: parse error before `*'
/usr/local/include/unix.h:200: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:200: `stream' was not declared in this scope
/usr/local/include/unix.h:200: parse error before `*'
/usr/local/include/unix.h:201: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:201: `stream' was not declared in this scope
/usr/local/include/unix.h:201: parse error before `*'
/usr/local/include/unix.h:202: syntax error before `*'
/usr/local/include/unix.h:203: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:203: `stream' was not declared in this scope
/usr/local/include/unix.h:203: parse error before `)'
/usr/local/include/unix.h:204: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:204: `stream' was not declared in this scope
/usr/local/include/unix.h:204: parse error before `long'
/usr/local/include/unix.h:206: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:206: `stream' was not declared in this scope
/usr/local/include/unix.h:206: parse error before `long'
..
.
.
*** Error code 1
make : Fatal error : Command failed for target `zend_language_scanner_cc.lo'
Current working directory /users/produits/temp/php4-200105170745/Zend
*** Error code 1
make : Fatal error : Command failed for target `all-recursive'


Can anyone help me... I configured and tried to compile it several time, without any 
success...

Many thanks for your help

Best regards

Florent


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10933&edit=2


-- 
PHP Development Mailing List 
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 #10933 Updated: make failure after successfull configuration

[fb33550]

ID: 10933
User Update by: [EMAIL PROTECTED]
Status: Duplicate
Bug Type: Compile Failure
Operating system: Solaris 8
PHP Version: 4.0 Latest CVS (2001-05-17)
Description: make failure after successfull configuration

Sorry,

I was wrong in the version I mentionned... this was to help...

Florent.

Previous Comments:
---

[2001-05-17 12:38:17] [EMAIL PROTECTED]
... of 10932

---

[2001-05-17 12:32:25] [EMAIL PROTECTED]
Hi,

I've got a problem making the latest version of php (source is php4-200105170745).

My configure line : ./configure --prefix=/users/produits/php4.0.5 --enable-sysvsem 
--enable-sysvshm --with-imap=/users/produits/include/imap 
--with-nsapi=/users/produits/ns-home/4.1 --with-mysql


Here the "make" command result : 


Making all in Zend
/bin/sh ../libtool --silent --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I../main   
-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DSUPPORT_UTF8 
-DXML_BYTE_ORDER=21 -I../TSRM -DTHREAD=1  -pthreads -prefer-pic -c 
zend_language_scanner_cc.cc
In file included from zend.h:51,
 from zend_language_scanner_cc.cc:2661:
/usr/local/include/unix.h:182: syntax error before `*'
/usr/local/include/unix.h:193: syntax error before `*'
/usr/local/include/unix.h:196: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:196: `stream' was not declared in this scope
/usr/local/include/unix.h:196: parse error before `*'
/usr/local/include/unix.h:197: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:197: `stream' was not declared in this scope
/usr/local/include/unix.h:197: parse error before `*'
/usr/local/include/unix.h:198: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:198: `stream' was not declared in this scope
/usr/local/include/unix.h:198: parse error before `*'
/usr/local/include/unix.h:199: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:199: `stream' was not declared in this scope
/usr/local/include/unix.h:199: parse error before `*'
/usr/local/include/unix.h:200: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:200: `stream' was not declared in this scope
/usr/local/include/unix.h:200: parse error before `*'
/usr/local/include/unix.h:201: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:201: `stream' was not declared in this scope
/usr/local/include/unix.h:201: parse error before `*'
/usr/local/include/unix.h:202: syntax error before `*'
/usr/local/include/unix.h:203: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:203: `stream' was not declared in this scope
/usr/local/include/unix.h:203: parse error before `)'
/usr/local/include/unix.h:204: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:204: `stream' was not declared in this scope
/usr/local/include/unix.h:204: parse error before `long'
/usr/local/include/unix.h:206: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:206: `stream' was not declared in this scope
/usr/local/include/unix.h:206: parse error before `long'
..
.
.
*** Error code 1
make : Fatal error : Command failed for target `zend_language_scanner_cc.lo'
Current working directory /users/produits/temp/php4-200105170745/Zend
*** Error code 1
make : Fatal error : Command failed for target `all-recursive'


Can anyone help me... I configured and tried to compile it several time, without any 
success...

Many thanks for your help

Best regards

Florent


---


Full Bug description available at: http://bugs.php.net/?id=10933


-- 
PHP Development Mailing List 
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 #10933 Updated: make failure after successfull configuration

[vlad]

ID: 10933
Updated by: vlad
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Duplicate
Bug Type: Compile Failure
Operating system: 
PHP Version: 4.0 Latest CVS (2001-05-17)
Assigned To: 
Comments:

... of 10932

Previous Comments:
---

[2001-05-17 12:32:25] [EMAIL PROTECTED]
Hi,

I've got a problem making the latest version of php (source is php4-200105170745).

My configure line : ./configure --prefix=/users/produits/php4.0.5 --enable-sysvsem 
--enable-sysvshm --with-imap=/users/produits/include/imap 
--with-nsapi=/users/produits/ns-home/4.1 --with-mysql


Here the "make" command result : 


Making all in Zend
/bin/sh ../libtool --silent --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I../main   
-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DSUPPORT_UTF8 
-DXML_BYTE_ORDER=21 -I../TSRM -DTHREAD=1  -pthreads -prefer-pic -c 
zend_language_scanner_cc.cc
In file included from zend.h:51,
 from zend_language_scanner_cc.cc:2661:
/usr/local/include/unix.h:182: syntax error before `*'
/usr/local/include/unix.h:193: syntax error before `*'
/usr/local/include/unix.h:196: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:196: `stream' was not declared in this scope
/usr/local/include/unix.h:196: parse error before `*'
/usr/local/include/unix.h:197: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:197: `stream' was not declared in this scope
/usr/local/include/unix.h:197: parse error before `*'
/usr/local/include/unix.h:198: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:198: `stream' was not declared in this scope
/usr/local/include/unix.h:198: parse error before `*'
/usr/local/include/unix.h:199: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:199: `stream' was not declared in this scope
/usr/local/include/unix.h:199: parse error before `*'
/usr/local/include/unix.h:200: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:200: `stream' was not declared in this scope
/usr/local/include/unix.h:200: parse error before `*'
/usr/local/include/unix.h:201: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:201: `stream' was not declared in this scope
/usr/local/include/unix.h:201: parse error before `*'
/usr/local/include/unix.h:202: syntax error before `*'
/usr/local/include/unix.h:203: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:203: `stream' was not declared in this scope
/usr/local/include/unix.h:203: parse error before `)'
/usr/local/include/unix.h:204: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:204: `stream' was not declared in this scope
/usr/local/include/unix.h:204: parse error before `long'
/usr/local/include/unix.h:206: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:206: `stream' was not declared in this scope
/usr/local/include/unix.h:206: parse error before `long'
..
.
.
*** Error code 1
make : Fatal error : Command failed for target `zend_language_scanner_cc.lo'
Current working directory /users/produits/temp/php4-200105170745/Zend
*** Error code 1
make : Fatal error : Command failed for target `all-recursive'


Can anyone help me... I configured and tried to compile it several time, without any 
success...

Many thanks for your help

Best regards

Florent


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10933&edit=2


-- 
PHP Development Mailing List 
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 #10931 Updated: IBM HTTP Server 1.3.12.2 can't load the php4apache.dll

[derick]

ID: 10931
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Other web server
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

Please provide some more information, this is not enough to track down a problem.
Please also read www.php.net/bugs-dos-and-donts.php

Derick

Previous Comments:
---

[2001-05-17 12:29:18] [EMAIL PROTECTED]


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10931&edit=2


-- 
PHP Development Mailing List 
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 #10927 Updated: mycrpt no longer works in 4.0.5

[derick]

ID: 10927
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Assigned
Bug Type: mcrypt related
Operating system: 
PHP Version: 4.0.5
Assigned To: derick
Comments:

Hello,

I find it very strange that mcrypt does not report any error. (Are there things about 
a Signal 11, or Segmentation fault in your apache error_log?)
mcrypt works fine here, on both my development server here (Linux) and another 
production server (OpenBSD).

Do I correctly understand, the strings you want to encrypt are not being encrypted?

Derick

Previous Comments:
---

[2001-05-17 11:26:26] [EMAIL PROTECTED]
We have just upgraded to the latest version of PHP in order to take advantage of some 
new features, particularly those dealing with arrays.

Our user accounts store (amongst other things) two variables, the username and 
password in a mySQL database.

The password is encrypted using mcrypt. The key for which is provided by generating an 
md5 string of the given username. decryption does not occur; encrypted strings are 
compared for similarity using strcmp().

Ever since we upgraded to 4.0.5, *all* mcrypt functions are failing - no encryption 
takes place and PHP returns no error, simply failing to produce anything. 

Please fix this ASAP. This is not a code issue, it is an issue with the mcrypt 
functionality since the latest release of PHP. 

Many thanks.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10927&edit=2


-- 
PHP Development Mailing List 
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 #10933: make failure after successfull configuration

[fb33550]

From: [EMAIL PROTECTED]
Operating system: Solaris 8
PHP version:  4.0 Latest CVS (2001-05-17)
PHP Bug Type: Compile Failure
Bug description:  make failure after successfull configuration

Hi,

I've got a problem making the latest version of php (source is php4-200105170745).

My configure line : ./configure --prefix=/users/produits/php4.0.5 --enable-sysvsem 
--enable-sysvshm --with-imap=/users/produits/include/imap 
--with-nsapi=/users/produits/ns-home/4.1 --with-mysql


Here the "make" command result : 


Making all in Zend
/bin/sh ../libtool --silent --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I../main   
-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DSUPPORT_UTF8 
-DXML_BYTE_ORDER=21 -I../TSRM -DTHREAD=1  -pthreads -prefer-pic -c 
zend_language_scanner_cc.cc
In file included from zend.h:51,
 from zend_language_scanner_cc.cc:2661:
/usr/local/include/unix.h:182: syntax error before `*'
/usr/local/include/unix.h:193: syntax error before `*'
/usr/local/include/unix.h:196: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:196: `stream' was not declared in this scope
/usr/local/include/unix.h:196: parse error before `*'
/usr/local/include/unix.h:197: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:197: `stream' was not declared in this scope
/usr/local/include/unix.h:197: parse error before `*'
/usr/local/include/unix.h:198: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:198: `stream' was not declared in this scope
/usr/local/include/unix.h:198: parse error before `*'
/usr/local/include/unix.h:199: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:199: `stream' was not declared in this scope
/usr/local/include/unix.h:199: parse error before `*'
/usr/local/include/unix.h:200: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:200: `stream' was not declared in this scope
/usr/local/include/unix.h:200: parse error before `*'
/usr/local/include/unix.h:201: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:201: `stream' was not declared in this scope
/usr/local/include/unix.h:201: parse error before `*'
/usr/local/include/unix.h:202: syntax error before `*'
/usr/local/include/unix.h:203: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:203: `stream' was not declared in this scope
/usr/local/include/unix.h:203: parse error before `)'
/usr/local/include/unix.h:204: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:204: `stream' was not declared in this scope
/usr/local/include/unix.h:204: parse error before `long'
/usr/local/include/unix.h:206: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:206: `stream' was not declared in this scope
/usr/local/include/unix.h:206: parse error before `long'
..
.
.
*** Error code 1
make : Fatal error : Command failed for target `zend_language_scanner_cc.lo'
Current working directory /users/produits/temp/php4-200105170745/Zend
*** Error code 1
make : Fatal error : Command failed for target `all-recursive'


Can anyone help me... I configured and tried to compile it several time, without any 
success...

Many thanks for your help

Best regards

Florent



-- 
Edit Bug report at: http://bugs.php.net/?id=10933&edit=1



-- 
PHP Development Mailing List 
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 #10932: make failure after successfull configuration

[fb33550]

From: [EMAIL PROTECTED]
Operating system: Solaris 8
PHP version:  4.0.5
PHP Bug Type: Compile Failure
Bug description:  make failure after successfull configuration

Hi,

I've got a problem making the latest version of php (source is php4-200105170745).

My configure line : ./configure --prefix=/users/produits/php4.0.5 --enable-sysvsem 
--enable-sysvshm --with-imap=/users/produits/include/imap 
--with-nsapi=/users/produits/ns-home/4.1 --with-mysql


Here the "make" command result : 


Making all in Zend
/bin/sh ../libtool --silent --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I../main   
-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DSUPPORT_UTF8 
-DXML_BYTE_ORDER=21 -I../TSRM -DTHREAD=1  -pthreads -prefer-pic -c 
zend_language_scanner_cc.cc
In file included from zend.h:51,
 from zend_language_scanner_cc.cc:2661:
/usr/local/include/unix.h:182: syntax error before `*'
/usr/local/include/unix.h:193: syntax error before `*'
/usr/local/include/unix.h:196: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:196: `stream' was not declared in this scope
/usr/local/include/unix.h:196: parse error before `*'
/usr/local/include/unix.h:197: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:197: `stream' was not declared in this scope
/usr/local/include/unix.h:197: parse error before `*'
/usr/local/include/unix.h:198: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:198: `stream' was not declared in this scope
/usr/local/include/unix.h:198: parse error before `*'
/usr/local/include/unix.h:199: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:199: `stream' was not declared in this scope
/usr/local/include/unix.h:199: parse error before `*'
/usr/local/include/unix.h:200: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:200: `stream' was not declared in this scope
/usr/local/include/unix.h:200: parse error before `*'
/usr/local/include/unix.h:201: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:201: `stream' was not declared in this scope
/usr/local/include/unix.h:201: parse error before `*'
/usr/local/include/unix.h:202: syntax error before `*'
/usr/local/include/unix.h:203: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:203: `stream' was not declared in this scope
/usr/local/include/unix.h:203: parse error before `)'
/usr/local/include/unix.h:204: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:204: `stream' was not declared in this scope
/usr/local/include/unix.h:204: parse error before `long'
/usr/local/include/unix.h:206: `MAILSTREAM' was not declared in this scope
/usr/local/include/unix.h:206: `stream' was not declared in this scope
/usr/local/include/unix.h:206: parse error before `long'
..
.
.
*** Error code 1
make : Fatal error : Command failed for target `zend_language_scanner_cc.lo'
Current working directory /users/produits/temp/php4-200105170745/Zend
*** Error code 1
make : Fatal error : Command failed for target `all-recursive'


Can anyone help me... I configured and tried to compile it several time, without any 
success...

Many thanks for your help

Best regards

Florent



-- 
Edit Bug report at: http://bugs.php.net/?id=10932&edit=1



-- 
PHP Development Mailing List 
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 #10931: IBM HTTP Server 1.3.12.2 can't load the php4apache.dll

[tmjiang]

From: [EMAIL PROTECTED]
Operating system: windows 2000 professional
PHP version:  4.0.5
PHP Bug Type: Other web server
Bug description:  IBM HTTP Server 1.3.12.2 can't load the php4apache.dll




-- 
Edit Bug report at: http://bugs.php.net/?id=10931&edit=1



-- 
PHP Development Mailing List 
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 #10930: Can't connect to mysql after running some code that crashes IIS 5

[tyler . longren]

From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version:  4.0.5
PHP Bug Type: MySQL related
Bug description:  Can't connect to mysql after running some code that crashes IIS 5

After running the code below, PHP 4.0.5 is no longer able to connecto to mysql.  I 
have tested this at 2 different locations, and the result is the same every time.  
Also after visiting the website with this code in it, inetinfo.exe (IIS) crashes.

PHP was installed with php405-installer.exe.  The problem occurs on Windows 2000 
Professional SP1 & SP2.  Windows 2000 server has not been tested.  Below is the code 
that should be pasted into a webpage, and then visited with any browser.  I 
accidentally caused inetinfo.exe to die with this:

.
This was found on accident...thanks to my crappy coding.  :)
Date: 05-14-2001
Kills: Inetinfo.exe on Win2k
*/
session_start();
session_register('username');
session_register('password');
header("Location: $PHP_SELF");
if ($formusername) {
mysql_connect("$mysql_host","$mysql_user","$mysql_pass");
mysql_select_db("$mysql_db");
$auth_sql = mysql_query("SELECT * FROM $mysql_user_table WHERE username =
'$formusername' AND password = '$formpassword'");
$user_exists = mysql_num_rows($auth_sql);
if ($user_exists == "1") {
$username = $formusername;
$password = $formpassword;

}
else {
$login_error = "Error:Wrongusername/password";
session_unregister('username');
session_unregister('password');
}

}
else {
mysql_connect("$mysql_host","$mysql_user","$mysql_pass");
mysql_select_db("$mysql_db");
$auth_sql = mysql_query("SELECT * FROM $mysql_user_table WHERE username =
'$username' AND password = '$password'");
$user_exists = mysql_num_rows($auth_sql);
if ($user_exists == "1") {
// blah blah blah!
}
else {
$login_error = "Error:Wrongusername/password";
session_unregister('username');
session_unregister('password');
}
}
if ($login == "no") {
session_destroy();
session_unregister('username');
session_unregister('password');
header("Location: $PHP_SELF");
}
?>


-- 
Edit Bug report at: http://bugs.php.net/?id=10930&edit=1



-- 
PHP Development Mailing List 
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 #10929: got "segmentation fault" after successful compile

[marija]

From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.0.5
PHP Bug Type: Apache related
Bug description:  got "segmentation fault" after successful compile

cd /usr/src/apache_1.3.19
./configure --prefix=/www
cd  ../php-4.0.5
./configure --with-mysql=/usr/local/ --with-oracle=/home/oracle/OraHome1/ 
--with-apache=../apache_1.3.19 --enable-sigchild --enable-track-vars
make
make install
cd ../apache_1.3.19
./configure --activate-module=src/modules/php4/libphp4.a
make
make install

All of this didn't produce any errors. After trying to start apache (it was down all 
the time) with
/usr/local/apache/bin/apachectl start
I got "segmentation fault"
I checked, that was newly compiled apache.

Just for reference, version 4.0.4 with same parameters is compiled and it is runing 
just OK



-- 
Edit Bug report at: http://bugs.php.net/?id=10929&edit=1



-- 
PHP Development Mailing List 
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] Boolean weirdness?

[Andrei Zmievski]

On Thu, 17 May 2001, Sebastian Bergmann wrote:
>   Hey there,
> 
>   I was just bitten by a - IMHO - weirdness with boolean values:
> 
>$foo = -1;
>   if ($foo) { print "bar"; }
> ?>
> 
>   The code above print 'bar'. I would expect if($x) t return true if $x
> is an integer and greater that zero. This is what my intuition tells me
> :)

Anything that's not 0 is true.

-Andrei

"Try to spend the next 30 seconds not thinking
 about a blue-eyed polar bear." -Feodor Dostoevsky 

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Boolean weirdness?

[Sebastian Bergmann]

  Hey there,

  I was just bitten by a - IMHO - weirdness with boolean values:



  The code above print 'bar'. I would expect if($x) t return true if $x
is an integer and greater that zero. This is what my intuition tells me
:)

  Just a thought,
Sebastian

-- 
 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 
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: Exporting strlcat()?

[Sterling Hughes]

Daniel Stenberg wrote:

> On Wed, 16 May 2001, Sterling Hughes wrote:
> 
> [Talking about strlcat() as it exists globallly in libcurl that then collides
> with the PHP internal one when building PHP with curl]
> 
> 
>>>Yes, I _could_ rename the strlcat() function to something else, but that
>>>would not be a really satisfactory solution for me, since the function is
>>>indeed used by people and it will be assumed to be around.
>>>
>>When did you add strlcat()?  I only have this problem with 7.7.3.
>>
> 
> libcurl's strlcat() has been around longer than that. It first appeared in
> 7.6.1, back in february this year.
>


Its odd that I'm just having this problem now then (actually the whole 
problem seems a bit suspicious of something else being wrong, either 
with PHP or cURL or my system ;).

 
> 
>>If its the internal code-base of cURL your worried about, the patch I
>>sent you declaring it 'static inline' should make the function accessable
>>within cURL itself.
>>
> 
> Well, to start off with, I can't make it 'inline' indepedent of compiler as
> there is no standard inline keyword for ANSI C. Secondly, I don't really want
> it inlined as that will increase the size of the library with very little
> gain.
> 


yeah, ok ;)

you mean there are other systems besides Linux??? Pahh! I'll believe it 
when I see it.


> I could make a solution work for me that would name the function
> 'Curl_strlcat' and then I'd have a macro for libcurl code that looks like
> #define strlcat(x,y,z) Curl_strlcat(x,y,z)
> 
> I'd consider that an acceptable solution.
> 
> Of course, all libs couldn't do what libcurl does like this, as then you
> couldn't link with several of this kind. I realize that.
> 


yeah, and I'm sure *some* of them mess with our namespace, that's why 
I'm not sure why this is happening.


> 
>>I also think that curl shouldn't be exporting a function like strlcat()
>>simply because the purpose of cURL is not that of a general purpose
>>library, but rather a library for fetching URL's.
>>
> 
> Yes, you're right. But bear in mind that I don't explicitly "export"
> strlcat(), it just happens to be a global symbol in my library that also is
> externally accessible. You can find a long range of other symbols too, that
> I'd rather not have exported but unfortunately they are. That is mostly due
> to the nature of the standard unix library concept.
> 


yup.  but besides the libc functions, most of them are ns protected.


> 
>>If you'll notice strlcpy() is not exported (nm -g libcurl.so | grep
>>strlcpy) from the library, as it is defined in krb4.c not a header file.
>>
> 
> It is probably not around in your version because you don't have it built
> with krb4-support enabled, otherwise it will be there.
> 


could be ;P


> I'll probably make the same fix for this function as the one mentioned above.
> 


That would be cool...  Regardless of the current issue, I think they 
should be ns protected (of course that might be because it helps me out 
if they are :)


> 
>>I've CC'ed the php-dev mailing list on this.  As I don't know PHP's build
>>system as in depth as some of the people on this list do.
>>
> 
> Cc'ed back. Do CC me if you want me to receive replies, I don't subscribe to
> php-dev.
> 


Naturally ;)

-Sterling



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] mcrypt failure under PHP 4.0.5 -> more info.

[Chris Walker]

Hi fellow developers,

RE: mcrypt functionality failure since PHP 4.0.5 upgrade.

This is a snippet taken from the class that handles the addition of
new users into the users table. It shows the way we *were
successfully* using mcrypt to encrypt user's passwords:

//--- Begin code paste.

   $password_key = md5($username);

   // Actual passwords are randomly generated.
   // User may change later.

   srand((double)microtime()*100);
   $password = substr(md5(rand(0,999)),0,8);

   // Encrypt password using md5 string above.

   $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, $password_key, $iv);
   $encrypted_password = mcrypt_generic ($td,$password);
   mcrypt_generic_end ($td);

   // Do database insert using $encrypted_password value.

//--- End code paste.

The rest is irrelevant. Up until the upgrade to PHP 4.0.5, the above
method worked without any issue, each time returning properly
encrypted passwords which were then stored in the database.

At the moment passwords are now being stored unencrypted but since its
currently on an internal development server the security implications
are negligible, BUT I would appreciate any feedback, similar
encounters, etc from the development community since this clearly
needs fixing.

Many thanks,

Chris.



-- 
PHP Development Mailing List 
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: Loading PHP as a DSO fails - "garbled"

[dave]

From: [EMAIL PROTECTED]
Operating system: Linux Redhat 6.2 Kernel 2.2.17
PHP version:  4.0.5
PHP Bug Type: Dynamic loading
Bug description:  Loading PHP as a DSO fails - "garbled"

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.


-- 
Edit Bug report at: http://bugs.php.net/?id=10928&edit=1



-- 
PHP Development Mailing List 
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 #10927: mycrpt no longer works in 4.0.5

[chris]

From: [EMAIL PROTECTED]
Operating system: FreeBSD
PHP version:  4.0.5
PHP Bug Type: mcrypt related
Bug description:  mycrpt no longer works in 4.0.5

We have just upgraded to the latest version of PHP in order to take advantage of some 
new features, particularly those dealing with arrays.

Our user accounts store (amongst other things) two variables, the username and 
password in a mySQL database.

The password is encrypted using mcrypt. The key for which is provided by generating an 
md5 string of the given username. decryption does not occur; encrypted strings are 
compared for similarity using strcmp().

Ever since we upgraded to 4.0.5, *all* mcrypt functions are failing - no encryption 
takes place and PHP returns no error, simply failing to produce anything. 

Please fix this ASAP. This is not a code issue, it is an issue with the mcrypt 
functionality since the latest release of PHP. 

Many thanks.


-- 
Edit Bug report at: http://bugs.php.net/?id=10927&edit=1



-- 
PHP Development Mailing List 
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 #10906 Updated: mod_ssl and php oci8 interaction problem

[dawson_j]

ID: 10906
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: OCI8 related
Operating system: RedHat Linux 7.1
PHP Version: 4.0.5
Description: mod_ssl and php oci8 interaction problem

libpthread problem again

Previous Comments:
---

[2001-05-16 13:43:42] [EMAIL PROTECTED]
When building apache, ssl and php4 with oci8 support statically, and compiling 
everything myself, things are great.
However,

When trying  to use RedHat's built in Apache server and mod_ssl, on both RedHat 
version 7.0 and 7.1,
The following events happen.

Scenario 1:
Using Apache without the mod_ssl rpm installed.
Build php 4.0.5 using apxs with-oci8

This works.

Scenario 2:
Using apache with the mod_ssl rpm installed.
build php4.0.5 using apxs without-oci8
This works.

Scenario 3.
Using apache with mod_ssl rpm installed,
build php4.0.5 using apxs with-oci8

httpd dies silently, no error message.

This method is also reproducable by loading the RedHat 7.1 SRPM for php version 
4.0.4pl1.
modify the spec file to include --with-oci8.
rebuild the rpm and install.

I have seen this particular problem in mailing lists, but not specifically described 
in detail. By trying all of 
these different combinations, I believe that something with the oci8 support is 
conflicting with mod_ssl.

Is this a problem of a missing -DEAPI flag?

I tried modifying the make file for it, but that didn't work either.



---


Full Bug description available at: http://bugs.php.net/?id=10906


-- 
PHP Development Mailing List 
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 #10925 Updated:

[derick]

ID: 10925
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Closed
Status: Bogus
Bug Type: *General Issues
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

Marking this one bogus, so that it can be removed.

Previous Comments:
---

[2001-05-17 09:40:46] [EMAIL PROTECTED]
not a bug!

---

[2001-05-17 09:35:20] [EMAIL PROTECTED]


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10925&edit=2


-- 
PHP Development Mailing List 
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 #10384 Updated: read() buffer memory not freed

[rod]

ID: 10384
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Sockets related
Operating system: FreeBSD 4.2
PHP Version: 4.0.4pl1
Description: read() buffer memory not freed

This problem appears to be FreeBSD specific.  Still exists with FreeBSD 4.3 but is 
non-existent on Slackware.

Interesting side note:  I had modified the code below and introduced a bug which 
caused Slackware to send a 0 length message.  That is this line:

write($msgsock,$send,strlen($send));

was changed to:

write($msgsock,$msgToSend,strlen($send));

and should have been:

write($msgsock,$msgToSend,strlen($msgToSend));

The variable $send was no longer defined resulting in the correct behavior under 
Slackware of sending no message, however under FreeBSD the full message was sent.

Since this appears to be a bug in the libraries under FreeBSD and NOT PHP related I'm 
closing the ticket.

Previous Comments:
---

[2001-05-03 13:33:45] [EMAIL PROTECTED]
Problem still exists in 4.0.5

The script originally uses ~2MB resident.  After connections are accepted it begins 
using memory in chunks specified in the read() function until it reaches ~6-6.5MB 
(varies with each run), at which time it continues to run without allocating more 
memory.

---

[2001-04-18 15:27:25] [EMAIL PROTECTED]
Using the  following code:



(The function procMsg() is not relevent as for bug testing is set to return 'test')

Running this script causes memory to be consumed and not released with each 
connection.  I've narrowed the problem down to the read() function as I can affect the 
rate of memory consumption by modifying the length argument.  Evidently the buffer is 
not freed.



---


Full Bug description available at: http://bugs.php.net/?id=10384


-- 
PHP Development Mailing List 
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]

> >I really don't think that this should be something to strive for.  There
> >should be a really really good reason for making changes that break
> >backward compatibility.  We have that second version number reserved for
> >such BC breaking changes that don't involve a huge rewrite (which is what
> >the first version number is for).  And yes, we have been very afraid to
> >make such changes, as we should be!  And the fact that we have never had a
> >.1 is an indication of just how unwilling we have been to make such
> >changes.  I see this as a success and not as a failure.  Imagine writing a
>
> 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.

-Rasmus


-- 
PHP Development Mailing List 
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()

[Cynic]

At 06:56 17.5. 2001 -0700, [EMAIL PROTECTED] wrote:
> > >Being antagonistically sarcastic won't win you any friends, Jani.
> >
> > If I wanted friends, I'd get a dog.. :)
> >
> > >As far as your question about the version numbers, the middle digit gets
> > >bumped up when we plan some changes that will break backwards
> > >compatibility and implement features in the core language. So, yes, it
> > >is something special, it's not for bug fixes or extension changes.
> >
> > Exactly. As we now agree with it, let's get busy and start breaking
> > things! :)
>
>I really don't think that this should be something to strive for.  There
>should be a really really good reason for making changes that break
>backward compatibility.  We have that second version number reserved for
>such BC breaking changes that don't involve a huge rewrite (which is what
>the first version number is for).  And yes, we have been very afraid to
>make such changes, as we should be!  And the fact that we have never had a
>.1 is an indication of just how unwilling we have been to make such
>changes.  I see this as a success and not as a failure.  Imagine writing a

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?

>PHP package and having to indicate that this package will work on PHP
>4.0.x, not 4.1.x and 4.2.x, but 4.3.x is fine.
>
>But, if a good case can be made for such changes, or if we have a large
>set of feature changes, then sure, let's use that second version number.
>It isn't a rule written instone that the second version number is
>exclusively for BC-breaking changes.  That's just what we have done so
>far.
>
>-Rasmus
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]



[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
 - Book of Installation chapt 3 sec 7 


-- 
PHP Development Mailing List 
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 #10926: Access Violation, reboot and then OCI no longer works

[sylvain_baudoin]

From: [EMAIL PROTECTED]
Operating system: NT4.0 Server PL5
PHP version:  4.0.4pl1
PHP Bug Type: OCI8 related
Bug description:  Access Violation, reboot and then OCI no longer works

First of all, I don't know if and how this bug is reproductible.

I've been using IIS 4 with PHP as an ISAPI module for 2 weeks, and I've just got this 
problem yesterday and today. Everything seems to work fine when I use OCI (Oracle 
8.0.5), and suddenly, the web server sends an Access Violation message, and then it is 
no longer possible to use it. I stop it and restart it, then I can access "normal" PHP 
pages (without any OCI function), but not pages that contain OCI functions. Yesterday, 
I had to restart my machine twice before being able to use OCI again.

I tried yesterday to use php.exe to check out errors, but then I had a surprise: PHP 
returns the well-known "ORA-12154" error message, whereas my web server was working 
fine again...

Any clue? I was not able to upgrade PHP (IIS seems not to be able to find a library).


-- 
Edit Bug report at: http://bugs.php.net/?id=10926&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]