LimeWire 4.10.7 Beta
 

LimeWire 4.10.7's been out for a day or so. Changes are listed at http://www.limewire.com/english/cont..._history.shtml .

If folks could give this a whirl and let us know how it goes, it'd be much appreciated. There's some serious changes to the internal networking code, and we'd like to make sure everything works.

If you do LAN transfers (from one computer to another within the same network) and they're both using this newer version, you'll notice the transfer speeds are faster than anything you've ever seen since 4.9.0. (We saw ~5,000kbps speeds.) Even if you don't do LAN transfers and both sides are using this newer version, transfer speeds should be faster.

Thanks.

RKapsi, I noticed the improved iTunes support for videos. On OSX does that mean automatic import for mpeg 4 files? It seems like something easy to add. Perhaps not everybody would desire their movies be imported also, but if they are, then they could just as easily be deleted from iTunes. Just a few days ago I tested out my new dvd player which supports divx/xvid/mpeg4 & simply burnt a data dvd-rw with music clips, & they played happily on the player. (Cost equivalent of US $80.45)

What are the improvements for iTunes video if this is not the case? "Added support for sharing video files via DAAP (to programs such as iTunes)"

* Whilst I was running Panther & 4.10, I found my VM usage whilst using the search function seemed to have a memory leak. Has this been repaired? Will this also occur on Tiger using Java 1.5? Perhaps it's system & hardware related ... I upgraded about a week ago. I found instant improvements in Java 1.5 but didn't try 1.4.2 in Tiger & haven't been using 4.10 (was too impractical before ... see jum's last thread in this section!)

Sam, let me be the first (around here) to give you a warm welcome back. I also like the new changes. (btw, I've been bitching about LAN transfer speeds for a long time now. ;) its about time you remove the cap on it! :D)

I also want to say that spam is on the rise (in a few areas). A few things to seriously consider for the next release:

1) Along with WMV/ASF files, ASX files should also be ignored by default. As I already told Roger about this: "ASX files are textual command files that manage streaming of ASF files." These files are being used specifically by spammers. Since you already ignore ASF files by default, why not ignore the files that are used to control them?

2) The most important of all: Action URL Launching. The word is out!! Spammers are using this technique now. Its only a matter of time before a malicious user will take this convient tool and destroy gnutella (and its users) with a nice exploit through a browser. Think of how many LW users run Internet Explorer. Its an exploit playground. (to the average user that reads this, i just have to recommend the firefox browser instead of Internet Explorer - www.getfirefox.com)

well I doubt it will make much difference or any on my machines since LW was already capable of maxing out my connection with no problem 750KB/s+ but I will give it a try.

ultracross

Have you given IE 7 Beta a try they have made some improvements to browser safety and it loads pages allot faster. It has a Phishing filter in it now and they say the official release will be even faster and more secure than the beta. Personally I like but haven't really be able to test the new security that much yet. It has blocked a couple of web pages with the Phishing filter but I don't know if they were actually Phishing pages.

Some bug reports:

LimeWire version 4.10.7 Pro
Java version 1.5.0_06 from Sun Microsystems Inc.
Windows XP v. 5.1 on x86
Free/total memory: 2505280/23158784

