Buy VPN - Never trust a VPN Provider that doesn't take Bitcoin
Welcome everybody to the new FrostWire forums.

Make sure to check out our Community Guidelines
http://www.frostwire.com/guidelines

Please be a good neighbor, treat others with respect and patience.
Make friends!

-FrostWire Team

FrostWire 5.1.4 Errors and Lag on Macintosh

For some reason, I get the following error every time I launch FrostWire:
FrostWire version 5.1.4
Java version 1.6.0_26 from Apple Inc.
Mac OS X v. 10.6.8 on x86_64
Free/total memory: 49253664/254476288

java.lang.IndexOutOfBoundsException: Index: 289, Size: 1
	at java.util.ArrayList.RangeCheck(ArrayList.java:547)
	at java.util.ArrayList.get(ArrayList.java:322)
	at com.limegroup.gnutella.gui.tables.BasicDataLineModel.get(Unknown Source)
	at com.frostwire.gui.bittorrent.BTDownloadModel.refresh(Unknown Source)
	at com.frostwire.gui.bittorrent.BTDownloadMediator.doRefresh(Unknown Source)
	at com.limegroup.gnutella.gui.tables.AbstractTableMediator.refresh(Unknown Source)
	at com.limegroup.gnutella.gui.GUIMediator.refreshGUI(Unknown Source)
	at com.limegroup.gnutella.gui.RefreshTimer.refreshGUI(Unknown Source)
	at com.limegroup.gnutella.gui.RefreshTimer.access$000(Unknown Source)
	at com.limegroup.gnutella.gui.RefreshTimer$1.actionPerformed(Unknown Source)
	at javax.swing.Timer.fireActionPerformed(Timer.java:291)
	at javax.swing.Timer$DoPostEvent.run(Timer.java:221)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:677)
	at java.awt.EventQueue.access$000(EventQueue.java:85)
	at java.awt.EventQueue$1.run(EventQueue.java:638)
	at java.awt.EventQueue$1.run(EventQueue.java:636)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:647)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)


Detail: null
CLASSPATH:
  /Applications/FrostWire.app/Contents/Resources/Java/lw-azureus.jar
  /Applications/FrostWire.app/Contents/Resources/Java/lw-collection.jar
  /Applications/FrostWire.app/Contents/Resources/Java/lw-common.jar
  /Applications/FrostWire.app/Contents/Resources/Java/lw-io.jar
  /Applications/FrostWire.app/Contents/Resources/Java/lw-resources.jar
  /Applications/FrostWire.app/Contents/Resources/Java/lw-setting.jar
  /Applications/FrostWire.app/Contents/Resources/Java/FrostWire.jar
  /Applications/FrostWire.app/Contents/Resources/Java/commons-logging.jar
  /Applications/FrostWire.app/Contents/Resources/Java/gettext-commons.jar
  /Applications/FrostWire.app/Contents/Resources/Java/gson-1.4.jar
  /Applications/FrostWire.app/Contents/Resources/Java/httpclient-4.0.jar
  /Applications/FrostWire.app/Contents/Resources/Java/httpcore-4.0.1.jar
  /Applications/FrostWire.app/Contents/Resources/Java/jdic.jar
  /Applications/FrostWire.app/Contents/Resources/Java/messages.jar
  /Applications/FrostWire.app/Contents/Resources/Java/MRJAdapter.jar
  /Applications/FrostWire.app/Contents/Resources/Java/splash.jar
  /Applications/FrostWire.app/Contents/Resources/Java/substance.jar
  /Applications/FrostWire.app/Contents/Resources/Java/trident.jar
  /Applications/FrostWire.app/Contents/Resources/Java/FrostWire.jar


-- listing session information --
Current thread: AWT-EventQueue-0
Active Threads: 161
Peak Number of Thread: 170
System Load Avg: 1.9921875
Objects Pending GC: 0
Free Space In Settings: 323353239552
Free Space In Incomplete: 
Heap Memory Usage: init = 67108864(65536K) used = 205222624(200412K) committed = 254476288(248512K) max = 265093120(258880K)
Non-Heap Memory Usage: init = 24317952(23748K) used = 57185760(55845K) committed = 91303936(89164K) max = 136314880(133120K)

