Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.5.0a1

Bug #10909 PHP Notice in PDF Converter line 210
Submitted: 2007-05-02 10:19 UTC Modified: 2007-12-07 22:46 UTC
From: cardoe Assigned: ashnazg
Status: Closed Package: PhpDocumentor (version 1.3.2)
PHP Version: 5.2.2 OS: Gentoo
Roadmaps: 1.4.1    

 [2007-05-02 10:19 UTC] cardoe (Doug Goldstein)
Description: ------------ Version 1.3.2 fixes the previous PHP Notice in the PDF converter but adds a new one. Notice: Trying to get property of non-object in /usr/share/php/PhpDocumentor/phpDocumentor/Converters/PDF/default/ on line 210 Line 186 is: if (!$element) return false; But should really be... if (!$element && !is_object($element)) return false; Also the docs for this function are wrong.


 [2007-05-02 10:22 UTC] cardoe (Doug Goldstein)
Wow.. Logic error in my head... if(!$element || !is_object($element)) return false;
 [2007-05-03 10:37 UTC] ashnazg (Chuck Burgess)
cardoe, I am not able to duplicate that PDF error pointing at line 210, so I'm not able to reliably test your patch idea. Any chance you can post a small docblock that you can trigger it with?
 [2007-05-03 11:01 UTC] ashnazg (Chuck Burgess)
I was, however, able to generate a PHP Notice from the PDF default converter pointing at line 533, where it complained about code that tried to default a function's return type when no return tag was in the docblock. I've attached the patch for that problem, though I still think Doug's original problem relates to another issue that I want to tackle if I can.
 [2007-05-11 10:15 UTC] cardoe (Doug Goldstein)
I made the following tweak to spit out some more details.. if (!$element) return false; if (!is_object($element)) var_dump($element); Which results in the following being printed.. string(12) "object array" Notice: Trying to get property of non-object in /usr/share/php/PhpDocumentor/phpDocumentor/Converters/PDF/default/ on line 213 I'm running this on a whole bunch of files so I'm not sure which docblock this is coming from... My only guess is at the very start of a file I have the following block: @package MyCompany @subpackage @see Class1, Class2, Class3, Class4 @see Class5, Class6, Class7, Class8 @see Class9 for the file level docblock.
 [2007-05-11 10:16 UTC] cardoe (Doug Goldstein)
Should be noted that the Notice is only printed 9 times and there are 9 classes referenced in that file level docblock.
 [2007-05-11 10:31 UTC] ashnazg (Chuck Burgess)
That subpackage tag is empty? Also, are the files containing those nine class definitions also included in your run?
 [2007-05-11 10:40 UTC] cardoe (Doug Goldstein)
erm. No That was just a typo on my part with the @subpackage, it has stuff in it. Currently our structure is: MyCompany/subpackage/PossibleError.php MyCompany/subpackage/Class1.php MyCompany/subpackage/Class2.php MyCompany/subpackage/Class3.php MyCompany/subpackage/Class4.php MyCompany/subpackage/Class5.php MyCompany/subpackage/Class6.php MyCompany/subpackage/Class7.php MyCompany/subpackage/Class8.php MyCompany/subpackage/Class9.php Where PossibleError.php contains the file level doc block I previously posted. All the classes are in the same subpackage. I've actually been working here internally to publish this code since it's designed to be a PEAR pkg for interfacing to my company's software. Hopefully I can give specific files as reference soon.
 [2007-05-11 11:20 UTC] ashnazg (Chuck Burgess)
Do the class-level docblocks also have the same package and subpackage tags on them?
 [2007-05-11 12:23 UTC] cardoe (Doug Goldstein)
Yes. There's actually a file level doc block. Then some includes, which has it's own doc block since I was getting warnings without that. Then the class level doc block. The file level and class level doc blocks have the same @package and @subpackage sections. The include level one does not.
 [2007-05-11 13:03 UTC] ashnazg (Chuck Burgess)
Does removing the @see tags stop the notices from happening?
 [2007-05-11 14:08 UTC] cardoe (Doug Goldstein)
I should have checked that before... sorry.. I've removed all @see from my sources and I still get it. This is in a SVN checkout however, so there still are pristine copies with @see in them, but I assume you don't parse anything that doesn't end in .php
 [2007-05-11 14:18 UTC] cardoe (Doug Goldstein)
