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

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" <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