java.lang.RuntimeException: java.io.IOException: Unable to establish loopback connection
at com.limegroup.gnutella.io.NIODispatcher.swapSelect or(NIODispatcher.java:504)
at com.limegroup.gnutella.io.NIODispatcher.run(NIODis patcher.java:542)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.java:64)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:53)
Caused by: java.io.IOException: Unable to establish loopback connection
at sun.nio.ch.PipeImpl$Initializer.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.nio.ch.PipeImpl.<init>(Unknown Source)
at sun.nio.ch.SelectorProviderImpl.openPipe(Unknown Source)
at java.nio.channels.Pipe.open(Unknown Source)
at sun.nio.ch.WindowsSelectorImpl.<init>(Unknown Source)
at sun.nio.ch.WindowsSelectorProvider.openSelector(Un known Source)
at java.nio.channels.Selector.open(Unknown Source)
at com.limegroup.gnutella.io.NIODispatcher.swapSelect or(NIODispatcher.java:501)
... 4 more
Caused by: java.net.SocketException: No buffer space available (maximum connections reached?): listen
at sun.nio.ch.ServerSocketChannelImpl.listen(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
... 13 more


Detail: Uncaught thread error.

-- listing session information --
Current thread: NIODispatcher
Active Threads: 31
Uptime: 6:50:07
Is Connected: true
Number of Ultrapeer -> Ultrapeer Connections: 0
Number of Ultrapeer -> Leaf Connections: 0
Number of Leaf -> Ultrapeer Connections: 2
Number of Old Connections: 0
Acting as Ultrapeer: false
Acting as Shielded Leaf: true
Number of Active Uploads: 0
Number of Queued Uploads: 0
Number of Active Managed Downloads: 1
Number of Active HTTP Downloaders: 9
Number of Waiting Downloads: 0
Received incoming this session: true
Number of Shared Files: 10
Guess Capable: true
Received Solicited UDP: true
SIMPP version: 44
Port Stable: true
FWT Capable: true
Last Reported Port: 6390
External Port: 6390
IP Pongs Received: 0

-- listing threads --
JmDNS.RecordReaper: 1
HttpClient-ReferenceQueueThread: 1
MessageDispatch: 1
Thread-9: 1
QueryUnicaster: 1
ManagedDownload: 1
Java2D Disposer: 1
TimerQueue: 1
DownloadWorker: 9
BlockingVF: 1
MulticastService: 1
Acceptor: 1
HttpClient-IdleConnectionThread: 1
Java Sound Event Dispatcher: 1
AWT-Shutdown: 1
AWT-Windows: 1
AWT-EventQueue-0: 1
Timer-0: 1
QRPPropagator: 1
DestroyJavaVM: 1
DaapServerThread: 1
HTTPAcceptor: 1
JmDNS.SocketListener: 1


-- listing properties --
WINDOW_Y=63
FORCE_IP_ADDRESS=true
WINDOW_X=23
PORT=6390
TTL=5
RUN_ON_STARTUP=false
UPDATE_DELAY=431999998
UPDATE_GIVEUP_FACTOR=24
SEARCH_MAGNETMIX_BUTTON=true
FILTER_HASH_QUERIES=true
INSTALLED=true
UI_LIBRARY_TREE_DIVIDER_LOCATION=193
EXTENSIONS_TO_SEARCH_FOR=html;htm;xml;txt;pdf;ps;r tf;doc;tex;m...
AVERAGE_UPTIME=148990
TOTAL_UPTIME=1340915
MAX_UPLOAD_BYTES_PER_SEC=85
MIN_CONNECT_TIME=7
COUNTRY=
TREE_NODE_PREFIXES=a
LAST_SHUTDOWN_TIME=1139877343578
APP_WIDTH=981
SESSIONS=9
SHOW_TOTD=false
FILTER_ADULT=true
FORCED_PORT=6390
ALLOW_PARTIAL_SHARING=false
LAST_ACCEPTABLE_BUG_VERSION=4.10.4
DOWNLOAD_SPEED=16
FRACTIONAL_UPTIME=0.13306428
CONNECTION_SPEED=3000
LAST_EXPIRE_TIME=1138761836921
MAX_DOWNLOAD_BYTES_PER_SEC=475
UPDATE_DOWNLOAD_DELAY=10000000
RUN_ONCE=true
APP_HEIGHT=658
EVER_SUPERNODE_CAPABLE=true
MAX_SIM_DOWNLOAD=8
LAST_GWEBCACHE_FETCH_TIME=1139671890890
EVER_ACCEPTED_INCOMING=true
UNSET_FIREWALLED_FROM_CONNECTBACK=true
CLIENT_ID=0442606738FE89A9FF5199D6ED087400
FILTER_WHATS_NEW_ADULT=false
PARALLEL_SEARCH=10
FLUSH_DELAY_TIME=256
IDLE_CONNECTIONS=2
CONNECTION_VIEW_ENABLED=true


-----------------------------------------------


LimeWire version 4.10.7 Pro
Java version 1.5.0_06 from Sun Microsystems Inc.
Windows XP v. 5.1 on x86
Free/total memory: 1711792/23158784

java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at com.limegroup.gnutella.downloader.ManagedDownloade r.startWorker(ManagedDownloader.java:2297)
at com.limegroup.gnutella.downloader.ManagedDownloade r.fireDownloadWorkers(ManagedDownloader.java:2484)
at com.limegroup.gnutella.downloader.ManagedDownloade r.performDownload(ManagedDownloader.java:1990)
at com.limegroup.gnutella.downloader.ManagedDownloade r$1.run(ManagedDownloader.java:759)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.java:64)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:53)


