Large output files

Message boards : Number crunching : Large output files

Author	Message
Webmaster Yoda Volunteer tester Joined: Nov 14 06 Posts: 43 ID: 271 Credit: 6,498 RAC: 0	Message 1545 - Posted 21 Nov 2006 14:38:36 UTC
	Just had one of these errors come up on a WU that was close to completion (at 9.5 hours) on Windows. The computer stopped responding (froze) and on restart the WU had crashed. Pentium 4 550 with HT enabled 1GB Dual Channel RAM Windows 2003 SBS Result is at http://docking.utep.edu/result.php?resultid=49206 I don't know if Docking caused the computer to hang or whether it was another cause, but the last time I checked on that work unit (just prior to the crash) it was very cloe to 100%. Also, I saw it was trying to upload a file that was over 30MB in size. I haven't looked at it before but is that normal? Sounds a bit big when compared to most other projects - glad I'm not on dial-up... ____________ Join the #1 Aussie Alliance on Docking@Home
	ID: 1545 \| Rating: 0 \| rate: /

Conan Volunteer tester Joined: Sep 13 06 Posts: 219 ID: 100 Credit: 4,256,493 RAC: 0	Message 1547 - Posted 21 Nov 2006 14:55:43 UTC - in response to Message ID 1545 .
	Just had one of these errors come up on a WU that was close to completion (at 9.5 hours) on Windows. The computer stopped responding (froze) and on restart the WU had crashed. Pentium 4 550 with HT enabled 1GB Dual Channel RAM Windows 2003 SBS Result is at http://docking.utep.edu/result.php?resultid=49206 I don't know if Docking caused the computer to hang or whether it was another cause, but the last time I checked on that work unit (just prior to the crash) it was very cloe to 100%. Also, I saw it was trying to upload a file that was over 30MB in size. I haven't looked at it before but is that normal? Sounds a bit big when compared to most other projects - glad I'm not on dial-up... > G'Day Webmaster Yoda, I too have seen a large file get uploaded, mine was 65 MB and took quite a while to finish uploading. Was unable to see any results that matched the upload. ____________
	ID: 1547 \| Rating: 0 \| rate: /

suguruhirahara Forum moderator Volunteer tester Joined: Sep 13 06 Posts: 282 ID: 15 Credit: 56,614 RAC: 0	Message 1548 - Posted 21 Nov 2006 14:59:20 UTC - in response to Message ID 1547 .
	Also, I saw it was trying to upload a file that was over 30MB in size. I haven't looked at it before but is that normal? Sounds a bit big when compared to most other projects - glad I'm not on dial-up... > G'Day Webmaster Yoda, I too have seen a large file get uploaded, mine was 65 MB and took quite a while to finish uploading. Was unable to see any results that matched the upload. Me too. The result which failed to be completed often send a very large file... It's troublesome for dialup users. ____________ I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions.
	ID: 1548 \| Rating: 0 \| rate: /

Conan Volunteer tester Joined: Sep 13 06 Posts: 219 ID: 100 Credit: 4,256,493 RAC: 0	Message 1551 - Posted 21 Nov 2006 15:04:10 UTC - in response to Message ID 1548 .
	Also, I saw it was trying to upload a file that was over 30MB in size. I haven't looked at it before but is that normal? Sounds a bit big when compared to most other projects - glad I'm not on dial-up... > G'Day Webmaster Yoda, I too have seen a large file get uploaded, mine was 65 MB and took quite a while to finish uploading. Was unable to see any results that matched the upload. Me too. The result which failed to be completed often send a very large file... It's troublesome for dialup users. Ah that would explain it as I had a heap that I had to dump due to a Boinc issue that said my checksum was faulty or something. I lost 2 lots of downloads due to this problem in a 10 minutes after I detached, reattached the reinstalled Boinc. Boinc was sending back 20 to 30 failed WU's at once with debugging infomation I suppose. Thanks suguruhirahara. ____________
	ID: 1551 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1556 - Posted 21 Nov 2006 16:02:52 UTC - in response to Message ID 1545 .
	I checked the files we received for this workunit on the server and the largest one (the output log of the app) is 688 KByte in size. I don't know where that 30 MB file went to, but not to Docking@Home :-) Looking at the last couple of lines in the logfile it looks like we might be experiencing the same kind of memory problems we have on the linux side. Will look into that soon. Also the new version of Charmm will hopefully solve these problems; the new estimate of arrival is tomorrow... Andre Just had one of these errors come up on a WU that was close to completion (at 9.5 hours) on Windows. The computer stopped responding (froze) and on restart the WU had crashed. Pentium 4 550 with HT enabled 1GB Dual Channel RAM Windows 2003 SBS Result is at http://docking.utep.edu/result.php?resultid=49206 I don't know if Docking caused the computer to hang or whether it was another cause, but the last time I checked on that work unit (just prior to the crash) it was very cloe to 100%. Also, I saw it was trying to upload a file that was over 30MB in size. I haven't looked at it before but is that normal? Sounds a bit big when compared to most other projects - glad I'm not on dial-up... ____________ D@H the greatest project in the world... a while from now!
	ID: 1556 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1557 - Posted 21 Nov 2006 16:08:46 UTC - in response to Message ID 1547 .
	Do you still now the workunit number so that I can check? Andre > G'Day Webmaster Yoda, I too have seen a large file get uploaded, mine was 65 MB and took quite a while to finish uploading. Was unable to see any results that matched the upload. ____________ D@H the greatest project in the world... a while from now!
	ID: 1557 \| Rating: 0 \| rate: /

