In the menu! You don't need to open the options panel to generate a pseudo bug-report for display: Help->Generate error

http://www.rodage.net/private/report1.png

This will open a "Internal error" alert that you can consult with the second button.

http://www.rodage.net/private/report2.png

The whole report is in the white scrollable area, which is selectable (you can copy from it).

http://www.rodage.net/private/report3.png

Then click OK to close it, and finally "Reject" in the first screen to ignore the report (don't need to send it to LimeWire, as it's a faked error, but not a bug in the software).

The "Generate Error" menu option is only available in CVS versions of LimeWire. We don't want generated exceptions bogging down our bugserver.

You can view a similiar report in production versions by going to Tools -> Options, Bug Reports, and choosing 'View Example'.

I should have noticed it... Thanks for noting it is is absent from beta versions (I thought it was only missing in releases).
Well we could as well disable the "Send report" button. Of course the "View example" button in options pane will work as well.

Transparency may not work on MacOS Classic, it is tricky to program due to display refreshes. If your display board does not support accelerated alpha transparency, this may take lots of CPU time.
Well I think that the simplest would be that a click on a tooltip forces it to close, so you can click behind it.

The upstream bandwidth currently only counts the actual TCP payload (ignoring automatic retransmissions in case of TCP errors detected), but not the TCP header or IP headers which are unpredictable due to buffering within the OS, and not even the PPP/LCP overhead on the internet link or the ATM encapsulation.

To get more accurate data, you need to estimate the overhead, or look into OS statistics (you won't get data below the IP level (i.e. PPP/LCP or ATM framing will not be visible on DSL/cable connections; on 56K modems, you can get the final bandwidth sent to the modem in the OS statistics, but even in that case your modem will apply its own protocol (data compression, error control, and framing bits).

The true bandwidth used is hard to determine (you can just take an estimate of about 5% of overhead for the underlying transport or link protocols).

Also the "spiky" bandwidth is typical in case of slow or far downloaders, that can't reply in sustained time. This spiky curve is smoothed when there are parallel transfers to distinct hosts.

Ok, I have restarted 3.6.12, it is now hogging CPU at >95%. Now I open the "sample error" message window. but unlike LW's error messages there is no cptoin for copying the text , unless there is some undocumented keyboard combination (Ctrl-Ins doesn't seem to work). I hope you aren't expecting me to type the text line-by-line into my browser :(

OK, Use Ctrl+C to copy the selected text...

This gives me a suggestion for the GUI: add tabbed panes in the About box, with one listing this configuration (without the unneeded error trace). And add a Copy button in the bug report view.

Another suggestion: couldn't we display the startup tips in the empty search result window, beside the promotional HTML panel?
This would allowing closing permanently this tip window that I find irritating, but it would be visible enough to inform users.

Ok, to start with, I deleted all the files in .limeware except createtimes.cache and
fileurns.cache (it takes ages to regenerate these). This cleared up the above-mentioned startup problems (<strike>except for some reason that LW is reconnecting as leaf rather than UP, even though the latter is enabled</strike>it is now running as UP). Now, I startup, and within 60 secs, LW starts grabbing >99% CPU.

I have a 2048/1024 ASDL connection and am sharing ~4,5k files

<pre>
LimeWire version 3.9.12 Pro
Java version 1.4.2_01 from Sun Microsystems Inc.
OS/2 v. 20.45 on x86
Free/total memory: 12014248/66650112

