History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: LPP-2071
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: -- --
Assignee: Unassigned
Reporter: Chris Kohlhardt
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
OpenLaszlo

__LzDebug.whyAlive() incorrectly reports leaking arrays with SWF8

Created: 18/May/06 12:38 PM   Updated: 19/Mar/08 08:48 AM
Component/s: Debugger
Affects Version/s: 3.2 (Sage)
Fix Version/s: RingDing (4.1), Eskimo Pie (4.0.8)

Time Tracking:
Not Specified

Severity: Minor
Fixed in Change#: 7,573
Runtime: N/A
Fix in hand: False


 Description  « Hide
Compile the code below as SWF8 with the debugger on. Follow this procedure:

1) invoke __LzDebug.markObjects() in the debugger. Wait for 'done' message.
2) hit the button to create/destroy objects
3) invoke __LzDebug.findNewObjects() in the debugger. Wait for 'done' message.
4) invoke __LzDebug.whyAlive().toString() in the debugger.
5) Notice all the empty arrays that are reported as leaking.

This error was produced in Safari 2.0.3 on OS X 10.4.6 for PPC with Flash Player 8,0,24,0
Also see this email thread:
http://www.openlaszlo.org/pipermail/laszlo-user/2006-May/003558.html


<canvas>

    <button>
        <handler name="onclick">
        <![CDATA[
            Debug.write('do stuff');
            for( var i = 0; i < 100 ; i++ ) {
                Debug.write('new butt');
                new button (foo);
            }

            for( var i= foo.subviews.length -1 ; i > 0 ; i-- ) {
                Debug.write('destroy');
                foo.subviews[i].destroy();
            }

            Debug.write('done doing stuff');
         ]]>
        </handler>
    </button>

    <view id="foo">
    </view>

</canvas>
~

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
P T Withington - 18/Dec/07 04:56 AM
r7573 | ptw | 2007-12-17 17:41:55 -0500 (Mon, 17 Dec 2007) | 64 lines
Changed paths:
   M /openlaszlo/trunk/WEB-INF/lps/lfc/compiler/LzRuntime.lzs
   M /openlaszlo/trunk/WEB-INF/lps/lfc/debugger/Library.lzs
   M /openlaszlo/trunk/WEB-INF/lps/lfc/debugger/LzMemory.lzs
   M /openlaszlo/trunk/WEB-INF/lps/lfc/debugger/platform/dhtml/kernel.js
   D /openlaszlo/trunk/WEB-INF/lps/lfc/debugger/platform/swf/LzMemory.as
   M /openlaszlo/trunk/lps/includes/laszlo-debugger.css

Change 20071214-ptw-i by ptw@dueling-banjos.local on 2007-12-14 18:23:23 EST
    in /Users/ptw/OpenLaszlo/ringding-2
    for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: Make the memory tracer generic

New Features: Memory tracing now works (for some definition of works)
in DHTML in addition to SWF.

Bugs Fixed:
LPP-2071: '__LzDebug.whyAlive() incorrectly reports leaking arrays with SWF8'

