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
