Justtechjobs.com Find a programming school near you






Online Campus Both


php4-beta | 199912

Re: [PHP4BETA] ABR: Array bounds read in ZTS mode + explanation. From: Andi Gutmans (andi <email protected>)
Date: 12/27/99

Thies can you please check if my patch fixes the problem?

Andi

On Mon, 27 Dec 1999, Andi Gutmans wrote:

> On Mon, 27 Dec 1999, Thies C. Arntzen wrote:
>
> > On Mon, 27 Dec 1999, Zeev Suraski wrote:
> >
> > > On Mon, 27 Dec 1999, Thies C. Arntzen wrote:
> > >
> > > > **** Purify instrumented bin/nsd (pid 22145) ****
> > > > ABR: Array bounds read (9440 times):
> > > > * This is occurring while in thread 10:
> > > > memcpy [rtlib.o]
> > > > zend_hash_copy [zend_hash.c:861]
> > > > compiler_globals_ctor [zend.c:247]
> > > > allocate_new_resource [TSRM.c:200]
> > > > ts_resource [TSRM.c:235]
> > > > php_ns_request_handler [aolserver.c:500]
> > > > * Reading 60 bytes from 0x264ec8 in the heap (44 bytes at 0x264ed8 illegal).
> > > > * Address 0x264ec8 is at the beginning of a malloc'd block of 16 bytes.
> > > > * This block was allocated from:
> > > > malloc [rtlib.o]
> > > > zend_hash_add_or_update [zend_hash.c:189]
> > > > zend_register_functions [zend_API.c:698]
> > > > zend_startup_builtin_functions [zend_builtin_functions.c:78]
> > > > zend_startup [zend.c:363]
> > > >
> > > > problem is :
> > > >
> > > > zend_API.c line 698
> > > > if (zend_hash_add(target_function_table, ptr->fname, strlen(ptr->fname)+1, &internal_function, sizeof(zend_internal_function), NULL) == FAILURE) {
> > > > unload=1;
> > > > break;
> > > > }
> > > >
> > > > zend.c line 238:
> > > > zend_hash_copy(compiler_globals->function_table, global_function_table, NULL, &tmp_func, sizeof(zend_function));
> > > >
> > > >
> > > > but: sizeof(zend_function) > sizeof(zend_internal_function) so we're
> > > > coying uninted memory (as purify tells us) in compiler_globals_ctor().
> > >
> > > Well, that's one of the places that purify reports, correctly from its
> > > point of view, but that we really don't care about.
> >
> > reading beyond a malloced block is not considered safe AFAIK. it is very,
> > very unlikely but it could cause trouble. i can easily live with it, but
> > i think it's bad style. how bad would be the penalty if we tried for a
> > clean solution?
>
> We will clean it up.
>
> Andi
>
>
> 

-- 
PHP 4.0 Beta Mailing List <http://www.php.net/version4/>
To unsubscribe, e-mail: php4beta-unsubscribe <email protected>
For additional commands, e-mail: php4beta-help <email protected>
To contact the list administrators, e-mail: php4beta-admin <email protected>