Webmaster Yoda Volunteer tester Joined: Nov 14 06 Posts: 43 ID: 271 Credit: 6,498 RAC: 0	Message 1558 - Posted 21 Nov 2006 16:14:26 UTC - in response to Message ID 1556 . Last modified: 21 Nov 2006 16:22:43 UTC
	I checked the files we received for this workunit on the server and the largest one (the output log of the app) is 688 KByte in size. I don't know where that 30 MB file went to, but not to Docking@Home :-) As the WU had crashed anyway, I aborted the huge upload. That's why you can't find it. EDIT: in case it's any help, here's an extract of some message in my local BOINC log files, relating to the missing file... Docking@Home 21/11/2006 22:06:51 Backing off 1 minutes and 0 seconds on upload of file 1tng_mod0001_11811_258050_0_3 Docking@Home 21/11/2006 22:06:51 Temporarily failed upload of 1tng_mod0001_11811_258050_0_3: transient upload error Docking@Home 21/11/2006 22:06:51 Error on file upload: [1tng_mod0001_11811_258050_0_3] locked by file_upload_handler PID=2110 Docking@Home 21/11/2006 22:06:48 Started upload of file 1tng_mod0001_11811_258050_0_3 Docking@Home 21/11/2006 22:05:48 Backing off 1 minutes and 0 seconds on upload of file 1tng_mod0001_11811_258050_0_3 Docking@Home 21/11/2006 22:05:48 Temporarily failed upload of 1tng_mod0001_11811_258050_0_3: transient upload error Docking@Home 21/11/2006 22:05:48 Error on file upload: [1tng_mod0001_11811_258050_0_3] locked by file_upload_handler PID=2110 Docking@Home 21/11/2006 22:05:44 Started upload of file 1tng_mod0001_11811_258050_0_3
	ID: 1558 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1559 - Posted 21 Nov 2006 16:15:03 UTC - in response to Message ID 1548 .
	Suguru, do you have a result number for me? We don't have files that large in our app file set; even the app logfile shouldn't grow that much. Thanks Andre Me too. The result which failed to be completed often send a very large file... It's troublesome for dialup users. ____________ D@H the greatest project in the world... a while from now!
	ID: 1559 \| Rating: 0 \| rate: /

suguruhirahara Forum moderator Volunteer tester Joined: Sep 13 06 Posts: 282 ID: 15 Credit: 56,614 RAC: 0	Message 1570 - Posted 21 Nov 2006 16:47:35 UTC - in response to Message ID 1559 . Last modified: 21 Nov 2006 16:47:49 UTC
	Suguru, do you have a result number for me? We don't have files that large in our app file set; even the app logfile shouldn't grow that much. I'm sorry but my host encountered the issue a couple of weeks ago. But I suppose that at least some Windows hosts which had the 0x1 error have sent the huge size of file. I would have known how to reproduce the same kind of error... Shutting down a computing a workunit via Task Manager can cause that. That is how my host faced to it. thanks for reading, suguruhirahara ____________ I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions.
	ID: 1570 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1573 - Posted 21 Nov 2006 16:56:08 UTC - in response to Message ID 1558 . Last modified: 21 Nov 2006 16:58:34 UTC
	Thanks. That helps: it is actually the app logfile (ends with _3). I have never seen it grow that large in size though! Would be nice to have seen what's in there, but I understand why you have aborted. Ah well, I guess that is what they call heterogeneous computing: surprises are always close by :-) Andre I checked the files we received for this workunit on the server and the largest one (the output log of the app) is 688 KByte in size. I don't know where that 30 MB file went to, but not to Docking@Home :-) As the WU had crashed anyway, I aborted the huge upload. That's why you can't find it. EDIT: in case it's any help, here's an extract of some message in my local BOINC log files, relating to the missing file... Docking@Home 21/11/2006 22:06:51 Backing off 1 minutes and 0 seconds on upload of file 1tng_mod0001_11811_258050_0_3 Docking@Home 21/11/2006 22:06:51 Temporarily failed upload of 1tng_mod0001_11811_258050_0_3: transient upload error Docking@Home 21/11/2006 22:06:51 Error on file upload: [1tng_mod0001_11811_258050_0_3] locked by file_upload_handler PID=2110 Docking@Home 21/11/2006 22:06:48 Started upload of file 1tng_mod0001_11811_258050_0_3 Docking@Home 21/11/2006 22:05:48 Backing off 1 minutes and 0 seconds on upload of file 1tng_mod0001_11811_258050_0_3 Docking@Home 21/11/2006 22:05:48 Temporarily failed upload of 1tng_mod0001_11811_258050_0_3: transient upload error Docking@Home 21/11/2006 22:05:48 Error on file upload: [1tng_mod0001_11811_258050_0_3] locked by file_upload_handler PID=2110 Docking@Home 21/11/2006 22:05:44 Started upload of file 1tng_mod0001_11811_258050_0_3 ____________ D@H the greatest project in the world... a while from now!
	ID: 1573 \| Rating: 0 \| rate: /

[B^S] Morgan the Gold Volunteer tester Joined: Oct 2 06 Posts: 41 ID: 170 Credit: 138,735 RAC: 0	Message 1580 - Posted 22 Nov 2006 4:39:03 UTC Last modified: 22 Nov 2006 4:40:00 UTC
	sorry, I ran through the results list on my boinclogx, and no failed wu on the machines logged (adding logging to linux machine now ). boinclogx would have saved the result, i could have mailed it to ya. but, sorry, those 3 pc havent failed any wu yet (i could fail 1 if u like ) ____________
	ID: 1580 \| Rating: 0 \| rate: /

suguruhirahara Forum moderator Volunteer tester Joined: Sep 13 06 Posts: 282 ID: 15 Credit: 56,614 RAC: 0	Message 1581 - Posted 22 Nov 2006 5:28:55 UTC
	When my host freezed and rebooted, the two results which it has been crunching encountered 0x1 error, but they sent small files, ~1MB. Not every result produces large files. ____________ I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions.
	ID: 1581 \| Rating: 1 \| rate: /

