[PHP-DEV] Memory allocation problems

[Edin Kadribasic]

I have a script that allocates a lot of memory (huge associative arrays). 
The problem is that this scripts bails out with fatal error (emalloc 
unable to allocate 44 bytes) when I hit the limit of physical ram in the 
machine. Swap never gets used. The machine has 1 GB of ram and 2 GB of 
swap space.

Has anyone seen something like this before? Are there any limitations in 
the PHP memory allocation code that would prevent it from being able to 
use more memory.

Edin



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

[Harald Radi]

"Sascha Schumann" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:<[EMAIL PROTECTED]>...
> > you're propably a bit too optimistic, i can hardly imagine that all
existing
> > extensions all over the world compile out of the box against ZE2. i guess
only
> > a handful do this.
> 
> Apparently, most of the extensions PHP ships with seem to
> work out of the box.  I'm under the impression that almost no
> changes are required, unless you directly manipulate objects.
> That brings up the question -- do we have some documentation
> for extension authors which covers necessary changes.

but there are lots that manipulate objects (e.g. all the sql exts have
*_fetch_object). they compile fine but those methods won't work and propably
crash php.
afaik there is no documentation beside the OBJECTS2_HOWTO in cvs. so use the
source, luke.

> 
> > the only thing that should be realized is that compiler warnings are still
a
> > bad thing(tm). i don't see any difference in this compared to changing the
> > number of arguments of a function.
> 
> There is an important difference regarding developer
> awareness:
> 
> No. of args change: The compiler will always bail out.
> Developer knows: Aha, I need to fix something.
> 
> Signedness change: The compiler might issue a warning or not.
> Developer knows: Usually nothing.

maybe we should change _that_ ?

> 
> There are so many signedness issues in ext/standard alone,
> that I would not want to run with such warnings enabled.

that's a bad attitude and leads to bad code. i can show you lots of different
types of warnings which would result in runtime errors and segfaults, but you
surely know them best.

but as my patch is already partially reverted and strlen is no longer uint we
can stop here too.

harald.


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] request data filter

[Maxim Maletsky]

Rasmus Lerdorf <[EMAIL PROTECTED]> wrote... :

> this would likely have different security policies, but I do think a 
> general hook is something that would be useful to all of PHP.
> 
> A huge number of web apps today are extremely vulnerable to
> cross-site-scripting attacks.  Occasionally developers remember to clean
> their data before displaying it, but for the most part they don't.  Take
> half and hour and find yourself a collection of sites where you can enter
> data that is somehow displayed back to you.  Shopping carts that ask for
> your name and phone number, or half of php.net's own stuff.  Stick a bit
> of javascript in your phone number and watch.


Just a little note here.

The government project I am working on was attacked on New Year's night
with XSS. Therefore, after we fixed it we decided to see what else is
vulnerable oiut there.

During the last two weeks I have played with a variaty of
sites/portals/apps trying to hack them to see how far I can go. I ended
up stealing the sessions of any  installations, changing the
passwords on  main website and could see the list of passwords in
pain user:pass format assigned as a cookie to anyone who sees my message
on ***.

Now, every *** was notified by me and, till they all will fix these, I
will try not to reveal their names.

What I think PHP should have is a function of a whole extension which
parses the output in various ways cleaning XSS in it.

Also, having such functionality in PHP would help it looking more secure
as XSS affects any programming language and not namy have such
protections.



--
Maxim Maletsky
[EMAIL PROTECTED]



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] jpeg2000 in php 4.3

[Adam Wright]

