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

Reply via email to