If you're running from CVS, then yes, Process Viewer will show 'com.limegroup.gnutella.gui.Main'. The output also won't go to Console, it will go into the Terminal that you started the CVS version with.

I'd ideally like to see the Console output of running kill -QUIT on a Beta LimeWire version, not LimeWire from CVS. Getting the output from CVS is not the same thing.

I guess I'll have to dl the beta version then :(

et voila -- Did you see the many threads you mentioned earlier while running the CVS version? We like people running from CVS, but it occasionally can be unstable, and we can't control how it runs or what it produces. Information about CVS is best sent to the core or gui dev mailing lists at limewire.org. These forums are best for information about the released betas. We not only change code when releasing, we change our packaging procedures and installers and launchers. When we ask people to test betas, we're looking for the full experience of using LimeWire, which unfortunately does include downloading, installing, and running the installed version.

(oh -- and congratulations to me on my 1000th post as a registered user. :) )

My server is always running a CVS version (because I compile LW to not upload to leech clients). I'll installl the beta onto it and will dl a big popular movie while running UP, I'm sure the problem will pop up ;)

This thread leak problem makes me remember a discussion about the OS X Aqua interface loosing threads with progress bars. Would it be feasible to test this by replacing all progress bars with a simple textual percentage and see if the problem goes away?

There's only one thread with progress bars, the Event Thread (otherwise known as the Swing thread). Not really possible to change that one.

No not that one. I did read in the java dev list that the swing progress bar component does spawn it's own threads for the animation and sometimes does forget to clean up this extra background thread. I thought if one could replace all progress bar components with a simple text label one that only display the percentage text one could check if the progress bar component is the culprit of the memory problem.

Ohhhh --- Yeah, it's definitely possible to do that.

There's only four progressbars that are used anywhere, though. The first is in the splash screen, the second is in the status bar while LimeWire is visible but still loading the core, the third is all uploads/downloads (they use a single JProgressBar) and the fourth is for the progress of search results (they also all use a single JProgressBar).

You can find the first two in com/limegroup/gnutella/gui/StatusComponent. The one in tables is in com/limegroup/gnutella/gui/tables/ProgressBarRenderer. The one for the search results is in the 'macosx' directory of gui, further in com/limegroup/gnutella/gui/AquaTab. (That one is easiest to change in com/limegroup/gnutella/gui/ProgTabUIFactory, though).

Downloaded two 700MB files this night, wasn't able to trigger the thread problems. Maybe a CVS problem... :)

150 threads 1GB VM... might not say a lot of things, but if it helps (yes 4.3.2 beta), here is the kill -QUIT console report.