In your stack dump, the function call that bombed was memcpy in the MS lib. Looking at the source in zend_alloc.c, I find that the lib's memcpy function is used. The way I finally tracked down my problem was tedious as hell, but I put the MS debug macro just before the function that was failing (in this case zend_strndup). Then I single stepped into the MS function that was failing. This method was required because I was running a service. I bet if you write an adhoc my_memcpy function in C and byte for byte copy over the string, the problem goes away. memcpy uses the same 32 bit algorothm as the string functions. I sent in a bug report to MS about a year ago, but was blown off (swept under the rug rather perhaps?). The algorithm seems to blow up only under weird circumstances.
Billy Rose [EMAIL PROTECTED] > -----Original Message----- > From: Joseph Tate [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 09, 2002 2:05 PM > To: Rose, Billy; Php-Dev List > Subject: RE: [PHP-DEV] zend questions and bug #15333 > > > zend_strndup is a php implementation. It does not use the > strndup function > available through MS's library. The problem occurs because a > length of > 1000000 or more is passed in, signifying to me that the source of that > length has become corrupted or not initialized. I've traced > that back to > the global_constants_table structure. I no longer get the > specific error > mentioned in the bug report, but get an error in the same > location under the > same circumstances. My error looks like the following: > > The HTTP server encountered an unhandled exception while > processing the > ISAPI Application ' > msvcrt!memcpy + 0x33 > php4ts!zend_strndup + 0x38 > php4ts!zend_get_extension + 0xA0 > php4ts!zend_hash_copy + 0x7B > php4ts!zend_get_extension + 0xFB > php4ts!zend_print_zval_r_ex + 0x999 > php4ts!ts_resource_ex + 0x21F > php4ts!ts_resource_ex + 0x98 > php4isapi!HttpExtensionProc + 0x37 > wam + 0x7A91 > wam + 0x8634 > RPCRT4!NdrServerInitialize + 0x45B > RPCRT4!NdrStubCall2 + 0x1A5 > RPCRT4!CStdStubBuffer_Invoke + 0x82 > ole32!StgGetIFillLockBytesOnFile + 0xA270 > ole32!StgGetIFillLockBytesOnFile + 0xA21F > ole32!CoImpersonateClient + 0x1B8 > + 0xFF6C8BE0 > + 0x1132AE13 > '. > > Of course I'm using the Release_TSDbg version of php4isapi > rather than a > release, so that's why I have a stack trace. All of this is with the > current PHP_4_2_0 release branch. > > Joseph > > > -----Original Message----- > > From: Rose, Billy [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 09, 2002 2:54 PM > > To: 'Joseph Tate'; Php-Dev List > > Subject: RE: [PHP-DEV] zend questions and bug #15333 > > > > > > Forgot to mention, the algorithm in the MS lib is what is faulty. It > > overruns the buffer at times. > > > > Billy Rose > > [EMAIL PROTECTED] > > > > > -----Original Message----- > > > From: Joseph Tate [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, April 09, 2002 1:41 PM > > > To: Php-Dev List > > > Subject: [PHP-DEV] zend questions and bug #15333 > > > > > > > > > http://bugs.php.net/15333 > > > > > > I've narrowed down the problem, but can't seem to get > > > anywhere with it. > > > > > > The state of the server when the problem occurrs: > > > > > > All serviceable threads have been killed or have timed out. > > > A request is received prompting the spawning of a new thread. > > > The new thread then goes through and copies the > > > global_constants_table, but > > > that has been corrupted somewhere causing an access violation > > > when trying to > > > dereference uninitialized memory. > > > > > > This happens every time the server has been idle for ~10 > minutes after > > > serving up php pages. > > > > > > Here are my questions that I haven't been able to track down > > > yet. Hopefully > > > someone can save me some time. > > > > > > 1. What code is executed when a thread times out? > > > zend_shutdown never seems > > > to run (or at least my breakpoints there never fire). > > > > > > 2. It appears that global_constants_table is not global > > > nor constant, each > > > thread has a separate copy. Why is this the case? And if it > > > is meant to > > > be, where is the original global_constants_table. What could > > > be modifying > > > it so that it cannot be copied when a new thread is started? > > > > > > 3. Where would be a good place to start to find the > > > answers to the zend > > > questions that I have as I track this down. > > > > > > > > > -- > > > PHP Development Mailing List <http://www.php.net/> > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