-- listing threads --
Tracker Timer[105]: 1
Tracker Timer[83]: 1
AEThead2:parked[4]: 1
DiskManager:start[65]: 1
DiskManager:start[107]: 1
MulticastClerk: 1
Tracker Timer[221]: 1
DiskManager:start[45]: 1
DiskManager:start[51]: 1
DiskManager:start[159]: 1
Universal Plug and Play (UPnP)::SSDP:queryLoop: 1
Tracker Timer[143]: 1
WriteController:WriteProcessor: 1
AEThead2:parked[5]: 1
Tracker Timer[51]: 1
Tracker Timer[163]: 1
Tracker Timer[117]: 1
Tracker Timer[39]: 1
Tracker Timer[21]: 1
Tracker Timer[209]: 1
ReadController:ReadProcessor: 1
DiskManager:start[119]: 1
DiskManager:start[97]: 1
DiskManager:start[77]: 1
DiskManager:start[165]: 1
Tracker Timer[229]: 1
DiskManager:start[131]: 1
MCGroup:MCListener: 6
DiskManager:start[111]: 1
AWT-EventQueue-0: 1
TRHost::stats.loop: 1
DiskManager:start[139]: 1
DiskManager:start[25]: 1
DiskManager:start[125]: 1
DiskManager:start[87]: 1
DiskManager:start[151]: 1
AEThead2:parked[11]: 1
AEThead2:parked[2]: 1
DiskManager:start[3]: 1
Tracker Timer[233]: 1
DiskManager:start[63]: 1
DiskManager:start[33]: 1
Tracker Timer[197]: 1
DiskManager:start[43]: 1
AEThreadMonitor: 1
Timer:Tracker Timer: 1
DiskManager:start[109]: 1
Tracker Timer[193]: 1
Tracker Timer[213]: 1
Tracker Timer[131]: 1
PluginVerifier: 1
DiskManager:start[101]: 1
Tracker Timer[141]: 1
Tracker Timer[111]: 1
Tracker Timer[161]: 1
AEThead2:parked[3]: 1
Timer-0: 1
NetworkGlueUDP: 1
AEThead2:parked[10]: 1
Tracker Timer[129]: 1
DiskManager:start[133]: 1
DiskManager:start[95]: 1
Tracker Timer[13]: 1
Tracker Timer[27]: 1
Trident pulse source thread: 1
GM:ListenDispatcher: 1
DiskM:ListenAggregatorDispatcher: 1
Poller SunPKCS11-Darwin: 1
DiskManager:start[75]: 1
DiskManager:start[113]: 1
DiskManager:start[23]: 1
DiskManager:start[81]: 1
DiskManager:start[163]: 1
DiskManager:start[153]: 1
DiskManager:start[143]: 1
DiskManager:start[89]: 1
DiskManager:start[123]: 1
Tracker Timer[189]: 1
DM:ListenAggregatorDispatcher: 1
DiskManager:start[141]: 1
AWT-AppKit: 1
Tracker Timer[225]: 1
DiskManager:start[103]: 1
DiskManager:start[61]: 1
AEThead2:parked[8]: 1
Tracker Timer[87]: 1
DiskManager:start[41]: 1
AEThead2:parked[7]: 1
MagnetURIHandler: 1
DiskManager:start[69]: 1
DiskManager:start[169]: 1
Thread-9: 1
ReadController:ReadSelector: 1
ConnectDisconnectManager: 1
PeerControlScheduler: 1
DiskManager:start[155]: 1
Tracker Timer[153]: 1
DiskManager:start[129]: 1
DiskManager:start[135]: 1
FMFileManager::closeQueueDispatcher: 1
Deadlock Detection Thread: 1
Tracker Timer[7]: 1
User event dispatch thread: 1
DiskManager:start[115]: 1
AEThead2:parked[1]: 1
DiskManager:start[149]: 1
ManualGC: 1
SwingWorker-pool-1-thread-2: 1
SwingWorker-pool-1-thread-1: 1
DiskManager:start[121]: 1
Trident callback thread: 1
DiskManager:start[93]: 1
DiskManager:start[9]: 1
AEThead2:parked[6]: 1
MCGroup:CtrlListener: 6
DiskManager:start[161]: 1
DiskManager:start[73]: 1
SystemTime: 1
Tracker Timer[57]: 1
DiskManager:start[71]: 1
IconLoader: 1
Tracker Timer[135]: 1
DiskManager:start[105]: 1
CleanStaleDevices: 1
DiskManager:start[47]: 1
MPlayer output parser: 2
DiskManager:start[167]: 1
DiskManager:start[57]: 1
WriteController:WriteSelector: 1
Timer:Simple Timer: 1
DiskManager:start[157]: 1
DiskManager:start[67]: 1
Tracker Timer[37]: 1
Tracker Timer[251]: 1
DiskManager:start[127]: 1
AWT-Shutdown: 1
DiskManager:start[137]: 1
Global Status Checker: 1
DiskManager:start[99]: 1
AEThead2:parked[9]: 1
BroadcastClerk: 1
DiskManager:start[91]: 1
AsyncDispatcher: 2
DiskManager:start[117]: 1
DiskManager:start[79]: 1
DiskManager:start[147]: 1
DiskManager:start[85]: 1
Tracker Timer[103]: 1
DestroyJavaVM: 1


