Could this be a bug?
in [General]
|
From: Thijs Lensselink on 14 Sep 2010 02:46 On 09/14/2010 08:33 AM, Thijs Lensselink wrote: > On 09/14/2010 12:16 AM, Camilo Sperberg wrote: >> I have some really strange behaviour going on here, and I think it >> could be >> a (minor) PHP's bug. >> I am not really sure about what happens internally, but my best guess >> would >> be that after a memory exhaustion, when I try to execute a custom error >> handler with the register_shutdown_function (which is executed even >> after a >> fatal error) and try to access the element that provoked the memory >> exhaustion, no error should raise instead of *Uninitialized string >> offset: >> 0. >> >> I have prepared a little test case to reproduce the error and (I >> hope) can >> explain the error. >> >> <?php >> date_default_timezone_set('America/Santiago'); >> ini_set('memory_limit','1M'); >> ini_set('display_errors',1); >> error_reporting(-1); >> >> function my_error_handler($errno = '0', $errstr = '[FATAL] General >> Error', >> $errfile = 'N/A', $errline = 'N/A', $errctx = '') { This seems to be your error. You set $errctx to be a string. But later on you use it as an array. Remove the = '' part. And it will function as expected. >> global $clean_exit; >> if(empty($clean_exit)) { >> ini_set('memory_limit','16M'); >> ob_start(); >> echo '<h1>PHP v'.PHP_VERSION.', error N° '.$errno.'</h1>'; >> ?><h4>-- BEGIN COPY --</h4><p style="font-size:110%;margin:50px 0 20px >> 25px"><em>Error N°:</em><br /><?php >> echo '<strong>'.$errno.'</strong><br />'; >> ?><em>Error Detail:</em><br /><?php >> echo '<strong>'.$errstr.'</strong><br /><em>File:</em><br >> /><strong>'.$errfile.'</strong><br /><em>Line:</em><br >> /><strong>'.$errline.'</strong><br /><em>Debug:</em><br />'; >> if (isset($errctx['r']['print'])) echo '<p>THIS LINE GIVES THE >> ERROR, >> WHAT SHOULD IT RETURN?</p>'; > > Maybe i'm missing something here (kinda sick at home) but.. > What do you expect to happen here? When i do a var_dump() on $errctx i > get > > string(0) "" > > That would explain the error you are seeing. > >> ?></p><h4>-- END COPY --</h4><?php >> $content = ob_get_contents(); >> ob_end_clean(); >> die($content); >> } >> } >> set_error_handler('my_error_handler'); >> register_shutdown_function('my_error_handler'); >> >> for ($i = 0; $i< 10000; $i++) $a[$i] = mt_rand(1,254); >> $r['print'] = print_r($a,TRUE); >> echo '<p>Everything fine.</p>'; >> >> $clean_exit = TRUE; >> >> * >> Would this be a bug or is this expected behaviour? I have tested this >> on PHP >> v5.2.14, I've not tested it yet on 5.3.3, but I guess it would have >> the same >> behaviour. >> >> Greetings! >> > >
From: Camilo Sperberg on 14 Sep 2010 17:31 On Tue, Sep 14, 2010 at 02:46, Thijs Lensselink <dev(a)lenss.nl> wrote: > On 09/14/2010 08:33 AM, Thijs Lensselink wrote: > >> On 09/14/2010 12:16 AM, Camilo Sperberg wrote: >> >>> I have some really strange behaviour going on here, and I think it could >>> be >>> a (minor) PHP's bug. >>> I am not really sure about what happens internally, but my best guess >>> would >>> be that after a memory exhaustion, when I try to execute a custom error >>> handler with the register_shutdown_function (which is executed even after >>> a >>> fatal error) and try to access the element that provoked the memory >>> exhaustion, no error should raise instead of *Uninitialized string >>> offset: >>> 0. >>> >>> I have prepared a little test case to reproduce the error and (I hope) >>> can >>> explain the error. >>> >>> <?php >>> date_default_timezone_set('America/Santiago'); >>> ini_set('memory_limit','1M'); >>> ini_set('display_errors',1); >>> error_reporting(-1); >>> >>> function my_error_handler($errno = '0', $errstr = '[FATAL] General >>> Error', >>> $errfile = 'N/A', $errline = 'N/A', $errctx = '') { >>> >> > This seems to be your error. You set $errctx to be a string. But later on > you use it as an array. > Remove the = '' part. And it will function as expected. You're right... However I don't like leaving non-default value in functions so I did something like if(empty($errctx)) $errctx = array() in the first line of the custom error handler which threw out the error message and everything works ok now. But -and correct me if I'm wrong- isn't isset (or empty) supposed to return a FALSE whenever that variable doesn't exist? With your help, I could reduce the test case into: $asdf = 'hello world'; if (empty($asdf[4]['inventing'])) echo 'nice little world'; if (isset($asdf['inventing'][6])) echo 'little nice world'; // This works ok. $asdf = ''; if (empty($asdf[4]['inventing'])) echo 'nice little world'; if (isset($asdf['inventing'][6])) echo 'little nice world'; // This returns E_NOTICE Shouldn't these 2 examples work exactly the same way? (AKA as Nº 1). If not... why not? Both are string types, onyl difference is that one has no characters in it while the other does, but essentialy they are both the same. Greetings ! -- Mailed by: UnReAl4U - unreal4u ICQ #: 54472056 www1: http://www.chw.net/ www2: http://unreal4u.com/
From: Thijs Lensselink on 15 Sep 2010 02:17
On 09/14/2010 11:31 PM, Camilo Sperberg wrote: > On Tue, Sep 14, 2010 at 02:46, Thijs Lensselink<dev(a)lenss.nl> wrote: > >> On 09/14/2010 08:33 AM, Thijs Lensselink wrote: >> >>> On 09/14/2010 12:16 AM, Camilo Sperberg wrote: >>> >>>> I have some really strange behaviour going on here, and I think it could >>>> be >>>> a (minor) PHP's bug. >>>> I am not really sure about what happens internally, but my best guess >>>> would >>>> be that after a memory exhaustion, when I try to execute a custom error >>>> handler with the register_shutdown_function (which is executed even after >>>> a >>>> fatal error) and try to access the element that provoked the memory >>>> exhaustion, no error should raise instead of *Uninitialized string >>>> offset: >>>> 0. >>>> >>>> I have prepared a little test case to reproduce the error and (I hope) >>>> can >>>> explain the error. >>>> >>>> <?php >>>> date_default_timezone_set('America/Santiago'); >>>> ini_set('memory_limit','1M'); >>>> ini_set('display_errors',1); >>>> error_reporting(-1); >>>> >>>> function my_error_handler($errno = '0', $errstr = '[FATAL] General >>>> Error', >>>> $errfile = 'N/A', $errline = 'N/A', $errctx = '') { >>>> >> This seems to be your error. You set $errctx to be a string. But later on >> you use it as an array. >> Remove the = '' part. And it will function as expected. > > You're right... However I don't like leaving non-default value in functions > so I did something like if(empty($errctx)) $errctx = array() in the first > line of the custom error handler which threw out the error message and > everything works ok now. I think from 5.2 and up you can use the array keyword to force an array as parameter.. > But -and correct me if I'm wrong- isn't isset (or empty) supposed to return > a FALSE whenever that variable doesn't exist? > > With your help, I could reduce the test case into: > > $asdf = 'hello world'; > if (empty($asdf[4]['inventing'])) echo 'nice little world'; > if (isset($asdf['inventing'][6])) echo 'little nice world'; > // This works ok. This works because the string $asdf is set with a value. So $asdf[4] exists but ['inventing'] doesn't so it will return false > $asdf = ''; > if (empty($asdf[4]['inventing'])) echo 'nice little world'; > if (isset($asdf['inventing'][6])) echo 'little nice world'; > // This returns E_NOTICE This doesn't work because the string $asdf is empty. So calling $asdf[4] will trigger a notice since there is no 4th character > Shouldn't these 2 examples work exactly the same way? (AKA as N� 1). If > not... why not? Both are string types, onyl difference is that one has no > characters in it while the other does, but essentialy they are both the > same. > > Greetings ! > |