suguruhirahara Forum moderator Volunteer tester Joined: Sep 13 06 Posts: 282 ID: 15 Credit: 56,614 RAC: 0	Message 1608 - Posted 24 Nov 2006 20:10:07 UTC Last modified: 25 Nov 2006 13:34:05 UTC
	After freesing of my host, I noticed that the results which it has computed produced large output files whose size is ~48MB and ~28MB. The files are 1tng_mod0001_11968_235151_1_3 and 1tng_mod0001_11969_476238_1_3 . The result ID of each is 49927 and 49930 . They were hung up after 5 hours and 3 hours have passed. I suspect that the more Charmm crunches by the end (though without completion), the larger output files are produced. They seems not to be a result of a calculation but progression of that, doesn't they? [edit: traffic monitor shows obviously these output files are sent to the server] Hope this helps, suguruhirahara ____________ I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions.
	ID: 1608 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1614 - Posted 25 Nov 2006 17:59:41 UTC - in response to Message ID 1608 . Last modified: 25 Nov 2006 18:02:28 UTC
	Hi Suguru, We think we have figured out why this is happening, but we need more information to confirm that this is the case. It seems from the output in the logfile, that the cause of the problem is an incomplete checkpoint file that Charmm tries to read when it is started again and on which it fails and stops with an error. It would be really useful if somebody can send us the file percentdone.str which can be found in the slots directory; this has to be done right after a reboot, because I think that boinc will remove these temp files after an error. The second issue is the freezing of machines; this seems to be only happening on windows machines (I can be wrong though) and it happens right after the boinc client switches to another project. We need to have more info on the moment when a machine freezes. The last thing Charmm is doing before being switched out is the energy minimization process as can be seen here: **** SOFT CORE AVAILABLE SUGGESTED OPTIONS : RDIE SWIT VSWIT FOR SPC WATER in CDIE USE : EMAX > 1000/EPS OR MINE=-100/EPS, FOR SPC WATER in RDIE USE : EMAX > 200/EPS 1 Chemistry at HARvard Macromolecular Mechanics (CHARMM) - Developmental Version 31a2 February 15, 2004 Copyright(c) 1984-2001 President and Fellows of Harvard College All Rights Reserved Maximum number of ATOMS: 60120, and RESidues: 72000 Current HEAP size: 10240000, and STACK size: 2000000 After that Charmm starts up again (the header with all the info) after being selected by the boinc client and tries to restart from the checkpoint file. And that's where things are going wrong because the checkpoint file seems to be incomplete: VOPEN> Attempting to open::percentdone.str:: OPNLGU> Unit 99 opened for READONLY access to C:Program FilesBOINCslots2percentdone.str INPUT STREAM SWITCHING TO UNIT 99 RDTITL> * PERCENT DONE STREAM FILE *** LEVEL -1 WARNING FROM <RDCMND> * * Command line too long: truncated. **************************************** BOMLEV ( -1) IS REACHED - TERMINATING. WRNLEV IS 5 Summary, we need to find out why machines are freezing: is it charmm or one of the other running projects that do this. We need to have more detail on the contents of percentdone.str at the time of the re-startup of charmm. For both pieces of information we are dependent on one of you to send us this info. Thanks in advance!! Andre PS We have enabled the large output files just for this testing phase. We disable this when we go into production. The longer charmm runs, the more output is send back into the log; suguru was right about that. After freesing of my host, I noticed that the results which it has computed produced large output files whose size is ~48MB and ~28MB. The files are 1tng_mod0001_11968_235151_1_3 and 1tng_mod0001_11969_476238_1_3 . The result ID of each is 49927 and 49930 . They were hung up after 5 hours and 3 hours have passed. I suspect that the more Charmm crunches by the end (though without completion), the larger output files are produced. They seems not to be a result of a calculation but progression of that, doesn't they? [edit: traffic monitor shows obviously these output files are sent to the server] Hope this helps, suguruhirahara ____________ D@H the greatest project in the world... a while from now!
	ID: 1614 \| Rating: 0 \| rate: /

suguruhirahara Forum moderator Volunteer tester Joined: Sep 13 06 Posts: 282 ID: 15 Credit: 56,614 RAC: 0	Message 1617 - Posted 25 Nov 2006 18:57:11 UTC - in response to Message ID 1614 . Last modified: 25 Nov 2006 19:02:06 UTC
	Hi Andre, We think we have figured out why this is happening, but we need more information to confirm that this is the case. It seems from the output in the logfile, that the cause of the problem is an incomplete checkpoint file that Charmm tries to read when it is started again and on which it fails and stops with an error. It would be really useful if somebody can send us the file percentdone.str which can be found in the slots directory; this has to be done right after a reboot, because I think that boinc will remove these temp files after an error. Here is percentdone.str, but because it's old file I doubt whether this is the file which should be. It can be normal, but I'll post it anyway. * PERCENT DONE STREAM FILE * SET FDONE = 100 SET GRIDDONE = FALSE SET GRIDSET = FALSE SET NUMIC = 81 SET RNUM = 1 SET MAXENER = -24.5791 SET MAXRMSD = 1.676674E-02 SET SEED = 15535.5 SET PHI = 146.878 SET XAX = 10.5754 SET YAX = 21.398 SET ZAX = 26.3704 SET RCOUNT = 12880 SET PHRAND = 0 Is percentdone always produced after crunching a result of this project, or only when a result encounters an error and becomes corrupt? thanks, suguruhirahara ____________ I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions.
	ID: 1617 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1619 - Posted 25 Nov 2006 19:39:20 UTC - in response to Message ID 1617 .
	Percentdone.str is one of our checkpoint files and is regularly produced by the application. The one below is a normal one which contains everything charmm needs to restart. If you (or somebody else) can send me the file right after a freeze of your machine and the following reboot, that would be great. Thanks Andre Hi Andre, We think we have figured out why this is happening, but we need more information to confirm that this is the case. It seems from the output in the logfile, that the cause of the problem is an incomplete checkpoint file that Charmm tries to read when it is started again and on which it fails and stops with an error. It would be really useful if somebody can send us the file percentdone.str which can be found in the slots directory; this has to be done right after a reboot, because I think that boinc will remove these temp files after an error. Here is percentdone.str, but because it's old file I doubt whether this is the file which should be. It can be normal, but I'll post it anyway. * PERCENT DONE STREAM FILE * SET FDONE = 100 SET GRIDDONE = FALSE SET GRIDSET = FALSE SET NUMIC = 81 SET RNUM = 1 SET MAXENER = -24.5791 SET MAXRMSD = 1.676674E-02 SET SEED = 15535.5 SET PHI = 146.878 SET XAX = 10.5754 SET YAX = 21.398 SET ZAX = 26.3704 SET RCOUNT = 12880 SET PHRAND = 0 Is percentdone always produced after crunching a result of this project, or only when a result encounters an error and becomes corrupt? thanks, suguruhirahara ____________ D@H the greatest project in the world... a while from now!
	ID: 1619 \| Rating: 0 \| rate: /

