Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Date: Fri, 20 Jul 2012 00:05:34 +0000 (UTC)
From: "Saber Chebka (JIRA)" <jira@apache.org>
To: flex-dev@incubator.apache.org
Message-ID: <722206238.79617.1342742734650.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <387689769.69245.1342623754817.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (FLEX-33139) HTTPService memory leak using both
 resultFormat e4x and xml
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.
Cases: 
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