-- listing session information --
Current thread: ManagedDownload
Active Threads: 35
Uptime: 6:49:57
Is Connected: true
Number of Ultrapeer -> Ultrapeer Connections: 0
Number of Ultrapeer -> Leaf Connections: 0
Number of Leaf -> Ultrapeer Connections: 2
Number of Old Connections: 0
Acting as Ultrapeer: false
Acting as Shielded Leaf: true
Number of Active Uploads: 0
Number of Queued Uploads: 0
Number of Active Managed Downloads: 1
Number of Active HTTP Downloaders: 9
Number of Waiting Downloads: 0
Received incoming this session: true
Number of Shared Files: 10
Guess Capable: true
Received Solicited UDP: true
SIMPP version: 44
Port Stable: true
FWT Capable: true
Last Reported Port: 6390
External Port: 6390
IP Pongs Received: 0

-- listing threads --
HttpClient-ReferenceQueueThread: 1
NIODispatcher: 1
UDPHostRanker: 1
DownloadWorker: 10
Acceptor: 1
MulticastService: 1
AWT-EventQueue-0: 1
AWT-Windows: 1
AWT-Shutdown: 1
Java Sound Event Dispatcher: 1
Timer-0: 1
DestroyJavaVM: 1
JmDNS.RecordReaper: 1
Image Fetcher 3: 1
MessageDispatch: 1
Thread-9: 1
QueryUnicaster: 1
ManagedDownload: 1
Java2D Disposer: 1
TimerQueue: 1
BlockingVF: 1
HttpClient-IdleConnectionThread: 1
QRPPropagator: 1
HTTPAcceptor: 1
DaapServerThread: 1
JmDNS.SocketListener: 1


-- listing properties --
WINDOW_Y=63
FORCE_IP_ADDRESS=true
WINDOW_X=23
PORT=6390
TTL=5
RUN_ON_STARTUP=false
UPDATE_DELAY=431999998
UPDATE_GIVEUP_FACTOR=24
SEARCH_MAGNETMIX_BUTTON=true
FILTER_HASH_QUERIES=true
INSTALLED=true
UI_LIBRARY_TREE_DIVIDER_LOCATION=193
EXTENSIONS_TO_SEARCH_FOR=html;htm;xml;txt;pdf;ps;r tf;doc;tex;m...
AVERAGE_UPTIME=148989
TOTAL_UPTIME=1340904
MAX_UPLOAD_BYTES_PER_SEC=85
MIN_CONNECT_TIME=7
COUNTRY=
TREE_NODE_PREFIXES=a
LAST_SHUTDOWN_TIME=1139877343578
APP_WIDTH=981
SESSIONS=9
SHOW_TOTD=false
FILTER_ADULT=true
FORCED_PORT=6390
ALLOW_PARTIAL_SHARING=false
LAST_ACCEPTABLE_BUG_VERSION=4.10.4
DOWNLOAD_SPEED=16
FRACTIONAL_UPTIME=0.13306428
CONNECTION_SPEED=3000
LAST_EXPIRE_TIME=1138761836921
MAX_DOWNLOAD_BYTES_PER_SEC=475
UPDATE_DOWNLOAD_DELAY=10000000
RUN_ONCE=true
APP_HEIGHT=658
EVER_SUPERNODE_CAPABLE=true
MAX_SIM_DOWNLOAD=8
LAST_GWEBCACHE_FETCH_TIME=1139671890890
EVER_ACCEPTED_INCOMING=true
UNSET_FIREWALLED_FROM_CONNECTBACK=true
CLIENT_ID=0442606738FE89A9FF5199D6ED087400
FILTER_WHATS_NEW_ADULT=false
PARALLEL_SEARCH=10
FLUSH_DELAY_TIME=256
IDLE_CONNECTIONS=2
CONNECTION_VIEW_ENABLED=true

Hi all, and thanks Sam for the changelog and asking for feedback here again.

Re LAN transfers--no luck here, but some improvements noted.

--The upload bandwidth controls still seem to control even LAN transfers. I had mine set on both machines to 90 KB/s. Could LAN transfers be made exempt from the bandwidth controls?