I've completed a short patch which cleans up the JPEG 2000 raw codestream
support ("j2c", though I've renamed it jpeg2000 in the file for clarity) in
getimagesize. It also adds JP2 support. I've put a context diff of it
against 4.3.x-dev from this morning up at...

http://www.j2g.org/patches/jpeg2000imgdiff.patch

Small changes have been made to ext/standard/php_image.h with 99% of the
work in ext/standard/image.c. I've tried to apply CODING_STANDARDS, but it's
probable I've messed up somewhere so I'm happy to make any changes or
regenerate the diffs in other formats.

If this gets applied, it might be worth adding something like the following
to the documentation.

"Note that JPEG 2000 and JP2 are capable of having components with differing
bit depths. In this case, the value for "bits" is the highest bit depth
encountered. Also, JP2 files can contain multiple JPEG 2000 codestreams. In
this case, getimagesize returns the values for the first codestream it
encounters in the root of the file."

Hope it's useful.

adamw
[EMAIL PROTECTED]

PS - I looked around but couldn't find any patch submission guidelines. Is
there a page people should read first?

- Original Message -
From: "Marcus Börger" <[EMAIL PROTECTED]>
To: "Adaloglou Maria" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, January 10, 2003 11:31 AM
Subject: Re: [PHP-DEV] jpeg2000 in php 4.3


> At 10:10 10.01.2003, Adaloglou Maria wrote:
> >As I have read in the manual about the getimagesize function that
> >"Note: JPEG2000 support will be added in PHP 4.3. "
> >Do you know if it is supported finaly?
>
> No - at the moment there is only support for jpc.
> sorry i haven't yet the time to read through the complete
> jpeg2000 specs.
>
> marcus
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] request data filter

[Moriyoshi Koizumi]

It looks like a mess indeed, and there seems a thought that
encoding conversion and variable registration should be separated
into two phases. However doing so doesn't make sense because
some of multibyte characters contains "[", "]", or "=" and they cannot
be handled properly in the ordinary query parser. Therefore Rasmus's
sugestion sounds quite logical to me.

Moriyoshi 


On Wed, Jan 15, 2003 at 04:52:58PM -0800, Rasmus Lerdorf wrote:
> In trying to implement a security policy I need to pass all user-supplied
> data (GET/POST/Cookie) through a filter function which implements this
> security.  This isn't all that hard to implement as an extension through
> new 4.3 treat_data and post_handler hooks, however it gets messy when you
> throw mbstring into the mix as that extension also uses those hooks.
> 
> The cleanest way I can think of doing this is to add a function pointer to 
> SAPI for the filtering function that will be run right before the 
> php_register_variable_safe() call.  Currently we are always calling 
> php_url_decode() on the data before registering the variable, so I propose 
> that we make php_url_decode() the default that an extension can then 
> override.
> 
> Anybody see any reason not to make this simple change?  Without that I 
> will need to somehow detect whether mbstring is present and then filter 
> the data after it has already been registered by mbstring's 
> treat_data/post_handler hooks.  That's a big mess!
> 
> -Rasmus
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] request data filter

[Zeev Suraski]

At 02:52 16/01/2003, Rasmus Lerdorf wrote:

In trying to implement a security policy I need to pass all user-supplied
data (GET/POST/Cookie) through a filter function which implements this
security.  This isn't all that hard to implement as an extension through
new 4.3 treat_data and post_handler hooks, however it gets messy when you
throw mbstring into the mix as that extension also uses those hooks.

The cleanest way I can think of doing this is to add a function pointer to
SAPI for the filtering function that will be run right before the
php_register_variable_safe() call.  Currently we are always calling
php_url_decode() on the data before registering the variable, so I propose
that we make php_url_decode() the default that an extension can then
override.

Anybody see any reason not to make this simple change?  Without that I
will need to somehow detect whether mbstring is present and then filter
the data after it has already been registered by mbstring's
treat_data/post_handler hooks.  That's a big mess!


Sounds good to me.

Zeev


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Memory allocation problems

[Greg Beaver]