Technical Reviewer: a.bargull@intensis.de (pending)
QA Reviewer: promanik@laszlosystems.com (message://<20071216160543.EBA091EF912@hemicuda.laszlosystems.com>)

Documentation:
    Debug.markObjects, findNewObjects, whyAlive now work in SWF and
    DHTML. DHTML is only beta-quality, and you will get a warning
    saying so, because it appears that some underlying runtimes
    themselves leak DOM objects (or our usage of them causes them to
    be leaked). It works reasonably well in Safari, less well in
    Firefox, hangs Opera, is untested in IE (but IE has its own leak
    tools).

Details:
    kernel.js: Initialize the debug window early so memory tracing can
    find it. Use a static style for debugger output, so that a new
    CSSStyle object is not consed for every line of debugger output.

    LzMemory.lzs: Make this generic (although there are still some if
    ($as2) bits for now, I think a unified code base is better than
    splitting this into the kernels). Add some metering to see how
    the background tracer is working. Add some documentation. Add
    some try/catch blocks to ignore errors trying to trace native
    wrapped objects in DHTML. Don't trace native wrapped object slots
    that return a 'new' object each time you access them. Use
    set/clearInterval instead of the old tracer movieclip to run the
    background task. Fix the path evaluator to be correct and
    platform-neutral. Use objectOwnProperties to find slots to trace.
    Make the code to hide the debugger from the leak detector generic,
    hide the debugger DOM tree. Make whyAlive output all relevant
    data, so it can be invoked as a button, not just from the
    debugger.

    Library.lzs: switch from the platform leak detector to the generic
    one.

    LzRuntime: Use static style for debugger output.

    laszlo-debugger.css: Define that static style.

Tests:
    The following test program works for me (pressing the 3 buttons at
    the appropriate times, creates a leak report):

    <canvas debug="true">
      <simplelayout axis="x" />
      <button onclick="Debug.markObjects()">Mark</button>
      <button onclick="Debug.findNewObjects()">Find New</button>
      <button onclick="Debug.whyAlive()">Why Alive</button>
    </canvas>



P T Withington - 03/Jan/08 08:55 AM
Migrated to Wafflecone for 4.0.8

r7714 | ptw | 2008-01-03 11:38:08 -0500 (Thu, 03 Jan 2008) | 132 lines
Changed paths:
   M /openlaszlo/branches/wafflecone
   M /openlaszlo/branches/wafflecone/WEB-INF/lps/lfc/compiler/LzFormatter.lzs
   M /openlaszlo/branches/wafflecone/WEB-INF/lps/lfc/compiler/LzRuntime.lzs
   M /openlaszlo/branches/wafflecone/WEB-INF/lps/lfc/debugger/Library.lzs
   M /openlaszlo/branches/wafflecone/WEB-INF/lps/lfc/debugger/LzDebug.lzs
   A /openlaszlo/branches/wafflecone/WEB-INF/lps/lfc/debugger/LzMemory.lzs (from /openlaszlo/trunk/WEB-INF/lps/lfc/debugger/LzMemory.lzs:7708)
   M /openlaszlo/branches/wafflecone/WEB-INF/lps/lfc/debugger/LzMessage.lzs
   M /openlaszlo/branches/wafflecone/WEB-INF/lps/lfc/debugger/platform/dhtml/LzDebug.js
   M /openlaszlo/branches/wafflecone/WEB-INF/lps/lfc/debugger/platform/dhtml/kernel.js
   M /openlaszlo/branches/wafflecone/WEB-INF/lps/lfc/debugger/platform/swf/LzDebug.as
   D /openlaszlo/branches/wafflecone/WEB-INF/lps/lfc/debugger/platform/swf/LzMemory.as
   M /openlaszlo/branches/wafflecone/lps/includes/laszlo-debugger.css

Change 20080102-ptw-l by ptw@dueling-banjos.local on 2008-01-02 19:49:48 EST
    in /Users/ptw/OpenLaszlo/wafflecone
    for http://svn.openlaszlo.org/openlaszlo/branches/wafflecone

Summary: Merged revisions 7489,7573 via svnmerge from
http://svn.openlaszlo.org/openlaszlo/trunk

Technical Reviewer: amy (Message-ID: <12587382.4001199377511558.JavaMail.amuntz@hedwig.laszlosystems.com>)
QA Reviewer: mamye (pending)

Details:
........
  r7489 | ptw | 2007-12-09 08:42:32 -0500 (Sun, 09 Dec 2007) | 53 lines
  
  Change 20071207-ptw-v by ptw@dueling-banjos.local on 2007-12-07 22:50:21 EST
      in /Users/ptw/OpenLaszlo/ringding-2
      for http://svn.openlaszlo.org/openlaszlo/trunk
  
  Summary: Bring memory tracing to the modern era
  
  Bugs Fixed:
  LPP-5205: 'Debug.whyAlive no longer shows reference keeping object alive'
  
  Technical Reviewer: philip@pbrdev.com (message:<20071208152841.7BC797C16E@hemicuda.laszlosystems.com>)
  QA Reviewer: yfang@laszlosystems.com (pending)
  
  Details:
      LzMessage: fix error in concat observed in passing, make
      appendInternal of another LzMessage concat, not present the
      message
  
      LzMemory: Make some things classes. Store leaks as a new class
      that has a pretty descriptor and breaks out the leak information
      for easy inspection. Use a stable sort on leaks, sort the biggest
      leak to the front of the Array. Make whyAlive describe the top
      leaks.
  
      LzDebug.*: Use user toString methods, obey unique flag.
  
      LzFormatter: New formatting flag `=` takes the next argument as
      the object to be represented by the format (overriding the normal
      hot-linking that occurs in the debugger so you can write a custom
      representation for an object).
  
  Tests:
      Debug.markObjects()
      Debug.findNewObjects()
      Debug.whyAlive()
  
      now yields useful information:
  
      lzx> Debug.whyAlive()
      global.spriteroot.$m1.debugloader.loadmc1.reqobj: (?\194?\16352) ?\194?\171Object#100| {_dbg_check:...?\194?\187
      global.LzFocus.csel.sprite.__LZtextclip.filters: (?\194?\1636) ?\194?\171Array(0)#102| []?\194?\187
      global.LzModeManager.__LZlastclick.sprite.__LZbuttonRef.but.filters: (?\194?\1636) ?\194?\171Array(0)#104| []?\194?\187
      global.__offscreenkeyclip.filters: (?\194?\1636) ?\194?\171Array(0)#106| []?\194?\187
      global.spriteroot.$m0.$m0.$m5.$LzText.filters: (?\194?\1636) ?\194?\171Array(0)#108| []?\194?\187
      global.spriteroot.$m0.$m0.$mcB.but.filters: (?\194?\1636) ?\194?\171Array(0)#110| []?\194?\187
      global.spriteroot.$m1.$m0.$m0.$mcB.but.filters: (?\194?\1636) ?\194?\171Array(0)#112| []?\194?\187
      global.spriteroot.$m1.$m0.$m1.$m0.$mcB.but.filters: (?\194?\1636) ?\194?\171Array(0)#114| []?\194?\187
      global.spriteroot.$m1.$m0.$m1.$m1.$mcB.but.filters: (?\194?\1636) ?\194?\171Array(0)#116| []?\194?\187
      global.spriteroot.$m1.$m0.$m1.$m2.$mcB.but.filters: (?\194?\1636) ?\194?\171Array(0)#118| []?\194?\187
      ...
      ?\194?\171__LzLeaks(28)#120| 208 smoots?\194?\187
      lzx>
........
  r7573 | ptw | 2007-12-17 17:41:55 -0500 (Mon, 17 Dec 2007) | 64 lines
  
  Change 20071214-ptw-i by ptw@dueling-banjos.local on 2007-12-14 18:23:23 EST
      in /Users/ptw/OpenLaszlo/ringding-2
      for http://svn.openlaszlo.org/openlaszlo/trunk
  
  Summary: Make the memory tracer generic
  
  New Features: Memory tracing now works (for some definition of works)
  in DHTML in addition to SWF.
  
  Bugs Fixed:
  LPP-2071: '__LzDebug.whyAlive() incorrectly reports leaking arrays with SWF8'
  
  Technical Reviewer: a.bargull@intensis.de (pending)
  QA Reviewer: promanik@laszlosystems.com (message://<20071216160543.EBA091EF912@hemicuda.laszlosystems.com>)
  
  Documentation:
      Debug.markObjects, findNewObjects, whyAlive now work in SWF and
      DHTML. DHTML is only beta-quality, and you will get a warning
      saying so, because it appears that some underlying runtimes
      themselves leak DOM objects (or our usage of them causes them to
      be leaked). It works reasonably well in Safari, less well in
      Firefox, hangs Opera, is untested in IE (but IE has its own leak
      tools).
  
  Details:
      kernel.js: Initialize the debug window early so memory tracing can
      find it. Use a static style for debugger output, so that a new
      CSSStyle object is not consed for every line of debugger output.
  
      LzMemory.lzs: Make this generic (although there are still some if
      ($as2) bits for now, I think a unified code base is better than
      splitting this into the kernels). Add some metering to see how
      the background tracer is working. Add some documentation. Add
      some try/catch blocks to ignore errors trying to trace native
      wrapped objects in DHTML. Don't trace native wrapped object slots
      that return a 'new' object each time you access them. Use
      set/clearInterval instead of the old tracer movieclip to run the
      background task. Fix the path evaluator to be correct and
      platform-neutral. Use objectOwnProperties to find slots to trace.
      Make the code to hide the debugger from the leak detector generic,
      hide the debugger DOM tree. Make whyAlive output all relevant
      data, so it can be invoked as a button, not just from the
      debugger.
  
      Library.lzs: switch from the platform leak detector to the generic
      one.
  
      LzRuntime: Use static style for debugger output.
  
      laszlo-debugger.css: Define that static style.
  
  Tests:
      The following test program works for me (pressing the 3 buttons at
      the appropriate times, creates a leak report):
  
      <canvas debug="true">
        <simplelayout axis="x" />
        <button onclick="Debug.markObjects()">Mark</button>
        <button onclick="Debug.findNewObjects()">Find New</button>
        <button onclick="Debug.whyAlive()">Why Alive</button>
      </canvas>
........



P T Withington - 03/Jan/08 11:17 AM
Fixed in Eskimo Pie, not Cranberry

Mamye Kratt - 04/Jan/08 02:27 PM
(wafflecone local build r7719 - 4.0.8 RC)
lzx> __LzDebug.markObjects()
Marking objects ...
lzx> DEBUG: 12 loops @ 759 iterations, 1271.08 milliseconds
 ... done!
do stuff
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
done doing stuff
lzx> __LzDebug.findNewObjects()
Finding new objects ...
lzx> DEBUG: 14 loops @ 670 iterations, 1284.64 milliseconds
 ... done!
lzx> __LzDebug.whyAlive().toString()
4338 smoots [13 objects @ ~334 smoots each]:
global.foo.__LZoutlieheight: (£4009) «lz.button#4»
global.spriteroot.$m3: (£116) «MovieClip#7| _level0.spriteroot.$m3»
global.LzFocus.lastfocus.__LZviewLinks: (£58) «Object#9| {_dbg_check: 58, _dbg_smoots: ...»
global.spriteroot.$m1.debugloader.loadmc1.reqobj: (£51) «Object#12| {_dbg_check: 51, _dbg_smoots:...»
global.LzFocus.lastfocus.onx: (£27) «LzEvent#15| «lz.button».onx»
global.LzFocus.lastfocus.ony: (£27) «LzEvent#17| «lz.button».ony»
global.LzIdle.coi: (£10) «Array(1)#20| [Delegate for _level0.sprit...»
global.foo.subviews: (£10) «Array(1)#22| [button ]»
global.foo.subnodes: (£10) «Array(1)#24| [button ]»
global.LzKeys.downKeysArray: (£8) «Array(1)#27| [86]»
... [3 more @ ~4 smoots each]
'[object Object]'
lzx>

Mamye Kratt - 04/Jan/08 02:27 PM
Need to test in trunk for ringding

Mamye Kratt - 19/Mar/08 08:48 AM
(trunk 4 build r8276)

lzx> __LzDebug.markObjects()
Marking objects ...
lzx> do stuff
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
new butt
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
done doing stuff
DEBUG: 13 loops @ 743 iterations, 1281.08 milliseconds
 ... done!
lzx> __LzDebug.findNewObjects()
Finding new objects ...
lzx> DEBUG: 14 loops @ 695 iterations, 1291.14 milliseconds
 ... done!
lzx> __LzDebug.whyAlive().toString()
261 smoots [12 objects @ ~22 smoots each]:
global.LzFocus.lastfocus.__LZviewLinks: (£58) «Object#3| {_dbg_check: 58, _dbg_smoots: ...»
global.spriteroot.$m1.debugloader.loadmc1.reqobj: (£51) «Object#6| {_dbg_check: 51, _dbg_smoots: ...»
global.LzFocus.lastfocus.onx: (£27) «LzEvent#9| «lz.button».onx»
global.canvas.__focus._xydelegate.7: (£27) «LzEvent#13| #Debug.ony»
global.LzFocus.lastfocus.ony: (£27) «LzEvent#15| «lz.button».ony»
global.canvas.__focus._xydelegate.6: (£27) «LzEvent#17| #Debug.onx»
global.foo.subviews: (£10) «Array(1)#20| [button ]»
global.foo.subnodes: (£10) «Array(1)#22| [button ]»
global.LzIdle.coi: (£8) «Array(1)#25| [Delegate for _level0.sprit...»
global.LzKeys.downKeysArray: (£8) «Array(1)#28| [86]»
... [2 more @ ~4 smoots each]
'[object Object]'
lzx>