I've added a debug_print_backtrace() in there... #0 PDFdefaultConverter->returnSee(object array, array, 1) called at [/usr/share/php/PhpDocumentor/phpDocumentor/] #1 parserFunction->getIntricateFunctionCall(PDFdefaultConverter Object ([sort_absolutely_everything] => 1,[leftindex] => Array ([classes] => ,[pages] = > ,[functions] => ,[defines] => ,[globals] => ),[pagepackage_pagenums] => Array (),[classpackage_pagenums] => Array (),[outputformat] => PDF,[name] => d efault,[curpagepackage] => Monetra,[curclasspackage] => Monetra,[smarty_dir] => /usr/share/php/data/PhpDocumentor/phpDocumentor/Converters/PDF/default/t emplates/default/,[pdf] => phpdocpdf Object ([reportContents] => Array (),[indexContents] => Array (),[indents] => Array (),[font_dir] => /usr/share/php /data/PhpDocumentor/phpDocumentor/Converters/PDF/default/templates/fonts/,[set_pageNumbering] => ,[converter] => PDFdefaultConverter Object ( *RECURSION * After the RECURSION.. it goes on and on for several hundreds of lines.. I can't quite catch the other calls but here's the end.. #8 phpDocumentor_IntermediateParser->Output() called at [/usr/share/php/PhpDocumentor/phpDocumentor/] #9 phpDocumentor_setup->createDocs() called at [/usr/share/php/PhpDocumentor/phpDocumentor/] #10 include(/usr/share/php/PhpDocumentor/phpDocumentor/ called at [/usr/bin/phpdoc:37]
 [2007-05-11 14:24 UTC] cardoe (Doug Goldstein)
Guess I could just write my own to filter out the args from debug_backtrace(). PDFdefaultConverter->returnSee() called at [/usr/share/php/PhpDocumentor/phpDocumentor/] parserFunction->getIntricateFunctionCall() called at [/usr/share/php/PhpDocumentor/phpDocumentor/] parserMethod->getIntricateFunctionCall() called at [/usr/share/php/PhpDocumentor/phpDocumentor/Converters/PDF/default/] PDFdefaultConverter->convertMethod() called at [/usr/share/php/PhpDocumentor/phpDocumentor/] Converter->Convert() called at [/usr/share/php/PhpDocumentor/phpDocumentor/] Converter->walk_everything() called at [/usr/share/php/PhpDocumentor/phpDocumentor/] Converter->walk() called at [/usr/share/php/PhpDocumentor/phpDocumentor/] phpDocumentor_IntermediateParser->Convert() called at [/usr/share/php/PhpDocumentor/phpDocumentor/] phpDocumentor_IntermediateParser->Output() called at [/usr/share/php/PhpDocumentor/phpDocumentor/] phpDocumentor_setup->createDocs() called at [/usr/share/php/PhpDocumentor/phpDocumentor/] include() called at [/usr/bin/phpdoc:37]
 [2007-05-11 14:39 UTC] cardoe (Doug Goldstein)
Just before the returnSee call on /usr/share/php/PhpDocumentor/phpDocumentor/ I added print_r($link) and got: classLink Object ( [type] => class [path] => /usr/local/php/MyCompany/MyComapny.php [fileAlias] => MyCompany---MyCompany.php [name] => MyCompany [category] => default [package] => MyCompany [subpackage] => ) That file does not have a @subpackage. It appears to be correct.. I added an exit; to returnSee() when it got a non-object and that's the only thing that prints out.
 [2007-05-11 14:49 UTC] cardoe (Doug Goldstein)
Actually.. my mistake... Adding the following code before line 647... echo $param[2] . " param2\n"; var_dump($link); echo "\nprint_r" . "\n"; Produces: array param2 string(12) "object array" print_r I do use "array" to decorate some of my parameters in my code since some of them are raw arrays. You're allowed in PHP 5 to decorate your parameters with their class name or the parameter "array". Changing line 643 from: if (isset($param[2])) to: if (isset($param[2]) && $param[2] != "array") Fixes the issue as well.
 [2007-05-29 13:32 UTC] cardoe (Doug Goldstein)
Any word on this? Need me to do anymore testing? Once you push out 1.4.0a2, I'll probably switch to that version to test.
 [2007-05-30 20:59 UTC] ashnazg (Chuck Burgess)
I've still not been able to duplicate Doug's specific PHP notice error. My testing against the @return code, that I COULD trigger the notices with, continues to be good. I'm going to commit that fix, and continue working with Doug to try duplicating his scenario.
 [2007-05-30 21:02 UTC] ashnazg (Chuck Burgess)
committed @return patch
 [2007-05-30 21:04 UTC] ashnazg (Chuck Burgess)
Doug, Although I can't imagine my @return patch solving your issue, can you at least patch your file so that you and I are testing against the same file? I still cannot put together a test file / tags combination to trigger the notices you're getting around the 210 line, so I need some more "hints" regarding your code that you can't show just yet.
 [2007-07-17 15:16 UTC] ashnazg2 (Chuck Burgess (2))
this is a test comment by Chuck
 [2007-12-07 22:46 UTC] ashnazg (Chuck Burgess)
Nothing further on this since committing my @return patch, so closing this bug.