phpDocumentor (http://www.phpdoc.org) has had problems with this as well.
PHP often doesn't give a fatal error, but instead segfaults.  As of php
4.3.0, we aren't seeing any crashes, but haven't done extensive testing on
the cvs, as we are not yet near a full release.

Greg

"Edin Kadribasic" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> I have a script that allocates a lot of memory (huge associative arrays).
> The problem is that this scripts bails out with fatal error (emalloc
> unable to allocate 44 bytes) when I hit the limit of physical ram in the
> machine. Swap never gets used. The machine has 1 GB of ram and 2 GB of
> swap space.
>
> Has anyone seen something like this before? Are there any limitations in
> the PHP memory allocation code that would prevent it from being able to
> use more memory.
>
> Edin
>
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Win32 builds dead?

[Dan Kalowsky]

Seem to be dead on building ext/rpc (fresh CVS).

ext/rpc/php_rpc.h(45) : error C2061: syntax error : indentifier 
'rpc_objects_new'
ext/rpc/php_rpc.h(45) : error C2059: syntax error : ';'
ext/rpc/php_rpc.h(45) : error C2059: syntax error : 'type'

>---<
Dan Kalowsky"I've learned to fake it,
http://www.deadmime.org/~dankand just smile along."
[EMAIL PROTECTED]- "Candy",
[EMAIL PROTECTED]  Iggy Pop


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] SNMP value retrieval

[Harrie Hazewinkel]

HI,

Just a notice that I am not ignoring it.
I am looking into it and try to understand it.

On Tuesday, January 14, 2003, at 08:19 PM, Johann Hanne wrote:



Hi,

The patch makes it much easier to parse the returned SNMP values, as 
they
are no longer pre-parsed by the net-snmp library after you have set
SNMP_VALUEMETHOD_PLAIN.

That is a good feature, since using the string is somehow cumbersome
if you do want to process the values.


 I've attached a simple PHP script which should
make the new functionality even clearer.


Just to help me, what do you mean by pre-parsed??
The name translation from a type and value to string expression
the type and value??

Harrie
--
Author of MOD-SNMP, enabling SNMP management of Apache HTTP server


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)

[Shane Caraveo]

As a matter of fact I think it would be good idea to go for 4.3.1 in
February because number of bugfixes in PHP_4_3 branch is already significant
and since no major new features have been added there the QA process
shouldn't take that long either.




And I have a pretty bad bug I'm still trying to repro (just got access 
to a box with the bug) that needs to get into a 4.3.1.

There were some, for example Sascha's addition. This alone would qualify 
a full QA, and not a short and fast one. Our general idea was to NOT add 
new code to release branches, but at the moment developers are still 
doing this because *they* need a new function and dont want to wait for 
5.0.0. I can understand that they dont want to wait for PHP 5, but what 
I dont understand is that they think less about the general stability 
and QA processes for the PHP 4.3.x series. 

Derick

And thus the need to have a pure 4_3 tree that 4_3_1 can be branched 
from.  Those people who need to add new features can do so on 4_3_head, 
but they might not ever make it into an official 4.x release depending 
on QA and the time cycle for 5.

Shane



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory allocation problems

[Marcus Börger]

At 11:38 16.01.2003, Edin Kadribasic wrote:

I have a script that allocates a lot of memory (huge associative arrays).
The problem is that this scripts bails out with fatal error (emalloc
unable to allocate 44 bytes) when I hit the limit of physical ram in the
machine. Swap never gets used. The machine has 1 GB of ram and 2 GB of
swap space.



I suppose you use some windows machine. I remember that all application have
only 1GB of RAM for their own until you have a windows server version and that
has an appropriate HAL and is configured to have more than 1gig.

marcus


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] SNMP value retrieval

[Johann Hanne]

Hi Harrie,

thanks for the reply. I nearly began to believe that it *IS* ignored ;-)

Cheers, Jonny <[EMAIL PROTECTED]>

On Thu, 16 Jan 2003, Harrie Hazewinkel wrote:

> HI,
> 
> Just a notice that I am not ignoring it.
> I am looking into it and try to understand it.
> 
> On Tuesday, January 14, 2003, at 08:19 PM, Johann Hanne wrote:
> 
> >
> > Hi,
> >
> > The patch makes it much easier to parse the returned SNMP values, as 
> > they
> > are no longer pre-parsed by the net-snmp library after you have set
> > SNMP_VALUEMETHOD_PLAIN.
> 
> That is a good feature, since using the string is somehow cumbersome
> if you do want to process the values.
> 
> >  I've attached a simple PHP script which should
> > make the new functionality even clearer.
> 
> Just to help me, what do you mean by pre-parsed??
> The name translation from a type and value to string expression
> the type and value??
> 
> Harrie
> --
> Author of MOD-SNMP, enabling SNMP management of Apache HTTP server
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] jpeg2000 in php 4.3