KWSN - A Shrubbery Volunteer tester Joined: Sep 13 06 Posts: 24 ID: 12 Credit: 25,912 RAC: 0	Message 1624 - Posted 26 Nov 2006 20:21:01 UTC Last modified: 26 Nov 2006 20:21:28 UTC
	If you're still looking for result numbers with large outputs, http://docking.utep.edu/workunit.php?wuid=14697 errored out when my system froze and uploaded about 13mb. Should still be in your DB. I'm pretty sure the lockup was not caused by BOINC or Docking. ____________ KWSN - A Shrubbery http://www.kwsnforum.com
	ID: 1624 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1626 - Posted 27 Nov 2006 0:48:29 UTC - in response to Message ID 1624 .
	Thanks Kwsn, Seems like the same thing as happened to Suguru's result. After your restart and the restart of Charmm by the BOINC client, the app tries to read a corrupted checkpoint file and stops. It actually detects this and stops by showing a nice skull ;-) What this means is probably that we have to make our checkpointing more like an atomic operation, because at the moment this is not the case: if a machine crashes or freezes during the time a checkpoint is written, we have a problem and the next time BOINC restarts the app, it will terminate. Fortunately this doesn't happen all to often I think, but when it happens, there is not much we can do about it right now. We'll have to have a hard think about how to make the checkpointing more atomic. Thanks Andre If you're still looking for result numbers with large outputs, http://docking.utep.edu/workunit.php?wuid=14697 errored out when my system froze and uploaded about 13mb. Should still be in your DB. I'm pretty sure the lockup was not caused by BOINC or Docking. ____________ D@H the greatest project in the world... a while from now!
	ID: 1626 \| Rating: 0 \| rate: /