--even with the upload bandwidth slider set to "Unlimited" on either or both machines, transfers were limited to not much more than 150 KB/s

--browsing each machine was not smooth--several tries were needed. I remember LAN browsing being almost instant. Port 20300 opened and forwarded on one machine; 20303 on the other.

the good news: the Monitor pane showed only a single upload (in the past two uploads showed per transfer; one to the router's internal IP; the other to the machine's internal IP)

Both machines were running LW PRo 4.10.7, but different java versions. 1.5.0_05 on the laptop; 1.4.2_09 on the desktop.

I have to say that I did not even see the speed increase over LAN transfers.

Any chance something changed in 4.10.7 to increase CPU %?
On a 1.4 GHz G4 running Mac OS X v. 10.4.4 on ppc (1 GB RAM), I was surprised to see the CPU use seems to be much higher than I recall from last summer.

(btw--the VM problem is still the same, but that's not new).

I didn't get around to trying 4.10.7, but just trying 4.10.8 now. I notice my pre-4.9 incompletes refused to load. lol :D Anyway more to today's issues, I've been finding some odd behaviour. Tiger 10.4.4 with Java 1.5; Audio downlds are seeming to freeze LW during verification (just small files) but the downld & importation into iTunes still continues. I was surprised to see my search & verfication freeze (at 90%) but then iTunes open & import. Similar for the next file. A total freeze of LW except for prefs. 3rd downld the same, froze at 93% verification but iTunes still imported it. The freeze seems to last for a reasonable time after iTunes has imported it. There doesn't appear to be any jump in VM or ram during that time but cpu does jump up.

In one search (my 1st) I initially obtained many results, but suddenly these disappeared. These were files of all sizes & names & artists. I ended up with "only" results of the artist I was after. The search tab shows eg 40/80 as though the others have been filtered out. I didn't see why the others should have been filtered out. CPU is running around 15-20% for a simple downld & upld, 167 MB ram, 543 MB VM, after 4rth search & 1 browse. A browse seems to shoot cpu up to about 50%, with vm & ram staying about the same. End of browse cpu drops down. I have to say since all my searches were for the one artist, not one of them shows any other artists. Is this something new or is this the junk filter gone wild (the level is set on mildish)? I haven't filtered out much at all - just 2 in fact. Or do you think this complication is related to me using old preferences? I forgot to mention, I was doing Any Type searches not audio type searches. And it was only the very 1st search that showed a 40/40 result with the other 40 disappearing. The rest "only" showed the artist I was searching.

The search tab seems to jump into the next hidden thingy ... I have to select that search from the arrow next to the tab to see it when multiple search tabs are present.

But I'm not so far suffering the vm issue I did with the initial 4.10 release. But then I'm running Java 1.5 & Tiger now.

2nd edit: Update: 4rth downld froze at 98% verif. & cpu jumps all around between 50-85%, mostly around the 80% mark during this time & freeze lasts for about 1 minute.

3rd edit: Now some hours later. I did a search, started downlding a file & despite another 2 results (sources) showing up it went to busy host, so I pressed cancel & LW froze up for just over 2 mins. I was still mid-way through the search also. When the freeze stopped, the search had finished. I was at least able to reselect the downld & get it downlding from 2 of the 3 hosts in the search results. But then, I lost one of the hosts & the other went to busy again. So I repeated the process, same thing ... freeze for over 2 mins. cpu jumping between 30-50% & vm 589 & ram 237. Then same thing happened a 3rd time running. :rolleyes: cpu goes back down to 20% or less afterward. I had another downld going but this wasn't affected, although it of course froze in the downld window but didn't seem to be affected when the freeze stopped. (BTW I use a Quicksilver 733 with 1.5 GB pc 133-333 ram.)

4th Edit: (almost an hour later) I notice that the file that I cancelled earlier, after coming out of Busy Host, then downlds with 2 sources for a short time but very quickly goes back to busy (after about 10-15 secs & stays busy for 1-2 mins). That's very odd it should do this from 2 hosts simultaneously. Almost as though it is the same host. Well there's about 1 second difference between the 1st & 2nd host starting to downld from. Ah I've noticed it's not always 2 hosts. But did this for some time anyway up until a couple of mins ago. It downlds at 10-13 KB/s or 5 KB/s (depending on occasion). I started this downld about an hr ago.

I had a kern protection failure when LW tried to access iTunes, and the iTunes EULA was hidden. That was on the desktop machine (10.3.9, java 1.4.2_09, and LW Pro 10.4.7), which I hadn't used with LW for quite a while.

Not sure what was going on, but sent the report to Apple with a comment that they support their java.

Thanks for the heads-up on 4.10.8--off to download :)

