[TIMOB-12405] Android: Titanium object modules shown retained (Memory Analyzer Tool)

Hi, These are the steps to reproduce the problem: 1. Open Titanium Studio 2. Create a new app w/ the Single Window app template 3. Project OS target: only Android checkbox, and no cloud settings. Name and id, whatever. SDK 3.0.0.GA (check others possibilites in environment field) 4. Once created, open tiapp and replace 'android' node with this:

 
    <android xmlns:android="http://schemas.android.com/apk/res/android">
        <manifest>
            <application android:debuggable="true"/>
        </manifest>
    </android>

(this let us trace memory with MAT when deoployed to real device) 5. Clean & run the app in the emulator / device (although no matter what you do as we'll see the same behaviour). 6. Once deployed, change to DDMS perspective. 7. In devices list, highlight our (device and) app process. 8. Click the 'Update HEAP' button. 9. Now run - quit (back button) - run X times. 10. In Heap tab, click "Cause GC" button a few times until you see memory indicators stable. 11. Click "Dump HPROF file" button, and get object Histogram with MAT. 12. Search for Class Name regex typing 'Module'. Now see X objects of each Titanium module; you can go deeper: 13. Right click on any of the Histogram lines > List objects > with incoming references 14. Right click on any item from list_objects > Path to GC Roots > Exclude all phantom/weak/soft etc. references Then you'll see only one Native Stack GC Root, which I guess the memory is retained inside 'JNI land'. I've tried this with ALL the environment variables I've specified in this ticket enviroment field, with almost all possible combinations, and always get the same result. I've also attached screenshots and even tried this with a very very simple app! (https://gist.github.com/4585261) There's more: it also happens with custom modules. Actually, while I was developing my GCM module I realized that 'something' memory related was happening. Just a few lines: the module has a method (registerForPushNotifications) which has a js object as an argument, and its properties are function callbacks... in Java land those callbacks are really KrollCallback, as you may guess. When the method is executed, the callbacks are assigned to instance KrollCallback private properties. When the module has been integrated into an existing app, it worked as expected BUT after some tests something really weird happened: callbacks were fired, but the logic inside reported a wrong state (e.g. logging out a counter variable shown wrong values). After tons of tests, I made the KrollCallback properties static, and it 'solved' the problem. I'm not one of those who always think that it's fault of the underlying framework / SDK, so 1st thing I thought was I was doing some bad memory management, retaining whatever. No way... I commented everything until make the module useless, doing nothing... and even without making a single require of the module in JS land, MAT shown X Module objects. I also thought that it really wasn't a bug, just some MAT understandable memory thing... but definitely the wrong behaviour with my module solved making static properties made me think the opposite. Finally (and I don't know if it has something to do) I've also attached a screenshot of logcat output with mysterious messages: 01-21 10:43:09.467: W/TiApplication(2479): (KrollRuntimeThread) [312,312] Registering module with name already in use. If this is not a bug, I'll really appreciate a technical explanation of what is happening, why MAT is reporting X instances of Ti / custmo modules. But, if it IS a bug, IMHO must be considered a serious bug, and I really hope it'll be solved very soon.