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