I can confirm a spike in the verification process. As I already told Roger Kapsi, it would probably reduce a huge bottleneck if the verification of chunks while downloading would be verified in memory instead of writing to the disk, then verifying it. Verifying it in memory cuts the read/write process in half since you download it, verify it in memory then write it to disk instead of downloading it, writing it to disk, then verifying it. Make sense? This could also potentially speed up the downloading process as a whole. I just know that its killing my disk with amount of read/writes its doing.

Or maybe a hyrbrid combination if the user doesn't have enough RAM?

Making sure we understand correctly a during the verification process the entire LW application freezes, but an import into iTunes succeeds, and eventually LW recovers from the freeze? If so, does this happen only with audio files of certain size? Does it also happen with video files (those should be shared with iTunes), and any other type of file?

What exactly do you mean by "A total freeze of LW except for prefs." Are you able to open and use the LW preferences? Do they get saved properly if modified?

Could you please try to compare whether the cpu and disk activity of 4.10.5 during the verification phase with that of .6, .7 or .8. Also, if you could get a stack trace during the freeze it would help us a ton.

The same issues haven't been evident. So despite using the console to make reports, there's nothing to report. :D I wonder if it was initial taking over of older version preferences. So I haven't had the same problems reported earlier. No freezing for verification or canceling downlds.

Videos appear in iTunes playlist if that's what you wanted to know. Are you intending to leave as an option in the LW preferences for potential future auto-importing of videos to iTunes on OSX?

After 12 hrs of leaving LW static (but uplding), VM was around 750 MB & after 4 hrs of searching & downlding it finished at just over 900 MB. Closing off windows, searches & console reduced it by perhaps 8 MB. :D

Edit: I will add though that LW just crashed whilst running in the background. It hasn't done that since I updated to Java 1.5 a couple of weeks ago.

4.10.9 released
 

Beta 4.10.9 is out. It reverts some of the changes that went into the last three betas and should use less cpu and cause less disk activity. Unfortunately, LAN transfers may be slower. Please give it a try and let us know how it goes.

Best,
LW dev team

Nothing special to report, other than after about 18 hours of use, all of a sudden both RAM & VM are suddenly on the increase whilst LW is not downlding (is uplding.) Have downlded large files over this time. Have 6 search tabs still up. I did a search just 5 mins before the 1st snapshot image below.

There's 3 mins between no. #1 & 2, 10 mins between no. 5 & 6, 22 mins between 1 & 6. It seems LW or Java has reached that point it just collapses in handling LW. Using Java 1.5, OS 10.4.4, LW 4.10.9
At this moment, 10 mins after the last snapshot, the ram is 348 MB, VM=2.04 GB, & 2,181 threads.

I can presume that LW will crash within the next half an hr. I presume this is OSX Java right & not LW's fault. :confused:

I decided to open the console before it crashed & save a report covering a few mins. Do you want to see any of it & if so, how much of it?

LW is now extremely sluggish, getting spinning beach ball trying to change view mode or other things for eg.

At present:
Threads=2,364 (increasing sharply!)
RAM=538 MB
VM=2.14 GB

Edit: I just got a couple of internal errors. Lost connection ... error of Potential dud connection in console report.
Ram=525
T=2,451
VM=2.18

Doesn't seem to be able to reconnect! Trying for several mins.

I gave up, LW refused to reconnect. It had used 2.20 GB VM.
I noticed there were around 1,500 listed as Upload capacity reached in my monitor window & the usual queued & uplder at 0. lol :D Was able to reconnect after re-opening.

So I guess LW reaches a point of no return re: Java on OSX.

BTW whatever happened to the days of files continuing on their own (find their own sources after LW starts)?

Memory doesn't surprise me, but 2000 threads???! Never seen that so far.

CPU% is much better with 4.10.9

