Re: issue in copying the hash table(Reposted third time)

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" <moriyoshi@at.wakwak.com> 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 >