From: Panayotis K. <pan...@pa...> - 2010-05-24 13:28:14
|
I think I found a serious memory bug with current implementation of xmlvm. Here is the minimum java code to reproduce this bug: package xmlvm; import org.xmlvm.iphone.UIApplication; import org.xmlvm.iphone.UIView; public class Main extends UIApplication { public void applicationDidFinishLaunching(UIApplication app) { testView view = new testView(); } public static void main(String[] args) { UIApplication.main(args, Main.class); } public class testView extends UIView { public testView() { System.out.println(getFrame().size); } } } the initialization code of testView produces this code: - (void) __init_xmlvm_Main_testView___xmlvm_Main :(xmlvm_Main*)n1 { XMLVMElem _rtmp; XMLVMElem _r0; XMLVMElem _r1; XMLVMElem _r2; XMLVMElem _r3; _r2.o = self; _r3.o = n1; _r0.o = JAVA_NULL; _r1.o = JAVA_NULL; [_r3.o retain]; [((xmlvm_Main_testView*) _r2.o)->this_0_xmlvm_Main release]; ((xmlvm_Main_testView*) _r2.o)->this_0_xmlvm_Main = _r3.o; [((org_xmlvm_iphone_UIView*) _r2.o) __init_org_xmlvm_iphone_UIView__]; _r0.o = [java_lang_System _GET_out]; _r1.o = [((xmlvm_Main_testView*) _r2.o) getFrame__]; _rtmp.o = _r1.o; _r1.o = ((org_xmlvm_iphone_CGRect*) _r1.o)->size_org_xmlvm_iphone_CGSize; [_rtmp.o release]; _rtmp.o = JAVA_NULL; [((java_io_PrintStream*) _r0.o) println___java_lang_Object:_r1.o]; return; } Now, let me copy & paste the code and add some comments, to describe it: // perform getFrame() _r1.o = [((xmlvm_Main_testView*) _r2.o) getFrame__]; // keep result of getFrame() into temporary variable _rtmp _rtmp.o = _r1.o; // frame's size is received from the structure _r1.o = ((org_xmlvm_iphone_CGRect*) _r1.o)->size_org_xmlvm_iphone_CGSize; // **release frame ** - here is the bug [_rtmp.o release]; _rtmp.o = JAVA_NULL; // Use CGSize data, although the structure that was encapsulating it (the frame) is already freed! [((java_io_PrintStream*) _r0.o) println___java_lang_Object:_r1.o]; It seems that objects whose member items are used later on, should also be tracked and released ONLY after the inside items are not used any more! Or, even better, every time a reference with the -> operator is made, also retain this object and properly release it afterwards. What others do say? |
From: Joshua M. <xm...@me...> - 2010-05-24 16:38:47
|
Hi Panayotis, I am aware of this issue and have been working on a fix for it. Sadly, the fix is non trivial though I am making (slow) progress on it. For now, the best workaround is to comment out // new ExcessRetainsOptimization().Process(curRun.allCodePaths, curRun.beenTo, // codeElement); in ReferenceCounting.java. Since this bug is affecting people, I will talk to Arno about checking in that workaround until I can actually implement a correct fix. Sorry you encountered this... -- Joshua Melcon On Mon, May 24, 2010 at 6:28 AM, Panayotis Katsaloulis <pan...@pa...> wrote: > I think I found a serious memory bug with current implementation of xmlvm. > > Here is the minimum java code to reproduce this bug: > > package xmlvm; > import org.xmlvm.iphone.UIApplication; > import org.xmlvm.iphone.UIView; > > public class Main extends UIApplication { > public void applicationDidFinishLaunching(UIApplication app) { > testView view = new testView(); > } > public static void main(String[] args) { > UIApplication.main(args, Main.class); > } > public class testView extends UIView { > public testView() { > System.out.println(getFrame().size); > } > } > } > > > the initialization code of testView produces this code: > > - (void) __init_xmlvm_Main_testView___xmlvm_Main :(xmlvm_Main*)n1 > { > XMLVMElem _rtmp; > XMLVMElem _r0; > XMLVMElem _r1; > XMLVMElem _r2; > XMLVMElem _r3; > _r2.o = self; > _r3.o = n1; > _r0.o = JAVA_NULL; > _r1.o = JAVA_NULL; > [_r3.o retain]; > [((xmlvm_Main_testView*) _r2.o)->this_0_xmlvm_Main release]; > ((xmlvm_Main_testView*) _r2.o)->this_0_xmlvm_Main = _r3.o; > [((org_xmlvm_iphone_UIView*) _r2.o) __init_org_xmlvm_iphone_UIView__]; > _r0.o = [java_lang_System _GET_out]; > _r1.o = [((xmlvm_Main_testView*) _r2.o) getFrame__]; > _rtmp.o = _r1.o; > _r1.o = ((org_xmlvm_iphone_CGRect*) _r1.o)->size_org_xmlvm_iphone_CGSize; > [_rtmp.o release]; > _rtmp.o = JAVA_NULL; > [((java_io_PrintStream*) _r0.o) println___java_lang_Object:_r1.o]; > return; > } > > > > Now, let me copy & paste the code and add some comments, to describe it: > // perform getFrame() > _r1.o = [((xmlvm_Main_testView*) _r2.o) getFrame__]; > > // keep result of getFrame() into temporary variable _rtmp > _rtmp.o = _r1.o; > > // frame's size is received from the structure > _r1.o = ((org_xmlvm_iphone_CGRect*) _r1.o)->size_org_xmlvm_iphone_CGSize; > > // **release frame ** - here is the bug > [_rtmp.o release]; > _rtmp.o = JAVA_NULL; > > // Use CGSize data, although the structure that was encapsulating it (the frame) is already freed! > [((java_io_PrintStream*) _r0.o) println___java_lang_Object:_r1.o]; > > > > It seems that objects whose member items are used later on, should also be tracked and released ONLY after the inside items are not used any more! > Or, even better, every time a reference with the -> operator is made, also retain this object and properly release it afterwards. > > What others do say? > ------------------------------------------------------------------------------ > > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |
From: Panayotis K. <pan...@pa...> - 2010-05-24 17:09:32
|
On 24 Μαϊ 2010, at 7:16 μ.μ., Joshua Melcon wrote: > Hi Panayotis, > > I am aware of this issue and have been working on a fix for it. > Sadly, the fix is non trivial though I am making (slow) progress on > it. > > For now, the best workaround is to comment out > // new ExcessRetainsOptimization().Process(curRun.allCodePaths, curRun.beenTo, > // codeElement); > > in ReferenceCounting.java. > > Since this bug is affecting people, I will talk to Arno about checking > in that workaround until I can actually implement a correct fix. > > Sorry you encountered this… The good thing is someone is working on it (the bad is that I spent 4 hours to understand why my application didn't work with latest version of xmlvm :-o ) As with my previous e-mail, I'll suggest a simple fix for this: every time an object is referenced this way, retain this object and keep track of it, as with other objects. When this is no longer needed, release it. Probably of course it gets more complex than this :) For now, I preferred to do it the "hard" way - just retain this object and release it later on (yes, yes, with my newest shiny patch :P ) |
From: Joshua M. <xm...@me...> - 2010-05-24 17:20:01
|
Panayotis, This particular issue can occur in a variety of places. In general they are very hard to detect unless you get lucky at runtime. I strongly recommend commenting out: >> // new ExcessRetainsOptimization().Process(curRun.allCodePaths, curRun.beenTo, >> // codeElement); in order to prevent any other nasty surprises. Regards, -- Joshua Melcon 2010/5/24 Panayotis Katsaloulis <pan...@pa...>: > > On 24 Μαϊ 2010, at 7:16 μ.μ., Joshua Melcon wrote: > >> Hi Panayotis, >> >> I am aware of this issue and have been working on a fix for it. >> Sadly, the fix is non trivial though I am making (slow) progress on >> it. >> >> For now, the best workaround is to comment out >> // new ExcessRetainsOptimization().Process(curRun.allCodePaths, curRun.beenTo, >> // codeElement); >> >> in ReferenceCounting.java. >> >> Since this bug is affecting people, I will talk to Arno about checking >> in that workaround until I can actually implement a correct fix. >> >> Sorry you encountered this... > > The good thing is someone is working on it (the bad is that I spent 4 hours to understand why my application didn't work with latest version of xmlvm :-o ) > > As with my previous e-mail, I'll suggest a simple fix for this: every time an object is referenced this way, retain this object and keep track of it, as with other objects. When this is no longer needed, release it. > Probably of course it gets more complex than this :) > > For now, I preferred to do it the "hard" way - just retain this object and release it later on (yes, yes, with my newest shiny patch :P ) > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |
From: Panayotis K. <pan...@pa...> - 2010-05-25 06:27:48
|
On 24 Μαϊ 2010, at 8:19 μ.μ., Joshua Melcon wrote: > Panayotis, > > This particular issue can occur in a variety of places. In general > they are very hard to detect unless you get lucky at runtime. I > strongly recommend commenting out: >>> // new ExcessRetainsOptimization().Process(curRun.allCodePaths, curRun.beenTo, >>> // codeElement); > > in order to prevent any other nasty surprises. > > Regards, > > -- Joshua Melcon > Probably then this should be default for xmlvm? Or what about a (hidden/advanced?) parameter for xmlvm which will turn this on and off? |
From: Arno P. <ar...@pu...> - 2010-05-25 06:37:48
|
I just commented out the faulty optimization in the repository. I don't think it makes sense to add a parameter for something that doesn't work. Arno On 5/25/10 8:22 AM, Panayotis Katsaloulis wrote: > > On 24 Μαϊ 2010, at 8:19 μ.μ., Joshua Melcon wrote: > >> Panayotis, >> >> This particular issue can occur in a variety of places. In general >> they are very hard to detect unless you get lucky at runtime. I >> strongly recommend commenting out: >>>> // new ExcessRetainsOptimization().Process(curRun.allCodePaths, curRun.beenTo, >>>> // codeElement); >> >> in order to prevent any other nasty surprises. >> >> Regards, >> >> -- Joshua Melcon >> > > > Probably then this should be default for xmlvm? > Or what about a (hidden/advanced?) parameter for xmlvm which will turn this on and off? > ------------------------------------------------------------------------------ > > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users |
From: Gergely K. <ger...@ma...> - 2010-05-25 19:27:16
|
Hi, Actually it might make sense to add a set of -O compiler flags, so that it is easier for the users to experiment with it, but the default settings would generate "safe" code. What do you think? Best Regards, Gergely 2010/5/25 Arno Puder <ar...@pu...> > > I just commented out the faulty optimization in the repository. I don't > think it makes sense to add a parameter for something that doesn't work. > > Arno > > > On 5/25/10 8:22 AM, Panayotis Katsaloulis wrote: > > > > On 24 Μαϊ 2010, at 8:19 μ.μ., Joshua Melcon wrote: > > > >> Panayotis, > >> > >> This particular issue can occur in a variety of places. In general > >> they are very hard to detect unless you get lucky at runtime. I > >> strongly recommend commenting out: > >>>> // new ExcessRetainsOptimization().Process(curRun.allCodePaths, > curRun.beenTo, > >>>> // codeElement); > >> > >> in order to prevent any other nasty surprises. > >> > >> Regards, > >> > >> -- Joshua Melcon > >> > > > > > > Probably then this should be default for xmlvm? > > Or what about a (hidden/advanced?) parameter for xmlvm which will turn > this on and off? > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > xmlvm-users mailing list > > xml...@li... > > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > > > ------------------------------------------------------------------------------ > > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > -- Kis Gergely MattaKis Consulting Email: ger...@ma... Web: http://www.mattakis.com Phone: +36 70 408 1723 Fax: +36 27 998 622 |