recently i reinstalled the os from scatch after re-formatting the disk, applied the upgrade, repaired the disk and permissions after this.

installed limewire 4.1,9 pro and all ran smoothly for half an hour and it crashed. it crashes all the time after half an hour or so.

however, if i boot it up and leave it, ie, no searches then it will run for days.

tried all the usual stuff, repairing permissions, trashing preferences.

any ideas or is it a question of waiting for the next version of limewire

g4, 2x1.25
2gb ram
osx10.3.9
lw 4.10.9pro, (latest)

tia

ta for the qiuck response only a hobo. :-)

it crashes as it wipes out and the flash has unexpedly qui, quicktime 7.1 now but was version 5.0 at first install. version 1.4.2 of java, over 90gb of disk space.

will give the new beta a go then,

thanks

The Flash is USB read right? Do you have a usb 1.1 or later version card. In any case usb device for saving as you're trying to do is what's causing you problems. It's the flash card not LW that's causing the delay in reading & thus problems with overall performance (thus crashes/freezing!) Flash disks are only intended for quick copying of files ... not to be used as any type of share drive/external drive for any other purpose.

thanks for all the help feedback.

ive updated to the beta version but still the problem persists, yet if i leave limewire alone, (dont search for anything it will run happily for days)

dont know where flash came from i meant limewire :-)

the system is now on quicktime 7.1.1

here is the crash log if thats any use, just featureing the two threads that crashed

any advice appreciated, as some of the partial downloads dont restart unless i search for them


----

Date/Time: 2006-06-01 13:21:10 +0100
OS Version: 10.3.9 (Build 7W98)
Report Version: 2

Command: LimeWire
Path: /Applications/LimeWire/LimeWire.app/Contents/MacOS/LimeWire
Version: 4.11.1 Pro (LimeWire 4.11.1 Pro)
PID: 348
Thread: 10

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000010


Thread 2 Crashed:
0 libSystem.B.dylib 0x900158f4 _fmt + 0x2d8
1 libSystem.B.dylib 0x9001d5f0 strftime + 0x50
2 libSystem.B.dylib 0x9002a0dc syslog + 0xfc
3 libjvm.dylib 0x970c5d8c JVM_UnloadLibrary + 0x8447c
4 libjvm.dylib 0x970c6108 JVM_UnloadLibrary + 0x847f8
5 libjvm.dylib 0x9702171c JVM_FreeMemory + 0x87c
6 libjvm.dylib 0x9700020c JNI_CreateJavaVM_Impl + 0x452c
7 libjvm.dylib 0x97000160 JNI_CreateJavaVM_Impl + 0x4480
8 libjvm.dylib 0x970f290c JVM_UnloadLibrary + 0xb0ffc
9 libSystem.B.dylib 0x90024990 _pthread_body + 0x28


Thread 10 Crashed:
0 libSystem.B.dylib 0x900158f4 _fmt + 0x2d8
1 libSystem.B.dylib 0x9001d5f0 strftime + 0x50
2 libSystem.B.dylib 0x9002a0dc syslog + 0xfc
3 libobjc.A.dylib 0x9086bcf0 _objc_syslog + 0xa4
4 libobjc.A.dylib 0x9086bdb4 _objc_error + 0x4c
5 libobjc.A.dylib 0x9086bd44 __objc_error + 0x40
6 libobjc.A.dylib 0x90861b50 _internal_class_createInstanceFromZone + 0x70
7 com.apple.Foundation 0x90a22314 NSAllocateObject + 0x60
8 com.apple.AppKit 0x92fcb3a0 +[NSColor colorWithDeviceRed:green:blue:alpha:] + 0x40
9 com.apple.AppKit 0x92fbd788 -[NSCalibratedRGBColor colorUsingColorSpaceName:device:] + 0x11c
10 com.apple.AppKit 0x92edfde8 -[NSCatalogColor colorUsingColorSpaceName:device:] + 0x188
11 libawt.jnilib 0x81077dd0 Java_apple_awt_CColorPaint_getNativeRGB + 0x70
12 <<00000000>> 0x04b281a0 0 + 0x4b281a0
13 <<00000000>> 0x04b27fa8 0 + 0x4b27fa8
14 <<00000000>> 0x04b32060 0 + 0x4b32060
15 <<00000000>> 0x04b32744 0 + 0x4b32744
16 <<00000000>> 0x04b305dc 0 + 0x4b305dc
17 <<00000000>> 0x04d4e1f0 0 + 0x4d4e1f0
18 <<00000000>> 0x04b40318 0 + 0x4b40318
19 <<00000000>> 0x0493df98 0 + 0x493df98
20 <<00000000>> 0x04931e70 0 + 0x4931e70
21 <<00000000>> 0x04925614 0 + 0x4925614
22 <<00000000>> 0x048eaf7c 0 + 0x48eaf7c
23 <<00000000>> 0x049256b4 0 + 0x49256b4
24 <<00000000>> 0x04c0f9bc 0 + 0x4c0f9bc
25 <<00000000>> 0x0499b0f4 0 + 0x499b0f4
26 <<00000000>> 0x049b4ee8 0 + 0x49b4ee8
27 <<00000000>> 0x04bfe550 0 + 0x4bfe550
28 <<00000000>> 0x048eecdc 0 + 0x48eecdc
29 <<00000000>> 0x048e89e0 0 + 0x48e89e0
30 <<00000000>> 0x048e1c64 0 + 0x48e1c64
31 <<00000000>> 0x04caef30 0 + 0x4caef30
32 <<00000000>> 0x047a4680 0 + 0x47a4680
33 <<00000000>> 0x0472ffb0 0 + 0x472ffb0
34 <<00000000>> 0x0472ffb0 0 + 0x472ffb0
35 <<00000000>> 0x0472ffb0 0 + 0x472ffb0
36 <<00000000>> 0x0472d16c 0 + 0x472d16c
37 libjvm.dylib 0x96f3afe8 JVM_GetCPMethodClassNameUTF + 0xb38
38 libjvm.dylib 0x96f5c438 JVM_GetCPClassNameUTF + 0x998
39 libjvm.dylib 0x96f99098 JVM_Close + 0x4b8
40 libjvm.dylib 0x96fa9960 JVM_Interrupt + 0x2e0
41 libjvm.dylib 0x9704e6fc JVM_UnloadLibrary + 0xcdec
42 libjvm.dylib 0x96f94df4 JVM_FindClassFromClass + 0xc14
43 libjvm.dylib 0x970f290c JVM_UnloadLibrary + 0xb0ffc
44 libSystem.B.dylib 0x90024990 _pthread_body + 0x28

