Re: FF DevMode plugin + Memory leaks (+ Address already in use)
Tracking bug: http://code.google.com/p/google-web-toolkit/issues/detail?id=7648 On Tuesday, August 28, 2012 7:13:27 PM UTC-7, Brian Slesinsky wrote: Reproduced the thread leak in the Firefox 15 release that I'm working on. (On a Mac; using jps to list the threads.) On Tuesday, August 28, 2012 3:31:10 PM UTC-7, Chris Lercher wrote: Yes. I disabled all Add-Ons: All Extensions (except for the GWT Extension) and all Plugins, and restarted Firefox. On Wednesday, August 29, 2012 12:12:03 AM UTC+2, Brian Slesinsky wrote: Does the connection leak happen with all plugins (other than GWT) disabled? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/nu37r6UNg80J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: FF DevMode plugin + Memory leaks (+ Address already in use)
I analyzed this a bit more (this time on Linux), and I noticed, that the number of Thread also grows: 1 thread per reload. Again, this happens only with Firefox, not with Chrome. So probably the ClassLoader references will be discarded only when the Thread terminates... One more thing that might be interesting: When closing the entire FF instance (just closing the tab is not enough), then the threads are discarded, and Heap/PermGen space can be garbage collected. By the way, closing the FF instance leads to the following Exception printed by the DevMode server: 10:53:21.549 [ERROR] [mymodule] Remote connection lost com.google.gwt.dev.shell.BrowserChannel$RemoteDeathError: Remote connection lost at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:308) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.EOFException: null at java.io.DataInputStream.readByte(DataInputStream.java:250) at com.google.gwt.dev.shell.BrowserChannel$Message.readMessageType(BrowserChannel.java:1100) at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:284) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364) at java.lang.Thread.run(Thread.java:662) On Tuesday, August 28, 2012 2:07:02 AM UTC+2, Brian Slesinsky wrote: That's an interesting report. We always want to garbage collect the ClassLoader when the session is over and if that doesn't happen, it's a bug. I don't know why Firefox would behave differently; the JVM side should work the same way for Firefox versus Chrome. The only thing I can think of is some difference in distributed garbage collection, but that shouldn't matter once the session ends. Alan's not on the team anymore. I'd like to fix this, but I'm busy with other things and I don't have a good idea where to begin. If someone's handy with a memory profiler, figuring out what's preventing the classloader from being gc-ed in this case would be very useful. - Brian -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/0tBYLSRxh1AJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: FF DevMode plugin + Memory leaks (+ Address already in use)
In other words: it looks like the Firefox plugin doesn't send a QuitMessage to the DevMode, and worse, is kept alive in the background! On Tuesday, August 28, 2012 11:05:38 AM UTC+2, Chris Lercher wrote: I analyzed this a bit more (this time on Linux), and I noticed, that the number of Thread also grows: 1 thread per reload. Again, this happens only with Firefox, not with Chrome. So probably the ClassLoader references will be discarded only when the Thread terminates... One more thing that might be interesting: When closing the entire FF instance (just closing the tab is not enough), then the threads are discarded, and Heap/PermGen space can be garbage collected. By the way, closing the FF instance leads to the following Exception printed by the DevMode server: 10:53:21.549 [ERROR] [mymodule] Remote connection lost com.google.gwt.dev.shell.BrowserChannel$RemoteDeathError: Remote connection lost at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:308) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.EOFException: null at java.io.DataInputStream.readByte(DataInputStream.java:250) at com.google.gwt.dev.shell.BrowserChannel$Message.readMessageType(BrowserChannel.java:1100) at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:284) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364) at java.lang.Thread.run(Thread.java:662) On Tuesday, August 28, 2012 2:07:02 AM UTC+2, Brian Slesinsky wrote: That's an interesting report. We always want to garbage collect the ClassLoader when the session is over and if that doesn't happen, it's a bug. I don't know why Firefox would behave differently; the JVM side should work the same way for Firefox versus Chrome. The only thing I can think of is some difference in distributed garbage collection, but that shouldn't matter once the session ends. Alan's not on the team anymore. I'd like to fix this, but I'm busy with other things and I don't have a good idea where to begin. If someone's handy with a memory profiler, figuring out what's preventing the classloader from being gc-ed in this case would be very useful. - Brian -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/5saLTgZ7UjEJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: FF DevMode plugin + Memory leaks (+ Address already in use)
Thanks, I think I can do something about this. On Tue, Aug 28, 2012 at 2:15 AM, Thomas Broyer t.bro...@gmail.com wrote: In other words: it looks like the Firefox plugin doesn't send a QuitMessage to the DevMode, and worse, is kept alive in the background! On Tuesday, August 28, 2012 11:05:38 AM UTC+2, Chris Lercher wrote: I analyzed this a bit more (this time on Linux), and I noticed, that the number of Thread also grows: 1 thread per reload. Again, this happens only with Firefox, not with Chrome. So probably the ClassLoader references will be discarded only when the Thread terminates... One more thing that might be interesting: When closing the entire FF instance (just closing the tab is not enough), then the threads are discarded, and Heap/PermGen space can be garbage collected. By the way, closing the FF instance leads to the following Exception printed by the DevMode server: 10:53:21.549 [ERROR] [mymodule] Remote connection lost com.google.gwt.dev.shell.BrowserChannel$RemoteDeathError: Remote connection lost at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:308) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.EOFException: null at java.io.DataInputStream.readByte(DataInputStream.java:250) at com.google.gwt.dev.shell.BrowserChannel$Message.readMessageType(BrowserChannel.java:1100) at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:284) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364) at java.lang.Thread.run(Thread.java:662) On Tuesday, August 28, 2012 2:07:02 AM UTC+2, Brian Slesinsky wrote: That's an interesting report. We always want to garbage collect the ClassLoader when the session is over and if that doesn't happen, it's a bug. I don't know why Firefox would behave differently; the JVM side should work the same way for Firefox versus Chrome. The only thing I can think of is some difference in distributed garbage collection, but that shouldn't matter once the session ends. Alan's not on the team anymore. I'd like to fix this, but I'm busy with other things and I don't have a good idea where to begin. If someone's handy with a memory profiler, figuring out what's preventing the classloader from being gc-ed in this case would be very useful. - Brian -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/5saLTgZ7UjEJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: FF DevMode plugin + Memory leaks (+ Address already in use)
Does the connection leak happen with all plugins (other than GWT) disabled? On Tuesday, August 28, 2012 7:57:37 AM UTC-7, Brian Slesinsky wrote: Thanks, I think I can do something about this. On Tue, Aug 28, 2012 at 2:15 AM, Thomas Broyer wrote: In other words: it looks like the Firefox plugin doesn't send a QuitMessage to the DevMode, and worse, is kept alive in the background! On Tuesday, August 28, 2012 11:05:38 AM UTC+2, Chris Lercher wrote: I analyzed this a bit more (this time on Linux), and I noticed, that the number of Thread also grows: 1 thread per reload. Again, this happens only with Firefox, not with Chrome. So probably the ClassLoader references will be discarded only when the Thread terminates... One more thing that might be interesting: When closing the entire FF instance (just closing the tab is not enough), then the threads are discarded, and Heap/PermGen space can be garbage collected. By the way, closing the FF instance leads to the following Exception printed by the DevMode server: 10:53:21.549 [ERROR] [mymodule] Remote connection lost com.google.gwt.dev.shell.BrowserChannel$RemoteDeathError: Remote connection lost at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:308) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.EOFException: null at java.io.DataInputStream.readByte(DataInputStream.java:250) at com.google.gwt.dev.shell.BrowserChannel$Message.readMessageType(BrowserChannel.java:1100) at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:284) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364) at java.lang.Thread.run(Thread.java:662) On Tuesday, August 28, 2012 2:07:02 AM UTC+2, Brian Slesinsky wrote: That's an interesting report. We always want to garbage collect the ClassLoader when the session is over and if that doesn't happen, it's a bug. I don't know why Firefox would behave differently; the JVM side should work the same way for Firefox versus Chrome. The only thing I can think of is some difference in distributed garbage collection, but that shouldn't matter once the session ends. Alan's not on the team anymore. I'd like to fix this, but I'm busy with other things and I don't have a good idea where to begin. If someone's handy with a memory profiler, figuring out what's preventing the classloader from being gc-ed in this case would be very useful. - Brian -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/YxkUXpopHQYJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: FF DevMode plugin + Memory leaks (+ Address already in use)
Yes. I disabled all Add-Ons: All Extensions (except for the GWT Extension) and all Plugins, and restarted Firefox. On Wednesday, August 29, 2012 12:12:03 AM UTC+2, Brian Slesinsky wrote: Does the connection leak happen with all plugins (other than GWT) disabled? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Y47n4p71LKAJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: FF DevMode plugin + Memory leaks (+ Address already in use)
Reproduced the thread leak in the Firefox 15 release that I'm working on. (On a Mac; using jps to list the threads.) On Tuesday, August 28, 2012 3:31:10 PM UTC-7, Chris Lercher wrote: Yes. I disabled all Add-Ons: All Extensions (except for the GWT Extension) and all Plugins, and restarted Firefox. On Wednesday, August 29, 2012 12:12:03 AM UTC+2, Brian Slesinsky wrote: Does the connection leak happen with all plugins (other than GWT) disabled? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Q7LNeHh71V0J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
FF DevMode plugin + Memory leaks (+ Address already in use)
When I analyze a DevMode process's memory usage (e.g. using jconsole), it shows that Heap and Non-Heap (PermGen) Memory usage increases, whenever the page is reloaded. This happens both when I run DevMode with Firefox 14, as well as Chrome 21. The difference is however, that - with Chrome, Heap and PermGen usage restores to a very low value after calling Perform GC - whereas in Firefox the PermGen stays at the high value, and the Heap just decreases slightly. After a number of reloads, this leads to an out of memory (Heap or PermGen, depending on which reaches the limit first). More often than not, the out of memory is not printed (which is usual for out of memory errors). *How to reproduce the error?* Create a simple GWT project (e.g. the one that's auto-generated by Eclipse), use Firefox, press the reload-button repeatedly (tested on OS X 10.6, but I've encountered similar memory problems on Linux amd64, too) *Solution?* Without knowing anything about the details of the FF plugin, it looks as if the Chrome plugin discards the ClassLoader entirely (so the PermGen space can be freed up http://stackoverflow.com/a/148707/291741), whereas FF probably keeps a reference to the ClassLoader somewhere (?) *Problems when restarting DevMode* The problem may also explain, why many people are seeing an [ERROR] Unable to bind socket on port 9997 -- is another session active? java.net.BindException: Address already in use after restarting DevMode (see e.g. https://groups.google.com/d/topic/google-web-toolkit/btPIOoriq_o/discussion , http://code.google.com/p/google-web-toolkit/issues/detail?id=4312 , http://code.google.com/p/google-web-toolkit/issues/detail?id=4514 , ...). It would also explain, why it's often dismissed as cannot reproduce (because it cannot be reproduced with Chrome). But when stopping a DevMode server that is (nearly) out of memory, it may hang. And you usually won't see an error message (the reason why I finally found this issue, is that I did get it a few times now). Plus, in Eclipse it looks as if DevMode had already terminated (the red stop button turns gray). *Question:* Is it a good idea to create another new issue for this? I'd like to ask here first, if anybody knows what the Status is? @AlanLeung? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/aDdcADCmUbIJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: FF DevMode plugin + Memory leaks (+ Address already in use)
That's an interesting report. We always want to garbage collect the ClassLoader when the session is over and if that doesn't happen, it's a bug. I don't know why Firefox would behave differently; the JVM side should work the same way for Firefox versus Chrome. The only thing I can think of is some difference in distributed garbage collection, but that shouldn't matter once the session ends. Alan's not on the team anymore. I'd like to fix this, but I'm busy with other things and I don't have a good idea where to begin. If someone's handy with a memory profiler, figuring out what's preventing the classloader from being gc-ed in this case would be very useful. - Brian On Monday, August 27, 2012 10:07:08 AM UTC-7, Chris Lercher wrote: When I analyze a DevMode process's memory usage (e.g. using jconsole), it shows that Heap and Non-Heap (PermGen) Memory usage increases, whenever the page is reloaded. This happens both when I run DevMode with Firefox 14, as well as Chrome 21. The difference is however, that - with Chrome, Heap and PermGen usage restores to a very low value after calling Perform GC - whereas in Firefox the PermGen stays at the high value, and the Heap just decreases slightly. After a number of reloads, this leads to an out of memory (Heap or PermGen, depending on which reaches the limit first). More often than not, the out of memory is not printed (which is usual for out of memory errors). *How to reproduce the error?* Create a simple GWT project (e.g. the one that's auto-generated by Eclipse), use Firefox, press the reload-button repeatedly (tested on OS X 10.6, but I've encountered similar memory problems on Linux amd64, too) *Solution?* Without knowing anything about the details of the FF plugin, it looks as if the Chrome plugin discards the ClassLoader entirely (so the PermGen space can be freed up http://stackoverflow.com/a/148707/291741), whereas FF probably keeps a reference to the ClassLoader somewhere (?) *Problems when restarting DevMode* The problem may also explain, why many people are seeing an [ERROR] Unable to bind socket on port 9997 -- is another session active? java.net.BindException: Address already in use after restarting DevMode (see e.g. https://groups.google.com/d/topic/google-web-toolkit/btPIOoriq_o/discussion , http://code.google.com/p/google-web-toolkit/issues/detail?id=4312 , http://code.google.com/p/google-web-toolkit/issues/detail?id=4514 , ...). It would also explain, why it's often dismissed as cannot reproduce (because it cannot be reproduced with Chrome). But when stopping a DevMode server that is (nearly) out of memory, it may hang. And you usually won't see an error message (the reason why I finally found this issue, is that I did get it a few times now). Plus, in Eclipse it looks as if DevMode had already terminated (the red stop button turns gray). *Question:* Is it a good idea to create another new issue for this? I'd like to ask here first, if anybody knows what the Status is? @AlanLeung? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/I3cf0A4RHKUJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