[Marcus Börger]

At 13:50 16.01.2003, Adam Wright wrote:

I've completed a short patch which cleans up the JPEG 2000 raw codestream
support ("j2c", though I've renamed it jpeg2000 in the file for clarity) in
getimagesize. It also adds JP2 support. I've put a context diff of it
against 4.3.x-dev from this morning up at...


I have just updated my HEAD version and did a few changes and it works
very well.


Small changes have been made to ext/standard/php_image.h with 99% of the
work in ext/standard/image.c. I've tried to apply CODING_STANDARDS, but it's
probable I've messed up somewhere so I'm happy to make any changes or
regenerate the diffs in other formats.


You did good coding and style (but we prefer unified diffs "diff -u").


If this gets applied, it might be worth adding something like the following
to the documentation.


It will be but it is to be discussed if it will go into 4.3.1: I'd say yes 
because
the note in the manual.

"Note that JPEG 2000 and JP2 are capable of having components with differing
bit depths. In this case, the value for "bits" is the highest bit depth
encountered. Also, JP2 files can contain multiple JPEG 2000 codestreams. In
this case, getimagesize returns the values for the first codestream it
encounters in the root of the file."


Yes such a note may be useful.


Hope it's useful.

adamw
[EMAIL PROTECTED]

PS - I looked around but couldn't find any patch submission guidelines. Is
there a page people should read first?


As said above diff -u is prefered.

regards & thanks
marcus

by the way:could you send me a 1 x 1 jp2 file, because i am not able to produce
one my self?



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] request data filter

[Ivan Ristic]

I suppose I could munge with the apache tables directly in a hook before
the data is read by the standard treat_data hook, although for post data I
am not sure I have any way to get in there before the
ap_get_client_block() call and change what data ap_get_client_block() is
going to see.


  I don't think there's a way to do that with Apache 1.x. Would
  mod_security (http://www.webkreator.com/mod_security/) solve
  your problem? It is an Apache module that sits between the
  browser and the script, watching the data flowing by (I patch
  the core Apache engine to get to the POST data). I am not changing
  the data at the moment, but was planning to introduce the feature
  some time in the future.



The main goal here, in case it wasn't obvious, is to prevent
cross-site-scripting problems by forcing all user-originating data to be
cleaned automatically and providing a hoop to jump through in case the
developer really does want the raw uncleaned data.  It isn't something
that belongs in PHP directly as every site that would be interested in
this would likely have different security policies, but I do think a 
general hook is something that would be useful to all of PHP.

  I cannot agree more. There is only so much you can do outside
  the PHP (as I do in mod_security).


Bye,
Ivan


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] request data filter

[Rasmus Lerdorf]

>I cannot agree more. There is only so much you can do outside
>the PHP (as I do in mod_security).

I've finished the code.  I'll run it through its paces here and commit it 
soon.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main config.w32.h internal_functions_win32.c

[Sebastian Bergmann]

Harald Radi wrote:
> phantoThu Jan 16 17:09:58 2003 EDT
>
>   Modified files:
> /php4/mainconfig.w32.h internal_functions_win32.c
>   Log:
>   move the ZE2 check into internal_functions_win32.c

  I'm trying to build HEAD + ZendEngine 2 here, but get the

HEAD does not work with ZendEngine1 anymore

  error.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main config.w32.h internal_functions_win32.c

[Sebastian Bergmann]

Sebastian Bergmann wrote:
> I'm trying to build HEAD + ZendEngine 2 here, but get the
>
>   HEAD does not work with ZendEngine1 anymore
>
> error.

  Fixed in CVS.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php