re a cleaner GUI, I think I'll miss the lime, but not much. The search progress tabs make it redundant anyway.

I wondered if maybe the lime was removed to cut down on memory use

Well, at least we know it's not the cause of the VM problem

re the VM situation--I give up. For less than 1 GB of bandwidth, the VM rose to >1.5 GB before my G3 became pretty much unusable (took ~20 minutes of thrashing before I could quit this morning--and I still lost the BigTop graph). Would have been nice to track it down before Apple updates Java.

Hmm don't know if this is normal since I'm a really new user of LimeWire, but I just came to check the machine and when I was watching the connections screen It dumped about 20 peers and all of the leafs. The window flickered 3 0r 4 times and then it stabilized. I checked the Upload screen and all the speeds went way down (30 kb/s to 2kb/s). I wasn't downloading just sharing. No other programs running except Norton Internet Security. Now everything is back to normal. I've been connected for appx. 7 hours and 38 minutes

Ugh! I am still having a problem in LimeWire 4.3.3 beta (that also occurs in LimeWire 4.2.6) where LimeWire continues to download/upload but the actual window fails to redraw or respond to any keys or mouse clicks. To continue doing anything in LimeWire, I basically have to kill it and reload it. When reloaded, it runs for a little while (half an hour to 45 minutes) then the interface stops redrawing yet again. It seems to occur most often when "Advanced Statistics" is enabled, although it has happened a few times even with that turned off. This is on a machine with SuSE 9.0 Professional using Java 1.4.2_06. I've also tried java version 1.5.0_01 and it happens with that java version also. It occurs even with no downloads active.

Since you're running on SuSe, I take it you're running LimeWire from a console. If you could do a 'ps -aux' and locate the PID of the LimeWire process, then do a kill -QUIT on that process, LimeWire will spit out a stack trace on the console it was started on. The strack trace will show what is locked and preventing the GUI from refreshing.

Ok. I did a kill -SIGQUIT on LimeWire 4.3.3 beta running in java 1.4.2_06 during a recent GUI freeze and attached the full output of that stack trace.

Attached Files

limewire-freeze-stack-dump.txt (17.9 KB, 255 views)

Whelp, looks like it's the clipboard listening on Unixes that is freezing up the GUI -- it's waiting for the system to give it the available transfer types. Thanks for that clip, limenut.

No problem! Since you said it was clipboard related, it looks like I found reproducible way to trigger this bug.

1. Open LimeWire and don't minimize it.

2. Open Firefox in Linux.

3. Highlight some text on a web page then press CTRL C.

4. Exit Firefox.

The GUI in LimeWire would immediately fail to redraw after this.

hm, could you try with the latest jre from sun? You can get it from http://java.sun.com, it is 1.5.0_01

With 1.5.0_01, it freezes, but only for half a minute, then the GUI unfreezes afterwards when repeating the same steps that freezes the GUI permanently with java 1.4.2_06.

sberlin,
Yes, it happens on all tabs.
I was running 4.3.2 on JRE 1.5.0 (not "Update 1") so it's possible the problem is with Java.
The GUI corruption doesn't start right away. I think it only happens after the screensaver has run.

Since the change-log for 4.3.3 mentions "fix for GUI" I assume that something related was broken.
____________

As for the labels used in Connections, I think it would make more sense to refer to what kind of servent you're talking to, rather than to what kind of connection you have. I mean, if you're in Leaf mode and you upgrade to a UP, what are you going to learn from your former leaf-UP connections being re-labeled "peer" connections? OTOH, if you're in UP mode and you're talking to older non-UP clients, the current labels make it impossible to know.