Message boards : BOINC Manager : 6.10.43 bug? entire message buffer being duplicated
Message board moderation
Author | Message |
---|---|
Send message Joined: 27 Jun 08 Posts: 641 |
Not sure what is going on here. It seemed to start when I put in 6.10.43 on my Ubuntu 9.1 systems. I should see my nvidia gpu's listed just once, at the top of the dialog box for messages. Instead, they are listed multiple times. It would appear that every time a block of messages are written to the boinc message buffer, the entire message buffer is replicated. The longer I leave boincmgr running, the worse it gets. I did a grep for "nvidia" it is listed 100's of times. Should have been just listed twice - once for each gpu at startup of boincmgr. I went and deleted the stdout files that have the messages, stopped boincmgr, restarted. Seemed to be ok: about 150 messages all dated to the same 1-2 seconds (the startup message). Then slowly but surelly the entire message buffer started being duplciated. Intead of a message that a task completed, I got the entire message buffer duplicated. I copied and pasted the crap here I only spotted this problem when I attempted to debug why collatz tasks were being (supposidly) rejected because the app was wrong. AFAICT all my collatz wu's are being processed and reported to the project correctly even though the boincmgr indicated 100's of collatz tasks are wrong. That is also shown in the above mentioned crap. This problem occured on two ubuntu systems, both 9.1 and 6.10.43 |
Send message Joined: 29 Aug 05 Posts: 15563 |
Forwarded to development. |
Send message Joined: 27 Jun 08 Posts: 641 |
sorry - duplicate post |
Send message Joined: 27 Jun 08 Posts: 641 |
Just went back to 6.10.17 and got the same problem. I checked the resource manager and I am only running boinc and boincmgr once. This problem is on 9.1 ubuntu and I am running 2.6.31.20. Just put in a kernel update a few minutes ago thinking that might fix it, but the update did not require an nvidia kernel build (unlike the previous 9.1 updates) and the problem continues. I do not see this problem on my 8.04 ubuntu system. Using 6.10.43 on vista 64 I did a "select computer" to the 8.04 ubuntu and examined its message logs. I see a contiguous string of dates with no jumbled dates out of order or any duplicates ie: 3/19/2010 11:58:21 PM Starting BOINC client version 6.10.32 for x86_64-pc-linux-gnu 3/19/2010 11:58:21 PM log flags: file_xfer, sched_ops, task
3/21/2010 11:53:47 AM FreeHAL@home Reporting 1 completed tasks, not requesting new tasks 3/21/2010 11:53:52 AM FreeHAL@home Scheduler request completed
|
Send message Joined: 5 Oct 06 Posts: 5129 |
Just to be on the safe side, I checked my v6.10.43 Windows installation: the message log starts with 19-Mar-2010 19:11:10 [---] Starting BOINC client version 6.10.43 for windows_intelx86 and continues properly in date order without duplicates from then on. BB, be aware that the log files (such as stdoutdae.txt on disk) are created by the core client, not the Manager. So when you use a v6.10.43 Manager to connect across the network to a v6.10.32 client, you're not really testing v.43 at all - you're just testing that v.32 is still not creating duplicate messages (which I think we knew, but it's nice to be reassured :-) ). |
Send message Joined: 29 Aug 05 Posts: 15563 |
BB, can you please be a little clearer on what you see? Can you please just use just one computer with Ubuntu 9.1 and BOINC 6.10.43? As Richard already explained, BOINC Manager (the GUI) only shows the messages of the client (daemon), it does not generate them. The daemon generates them. As Richard also explained, when you use the BOINC Manager->Select computer option on another computer, you will see the messages from the computer you're pointing to. It doesn't matter at that time which version of BOINC Manager you use. Do you see the same in a command line window, when you start the client only and let it run for a while? |
Send message Joined: 27 Jun 08 Posts: 641 |
Found Bug (or at least I know how to duplicate the problem) I ran these test from a Windows Vista 64 system using boinc 6.10.43. The two target systems were 8.04 and 9.1 ubuntu. The 8.04 worked correcty. I have a total of 4 ubuntu systems, two of them are 9.1 the others are 8.04. The older OS work fine. Both of the 9.1 have the problem. I ran netmon to monitor traffic between two of my systems which helped spot the problem. I then ran boinccmd to duplicate the problem. For example: boinccmd --host 192.168.0.9 --get_message this retrieves all the message from an 8.04 ubuntu system I have that is running 6.10.32 As shown below, the sequence number of the last message 114. If you then make the same request but specify sequence number 114 (an offset) you should then get NO messages (unless there are new messages). This works correctly. Note that there is no text between the command that was typed and the empty prompt underneath it. OK the above worked correctly, there are no additional messages beyond <seqno>114</seqno> Now look what happens when I make the same request to a system running ubuntu 9.1 and boinc 6.10.17. Here is the first response to boinccmd --host 192.168.0.11 --get_message note that the message number ends in 71 Look at the last command I typed (above). When one presses Enter there should be no response (unless there are additional message after seqno 71) BINGO! The entire message buffer was re-displayed! That should not have happened! [EDIT] There is something else going on here. I am not getting consistent failures. For example, I can run the command 3 or 4 times in a row and it works perfectly: no results after the last seqno. Then all of a sudden I get the entire message buffer, then I am back to where it works ok and no messages are displayed if there are no new messages. |
Send message Joined: 27 Jun 08 Posts: 641 |
This was solved (sort of) by installing Dotsch as explained here Dotsch 1.2 is actually 8.1 so essentially I reverted 9.1 back to 8.1 and the problems I had been seeing disappeared. |
Send message Joined: 27 Jun 08 Posts: 641 |
I had to update this old thread because I finally figured out what was causing the error. I had inadvertantly installed the 32bit version of linux boinc on several 64 bit ubuntu systems. It actually ran some of the cpu tasks correctly, but on systems haveing a gpu that was where I had that strange message buffer problem. When I reverted back to 8.1 (Dotsch unix) that was a clean install so it got rid of the 32 bit boinc and that was why why it started working. The problem was not the 9.1 like I thought originally. I found out because just an hour ago I did the same wrong install and get the exact same buffer response problem. This time I noticed the download was missing the "64" amd realized my error. |
Send message Joined: 18 Jul 10 Posts: 3 |
I just found out I had the same problem: 32 vs. 64 bit. Thanks! Also, I run Kubuntu and found the repository version is constantly behind. To update, I download BOINC, run the .sh file, and then run this little script: cp BOINC/boinc /usr/bin/boinc cp BOINC/boinccmd /usr/bin/boinccmd cp BOINC/boincmgr /usr/bin/boincmgr cp BOINC/boincmgr.16x16.png /usr/share/pixmaps/boincmgr.16x16.png cp BOINC/boincmgr.32x32.png /usr/share/pixmaps/boincmgr.32x32.png cp BOINC/boincmgr.48x48.png /usr/share/pixmaps/boincmgr.48x48.png cp BOINC/ca-bundle.crt /var/lib/boinc-client/ca-bundle.crt cp BOINC/libcudart.so /var/lib/boinc-client/libcudart.so To run it (sudo), the client service must be stopped and the manager must be closed. Maybe, this should be posted somewhere else? Maybe, this could be included in the release? Edit: Don't know what to do about the language files. Also, other files exist in the /etc/boinc-client dir. |
Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.