I could not see the patch yet.
With regards
Kamesh Jayachandran
On Sun, 11 Jul 2004 23:26:54 -0700, "Andi Gutmans" <[EMAIL PROTECTED]> said:
> You seem to be right. I commited a patch. Please take a look and see if
> it
> solves your problems.
>
> At 11:02 PM 7/11/2004 -0700, Kamesh Jayachandran wrote:
> >Hi Moriyoshi,
> >Fine.
> >Correcting myself.
> >Only once global_class_table is allocated and each thread just
> >increments the individual zend_class_entry while making a copy.
> >
> >In linux I never faced the problem.
> >
> >I can not say it as a problem with NetWare.
> >As per concept trying to copy sizeof(zend_class_entry) from some source
> >address where we are ensured of only sizeof(zend_class_entry*) bytes of
> >memory is illegal.
> >
> >Even though the code works in Linux without any issues as of now. There
> >is a good chance of segfaulting in the future.
> >
> >One more issue we allocate sizeof(zend_class_entry) where as we need
> >only sizeof(zend_class_entry*)(Wastage of 292-4=288 bytes).
> >
> >Please correct me if I am wrong.
> >
> >
> >With regards
> >Kamesh Jayachandran
> >
> >
> >On Sat, 10 Jul 2004 22:59:32 +0900, "Moriyoshi Koizumi"
> ><[EMAIL PROTECTED]> said:
> > >
> > > On 2004/07/08, at 19:16, Kamesh Jayachandran wrote:
> > >
> > > > Hi Moriyoshi,
> > > > Sorry to copy the INIT_DATA macro in the mail.
> > > > #define INIT_DATA(ht, p, pData, nDataSize)
> > > > if (nDataSize == sizeof(void*)) {
> > > > memcpy(&(p)->pDataPtr, pData, sizeof(void *));
> > > > (p)->pData = &(p)->pDataPtr;
> > > > } else {
> > > > (p)->pData = (void *) pemalloc_rel(nDataSize,
> > > > (ht)->persistent);
> > > > if (!(p)->pData) {
> > > > pefree_rel(p, (ht)->persistent);
> > > > return
> > FAILURE;
> > }
> > memcpy((p)->pData, pData,
> > > > nDataSize);
> > > > (p)->pDataPtr=NULL;
> > }
> > > >
> > > > In case of deep copy the global_class_table,
> > > > For each class entry in the hash table, We call the above macro
> > > > INIT_DATA which allocates nDataSize( in this case 292) bytes for
> > > > zend_class_entry. We copy the corressponding entry(INIT_DATA).
> > >
> > > I don't know what you exactly mean by the word "deep copy",
> > > whether zend_hash_copy() duplicates the holding
> > > elements' instances themselves or not depends on the behaviour of the
> > > call
> > > back function passed to it. As for class entries, the call back just
> > > increases
> > > the reference counters and doesn't do the deep because the properties of
> > > entries will change in rare cases and it would be enough.
> > >
> > > > But the problem is in the NetWare port as I am not able copy the 292
> > > > bytes as the way with linux. The source address goes beyond my process
> > > > address space and I am getting segmentation fault.
> > >
> > > In this case each element is a pointer to a zend_class_entry
> > > instance which is allocated in a "persistent" manner and shared
> > > across threads, therefore those pointers should never be
> > > obfuscated like a variable in a stack frame at least.
> > >
> > > Thus that seems like a NetWare specific problem, otherwise some piece
> > > of code that is subtly violating a certain part of the address space
> > > destroys the hash table.
> > >
> > > > What is the likelyhood of having similar seg fault in Linux?
> > >
> > > I didn't experienced such a problem yet. Can I see the backtrace or
> > > something similar that helps to track down your problem?
> > >
> > > Moriyoshi
> > >
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
