Re: #20070 [WFx->Csd]: PHPDoc unrestrained recursion seg. faults php

Again, this limitation is not present in phpDocumentor. http://www.phpdoc.org Greg <timmyg@php.net> wrote in message news:20021028224617.11446.qmail@rack1.php.net... > ID: 20070 > Updated by: timmyg@php.net > Reported By: mattb@columbia.edu > -Status: Won't fix > +Status: Closed > Bug Type: PEAR related > Operating System: GNU/Linux 2.4.18-17.7.x (RedHat) > PHP Version: 4.2.3 > New Comment: > > Thank you for taking the time to write to us, but this is not > a bug. Please double-check the documentation available at > http://www.php.net/manual/ and the instructions on how to > report > a bug at http://bugs.php.net/how-to-report.php > > This is expected behavior. Read the docs, do not mix procedural code > with classes. the file processes just fine when the defines are > removed, or the class is removed. try it. The only work-around I have > for this, is to put the defines after the class, but this (according to > the docs) is not supported behavior. > > > Previous Comments: > ------------------------------------------------------------------------ > > [2002-10-28 12:11:54] mattb@columbia.edu > > > Unrestrained resucrsion such as: > > function a() { a(); } a(); will always core until PHP implements > it's > > own stack, which is unlikely to ever happen. Therefor, you should > > either, not use recursive functions or harcode some sort of a > > recurssion limit if you are not certain about the maximum possible > > number of recursions. > > HUH?! phpdoc is calling one of its own functions recursively! How can I > possibly be responsible for avoiding recursion and stack allocation > when I'll i'm doing is running phpdoc on an input file to generate > documentation? > > I even provided the file that was causing it to do this in my bug > report. Did you even read it before marking it as "Won't fix"? I went > through a lot of effort to provide as much detail as I could to make > it as easy as possible to reproduce the problem and fix it. Did you > even try? > > Unrestrained recursion is a bug. Period. There's no valid outcome > regardless of the architecture to deal with it (PHP's own stack or > not). > > phpdoc is an incredibly buggy tool, and it is VERY delicate. How can > anyone expect it to become a standard in its current state if its bugs > are written off without any investigation? > > ------------------------------------------------------------------------ > > [2002-10-28 10:49:15] iliaa@php.net > > Unrestrained resucrsion such as: > function a() { a(); } a(); will always core until PHP implements it's > own stack, which is unlikely to ever happen. Therefor, you should > either, not use recursive functions or harcode some sort of a > recurssion limit if you are not certain about the maximum possible > number of recursions. > > ------------------------------------------------------------------------ > > [2002-10-24 13:39:52] mattb@columbia.edu > > I've created a class whose comments seems to cause PHP to seg. fault > when running PHPDoc. I've attached the file which causes the seg. fault > as well as the output from "php -i". Here are the PEAR files I have > installed: > > % pear list-installed > Installed packages: > =================== > +---------+---------+--------+ > | Package | Version | State | > | PHPDoc | 0.1.0 | beta | > | PHPUnit | 0.4 | stable | > +---------+---------+--------+ > > Here is the command I use to run phpdoc: > > % ls -a ~/php > . .. Base.php > % rm -fr /tmp/phpdoc ; phpdoc -s ~/php -d /tmp/phpdoc \ > -t $PHP_HOME/share/pear/PHPDoc > zsh: segmentation fault phpdoc ... > > I don't have debugging symbols compiled into my version of PHP, but GDB > shows would looks like unrestrained recursion happening: > > (no debugging symbols found)... > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1024 (LWP 1114)] > 0x080b06ef in ?? () > (gdb) bt > #0 0x080b06ef in ?? () > #1 0x080af0cc in ?? () > #2 0x080af9e1 in ?? () > #3 0x080af0cc in ?? () > #4 0x080af9e1 in ?? () > #5 0x080af0cc in ?? () > #6 0x080af9e1 in ?? () > #7 0x080af0cc in ?? () > #8 0x080af9e1 in ?? () > #9 0x080af0cc in ?? () > #10 0x080af9e1 in ?? () > #11 0x080af0cc in ?? () > #12 0x080af9e1 in ?? () > ... > #8513 0x080af0cc in ?? () > #8514 0x080af9e1 in ?? () > #8515 0x080af0cc in ?? () > #8516 0x080af9e1 in ?? () > #8517 0x080af0cc in ?? () > #8518 0x080af008 in ?? () > #8519 0x080af008 in ?? () > #8520 0x080b1903 in ?? () > #8521 0x080b1903 in ?? () > #8522 0x080b1903 in ?? () > #8523 0x080af0cc in ?? () > #8524 0x080b1f74 in ?? () > #8525 0x080a77a6 in ?? () > #8526 0x080a7b6c in ?? () > #8527 0x0815710b in ?? () > #8528 0x081572df in ?? () > #8529 0x081572df in ?? () > #8530 0x081572df in ?? () > #8531 0x081572df in ?? () > #8532 0x0812ddee in ?? () > #8533 0x08067fb2 in ?? () > #8534 0x08065574 in ?? () > #8535 0x404ae1c4 in __libc_start_main () from /lib/libc.so.6 > > I'll try and paste the file here, but feel free to e-mail me for the > actual file (and the output from strace): > > <?php > > // Protected global constants > > //======================================================================== > /** > * the prefix of all vars which hold field values > * @const _ARENA_DATA_BASE_FIELD_PREFIX > */ > define('_ARENA_DATA_BASE_FIELD_PREFIX', '__field_'); > > //======================================================================== > /** > * the string length of _ARENA_DATA_BASE_FIELD_PREFIX > * @const _ARENA_DATA_BASE_FIELD_PREFIX_LEN > */ > define('_ARENA_DATA_BASE_FIELD_PREFIX_LEN', > strlen(_ARENA_DATA_BASE_FIELD_PREFIX)); > > //======================================================================== > /** > * Base class to represent a row in a table. > * > * Copyright (c) 2002 <a > href="http://arenaunlimited.com/">Arena > * Unlimited, Inc.</a> All rights reserved. > * > * Reproduction, distribution, use, and/or modification of this > software > * is strictly prohibitted without express written consent from Arena > * Unlimited, Inc. > * > * The above copyright notice and this permission notice shall be > included > * in all copies or substantial portions of the Software. > * > * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > EXPRESS > * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > NONINFRINGEMENT. > * IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR > ANY > * CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF > CONTRACT, > * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE > * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. > * > * @author Matthew Bogosian <matt@arenaunlimited.com> > * @package arena::data > * @version $Id: Arena_Base.php,v 1.1 2002/10/08 07:37:14 matt Exp $ > */ > class Arena_Data_Base > { > > // Constructor > > //======================================================================== > /** > * Class constructor. > * > * @param PEAR_DB &$a_Connection the PEAR_DB connection object > * @access public > */ > function Arena_Data_Base(&$a_Connection) > { > $__connection = &$a_Connection; > } > > // Public methods > > //======================================================================== > /** > * Returns the PEAR_DB connection associated with this database > object. > * > * @return object PEAR_DB the connection associated with this database > * object > * @access public > */ > function &getConnection() > { > return $__connection; > } > > // Protected hook methods > > //======================================================================== > /** > * Returns the names of the fields associated with this database > object. > * This hook function may be overridden by subclasses. However, there > is > * no need for subclasses to override this function if the subclass has > a > * declared var for each of its corresponding table fields named: > * <code> > * _ARENA_DATA_BASE_FIELD_PREFIX . [FIELD_NAME] > * </code> > * (Where [FIELD_NAME] is the name of the field.) Since vars are more > * strict than variable declarations, this must be done by declaring > vars > * with fixed names in the subclass in the following manner: > * <code> > * var $__field_[FIELD_NAME]; > * </code> > * Note: in versions up to and including PHP4, the following will not > * work: > * <code> > * // Not allowed by PHP > * var ${_ARENA_DATA_BASE_FIELD_PREFIX . [FIELD_NAME]}; > * </code> > * Here's an example for three fields named, 'id', 'full_name' and > * 'has_the_clap': > * <code> > * var $__field_id; > * var $__field_full_name; > * var $__field_has_the_clap; > * </code> > * Alternatively, if you're all right with losing some introspection > * functionality on your subclasses, you can get rid of the var > * declarations altogether and do something like the following in your > * constructor: > * <code> > * $this->{_ARENA_DATA_BASE_FIELD_PREFIX . [FIELD_NAME]} = null; > * </code> > * This will allow you to use the constant notation without > hard-coding > * '__field_' everywhere. This function uses instance inspection to > build > * the list of field names so even a combination of both techniques is > * acceptable. However, keep in mind that if it's not a var, and you > unset > * it, this function will lose visibility into it: > * <code> > * // This may have side effects; set it to null instead > * unset($this->{_ARENA_DATA_BASE_FIELD_PREFIX . [FIELD_NAME]}); > * </code> > * The array that is returned from the function is an array of the > * following format: > * <code> > * array > * ( > * [FIELD_NAME] => [FIELD_NAME], ... > * ); > * </code> > * Note that the field name is both the key and the value. This is > * intended to enable maximum flexibility by easing the complexity of > * subclasses that wish to extend this method while retaining the > ability > * to use the resulting array in a foreach loop: > * <code> > * class SubClass extends Arena_Data_Base > * { > * ... > * function &_getFieldNames() > * { > * $myFieldNames = array(...); > * return array_merge(parent::_getFieldNames(), > $myFieldNames); > * } > * } > * ... > * foreach ($mySubClass->_getFieldNames() as $fieldName) {...} > * </code> > * In order for this to work, all subclasses must also follow the > * [FIELD_NAME] => [FIELD_NAME] convention. > * > * @return array the names of the fields associated with this database > * object > * @access protected > */ > function &_getFieldNames() > { > // Get the instance variables > $varNames = array_keys((array)($this)); > $fieldNames = array(); > > // Figure out which names match > foreach ($varNames as $varName) > { > if (strncasecmp(_ARENA_DATA_BASE_FIELD_PREFIX, $varName, > _ARENA_DATA_BASE_FIELD_PREFIX_LEN) == 0 > && strlen($varName) > > _ARENA_DATA_BASE_FIELD_PREFIX_LEN) > { > $fieldName = substr($varName, > _ARENA_DATA_BASE_FIELD_PREFIX_LEN); > $fieldNames[$fieldName] = $fieldName; > } > } > > return $fieldNames; > } > > //======================================================================== > /** > * Returns the table name associated with this database object. > * > * @return string the table name associated with this database object > * @access protected > */ > function &_getTableName() > { > return ''; > } > > //======================================================================== > /** > * Returns the field names which make up the primary key of this > database > * object. The return from this function has the same format as > * Arena_Data_Base::_getFieldNames(). > * > * @return array the field names which make up the primary key of this > * database object > * @access protected > * @see Arena_Data_Base::_getFieldNames() > */ > function &_getPrimaryKey() > { > return _getFieldNames(); > } > > // Private data members > > //======================================================================== > /** > * the database connection > * > * @var object PEAR_DB > * @access private > */ > var $__connection; > > } > > ?> > > > ------------------------------------------------------------------------ > > > -- > Edit this bug report at > http://bugs.php.net/?id=20070&edit=1 >