java.lang.Exception: Example Bug
at com.limegroup.gnutella.gui.options.panes.BugsPaneI tem$1.actionPerformed(BugsPaneItem.java:91)
at javax.swing.AbstractButton.fireActionPerformed(Unk nown Source)
at javax.swing.AbstractButton$ForwardActionEvents.act ionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed (Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseRe leased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent( Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(U nknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unkno wn Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierar chy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarch y(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarch y(Unknown Source)
at java.awt.Dialog$1.run(Unknown Source)
at java.awt.Dialog.show(Unknown Source)
at com.limegroup.gnutella.gui.options.OptionsConstruc tor.setOptionsVisible(OptionsConstructor.java:372)
at com.limegroup.gnutella.gui.options.OptionsMediator .setOptionsVisible(OptionsMediator.java:84)
at com.limegroup.gnutella.gui.GUIMediator.setOptionsV isible(GUIMediator.java:536)
at com.limegroup.gnutella.gui.menu.ToolsMenu$1.action Performed(ToolsMenu.java:26)
at javax.swing.AbstractButton.fireActionPerformed(Unk nown Source)
at javax.swing.AbstractButton$ForwardActionEvents.act ionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed (Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unk nown Source)
at javax.swing.plaf.basic.BasicMenuItemUI$MenuDragMou seHandler.menuDragMouseReleased(Unknown Source)
at javax.swing.JMenuItem.fireMenuDragMouseReleased(Un known Source)
at javax.swing.JMenuItem.processMenuDragMouseEvent(Un known Source)
at javax.swing.JMenuItem.processMouseEvent(Unknown Source)
at javax.swing.MenuSelectionManager.processMouseEvent (Unknown Source)
at javax.swing.plaf.basic.BasicMenuUI$MouseInputHandl er.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent( Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(U nknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unkno wn Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierar chy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarch y(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)


Detail: Example

-- listing session information --
Current thread: AWT-EventQueue-0
Active Threads: 50
Uptime: 46:18
Is Connected: true
Number of Ultrapeer -> Ultrapeer Connections: 0
Number of Ultrapeer -> Leaf Connections: 0
Number of Leaf -> Ultrapeer Connections: 7
Number of Old Connections: 0
Acting as Ultrapeer: false
Acting as Shielded Leaf: true
Number of Active Uploads: 9
Number of Queued Uploads: 0
Number of Active Managed Downloads: 1
Number of Active HTTP Downloaders: 1
Number of Waiting Downloads: 1
Received incoming this session: true
Number of Shared Files: 4885
Guess Capable: true

-- listing threads --
Acceptor: 1
AWT-Shutdown: 1
AWT-EventQueue-0: 1
TreeHashTread: 1
pinger thread: 1
QRPPropagator: 1
MessageLoopingThread: 8
QueryDispatcher: 1
MulticastService: 1
HttpClient-ReferenceQueueThread: 1
TimerQueue: 1
FileManager.loadSettingsBlocking: 1
UDPService-Receiver: 1
TimerRunner: 1
DownloadWorker: 1
OutputRunner: 7
ConnectionDispatchRunner: 9
QueryUnicaster: 1
ConnectionWatchdog: 1
DestroyJavaVM: 1
Java2D Disposer: 1
PlayThread: 1
Thread-131: 1
AWT-Windows: 1
HttpClient-IdleConnectionThread: 1
Thread-397: 1
HTTPAcceptor: 1
ManagedDownload: 2


-- listing properties --
LAST_EXPIRE_TIME=1084664429120
UPLOADS_PER_PERSON=1
CLIENT_ID=488128BDC479AD40FF38C518E2C46100
FREELOADER_FILES=100
EVER_ACCEPTED_INCOMING=true
EVER_SUPERNODE_CAPABLE=true
FREELOADER_ALLOWED=10
MAX_UPLOAD_BYTES_PER_SEC=117
TOTAL_UPTIME=3922
PORT=6348
CONNECTION_VIEW_ENABLED=true
CLEAR_UPLOAD=false
AVERAGE_UPTIME=3922
EXTENSIONS_TO_SEARCH_FOR=mp3;ogg;jpg
INSTALLED=true
MAX_SIM_DOWNLOAD=12
LAST_GWEBCACHE_FETCH_TIME=1084664458460
CONNECTION_SPEED=1000
MAX_DOWNLOAD_BYTES_PER_SEC=4
</pre>

It seems you are alone to test LimeWire on OS/2. It seems to be an issue with the virtual memory management (with committed memory) on OS/2, and difficulties to handle multiple threads efficiently on this platform, and to support CPU throttling:

I note that you share a lot of files, but you have erased your THEX data cache. This is still a new feature in LimeWire, ant i will take time until all your files are indexed.

What seems to happen is that this occurs the first time a user starts downloading from you with THEX control. THEX tree data is not computed immediaely when you add files in the library. Instead it is computed in parallel with uploads.

I made special efforts to maximize the throughput and efficiency of the THEX hasher (which is running on is own thread on your host), so that it won't take lot of time to compute. However, throttling of this hasher by concurrent threads seems to be ineffective on OS/2. As there's nobody at LimeWire or in our open-sourcers that has worked to see what's happening on your platform, there's littel we can do to help you.

One suggestion:
Exit limewire, save your limewire.props file and the thex and urn cache files as well as the file stats cache.
Then restart with much lower number of shared files (for example reset the configuration to share the default share directory).
Restart and share only a few popular (but not too large) files, and see what is happening. You'll see a CPU spike when the first file will be uploaded, when this file gets THEX-hashed.
It should return to normal just after.
If you see that, then it just happens because your thex cache file was emptied.
You may then restore your saved settings. No immediate solution for you on OS/2 until all your popular files get THEX-hashed on demand. I recommand you check your system settings related to virtual memory management (if you don't have a permanent and unfragmented swap space, you could experiment long delays o perform efficient multithreading).


On Windows, my UltraPeer (using an Athlon XP 1800+) handles more than 450 concurrent threads with 5 to 10% of CPU usage...