David Ball Forum moderator Volunteer tester Joined: Sep 18 06 Posts: 274 ID: 115 Credit: 1,634,401 RAC: 0	Message 1631 - Posted 27 Nov 2006 14:41:51 UTC
	I don't know if this is related, but this is from the stderrdae.txt file on my RHEL3 machine. The '$' means that the line was too long to fit on the screen in the nano text editor. 2006-11-22 03:28:00 [lhcathome] No work from project 2006-11-22 03:41:02 [Docking@Home] Unrecoverable error for result 1tng_mod0001_9218_83020_5 (process exited with code 1 (0x1$ 2006-11-22 04:15:04 [Docking@Home] Message from server: No work sent 2006-11-22 04:15:04 [Docking@Home] Message from server: (reached daily quota of 1 results) 2006-11-22 04:15:04 [Docking@Home] No work from project SIGSEGV: segmentation violationStack trace (16 frames): /home/BOINC/boinc[0x8089dc2] /lib/libpthread.so.0[0x40174619] /lib/libc.so.6[0x400482b8] /lib/libc.so.6(vsprintf+0x5b)[0x4007da5b] /home/BOINC/boinc[0x808bc52] /home/BOINC/boinc[0x808c01b] /home/BOINC/boinc[0x80515c7] /home/BOINC/boinc[0x8051d2a] /home/BOINC/boinc[0x80718a9] /home/BOINC/boinc[0x80715eb] /home/BOINC/boinc[0x8071a99] /home/BOINC/boinc[0x8059c15] /home/BOINC/boinc[0x807d189] /home/BOINC/boinc[0x807d2b7] /lib/libc.so.6(__libc_start_main+0x8d)[0x40036bd1] /home/BOINC/boinc(__fxstat64+0x99)[0x804c1e1] Exiting... 2006-11-22 04:17:38 [rosetta@home] State file error: result DOC_1MLC_R061114_pose_u_global_search_1402_736_0 is in wrong sta$ 2006-11-22 08:17:57 [lhcathome] No work from project 2006-11-22 08:19:07 [lhcathome] Couldn't parse scheduler list 2006-11-22 08:20:15 [lhcathome] Couldn't parse scheduler list 2006-11-22 08:20:15 [lhcathome] 3 consecutive failures fetching scheduler list - deferring 604800 seconds 2006-11-22 19:34:26 [rosetta@home] Project is down 2006-11-23 05:54:46 [Docking@Home] Unrecoverable error for result 1tng_mod0001_12426_461610_2 (process exited with code 1 (0$ 2006-11-23 05:55:52 [Docking@Home] Message from server: No work sent Here's the stdoutdae.txt from the same time period. 2006-11-22 03:28:00 [lhcathome] Scheduler request succeeded 2006-11-22 03:28:00 [lhcathome] No work from project 2006-11-22 03:28:00 [lhcathome] Deferring scheduler requests for 1 hours, 30 minutes and 59 seconds 2006-11-22 03:28:05 [---] Suspending work fetch because computer is overcommitted. 2006-11-22 03:29:31 [---] Suspending network activity - user request 2006-11-22 03:41:02 [Docking@Home] Unrecoverable error for result 1tng_mod0001_9218_83020_5 (process exited with code 1 (0x1$ 2006-11-22 03:41:02 [Docking@Home] Deferring scheduler requests for 1 minutes and 0 seconds 2006-11-22 03:41:02 [---] Rescheduling CPU: application exited 2006-11-22 03:41:02 [Docking@Home] Computation for task 1tng_mod0001_9218_83020_5 finished 2006-11-22 03:41:02 [---] Resuming round-robin CPU scheduling. 2006-11-22 03:41:02 [rosetta@home] Resuming task DOC_1MLC_R061114_pose_u_global_search_1402_736_0 using rosetta version 540 2006-11-22 04:14:59 [---] Resuming network activity 2006-11-22 04:14:59 [---] Allowing work fetch again. 2006-11-22 04:14:59 [Docking@Home] Sending scheduler request to http://docking.utep.edu/docking_cgi/cgi 2006-11-22 04:14:59 [Docking@Home] Reason: To fetch work 2006-11-22 04:14:59 [Docking@Home] Requesting 21600 seconds of new work, and reporting 1 completed tasks 2006-11-22 04:15:00 [Docking@Home] Started upload of file 1tng_mod0001_9218_83020_5_0 2006-11-22 04:15:00 [Docking@Home] Started upload of file 1tng_mod0001_9218_83020_5_1 2006-11-22 04:15:04 [Docking@Home] Finished upload of file 1tng_mod0001_9218_83020_5_0 2006-11-22 04:15:04 [Docking@Home] Throughput 29451 bytes/sec 2006-11-22 04:15:04 [Docking@Home] Finished upload of file 1tng_mod0001_9218_83020_5_1 2006-11-22 04:15:04 [Docking@Home] Throughput 29425 bytes/sec 2006-11-22 04:15:04 [Docking@Home] Started upload of file 1tng_mod0001_9218_83020_5_2 2006-11-22 04:15:04 [Docking@Home] Started upload of file 1tng_mod0001_9218_83020_5_3 2006-11-22 04:15:04 [Docking@Home] Scheduler request succeeded 2006-11-22 04:15:04 [Docking@Home] Message from server: No work sent 2006-11-22 04:15:04 [Docking@Home] Message from server: (reached daily quota of 1 results) 2006-11-22 04:15:04 [Docking@Home] No work from project 2006-11-22 04:15:09 [rosetta@home] Sending scheduler request to http://boinc.bakerlab.org/rosetta_cgi/cgi 2006-11-22 04:15:09 [rosetta@home] Reason: To fetch work 2006-11-22 04:15:09 [rosetta@home] Requesting 21600 seconds of new work, and reporting 1 completed tasks 2006-11-22 04:15:12 [Docking@Home] Finished upload of file 1tng_mod0001_9218_83020_5_2 2006-11-22 04:15:12 [Docking@Home] Throughput 51542 bytes/sec 2006-11-22 04:15:12 [Docking@Home] Finished upload of file 1tng_mod0001_9218_83020_5_3 2006-11-22 04:15:12 [Docking@Home] Throughput 598603 bytes/sec 2006-11-22 04:15:14 [rosetta@home] Scheduler request succeeded 2006-11-22 04:15:15 [rosetta@home] Started download of file hom018_s014_.fasta.gz 2006-11-22 04:15:15 [rosetta@home] Started download of file hom018_s014_.psipred_ss2.gz 2006-11-22 04:17:38 [---] Starting BOINC client version 5.4.9 for i686-pc-linux-gnu 2006-11-22 04:17:38 [---] libcurl/7.15.3 OpenSSL/0.9.8a zlib/1.2.3 2006-11-22 04:17:38 [---] Executing as a daemon 2006-11-22 04:17:38 [---] Data directory: /home/BOINC 2006-11-22 04:17:38 [rosetta@home] State file error: result DOC_1MLC_R061114_pose_u_global_search_1402_736_0 is in wrong sta$ 2006-11-22 04:17:38 [---] Processor: 1 GenuineIntel Intel(R) Celeron(R) CPU 2.40GHz 2006-11-22 04:17:38 [---] Memory: 1.95 GB physical, 1.95 GB virtual 2006-11-22 04:17:38 [---] Disk: 16.02 GB total, 11.62 GB free 2006-11-22 04:17:38 [Docking@Home] URL: http://docking.utep.edu/; Computer ID: 223; location: work; project prefs: default 2006-11-22 04:17:38 [SETI@home] URL: http://setiathome.berkeley.edu/; Computer ID: 2185126; location: work; project prefs: d$ 2006-11-22 04:17:38 [rosetta@home] URL: http://boinc.bakerlab.org/rosetta/; Computer ID: 211470; location: work; project pre$ 2006-11-22 04:17:38 [lhcathome] URL: http://lhcathome.cern.ch/lhcathome/; Computer ID: 2363079; location: work; project pref$ 2006-11-22 04:17:38 [---] General prefs: from Docking@Home (last modified 2006-11-22 03:03:43) 2006-11-22 04:17:38 [---] General prefs: using separate prefs for work 2006-11-22 04:17:38 [---] Local control only allowed 2006-11-22 04:17:38 [---] Listening on port 31416 2006-11-22 04:17:38 [SETI@home] Deferring task 10jn03ab.7548.30496.284650.3.57_1 2006-11-22 04:17:38 [SETI@home] Restarting task 10jn03ab.7548.30496.284650.3.57_1 using setiathome_enhanced version 512 2006-11-22 04:17:39 [rosetta@home] Started download of file hom018_s014_.fasta.gz 2006-11-22 04:17:39 [rosetta@home] Started download of file hom018_s014_.psipred_ss2.gz 2006-11-22 04:17:42 [rosetta@home] Finished download of file hom018_s014_.fasta.gz 2006-11-22 04:17:42 [rosetta@home] Throughput 1149 bytes/sec 2006-11-22 04:17:42 [rosetta@home] Finished download of file hom018_s014_.psipred_ss2.gz 2006-11-22 04:17:42 [rosetta@home] Throughput 7188 bytes/sec 2006-11-22 04:17:42 [rosetta@home] Started download of file boinc_hom018_aas014_03_05.200_v1_3.gz 2006-11-22 04:17:42 [rosetta@home] Started download of file boinc_hom018_aas014_09_05.200_v1_3.gz 2006-11-22 04:17:44 [rosetta@home] Finished download of file boinc_hom018_aas014_09_05.200_v1_3.gz 2006-11-22 04:17:44 [rosetta@home] Throughput 360810 bytes/sec 2006-11-22 04:17:44 [rosetta@home] Started download of file sg_target_description.txt 2006-11-22 04:17:45 [rosetta@home] Finished download of file boinc_hom018_aas014_03_05.200_v1_3.gz 2006-11-22 04:17:45 [rosetta@home] Throughput 687255 bytes/sec 2006-11-22 04:17:45 [rosetta@home] Finished download of file sg_target_description.txt 2006-11-22 04:17:45 [rosetta@home] Throughput 943 bytes/sec 2006-11-22 04:17:46 [---] Rescheduling CPU: files downloaded 2006-11-22 04:17:46 [---] Using earliest-deadline-first scheduling because computer is overcommitted. 2006-11-22 04:17:46 [SETI@home] Pausing task 10jn03ab.7548.30496.284650.3.57_1 (left in memory) 2006-11-22 04:17:46 [rosetta@home] Starting task s014__BOINC_ABRELAX_SAVE_ALL_OUT_hom018__1406_4371_0 using rosetta version $ 2006-11-22 04:17:49 [---] Suspending work fetch because computer is overcommitted. 2006-11-22 08:17:51 [---] Allowing work fetch again. 2006-11-22 08:17:52 [lhcathome] Sending scheduler request to http://lhcathome.cern.ch/lhcathome_cgi/cgi 2006-11-22 08:17:52 [lhcathome] Reason: To fetch work 2006-11-22 08:17:52 [lhcathome] Requesting 21600 seconds of new work 2006-11-22 08:17:57 [lhcathome] Scheduler request succeeded 2006-11-22 08:17:57 [lhcathome] No work from project I'm not sure if this is related to Docking or Rosetta, but I have noticed that anytime you stop the BOINC service on this machine, Rosetta keeps running, but in sleeping mode so it doesn't use any CPU. You have to kill Rosetta from top with a SIGTERM. This had happened prior to the log above when I stopped boinc to change something for another try at getting docking to work on this machine, IIRC. BTW, a couple of times I have noticed it wasn't reporting results and found that rosetta had been sleeping for 2+ days and boinc was nowhere to be found. This is the standard boinc 5.4.9 client on a text only machine (both console and ssh are text only), running as a service. They really need to release a command line only Linux boinc client version again. I'm having to use the boinc_cmd from boinc 5.2.13 to control it. -- David
	ID: 1631 \| Rating: 0 \| rate: /

David Ball Forum moderator Volunteer tester Joined: Sep 18 06 Posts: 274 ID: 115 Credit: 1,634,401 RAC: 0	Message 1632 - Posted 27 Nov 2006 15:12:20 UTC - in response to Message ID 1631 . Last modified: 27 Nov 2006 15:25:52 UTC
	That error might have to do with the Rosetta command line being too long. I just ran a "ps axu" and here are the boinc processes as of now. boinc 28900 0.0 0.0 4724 2020 ? S Nov25 0:00 /home/BOINC/boinc -redirectio daemon boinc 31274 0.0 1.3 39288 26796 ? SN Nov26 0:00 setiathome-5.12.i686-pc-linux-gnu boinc 31275 0.0 1.3 39288 26796 ? RN Nov26 0:00 setiathome-5.12.i686-pc-linux-gnu boinc 31276 11.4 1.3 39288 26796 ? SN Nov26 111:25 setiathome-5.12.i686-pc-linux-gnu boinc 31277 0.0 1.3 39288 26796 ? SN Nov26 0:00 setiathome-5.12.i686-pc-linux-gnu boinc 9907 88.7 3.6 111684 73940 ? RN 01:45 385:40 rosetta_5.40_i686-pc-linux-gnu dd 1TAB 1 -s 1TAB.uppk -dock -pose -dock_mcm -randomize1 -randomize2 -unbound_start -ex1 -ex2aro_only -dock_rtmin -unboundrot -find_disulf -norepack_disulf -dock_score_norepack -no_filters -output_all -accept_all -nstruct 10 - boinc 9908 0.0 3.6 111684 73940 ? RN 01:45 0:00 rosetta_5.40_i686-pc-linux-gnu dd 1TAB 1 -s 1TAB.uppk -dock -pose -dock_mcm -randomize1 -randomize2 -unbound_start -ex1 -ex2aro_only -dock_rtmin -unboundrot -find_disulf -norepack_disulf -dock_score_norepack -no_filters -output_all -accept_all -nstruct 10 - boinc 9909 0.0 3.6 111684 73940 ? SN 01:45 0:00 rosetta_5.40_i686-pc-linux-gnu dd 1TAB 1 -s 1TAB.uppk -dock -pose -dock_mcm -randomize1 -randomize2 -unbound_start -ex1 -ex2aro_only -dock_rtmin -unboundrot -find_disulf norepack_disulf -dock_score_norepack -no_filters -output_all -accept_all -nstruct 10 - boinc 9921 0.0 3.6 111684 73940 ? SN 01:45 0:00 rosetta_5.40_i686-pc-linux-gnu dd 1TAB 1 -s 1TAB.uppk -dock -pose -dock_mcm -randomize1 -randomize2 -unbound_start -ex1 -ex2aro_only -dock_rtmin -unboundrot -find_disulf -norepack_disulf -dock_score_norepack -no_filters -output_all -accept_all -nstruct 10 - Sorry for any weird formatting. I piped the output of "ps axu" into "nano -v" and did a cut-paste from the screen in nano. It looks like "ps axu" clipped the command lines for rosetta. Again, I don't know if it was docking or rosetta that killed boinc. -- David EDIT: Just went into /proc/9907 and got the command line from there. The spaces between options didn't show so I'm guessing at that part to keep the line from being too long. [/proc/9907]# cat cmdline rosetta_5.40_i686-pc-linux-gnu dd 1TAB 1 -s 1TAB.uppk -dock -pose -dock_mcm -randomize1 -randomize2 -unbound_start -ex1 -ex2aro_only -dock_rtmin -unboundrot -find_disulf -norepack_disulf -dock_score_norepack -no_filters -output_all -accept_all -nstruct 10 -silent -output_silent_gz -pose_silent_out -cpu_run_time 10800 -watchdog -constant_seed -jran 2638533
	ID: 1632 \| Rating: 0 \| rate: /

Conan Volunteer tester Joined: Sep 13 06 Posts: 219 ID: 100 Credit: 4,256,493 RAC: 0	Message 1635 - Posted 28 Nov 2006 7:40:06 UTC Last modified: 28 Nov 2006 7:42:10 UTC
	While I did not catch this one in the act of uploading the error output file gives an indication that this was a big file to upload as it took over 10 minutes to do so 2006-11-28 11:10:33 [Docking@Home] Unrecoverable error for result 1tng_mod0001_11968_235151_6 (Incorrect function. (0x1) - exit code 1 (0x1)) 2006-11-28 11:10:33 [Docking@Home] Deferring scheduler requests for 1 minutes and 0 seconds 2006-11-28 11:10:33 [---] Rescheduling CPU: application exited 2006-11-28 11:10:33 [Docking@Home] Computation for task 1tng_mod0001_11968_235151_6 finished 2006-11-28 11:10:33 [---] Resuming round-robin CPU scheduling. 2006-11-28 11:10:33 [rosetta@home] Resuming task s014__BOINC_ABRELAX_SAVE_ALL_OUT_hom004__1406_6538_0 using rosetta version 540 2006-11-28 11:10:35 [---] Allowing work fetch again. 2006-11-28 11:10:36 [Docking@Home] Started upload of file 1tng_mod0001_11968_235151_6_0 2006-11-28 11:10:36 [Docking@Home] Started upload of file 1tng_mod0001_11968_235151_6_1 2006-11-28 11:10:39 [Docking@Home] Finished upload of file 1tng_mod0001_11968_235151_6_1 2006-11-28 11:10:39 [Docking@Home] Throughput 3852 bytes/sec 2006-11-28 11:10:39 [Docking@Home] Started upload of file 1tng_mod0001_11968_235151_6_2 2006-11-28 11:10:40 [Docking@Home] Finished upload of file 1tng_mod0001_11968_235151_6_0 2006-11-28 11:10:40 [Docking@Home] Throughput 3326 bytes/sec 2006-11-28 11:10:40 [Docking@Home] Started upload of file 1tng_mod0001_11968_235151_6_3 2006-11-28 11:11:00 [Docking@Home] Finished upload of file 1tng_mod0001_11968_235151_6_2 2006-11-28 11:11:00 [Docking@Home] Throughput 8290 bytes/sec 2006-11-28 11:11:35 [Docking@Home] Sending scheduler request to http://docking.utep.edu/docking_cgi/cgi 2006-11-28 11:11:35 [Docking@Home] Reason: To report completed tasks 2006-11-28 11:11:35 [Docking@Home] Reporting 1 tasks 2006-11-28 11:11:45 [Docking@Home] Scheduler request succeeded 2006-11-28 11:20:51 [Docking@Home] Finished upload of file 1tng_mod0001_11968_235151_6_3 2006-11-28 11:20:51 [Docking@Home] Throughput 10763 bytes/sec At the throughput speed of 3326 bytes/sec for 4 sec, segment 0 = 106,432 bits 3852 bytes/sec for 1 sec, segment 1 = 30,816 bits 8290 bytes/sec for 21 sec,segment 2 = 1,392,720 bits 10763 bytes/sec for 10 min 11 sec 3 =52,609,544 bits All up nearly 54 MB for the upload file. I am thankful I am no longer on dialup as it would of taken hours. This computer is an P4 2.53 Ghz @ 2.75 GHz with 1 GB of RAM and running Windows. Hope this is useful. ____________
	ID: 1635 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1647 - Posted 29 Nov 2006 4:29:14 UTC - in response to Message ID 1635 .
	Hmmm, the file on the server is only 6.3 MB in size and it just abruptly ends in the middle of the energy minimization function. This means the 'incorrect function' message really completely crashes the app without a chance to write something to the logfile. This seems a problem in many fortran-based boinc projects (as Suguru pointed out; just found out that Rosetta has a couple of those as well). I am hoping that the new version of Charmm (which still hasn't been released by the charmm developers :-( will solve many of these problems, because hundreds of bug fixes have been made in that release. Andre PS For people on dialup connections: please do not upload these giant output files; they can be useful for us, but are definitely not worth your money. Fortunately we have many broadband users with unlimited uploads and downloads that can help us out here. While I did not catch this one in the act of uploading the error output file gives an indication that this was a big file to upload as it took over 10 minutes to do so At the throughput speed of 3326 bytes/sec for 4 sec, segment 0 = 106,432 bits 3852 bytes/sec for 1 sec, segment 1 = 30,816 bits 8290 bytes/sec for 21 sec,segment 2 = 1,392,720 bits 10763 bytes/sec for 10 min 11 sec 3 =52,609,544 bits All up nearly 54 MB for the upload file. I am thankful I am no longer on dialup as it would of taken hours. This computer is an P4 2.53 Ghz @ 2.75 GHz with 1 GB of RAM and running Windows. Hope this is useful. ____________ D@H the greatest project in the world... a while from now!
	ID: 1647 \| Rating: 0 \| rate: /

suguruhirahara Forum moderator Volunteer tester Joined: Sep 13 06 Posts: 282 ID: 15 Credit: 56,614 RAC: 0	Message 1663 - Posted 30 Nov 2006 11:07:17 UTC - in response to Message ID 1647 .
	Hmmm, the file on the server is only 6.3 MB in size and it just abruptly ends in the middle of the energy minimization function. This means the 'incorrect function' message really completely crashes the app without a chance to write something to the logfile. This seems a problem in many fortran-based boinc projects (as Suguru pointed out; just found out that Rosetta has a couple of those as well). I'm not sure, but isn't a debugger of BOINC (BOINC Windows Runtime Debugger Version 5.5.0) available, so that devs can trace the memory dump file? ( http://boinc.berkeley.edu/app_debug_win.php ) Sometimes I saw the debugger run for results of rosetta@home. ____________ I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions.
	ID: 1663 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1666 - Posted 30 Nov 2006 18:17:04 UTC - in response to Message ID 1663 .
	True and Richard is looking into this to see if it usable for us. It's only for windows though. Andre Hmmm, the file on the server is only 6.3 MB in size and it just abruptly ends in the middle of the energy minimization function. This means the 'incorrect function' message really completely crashes the app without a chance to write something to the logfile. This seems a problem in many fortran-based boinc projects (as Suguru pointed out; just found out that Rosetta has a couple of those as well). I'm not sure, but isn't a debugger of BOINC (BOINC Windows Runtime Debugger Version 5.5.0) available, so that devs can trace the memory dump file? ( http://boinc.berkeley.edu/app_debug_win.php ) Sometimes I saw the debugger run for results of rosetta@home. ____________ D@H the greatest project in the world... a while from now!
	ID: 1666 \| Rating: 0 \| rate: /

suguruhirahara Forum moderator Volunteer tester Joined: Sep 13 06 Posts: 282 ID: 15 Credit: 56,614 RAC: 0	Message 1670 - Posted 1 Dec 2006 8:30:40 UTC - in response to Message ID 1666 .
	True and Richard is looking into this to see if it usable for us. It's only for windows though. FYI from the page of boinc, With the BOINC Runtime Debugger for Windows framework a project can publish their symbol files and only have to distribute the application to each of the BOINC clients. When a crash event occurs the runtime framework will download the symbol file from the symbol store and then proceed to dump as much diagnostic information as possible to help projects diagnose the failure. If charmm crashes completely because of incorrect function and it causes boinc to freeze, is there time for the runtime framework to do such a thing? BTW when I let the machine create dump file, there appears a file whose size is very large, more than 100MB! Also, I tried to debug the dump file on WinDbg, but the debugger cannot do since it fails to open 'symbol files', although the symbol search path is set to where windows symbol packages were downloaded from here . Where can I get the symbol file which enables the debugger to debug the file? The message it shows: Loading Dump File [C:\Users\Private\AppData\Local\Temp\charmm_5.DMP] User Mini Dump File with Full Memory: Only application data is available Windows Vista Version 5600 MP (2 procs) Free x86 compatible Product: WinNt, suite: SingleUserTS Debug session time: Fri Dec 1 02:42:52.000 2006 (GMT+9) System Uptime: 0 days 15:24:33.976 Process Uptime: 0 days 1:15:21.000 Symbol search path is: C:\Windows\Symbols Executable search path is: ............. * ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll - eax=00003020 ebx=02f811c0 ecx=0093d680 edx=0933bfa0 esi=ffffffff edi=ffffffff eip=007bd05a esp=0012e054 ebp=0012e5c0 iopl=0 nv up ei pl nz ac po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000212 * WARNING: Unable to verify checksum for charmm_5.3_windows_intelx86 *** ERROR: Module load completed but symbols could not be loaded for charmm_5.3_windows_intelx86 charmm_5+0x3bd05a: 007bd05a dfe0 fnstsw ax thanks for reading, suguruhirahara ____________ I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions.
	ID: 1670 \| Rating: 0 \| rate: /

bjango Volunteer tester Joined: Nov 14 06 Posts: 2 ID: 328 Credit: 5,116 RAC: 0	Message 1921 - Posted 2 Jan 2007 22:05:01 UTC - in response to Message ID 1670 .
	I am uploading a 54mb file at the moment for this workunit . ____________ damien rice - frank and the walters - Honda
	ID: 1921 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1922 - Posted 2 Jan 2007 22:54:42 UTC - in response to Message ID 1921 .
	Could you tell us what happened with that result on your computer? Did it crash? The result still shows as in progress on the server... Thanks Andre I am uploading a 54mb file at the moment for this workunit . ____________ D@H the greatest project in the world... a while from now!
	ID: 1922 \| Rating: 0 \| rate: /

bjango Volunteer tester Joined: Nov 14 06 Posts: 2 ID: 328 Credit: 5,116 RAC: 0	Message 1929 - Posted 3 Jan 2007 8:28:11 UTC - in response to Message ID 1922 .
	Could you tell us what happened with that result on your computer? Did it crash? The result still shows as in progress on the server... Thanks Andre I installed some more software. and during the restart, the above workunit and one for WCG crashed. Noel ____________ damien rice - frank and the walters - Honda
	ID: 1929 \| Rating: 0 \| rate: /

Andre Kerstens Forum moderator Project tester Volunteer tester Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0	Message 1930 - Posted 3 Jan 2007 14:37:05 UTC - in response to Message ID 1929 .
	Thanks. It seems the status now has correctly changed to 'invalid' with an error. Andre Could you tell us what happened with that result on your computer? Did it crash? The result still shows as in progress on the server... Thanks Andre I installed some more software. and during the restart, the above workunit and one for WCG crashed. Noel ____________ D@H the greatest project in the world... a while from now!
	ID: 1930 \| Rating: 0 \| rate: /

Message boards : Number crunching : Large output files

Database Error
: The MySQL server is running with the --read-only option so it cannot execute this statement

array(3) {
  [0]=>
  array(7) {
    ["file"]=>
    string(47) "/boinc/projects/docking/html_v2/inc/db_conn.inc"
    ["line"]=>
    int(97)
    ["function"]=>
    string(8) "do_query"
    ["class"]=>
    string(6) "DbConn"
    ["object"]=>
    object(DbConn)#34 (2) {
      ["db_conn"]=>
      resource(96) of type (mysql link persistent)
      ["db_name"]=>
      string(7) "docking"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(1) {
      [0]=>
      &string(51) "update DBNAME.thread set views=views+1 where id=116"
    }
  }
  [1]=>
  array(7) {
    ["file"]=>
    string(48) "/boinc/projects/docking/html_v2/inc/forum_db.inc"
    ["line"]=>
    int(60)
    ["function"]=>
    string(6) "update"
    ["class"]=>
    string(6) "DbConn"
    ["object"]=>
    object(DbConn)#34 (2) {
      ["db_conn"]=>
      resource(96) of type (mysql link persistent)
      ["db_name"]=>
      string(7) "docking"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(3) {
      [0]=>
      object(BoincThread)#3 (16) {
        ["id"]=>
        string(3) "116"
        ["forum"]=>
        string(1) "2"
        ["owner"]=>
        string(2) "15"
        ["status"]=>
        string(1) "0"
        ["title"]=>
        string(18) "Large output files"
        ["timestamp"]=>
        string(10) "1167835025"
        ["views"]=>
        string(4) "3524"
        ["replies"]=>
        string(2) "28"
        ["activity"]=>
        string(20) "3.5069687677469e-126"
        ["sufferers"]=>
        string(1) "0"
        ["score"]=>
        string(1) "0"
        ["votes"]=>
        string(1) "0"
        ["create_time"]=>
        string(10) "1164396945"
        ["hidden"]=>
        string(1) "0"
        ["sticky"]=>
        string(1) "0"
        ["locked"]=>
        string(1) "0"
      }
      [1]=>
      &string(6) "thread"
      [2]=>
      &string(13) "views=views+1"
    }
  }
  [2]=>
  array(7) {
    ["file"]=>
    string(63) "/boinc/projects/docking/html_v2/user/community/forum/thread.php"
    ["line"]=>
    int(184)
    ["function"]=>
    string(6) "update"
    ["class"]=>
    string(11) "BoincThread"
    ["object"]=>
    object(BoincThread)#3 (16) {
      ["id"]=>
      string(3) "116"
      ["forum"]=>
      string(1) "2"
      ["owner"]=>
      string(2) "15"
      ["status"]=>
      string(1) "0"
      ["title"]=>
      string(18) "Large output files"
      ["timestamp"]=>
      string(10) "1167835025"
      ["views"]=>
      string(4) "3524"
      ["replies"]=>
      string(2) "28"
      ["activity"]=>
      string(20) "3.5069687677469e-126"
      ["sufferers"]=>
      string(1) "0"
      ["score"]=>
      string(1) "0"
      ["votes"]=>
      string(1) "0"
      ["create_time"]=>
      string(10) "1164396945"
      ["hidden"]=>
      string(1) "0"
      ["sticky"]=>
      string(1) "0"
      ["locked"]=>
      string(1) "0"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(1) {
      [0]=>
      &string(13) "views=views+1"
    }
  }
}

query: update docking.thread set views=views+1 where id=116