-- listing properties --
APP_WIDTH=1029
APP_HEIGHT=662
WINDOW_Y=150
WINDOW_X=207
TOTAL_UPTIME=996418
AVERAGE_UPTIME=996418
INSTALLED=true
COUNTRY=
CHAT_IRC_NICK=Canarsie
LAST_EXPIRE_TIME=1314063074925
USE_BUG_SERVLET=true
CHAT_SERVER=chat.frostwire.com
RUN_ON_STARTUP=false
SEARCH_OPTIONS_COLLAPSED=false
RUN_ONCE=true
UI_LIBRARY_TREE_DIVIDER_LOCATION=151


**************** Comments from the user ****************
null

FILES IN CURRENT DIRECTORY NOT LISTED.
SIZE: 0

Sometimes the error window will appear multiple times before finally disappearing. Sometimes the error window flashes endlessly and I have to Force Quit out of FrostWire.

Additionally, when FrostWire does work, it will eventually get to the point when both the Downloads and the Uploads equal 0. When that happens, it is almost as if FrostWire freezes: I can search, but I cannot download and I cannot quit the application. I am forced to use Force Quit.

Lately, more often that not, every function with FrostWire has become unbearably slow, whether it is opening the window of a torrent to see the individual files located in it, or even to use a scroll bar or simply type in information - to the point where FrostWire is practically unusable.

I apologize in advance if any of these questions have been addressed. I searched and did not find the answers I was seeking.

Thank you for your assistance in advance.

