flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Saber Chebka (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLEX-33139) HTTPService memory leak using both resultFormat e4x and xml
Date Fri, 20 Jul 2012 00:05:34 GMT

    [ https://issues.apache.org/jira/browse/FLEX-33139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13418820#comment-13418820

Saber Chebka commented on FLEX-33139:

Very possible duplicate of http://bugs.adobe.com/jira/browse/SDK-11982 or http://bugs.adobe.com/jira/browse/SDK-11982,
status of resolution stays as "cannot fix" and "differed".
Reporter offers 4 testcase where only one is provoking a memory leak.
I tested them all and that was as expected.
1. format ="xml" file="leaktest.xml" -> It does not leak. 
2. format ="xml" file="pbentries.xml" -> It does not leak. 
3. format ="e4x" file="leaktest.xml" -> It does not leak. 
4. format ="e4x" file="pbentries.xml" -> It leaks. 
As a workaraound:
1- Reloading the app frees the memory. 
2- Walking into one of the 3 non leak test cases
> HTTPService memory leak using both resultFormat e4x and xml
> -----------------------------------------------------------
>                 Key: FLEX-33139
>                 URL: https://issues.apache.org/jira/browse/FLEX-33139
>             Project: Apache Flex
>          Issue Type: Bug
>          Components: RPC: HTTPService
>    Affects Versions: Adobe Flex SDK 4.6 (Release)
>            Reporter: Mansour Blanco
>            Priority: Critical
>              Labels: memory_leak
>         Attachments: UrlLoaderString.PNG, XLC.zip
> Steps to reproduce:
> 1.download the zip file
> 2.import as a project
> 3.profile using e4x or xml resultFormat
> 4.create 2 memory snapshots from the Flex profiler
> 5.use "Find Loitering Object" View between the 2 snapshots.
> 6.analyse String objects using "Open Objects Reference"
> Note : Forcing GC cannot remove Loitering String Objects
> UrlLoader is accumulating String objects on each refresh of data which cannot be GC .
> The attached screenshot shows the URLLoder string variables.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message