This means that java suffered a SYSTEM failure (KERN), and so when LimeWire went to do something, the system couldn't respond, and so the LimeWire thread crashed.

I haven't used 10.3.9 for a while, but if I recall correctly, reinstalling java would sometimes help, especially in a new user account.

We waited a long while for Apple to release a java that wouldn't crash, and so far I haven't seen any KERN failures with OS 10.4.6 and java 1.5. THe VMem problems are still present, though.

I know the LimeWire developers have let Apple know about such problems, but there is not much else they can do.

Wish I knew of a better solution than upgrading the system or reinstalling a new one

wish I could--so far I think the analogy is:

thread is to program,
what process is to system.

I'd be happy to hear a better explanation

Sam knew of a way (NIO) to have a single thread handle many jobs at once, and so rather than creating a new thread for every job, like connecting to a host, one "connecting" thread can handle multiple connections. This means more CPU use within a single thread. IIRC, he has found a way to create single threads for uploads, connections, downloads (and more).

I recall other developers before Sam trying to work on NIO, but that seriously involved major rewrites of much of the code, as you can imagine.

MAJOR credit to Sam for seeing this through, and so successfully
I was honestly expecting many bugs, and am surprised there are so few.

stief asked me to elaborate on NIO, so here's an elaboration that I tend to use when explaining what I do all day to friends and family (while I'm working on NIO things)...

Java's primary means of sending and receiving data from the network is using "streams". Streams are very basic ways of saying, "I want to write X" and "I want to read Y". A write to a stream doesn't finish until all of it is written, and there's no guarantee a read will finish at any time. So, you need to create a "Thread" to do these reads and writes. This is kind of like holding a conversation -- you need to devote a specific resource to maintaining the conversation with a person. Otherwise, if you tried to converse with many people at once, someone may experience a long delay between topics, as you were engrossed with someone else.

Newer versions of java introduced NIO -- new I/O. This allowed developers to write non-blocking I/O, meaning that you can just attempt to write or read, and it will only write or read as much as can be done right then. It also lets you know when something has room for more writing or has data that can be read. This lets you change the way you do network input & output so that you don't need to devote a specific resource to each conversation. Instead, you have a single thing that keeps track of all conversations you're currently in. When a conversation has something you can read, it informs anyone interested and they read as much as they can. The same thing with writing, connecting, and 'accepting' (being told someone wants to start talking with you).

The major difference is that before NIO, LimeWire required 2 threads for each Gnutella connection (one thread for reading, one thread for writing), so each Ultrapeer had at the very least 120 threads. It also required one thread for each download source, another thread for processing each new incoming connection, and another thread for making a new outgoing connection. With NIO, this is all reduced to a single thread.

Threads are a big deal because they waste resources on your computer. They're also a big deal because switching between them (what's known as a context-switch) is time-consuming.