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