RE: [PHP-DEV] zend questions and bug #15333

[Rose, Billy]

Is this using the Microsoft libraries? If so, I have encountered similar
string function problems while creating an NT service. In the MS libs,
strings are handled as 32 bit integers with any odd bytes masked off at the
end of the string. The rep counter increments 4 times per iteration until
odd bytes are encountered. I worked around this by writing my own string
copy function.

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 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] zend questions and bug #15333

[Rose, Billy]

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 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] zend questions and bug #15333

[Joseph Tate]

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

RE: [PHP-DEV] zend questions and bug #15333

[Rose, Billy]

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

RE: [PHP-DEV] zend questions and bug #15333

[Joseph Tate]

I've looked at it in the debugger immediately before the access violation
and have found that both the pointer to the char* to be copied and the
length are garbage, so it's not the lib.

> -Original Message-
> From: Rose, Billy [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 09, 2002 3:29 PM
> To: 'Joseph Tate'; Rose, Billy; Php-Dev List
> Subject: RE: [PHP-DEV] zend questions and bug #15333
>
>
> 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
> > 100 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
> > > &