Mantis Bugtracker          
testlink.org

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007009TestLinkReportspublic2015-03-13 18:432015-03-14 07:52
Reporterfilipse 
Assigned Tofman 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.9.13 (2015 #1) 
Fixed in Version1.9.14 (2015 Q3) 
Summary0007009: Blank report pages redux (OutOfMemory when generating reports)
DescriptionAs reported previously in issue 0006965, there is a out of memory while creating test plan reports. We have FOUND what is causing the out of memory and we PROVIDE a fix following a very detailed description of the problem.

After some hours of debugging, we have found that the function "renderTestSpecTreeForPrinting" in the file "print.inc.php" was creating an infinite recursion when the tree node provided had leafs. A simple structure like:

PARENT
|_ LEAF

Would create the problem (no matter how many test cases were associated with it). The problem lies in the representation of the tree node that is provided in the "$node" variable when the function is called from the file "printDocument.php". We have noticed that for some reason one of the array elements (leaf) is a string instead of the expected array (the correct representation of a node). In our case the string was "d8ba8cfb-ca92-4fa5-83c2-551977d405fb". We could trace back the origin of this string to the function "get_subtree" in the file "tree.class.php".
we have applied a improvement in the recursive function that will check if the leaf nodes are arrays, ignoring them if not. This will stop PHP from entering the infinite recursion (in our case it is was always around 3100 indentation levels).

The problematic code is when you do "$node['childNodes']" (line 807 of the "print.inc.php" file) to a string. Since PHP cannot resolve the "childNodes" key, it will return the first character of the string, in our case it was always returning "d" which is the first character of the "d8ba8cfb-ca92-4fa5-83c2-551977d405fb" string. We have attached some logging where you can see the tree structure and the recursion happening until the out of memory.

Follows the patch.

--- a/lib/functions/print.inc.php 2015-03-13 16:38:34.000000000 +0000
+++ b/lib/functions/print.inc.php 2015-03-13 17:51:52.000000000 +0000
@@ -767,7 +767,6 @@
 context['prefix']

 */
-
 function renderTestSpecTreeForPrinting(&$db,&$node,&$options,$env,$context,$tocPrefix,$indentLevel)
 {
   static $tree_mgr;
@@ -810,7 +809,7 @@
     for($idx = 0;$idx < $children_qty ;$idx++)
     {
       $current = $childNodes[$idx];
- if(is_null($current))
+ if(is_null($current) || !is_array($current))
       {
         continue;
       }
TagsNo tags attached.
Database (MySQL,Postgres,etc)MySQL
Browser
PHP Version
TestCaseID
QA Team - Task Workflow StatusTBD
Attached Fileslog file icon testlink.log [^] (7,212 bytes) 2015-03-13 18:43

- Relationships

-  Notes
(0022894)
fman (administrator)
2015-03-14 07:42
edited on: 2015-03-14 07:51

this bug has his root in an issue related to ext-js tree and JSON.
The JSON string created by build tree, contained null inside.
EXT-JS do not like the string null.
A simple replace of null with '', created some issues with node name.
Choice was instead of assign null assign a different fixed string (the strange string you have found).
After refactoring not enough test in each condition was possibile, and with help of user that found issues and provide conditions to try to reproduce, several fixed where produced mainly in the tree generation with and without filters.

Will see if other that fix provided can be fixed another way (simple compare with the fixed string) that may be can be cheaper on exec time when test spec contains thousands of item.

unfortunately in related issue several things happened that do not allow a clear action

1, first use report talk about permissions, and di not provide an similar scenario to reproduce

2. when other people start trying to help, again no clues about scenario were provided.
    A GOOD hint that I've missed (my fault) was the memory leak

3. more unrelated info was added regarding debug info on screen, making things worst

4. detailed scenario was never provided, and this is critical al less for me to try to reproduce


- Issue History
Date Modified Username Field Change
2015-03-13 18:43 filipse New Issue
2015-03-13 18:43 filipse File Added: testlink.log
2015-03-14 07:42 fman Note Added: 0022894
2015-03-14 07:46 fman QA Team - Task Workflow Status => TBD
2015-03-14 07:46 fman Description Updated View Revisions
2015-03-14 07:51 fman Note Edited: 0022894 View Revisions
2015-03-14 07:52 fman Status new => closed
2015-03-14 07:52 fman Assigned To => fman
2015-03-14 07:52 fman Resolution open => fixed
2015-03-14 07:52 fman Fixed in Version => 1.9.14 (2015 Q3)



Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker