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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.