I downloaded a couple of 600+MB files and I get like 80MB RAM and 490MB of VM between 28 and 80 threads, CPU usage is between 4-9% on 1.2Ghz iBook, Osx 10.4.5 java 1.5.0-5 with LW 4.10.9 as a leaf.

Very good so far, no easy bug or whatsoever to bitch about....

In fact I like 4.10.9, IMO downloads and uploads should be NIO to decrease, but... ;)

Ciao

Uploads & downoads (downloads first, probably) will be using NIO eventually.

Well if et voilà & Stief leave their system running 24+ hrs after downlding large & small files, ... then after a break do more searches .. perhaps some more junk filtering also ... & don't suffer the same java breakdown then it must be just my system. I thought I was doing well with Java 1.5 with an older LW version, but come 4.10 it seems a different story. Like the one I knew before the OSX upgrade if not worse. I didn't suffer internal errors before. Let alone inability to reconnect.

I guess I could trial out 4.10.0 again to see how Java 1.5 handles it compared to 1.4.2 in Panther. As documented in Jum's thread.

I don't run an imac. Is that the difference or is it the processor or general overall different mapology of newer G5's? :confused:

I don't mind beta testing if it's of any constructiveness for the proggies. But if I have a query, it would be helpful to me if I could get some type of answer. I don't know whether my reporting is constructive or just an ink blot on the page.

Ok perhaps I should delete my LW prefs, & change downld location to give it a total fresh approach. BTW how do we separate the section icons & figs at the bottom of the interface so we can know exactly how many files we're sharing? All I get is an ... as the sample image shows ... is that 37 tens or 3.7 thousands (or 370 k files)?

lotr
rather than changing location, etc, just install in a new admin account (then you don't have to worry about old prefs, etc).

I can run LW for about three days (as an UP), but when the system gets sluggish and the beachball starts working, then I know it's time to shutdown for two minutes to clear the VM. I also keep the incomplete folder purged as much as possible, and hide LW overnight. This really didn't change much whether it was with a G3, G4 and all the various OS X flavours.

re feedback in the beta threads: feedback is rare, but sure is nice when it shows. I think of the feedback as a bulletin board rather than a conversation.

More than fair enough comments! I'm a person who normally runs with a high no. of incompletes which no doubt contributed to my previous success of LW restarting incompletes without assistance.

What I had started to do just now would in effect start a new, fresh downld account if you like. But you're probably right, a new account will be without the intrusion of other program prefs, background running, etc. I will do this ... just the pia of relogging, blah blah .... :D When it shuts down all other operations.

If you hover over the number of shared files it should show a tooltip with the right number.

If you see a high # of threads again, could you get a full stack trace from the console log? You have to be running Java 1.5 to get it, so if that's possible that'd be good.

I did save 2-3 stack traces afaik if I did it right (6 altogether), reports of several mins of running last time. If you want to see them just ask. But I'll check in a new account & see how things go & see if it happens again. It will be a virgin downld space except for shares

I 1st need to finish using another app before I can log out though.

' "Full" stack traces ', what do you mean by full. I'd have thought about 20 hrs of running with stack trace on all the time would be somewhat over-sized. Yesterday I saved reports at intervals (1st two 9 & 10 hrs before) notably over the last period; 4 over 25 mins with each the equivalent of 15-16 A4 pages in Word (just to get a measure of the size.) The last 2 LW was not connected. I think the loss of connection happened during the 2nd last one (I'm not sure.) How to send them?

By full, I mean the ones from the console tab when choosing 'save' if you're running Java 1.5 or higher. The resulting file should include stack traces of every thread the program knows about. For now, just a single one of those when the program has this high number of threads should be fine. You're welcome to post it here as an attachment or mail it to this username @limepeer.com.

I'm not so much interested in the loss of connections right now as I am the 2000+ threads. The stack traces won't be too helpful to me for the loss of connections.

As a furter data point to the memory consumption on OS X: if you do not have any search tabs open and do just your queued downloads and uploads as searches come in everything is fine. As soon as I have a search tab open (even if it is not searching any more) the mem consumption goes up all the time and LimeWire will eventually crash due to the machine going out of memory.

well well well! Thanks for the tip--I'll give that a try this weekend. Might this then be "fixable" without Apple's help?

Possible problematic points:

search panel on the left
filter boxes on the left
search results table
downloads table

any chance you could muck around and see which one of those is causing the problems?

thanks.