Comments

  • Hi, I do experience some of what you describe. When you say you need to force quit Frostwire, does it totally sieze or are you still able to search and navigate the tabs or is it actually in the state "Application Not Responding" ?

    Please can you post the following info from clicking  > about this Mac > more info:

    Model Name:
    Model Identifier:
    Processor Name:
    Processor Speed:
    Number Of Processors:
    Total Number Of Cores:
    L2 Cache:
    Memory:
  • Absolutely!

    Here it is:

    Model Name: Mac Pro
    Model Identifier: MacPro4,1
    Processor Name: Quad-Core Intel Xeon
    Processor Speed: 2.26 GHz
    Number Of Processors: 2
    Total Number Of Cores: 8
    L2 Cache (per core): 256 KB
    L3 Cache (per processor): 8 MB
    Memory: 6 GB


    As for needing to Force Quit FrostWire, it will allow me to search and navigate the tabs and even use the scroll bars, but sometimes it is so excruciatingly slow that it may as well have totally seized altogether. By the way, this happened with previous versions such as 5.1.3 where I had to Force Quit as well, but the errors in 5.1.4 compounded the problems to the point where FrostWire is sometimes usable but more often unusable.

    What can be annoying is that when I re-launch FrostWire after forcibly quitting it, it usually — but not always — will randomly choose some songs already previously downloaded and download them again. I cannot stop this from happening; the best that I can do is wait until it is finished and then delete the duplicate songs from my iTunes.

    Having experience in quality assurance and ßeta testing, I tried to see if I could both replicate any of the issues definitively, as well as find some workarounds. I have had no luck except for this: if FrostWire gets to its “seizing” point but I am still able to search for files, I search and choose the ones I want, and then I use Force Quit. When I re-start FrostWire, it finds the songs I searched for and starts downloading them. This is not a great workaround, but it does work.

    Thank you in advance.
  • I was hoping to hear a response by now, but in the meantime, I have some further information that may be helpful.

    FrostWire 5.1.4 became so frustrating to use that I was forced to stop using it. Reverting back to FrostWire 5.1.3, which had worked fairly well before upgrading to FrostWire 5.1.4, eventually proved to be nearly as frustrating.

    I reverted back to FrostWire 5.0.8 and has been working rather well for me, other that the following issue, which I still encounter and have encountered in a number of versions of FrostWire that use torrents:
    Canarsie wrote:
    Additionally, when FrostWire does work, it will eventually get to the point when both the Downloads and the Uploads equal 0. When that happens, it is almost as if FrostWire freezes: I can search, but I cannot download and I cannot quit the application. I am forced to use Force Quit.

    This leads me to conclude that whatever is different about FrostWire 5.1.4 - and, to a certain extent, FrostWire 5.1.3 - from FrostWire 5.0.8 is causing the issues that compelled me to launch this discussion in the first place.

    An update pertaining to the issues discussed in this thread would be appreciated. Thank you in advance.
  • Thank you so much for properly reporting the issue.


    How many searches do you usually have running at the same time?

    How many downloads do you usually have at the same time?


    In the meantime, we already have a clue as to where start looking into this issue thanks to your logs.
  • by the way, just to make sure. Did you have FrostWire running non-stop for like 10 days?
    If that's the case you found a memory leak.
  • So I woke up and put 2 and 2 together with a fresher mind.

    Your crashlog, says you were running FrostWire non stop for over 10 days, also the log says:
    java.lang.IndexOutOfBoundsException: Index: 289, Size: 1
    

    Which I think is a bug that occurs when you are seeding but you chose to hide seeding transfers. (289 are hidden, but 1 transfer is visible)

    Are you hiding seeding transfers on your transfer manager?

    If that's the case, I believe you may have getting the slowness because you are seeding 289 torrents, therefore hitting every possible physical limit on your connection, thus the big slow down.

    If next time you run FrostWire, the user interface is (somehow) still useable, can you "Show seeds" on the transfer manager?
    If you see a shitload of them, remove them, and the slowness should go away.

    If my Sherlock Holmes theories are right please let me know, for we need to implement some UI elements that warn the user how many transfers are being seeded and we need to either add some warning, or we need to make FrostWire seed a limited number of transfers.
  • gubatron wrote:
    Your crashlog, says you were running FrostWire non stop for over 10 days
    The crashlog is incorrect, as I usually completely shut down my computer every night. I very rarely leave my computer on overnight.
    gubatron wrote:
    also the log says:
    java.lang.IndexOutOfBoundsException: Index: 289, Size: 1
    
    Which I think is a bug that occurs when you are seeding but you chose to hide seeding transfers. (289 are hidden, but 1 transfer is visible)

    Are you hiding seeding transfers on your transfer manager?
    I am not attempting to hide seeding transfers only because I do not want to be considered a "leech." If you mean the Seeds column under the Transfers area, I can clearly see which torrents that have already been downloaded are being seeded. I am not sure of where to control whether to hide or show seeding transfers, but I would think that I am not hiding them - although I could always be wrong. Could you please point me in the right direction?

    Also, can I implement the possible solutions in FrostWire 5.0.8? FrostWire 5.1.4 is unbearable for me to use anymore.

    Thank you in advance.
  • Thanks for all the clarifications.

    If you see the finished transfers as "Seeding" then, they are not being hidden.

    Hiding your seeds doesn't mean you will be a leech, it's just a visual relief in case you're seeding a lot of torrents and you only want to see the active transfers.
    You can do this with the right click menu on the transfer manager, can't remember if we put it under Advanced, or if it's at the first level towards the bottom of the context popup menu.

    If you want to be a leech, then you gotta go inside Tools > Options > BitTorrent ... somewhere in there you can configure your seeding behavior.

    Dear Watson, all my theories were wrong, back to the bug hunt.

    Thanks a lot!
  • gubatron wrote:
    Dear Watson, all my theories were wrong, back to the bug hunt.

    Thanks a lot!
    Believe me when I say I am not attempting to shoot down your theories.

    However, I still maintain that the following quote - especially the part highlighted in red - is the best clue to finding the answers we are both seeking to the issues I have described:
    Canarsie wrote:
    FrostWire 5.1.4 became so frustrating to use that I was forced to stop using it. Reverting back to FrostWire 5.1.3, which had worked fairly well before upgrading to FrostWire 5.1.4, eventually proved to be nearly as frustrating.

    I reverted back to FrostWire 5.0.8 and has been working rather well for me, other that the following issue, which I still encounter and have encountered in a number of versions of FrostWire that use torrents:
    Canarsie wrote:
    Additionally, when FrostWire does work, it will eventually get to the point when both the Downloads and the Uploads equal 0. When that happens, it is almost as if FrostWire freezes: I can search, but I cannot download and I cannot quit the application. I am forced to use Force Quit.

    This leads me to conclude that whatever is different about FrostWire 5.1.4 - and, to a certain extent, FrostWire 5.1.3 - from FrostWire 5.0.8 is causing the issues that compelled me to launch this discussion in the first place.
    Please let me know what I can do to be of any assistance to you.

    Thank you!
  • Can you plase go to your FrostWire preferences folder and tell me how big in megabytes is your search_db folder?

    Also, if the UI allows you, can you go to:

    Tools > Options > Searching

    And tell me the number of Torrents and the number Files indexed?

    I just want to see if this is related to the search database.

    In my computer I've managed to index over 250,000 files without any issues, maybe you are way past this number and we need to test with similar numbers to yours to replicate this behavior.
  • gubatron wrote:
    Can you plase go to your FrostWire preferences folder and tell me how big in megabytes is your search_db folder?
    I cannot find what it is you are specifically requesting.

    Could you please be more specific? Do you mean Preferences under the FrostWire menu - which is the same as selecting Options under the Tools menu - or is there an actual FrostWire Preferences folder where I can find out this information, which I could not find after searching for it?

    I do have the BitTorrent upload and download speeds set to Unlimited. Both sliders in the Filter Results area are set to Max.

    Thank you.
    gubatron wrote:
    Also, if the UI allows you, can you go to:

    Tools > Options > Searching

    And tell me the number of Torrents and the number Files indexed?
    The slowness was painful, but here it is:

    Total torrents indexed: 761
    Total files indexed: 348466

    That number sounds awfully high.

    Should I click on the Reset Smart Search Database button?
  • Don't do that yet!

    For now, let's just rename the folder where the smart search database goes into.

    Go to your preferences folder and rename the folder "search_db" into "search_db.bak"

    Then restart FrostWire and let us know if you feel any difference. This would be the equivalent of resetting the DB, only that if this doesn't fix the problem, you can shutdown frostwire, and recover your search_db.

    If the problem goes away, then you've helped us find the limits and we can fix this for the upcoming release in no time.
  • gubatron wrote:
    Don't do that yet!

    For now, let's just rename the folder where the smart search database goes into.

    Go to your preferences folder and rename the folder "search_db" into "search_db.bak"

    Then restart FrostWire and let us know if you feel any difference. This would be the equivalent of resetting the DB, only that if this doesn't fix the problem, you can shutdown frostwire, and recover your search_db.

    If the problem goes away, then you've helped us find the limits and we can fix this for the upcoming release in no time.
    There is only one problem...
    Canarsie wrote:
    is there an actual FrostWire Preferences folder where I can find out this information, which I could not find after searching for it?
    ...I searched my entire hard disk drive and cannot find the folder to which you are referencing.

    I searched "FrostWire", "search", "search_db" and "preference" and found nothing anywhere on my hard disk drive on my Apple Macintosh computer that remotely resembles what you describe.

    Perhaps this is the problem?

    Please advise so that I can assist...
  • Users > Your Name > Library > Preferences > FrostWire5 The search_db foder should be in that FrostWire folder.
  • Sorry, for a second I thought (without looking at the title of the conversation) that you were on Windows.

    Just copy & paste on a terminal the following and start FrostWire
    mv ~/Library/Preferences/FrostWire5/search_db ~/Library/Preferences/FrostWire5/search_db.bak
    
  • Users > Your Name > Library > Preferences > FrostWire5 The search_db foder should be in that FrostWire folder.
    I wonder why the Search function on my computer did not find that. Strange. However, I opened the FrostWire5 preferences folder, and even though I could have performed the change manually, I opened Terminal and did the following...
    gubatron wrote:
    Just copy & paste on a terminal the following and start FrostWire
    mv ~/Library/Preferences/FrostWire5/search_db ~/Library/Preferences/FrostWire5/search_db.bak
    
    ...and I monitored the folder. The name of the search_db folder was indeed automatically changed to search_db.bak.

    Although it was slow in opening - perhaps re-adjusting itself to the new folder name rather than a technical issue - I can confirm that, for the first time for me, FrostWire 5.1.4 opened with no errors at all. As I type this, it is even automatically downloading a file from a torrent I had previously chosen. The search is working well also.

    I hope this good news helps. Thank you both. So where do we go from here?
  • Well.

    According to this, the size of the DB does matter. Before the release we had tested with a database of 250k indexed files and we hadn't seen any issues.

    We'll now test with a much larger database, ideally we'll encounter similar problems to yours, we'll fix them, and we'll include the fixes on the next release sometime this week or the next.

    Another test that we can do now, would be to delete the new search_db folder, put the old search_db.bak folder as "search_db", and when you start FrostWire you should in theory experience the same issues.

    If you do this and you have problems again, then we know whatever is going on is related to the database in one way or the other.
  • gubatron wrote:
    Well.

    According to this, the size of the DB does matter. Before the release we had tested with a database of 250k indexed files and we hadn't seen any issues.

    We'll now test with a much larger database, ideally we'll encounter similar problems to yours, we'll fix them, and we'll include the fixes on the next release sometime this week or the next.

    Another test that we can do now, would be to delete the new search_db folder, put the old search_db.bak folder as "search_db", and when you start FrostWire you should in theory experience the same issues.

    If you do this and you have problems again, then we know whatever is going on is related to the database in one way or the other.
    I launched FrostWire 5.1.4 more than once since following your directions, and I can safely say that this issue can be reliably replicated.

    I look forward to the next release of FrostWire.

    Please let me know what else I can do to assist.

    Thank you.
  • Canarsie wrote:
    I wonder why the Search function on my computer did not find that. Strange. However, I opened the FrostWire5 preferences folder,

    Just to comment on that, I have found more than once, that neither the finder search nor Spotlight, manage to find things that they should, which can be a pain .. :)

Leave a Comment