FahMon is an open-source tool (GPL license) that allows you to quickly check the progress of your Folding@Home client (or clients if you have several), avoiding you having to open different files and/or to go to the Internet (for example to know how much your current work unit is worth). Other monitoring tools exist (such as Electron Microscope, FahSpy and InCrease), so if you don't like FahMon, have a look at them! FahMon is entirely coded in C++ and uses the wxWidgets library, which allows FahMon to exist both for Linux, Windows and OS X. It is designed to be really easy to use, and you should thus not encounter any major problems. FahMon homepage.
FahMon 2.3.99.1 Released FahMon 2.3.99.1 Released FahMon 2.3.99.1 is now available for download here: http://fahmon.net/download.html What's new in this release * Fixed a nasty crash-bug which affected Windows users monitoring linux clients. This also cleans up some behaviour that affects all platforms As always if you find any bugs in FahMon please report them using trac Complete changelog: Code: v2.3.99.1 (06/04/09) General Monitoring * Added more rigorous checks to file handling to ensure that invalid file access attempts don't crash FahMon (particularly on Windows). Other * Updated German translation.
uncle_fungus, Are you aware of a bug in 2.3.99.1? The app occasionally commits suicide on one of my Linux machines. I caught some blurb on the ssh console about glibc memory corruption. Something to do with a double linked list. I'll generate a bug report if I catch it again.
Yes, I have seen this before on one of my boxes. There are some unfortunate thread-safety issues still lingering in the codebase which I'm in the process of working through. When this is done, this bug should be fixed, in addition to the random string replacement bug. Edit: Thanks for the sticky btw
uncle_fungus, MT issues - what fun! I doubt this helps but anyway, from .xsession-errors .... Code: *** glibc detected *** /usr/bin/fahmon: double free or corruption (fasttop): 0x0000000001efaa10 *** ======= Backtrace: ========= /lib64/libc.so.6[0x34e0a77ec8] /lib64/libc.so.6(cfree+0x76)[0x34e0a7a486] /usr/bin/fahmon[0x42c241] /usr/bin/fahmon[0x44f572] /usr/lib64/libwx_baseu-2.8.so.0(_ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent+0x89)[0x304c2f5969] /usr/lib64/libwx_baseu-2.8.so.0(_ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler+0xa4)[0x304c2f6b44] /usr/lib64/libwx_baseu-2.8.so.0(_ZN12wxEvtHandler12ProcessEventER7wxEvent+0xc7)[0x304c2f6c37] /usr/lib64/libwx_gtk2u_core-2.8.so.0(_ZN11wxTimerBase6NotifyEv+0x66)[0x37f6ce8e86] /usr/lib64/libwx_gtk2u_core-2.8.so.0[0x37f6beee1b] /lib64/libglib-2.0.so.0[0x7f6a8218cf7b] /lib64/libglib-2.0.so.0(g_main_context_dispatch+0x23b)[0x7f6a8218c7bb] /lib64/libglib-2.0.so.0[0x7f6a8218ff8d] /lib64/libglib-2.0.so.0(g_main_loop_run+0x1cd)[0x7f6a821904bd] /usr/lib64/libgtk-x11-2.0.so.0(gtk_main+0xa7)[0x37f47238a7] /usr/lib64/libwx_gtk2u_core-2.8.so.0(_ZN11wxEventLoop3RunEv+0x48)[0x37f6be6768] /usr/lib64/libwx_gtk2u_core-2.8.so.0(_ZN9wxAppBase8MainLoopEv+0x4b)[0x37f6c6fafb] /usr/lib64/libwx_baseu-2.8.so.0(_Z7wxEntryRiPPw+0x4d)[0x304c299b8d] /usr/bin/fahmon[0x445822] /lib64/libc.so.6(__libc_start_main+0xe6)[0x34e0a1e576] /usr/bin/fahmon[0x415849]
Fun indeed Could you try running addr2line on those addresses to see if they resolve to real functions in fahmon (assuming you didn't strip the binary first)? Code: addr2line -e /usr/src/fahmon 0x42c241 addr2line -e /usr/src/fahmon 0x44f572 addr2line -e /usr/src/fahmon 0x415849
Binary is stripped, but I got the debuginfo package installed, so gdb ...... Code: (gdb) list *0x42c241 0x42c241 is in ClientsManager::ReloadThreaded(unsigned int) (clientsManager.cpp:287). (gdb) list *0x44f572 0x44f572 is in MainDialog::OnAutoReloadTimer(wxTimerEvent&) (mainDialog.cpp:1317). (gdb) list *0x415849 No source file for address 0x415849.
Excellent, that's the kind of backtrace I expected from a thread-safety related crash, so that's "good". If you fancy checking out some bleeding edge code, I'll hopefully be committing some code changes to SVN this evening, and they might help things a little.
Also, if you feel like trying to make FahMon crash, start it with the -s or --stress flag. This enables a forced refresh every 0.5 seconds (currently) which should hopefully highlight any issues much faster (and doesn't require you to blu-tak the F6 button down )
I discovered the "reload clients in series" option after spending 2 days keep modifying clients after their names and directories become "string" corrupted! Maybe that should be the default?
It may well have to be if I can't get this stupid thread safety issue fixed. At least that way there are only ever a max of 2 threads running (GUI + reload).
One other thing uncle_fungus - prior to the setting the "reload series" option, one thing I noticed when fahmon crashed due to threading issues while I have several other machines nfs mounted to get at their folding dirs. I suppose all bets are off at the point that a process crashes reading an nfs dir that is hard mounted, but for some reason the mounts were hung forever. I couldn't access them anymore and it was taking multiple "unmount -force" before a remount. I started to use the "intr" option when hard mounting the shares, which at least resulted in the shares not being hung following a crash. All of which is not strictly relevant to fahmon, but I thought I'd mention it.
I did notice the nfs issue when I had some nfs shares. The same thing can happend with cifs shares too unfortunately, but that's just due to the filesystem and I don't think its something I can do anything about in FahMon. You can usually get said broken shares to unmount with a forced lazy unmount (umount -lf).
when i leave FAHmon open for an 1-2hr on my system it makes my remote computer crash thats running GPU clients (Thread stuck in driver error)
other issue as well, can you make fahmon can you set option to only use config file not registry as i use fahmon on my pen stick when i run it off my usb pen stick it does an debug crash (it then merges the dir path from an other client in the list so 2 clients have the same dir path but 2 dif titles ) when FAHmon is open for 1hr or more it some times merges the title name into the dir path that then makes it no longer update or it puts the dir path in the title (that norm results in an crash in fahmon and saving the invalid dir name)
uncle_fungus - looks like some more-than-normal tweaking of FahMon is going to be required to try to take account of the new points system for the a3 cores??
I tried to install FahMon today and while it installed fine, when I shared the folders with the clients in it from my folding server, I added them in and they simply sat there without updating saying "Hung" with a red box on the left. No matter the fact I knew they were updating, it wouldn't update the FahMon setup with them, so I uninstalled the program