Posts by Professor Ray

41) Message boards : Questions and problems : Suspend - memory resident (Message 33529) Posted 26 Jun 2010 by Professor Ray Post: If BOINC is snoozed, or projects are suspended, and the leave memory resident option is enabled, does the project resume at the point in computation where it left off, or does it resume from the point of last checkpoint for WU being resumed?
42) Message boards : Questions and problems : BOINC 6.10.58 released to public (Message 33523) Posted 25 Jun 2010 by Professor Ray Post: Well, since I posted that, it appears that BOINC has settled down significantly. Since I posted he began resuming tasks about every 2.5 hrs, albeit all processing is still at high priority. Perhaps this was an 'initial state' issue where the new scheduler inherent the lastest versino of BOINC was confronted with all the WU's that the previous version of BOINC (6.10.43) had just downloaded prior to updating to 6.10.56. Hopefully he'll begin normal priority of WU processing soon.
43) Message boards : Questions and problems : BOINC 6.10.58 released to public (Message 33520) Posted 25 Jun 2010 by Professor Ray Post: I've noticed that since updating to v6.10.56 that BOINC is constantly resuming tasks every 1 to three minutes. Moreover, all its processing is done in 'high priority' mode. Furthermore, it was switching between all tasks for which WU's exist, i.e., ten different projects. Each WU was processed for about 2 minutes and it would switch to a different WU. Messages indicated that tasks exited with zero status but no finished file. Looking in the error files per project indicates no heartbeat. To address this issue I set all projects to NNT and then suspended every project except the one with the most urgent deadline, i.e., Virtual Prarie due 6-28 and estimated time to complete ~2.5 hours. It finished in about 2 hours and sent result to server. I then resumed all the tasks and then allowed work for all the projects. Within 20 minutes I received another Virtual Prarie WU and the whole shenanigans started up again. Until the Virtual Prarie WU was downloaded no task switching occured and no messages were generated concerning exit with zero status. Moreover WU processing occured in normal priority mode. The problem began again two hours after Virtual Prarie downloaded a new WU. At that time task switching began anew, it has switched tasks about 60 times in the last 80 minutes. However, there have been no indications of zero exit status. It is only switching between the WU with the most urgent deadline and the one with the oldest deadline, i.e., due 7-8. That WU (Cosmology) is estimated complete in 34 hours with 41% complete. The most recent Virtual Prarie is 10% complete with 10min on the clock. This is highly unusual based on previous experience.
44) Message boards : Questions and problems : BSODs - 'Page Fault in Nonpaged Area' (Message 33519) Posted 25 Jun 2010 by Professor Ray Post: I experienced this problem a couple of months ago. It turned out to be a bad mememory module. It took awhile to uncover the error because I never let MemTest86 run long enough to detect the error. The test sometimes would appear in test 5 (block 64 move) or a subsequent test. It always passed tests 1-4 & 6. If it didn't fail on 5, it would fail on 7 or 8 (I forget which one). The memory address was the same regardless of which test detected the error. That is if it failed in test 5, the same memory address would fail in test 7 (or 8). If it passed 5, it would still fail test 7 (or 8). Again, I don't remember the exact post-5 test it would fail on. Moreover, it would fail the extended test 5 (the block 512 move) at the same memory address implicated in the previous tests every time. If all tests, i.e., test 1-9 MemTest86 completes w/out error twice, then your RAM can be confidently assessed as being sound. Trouble is those tests take forever to complete. If the RAM passed MemTest86 testing, I'd hazard a guess it had something to do with your SATA drivers. It appears that reinstalling them resolved the issue. Based on my experience, the particular error caused a datawrite into the region on the HDD defined as being the swap file. This inherently causes the swap file to become fragmented / corrupted. I'd suggest that you delete the swap file on the drive. Then run CHKDSK /X on the drive. This should be done as a matter of course for any BSOD. Don't rely on the HDD dirty being set. After defragging the HDD, reestablish the swap file. This is assuming that you have a fixed size swap file established and a contiguous swap file is desired for optimal performance. If you haven't configured a fixed size page file then this may not be an issue. However, you should be aware that swap file fragmentation degrades performance and hinders defragmenting of the HDD. Ideally a fixed size swap file should accomodate 95% of expected paging requirements. The remaining 5% is the minimum size for the adjunct swap file on an alternate HDD. That swap file should be allowed to grow as necessary; when no longer needed it'll shrink back to its minimum defined size. I'm not all that concerned about swap file fragmentation in the 95+% swap file useage scenario.
45) Message boards : Questions and problems : Event log errors - starting BOINC 6.6.36 - Event ID 1 (Message 27983) Posted 13 Oct 2009 by Professor Ray Post: O.k., I think I found the culprit here. Most likely this was a Zone Alarm issue. I noticed in the Zone Alarm alerts log that ccEvtMngr (a Norton AV component) was trying to phone crl.verisign.net and was being blocked by ZA. According to the event log, the BOINC error 1 happened immediately after 2 consequtive ccPwdSvc events. I put the IP address for crl.verisign.net (197.7.48.190) into the trusted zone and allowed Event Manager Service (ccEvtMgr.exe) to have trusted zone access. After rebooting, I notice 3 consequtive ccPwdSvc events and no BOINC error. Hmmmmpf. Whoda thunk it was a permissions issue.
46) Message boards : Questions and problems : Event log errors - starting BOINC 6.6.36 - Event ID 1 (Message 27964) Posted 13 Oct 2009 by Professor Ray Post: Event Type: Error Event Source: BOINC Event Category: None Event ID: 1 Date: 10/13/2009 Time: 9:03:37 AM User: N/A Computer: HAL9000 Description: The description for Event ID ( 1 ) in Source ( BOINC ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: BOINC error: 183, Another instance of BOINC is running. Only one instance of each: BOINCMNGR BOINCTRAY in msconfig. No entries in [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run or C:\Documents and Settings\All Users\Start Menu or C:\Documents and Settings\user_name\Start Menu\Programs\Startup
47) Message boards : Questions and problems : BOINC 6.6.20 released for Windows, Windows x64, Linux, Linux x64 and MacOS X (Message 24293) Posted 14 Apr 2009 by Professor Ray Post: Dunno if this is the right place to post this, but here goes: I've recently installed BOINC 6.6.20 and now mouseover of the BOINC_tray icon in the system tray causes the taskbar to "lose focus". My task-bar properties have always been configured to enable auto-hide. And so when mouse-over of the BOINC systray object occurs, the task bar immediately loses focus; the net result is auto-hide takes immediate effect. That occurs when IE 6.0.2900.5512 SP3 browser has focus. When the MS IE browser is minimized, the aforementioned characteristic doesn't manifest itself. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Quote: "What are we supposed to do with the pirate NOW?"
48) Message boards : BOINC Manager : manager not responding (Message 16277) Posted 1 Apr 2008 by Professor Ray Post: I'm going to look into this tomorrow, could be a problem that cropped up with this version of libcurl & perhaps also a new Microsoft patch level? also I find it odd that LHC@home is using a 301 redirect (permanent redirect) to their home page on this cgi URL, so perhaps it's sending "bad vibes" to libcurl or something. <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="http://lhcathome.cern.ch/">here</a>.</p> <hr> <address>Apache/2 Server at lhcathome.cern.ch Port 80</address> </body></html> Yeah, well, something jacked that crap up big time. I hope I just didn't compound the matter further by trying to finger out how to get the stinkin' upload out of the queue. It seems like when I "opened the door" EVERYTHING phoned home and downloaded EXCEPT the Lattice Project; its STILL in my in-box. That notwithstanding, I DID manage to eliminate LHC from phoning home OR receiving calls; its still in my "fave" list. Much to my chagrin that didn't help a whole lot: my backup ain't no good any more (and who knows WHAT I just did to the greater network). Perhaps the most helpful thing I can do at this time is just STOP trying to be helpful. 4/1/2008 12:38:33 AM\|\|Starting BOINC client version 6.1.12 for windows_intelx86 4/1/2008 12:38:33 AM\|\|log flags: task, file_xfer, sched_ops 4/1/2008 12:38:33 AM\|\|Libraries: libcurl/7.17.1 OpenSSL/0.9.8e zlib/1.2.3 4/1/2008 12:38:33 AM\|\|Data directory: C:\Program Files\BOINC 4/1/2008 12:38:33 AM\|\|Processor: 1 GenuineIntel x86 Family 6 Model 8 Stepping 6 1007MHz [x86 Family 6 Model 8 Stepping 6] 4/1/2008 12:38:33 AM\|\|Processor features: fpu tsc sse mmx 4/1/2008 12:38:33 AM\|\|OS: Microsoft Windows XP: Professional Edition, Service Pack 2, (05.01.2600.00) 4/1/2008 12:38:33 AM\|\|Memory: 767.53 MB physical, 982.56 MB virtual 4/1/2008 12:38:33 AM\|\|Disk: 8.79 GB total, 738.00 MB free 4/1/2008 12:38:33 AM\|\|Local time is UTC -4 hours 4/1/2008 12:38:34 AM\|rosetta@home\|URL: http://boinc.bakerlab.org/rosetta/; Computer ID: 609131; location: home; project prefs: home 4/1/2008 12:38:34 AM\|boincsimap\|URL: http://boinc.bio.wzw.tum.de/boincsimap/; Computer ID: 83721; location: home; project prefs: default 4/1/2008 12:38:34 AM\|Einstein@Home\|URL: http://einstein.phys.uwm.edu/; Computer ID: 1011976; location: home; project prefs: home 4/1/2008 12:38:34 AM\|lhcathome\|URL: http://lhcathome.cern.ch/lhcathome/; Computer ID: not assigned yet; location: (none); project prefs: default 4/1/2008 12:38:34 AM\|SETI@home\|URL: http://setiathome.berkeley.edu/; Computer ID: 3829768; location: home; project prefs: home 4/1/2008 12:38:34 AM\|Spinhenge@home\|URL: http://spin.fh-bielefeld.de/; Computer ID: 100366; location: home; project prefs: default 4/1/2008 12:38:34 AM\|uFluids\|URL: http://www.ufluids.net/; Computer ID: 57580; location: home; project prefs: default 4/1/2008 12:38:34 AM\|The Lattice Project\|URL: http://boinc.umiacs.umd.edu/; Computer ID: 10196; location: home; project prefs: default 4/1/2008 12:38:34 AM\|Leiden Classical\|URL: http://boinc.gorlaeus.net/; Computer ID: 39374; location: home; project prefs: default 4/1/2008 12:38:34 AM\|\|General prefs: from boincsimap (last modified 22-Feb-2008 09:47:23) 4/1/2008 12:38:34 AM\|\|Computer location: home 4/1/2008 12:38:34 AM\|\|General prefs: using separate prefs for home 4/1/2008 12:38:34 AM\|\|Reading preferences override file 4/1/2008 12:38:34 AM\|\|Preferences limit memory usage when active to 383.77MB 4/1/2008 12:38:34 AM\|\|Preferences limit memory usage when idle to 690.78MB 4/1/2008 12:38:34 AM\|\|Preferences limit disk usage to 0.53GB 4/1/2008 12:38:34 AM\|\|Suspending network activity - user request 4/1/2008 12:38:34 AM\|SETI@home\|Restarting task 29mr07ag.10896.72.10.7.97_0 using setiathome_enhanced version 527 4/1/2008 12:39:38 AM\|\|Resuming network activity 4/1/2008 12:39:38 AM\|The Lattice Project\|Started download of 238092300.16818310564771688_1 4/1/2008 12:39:38 AM\|The Lattice Project\|Started download of 238092300.16818310564771688.10_2 4/1/2008 12:39:38 AM\|lhcathome\|Fetching scheduler list 4/1/2008 12:39:40 AM\|The Lattice Project\|Temporarily failed download of 238092300.16818310564771688_1: HTTP error 4/1/2008 12:39:40 AM\|The Lattice Project\|Backing off 3 hr 5 min 51 sec on download of 238092300.16818310564771688_1 4/1/2008 12:39:40 AM\|The Lattice Project\|Temporarily failed download of 238092300.16818310564771688.10_2: HTTP error 4/1/2008 12:39:40 AM\|The Lattice Project\|Backing off 28 min 44 sec on download of 238092300.16818310564771688.10_2 4/1/2008 12:39:44 AM\|lhcathome\|Master file download succeeded 4/1/2008 12:39:49 AM\|lhcathome\|Sending scheduler request: Project initialization. Requesting 1 seconds of work, reporting 0 completed tasks 4/1/2008 12:39:54 AM\|lhcathome\|[error][error] No start tag in scheduler reply 4/1/2008 12:39:59 AM\|boincsimap\|Sending scheduler request: To fetch work. Requesting 18254 seconds of work, reporting 0 completed tasks 4/1/2008 12:40:04 AM\|boincsimap\|Scheduler request succeeded: got 2 new tasks 4/1/2008 12:40:04 AM\|boincsimap\|Message from server: Resent lost result 8040101.012264_1 4/1/2008 12:40:04 AM\|boincsimap\|Message from server: Resent lost result 8040101.012265_1 4/1/2008 12:40:06 AM\|boincsimap\|Started download of 8040101.012264 4/1/2008 12:40:06 AM\|boincsimap\|Started download of 8040101.012265 4/1/2008 12:40:16 AM\|boincsimap\|Sending scheduler request: To fetch work. Requesting 7688 seconds of work, reporting 0 completed tasks 4/1/2008 12:40:21 AM\|boincsimap\|Scheduler request succeeded: got 1 new tasks 4/1/2008 12:40:31 AM\|boincsimap\|Sending scheduler request: To fetch work. Requesting 1505 seconds of work, reporting 0 completed tasks 4/1/2008 12:40:36 AM\|boincsimap\|Scheduler request succeeded: got 1 new tasks 4/1/2008 12:40:39 AM\|boincsimap\|Finished download of 8040101.012265 4/1/2008 12:40:39 AM\|boincsimap\|Started download of 8040101.054834 4/1/2008 12:40:42 AM\|boincsimap\|Finished download of 8040101.012264 4/1/2008 12:40:42 AM\|boincsimap\|Started download of 8040101.054816 4/1/2008 12:40:58 AM\|lhcathome\|Sending scheduler request: Project initialization. Requesting 1 seconds of work, reporting 0 completed tasks 4/1/2008 12:41:03 AM\|lhcathome\|[error][error] No start tag in scheduler reply 4/1/2008 12:41:09 AM\|boincsimap\|Finished download of 8040101.054834 4/1/2008 12:41:18 AM\|boincsimap\|Finished download of 8040101.054816 4/1/2008 12:42:04 AM\|lhcathome\|Sending scheduler request: Project initialization. Requesting 1 seconds of work, reporting 0 completed tasks 4/1/2008 12:42:09 AM\|lhcathome\|[error][error] No start tag in scheduler reply 4/1/2008 12:42:18 AM\|\|Suspending network activity - user request 4/1/2008 1:39:19 AM\|Einstein@Home\|Restarting task h1_0852.25_S5R3__38_S5R3b_1 using einstein_S5R3 version 426 From now on: I resolve to be unhelpful.
49) Message boards : BOINC Manager : manager not responding (Message 16263) Posted 1 Apr 2008 by Professor Ray Post: Does this help? Unhandled Exception Detected... - Unhandled Exception Record - Reason: Access Violation (0xc0000005) at address 0x0035D79C read attempt to address 0x65772075 Engaging BOINC Windows Runtime Debugger... ******************** BOINC Windows Runtime Debugger Version 6.1.12 Dump Timestamp : 03/31/08 20:58:27 Debugger Engine : 4.0.5.0 Symbol Search Path: C:\Program Files\BOINC;C:\Program Files\BOINC;srvC:\DOCUME~1\Raygun\LOCALS~1\Temp\symbolshttp://msdl.microsoft.com/download/symbols;srvC:\DOCUME~1\Raygun\LOCALS~1\Temp\symbolshttp://boinc.berkeley.edu/symstore [bla bla bla bla - mod loads - bla bla bla] * Dump of the Process Statistics: * - I/O Operations Counters - Read: 14579, Write: 0, Other 1102 - I/O Transfers Counters - Read: 0, Write: 12715, Other 0 - Paged Pool Usage - QuotaPagedPoolUsage: 23984, QuotaPeakPagedPoolUsage: 26052 QuotaNonPagedPoolUsage: 35544, QuotaPeakNonPagedPoolUsage: 38352 - Virtual Memory Usage - VirtualSize: 30932992, PeakVirtualSize: 33034240 - Pagefile Usage - PagefileUsage: 5541888, PeakPagefileUsage: 5943296 - Working Set Size - WorkingSetSize: 8396800, PeakWorkingSetSize: 8765440, PageFaultCount: 5448 * Dump of thread ID 3132 (state: Waiting): * - Information - Status: Wait Reason: UserRequest, , Kernel Time: 9413536.000000, User Time: 8512240.000000, Wait Time: 1862366.000000 - Unhandled Exception Record - Reason: Access Violation (0xc0000005) at address 0x0035D79C read attempt to address 0x65772075 - Registers - eax=00f8a228 ebx=00c64580 ecx=00c64580 edx=003f0608 esi=65772065 edi=00000000 eip=0035d79c esp=0012fca0 ebp=0012fd6c cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 - Callstack - ChildEBP RetAddr Args to Child 0012fd6c 0040c72f 00467c28 00000000 3fd322b0 7813eab9 libcurl!curl_multi_remove_handle+0x0 0012fdf0 00431501 00000000 3fd322b0 00000000 003f4ff8 boinc!+0x0 0012fe64 0043189d 00471aec 00000001 0012ffc0 00000000 boinc!+0x0 0012fe90 78136d6c f64df3d9 003f34b0 003f3498 7c90e027 boinc!+0x0 0012fedc 781323ff 781c3bc8 00000094 00000005 00000001 MSVCR80!__msize+0x0 0012ff28 0043c27e 0043c2ed f643d6b9 00471aec 0044e4d0 MSVCR80!__unlock+0x0 0012ff64 0043c2ed 0043c300 0044d670 0044d63a 0044d670 boinc!+0x0 0012ff68 0043c300 0044d670 0044d63a 0044d670 f643d7ad boinc!+0x0 0043c2ed 00000000 74ffc359 52e80424 f7ffffff f7c01bd8 boinc!+0x0 * Dump of thread ID 3012 (state: Waiting): * - Information - Status: Wait Reason: EventPairLow, , Kernel Time: 0.000000, User Time: 0.000000, Wait Time: 1862306.000000 - Registers - eax=71a5d5af ebx=c0000000 ecx=7c913288 edx=ffffffff esi=00000000 edi=71a87558 eip=7c90eb94 esp=014bff7c ebp=014bffb4 cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 - Callstack - ChildEBP RetAddr Args to Child 014bff78 7c90e31b 71a5d609 00000164 014bffbc 014bffb0 ntdll!_KiFastSystemCallRet@0+0x0 FPO: [0,0,0] 014bff7c 71a5d609 00000164 014bffbc 014bffb0 014bffa4 ntdll!_ZwRemoveIoCompletion@20+0x0 FPO: [5,0,0] 014bffb4 7c80b683 71a5d8ec 0012f714 7c90ee18 00161708 mswsock!_SockAsyncThread@4+0x0 014bffec 00000000 71a5d5af 00161708 00000000 000000c8 kernel32!_BaseThreadStart@8+0x0 * Debug Message Dump * Foreground Window Data *** Window Name : Window Class : Window Process ID: 0 Window Thread ID : 0 Exiting...
50) Message boards : BOINC client : (temporarily) Solving the LHC/BOINC crashing problem. (Message 16257) Posted 1 Apr 2008 by Professor Ray Post: Right, what you said. However, the aforementioned "band-aides" address the specific situation of BOINC manager crashing at this time for users who have completed LHC work units stuck in the transfer queue due to a crashed LHC server. To fix the BOINC manager crash, network connectivity must be disabled thereby preventing BOINC access to the LHC server. To disable network connectivity one has to hack the client_state.xml file as indicated. Doing so in the GUI is futile, in that the BOINC manager crashes on start (as soon as upload to LHC of completed LHC WU's that are stuck in the transfer queue is initiated). In my case a download pending for another BOINC client, a different BOINC client began execution, and LHC attempted to upload a completed result, and then BOINC manager crashed. The temp fix for this problem is to disable network communication. This however shuts the door to communication for ALL projects. To resolve THAT issue, hacking out completed LHC WU's allows users who have completed BOINC client WU's OTHER than LHC to upload that are approaching deadline (or if LHC WU's awaiting upload are passed deadline), OR have no other WU's to crunch in the mean time. If one is a dedicated LHC client, then they're sort of stuck for the time being.
51) Message boards : BOINC Manager : manager not responding (Message 16252) Posted 31 Mar 2008 by Professor Ray Post: Plain vanilla 5.10.45
52) Message boards : BOINC client : (temporarily) Solving the LHC/BOINC crashing problem. (Message 16251) Posted 31 Mar 2008 by Professor Ray Post: The above solution will hack out LHC WU's for transfer. To disable network connectivity with WU's pending for transfer, find the below string at the bottom of client_state.xml (open with Notepad): <user_network_request>1</user_network_request> Replace the numeral one (or whatever) in the above string with a numeral three. Save the file. Then restart BOINC. Do this and the aforementioned procedure by Ageless after BOINC has been terminated. Ensure that no BOINC client is running either (for me Rosetta would load and begin execution and then BOINC manager would crash trying to upload LHC WU). FWIW, do Ageless suggested "hack" if and ONLY if you have WU's for other projects that MUST be uploaded for credit (or if you have no other WU's to crunch). Thanks Ageless. Hope these band-aides help somebody.
53) Message boards : BOINC Manager : manager not responding (Message 16249) Posted 31 Mar 2008 by Professor Ray Post: Unhandled Exception Detected... - Unhandled Exception Record - Reason: Access Violation (0xc0000005) at address 0x0035D9FC read attempt to address 0x65772075 Engaging BOINC Windows Runtime Debugger... ******************** BOINC Windows Runtime Debugger Version 5.10.45 Dump Timestamp : 03/31/08 18:21:19 Debugger Engine : 4.0.5.0 Symbol Search Path: C:\Program Files\BOINC;C:\Program Files\BOINC;srvC:\DOCUME~1\Raygun\LOCALS~1\Temp\symbolshttp://msdl.microsoft.com/download/symbols;srvC:\DOCUME~1\Raygun\LOCALS~1\Temp\symbolshttp://boinc.berkeley.edu/symstore ///////////////////////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Then a bunch of mod-loads follow (none of which appear to be issues \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ///////////////////////////////////////////////////// * Dump of the Process Statistics: * - I/O Operations Counters - Read: 346, Write: 0, Other 755 - I/O Transfers Counters - Read: 0, Write: 14483, Other 0 - Paged Pool Usage - QuotaPagedPoolUsage: 21504, QuotaPeakPagedPoolUsage: 23616 QuotaNonPagedPoolUsage: 34880, QuotaPeakNonPagedPoolUsage: 38016 - Virtual Memory Usage - VirtualSize: 28655616, PeakVirtualSize: 30306304 - Pagefile Usage - PagefileUsage: 5455872, PeakPagefileUsage: 5861376 - Working Set Size - WorkingSetSize: 8048640, PeakWorkingSetSize: 8445952, PageFaultCount: 4303 * Dump of the thread (454): * - Information - Status: Ready, Kernel Time: 0.000000, User Time: 0.000000, Wait Time: 0.000000 - Registers - eax=004603d0 ebx=0012f8c4 ecx=00000061 edx=00000000 esi=7813e457 edi=7813ed1f eip=7c90eb94 esp=0012f1dc ebp=0012f1ec cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000212 - Callstack - ChildEBP RetAddr Args to Child 0012f1d8 7c90e57c 7c80a027 00000078 00000000 0012f89c ntdll!_KiFastSystemCallRet@0+0x0 FPO: [0,0,0] 0012f1dc 7c80a027 00000078 00000000 0012f89c 00445648 ntdll!_NtSetEvent@8+0x0 FPO: [2,0,0] 0012f1ec 00445648 00000078 0012f780 004455d0 7c884780 kernel32!_SetEvent@4+0x0 0012f200 7c863016 0012f8c4 00000000 00000000 00000000 boinc!boinc_catch_signal+0x0 (c:srcboincsvnbranchesboinc_core_release_5_10libdiagnostics_win.c:2142) 0012f89c 7c8436da 0012f8c4 7c839b09 0012f8cc 00000000 kernel32!_UnhandledExceptionFilter@4+0x0 (c:srcboincsvnbranchesboinc_core_release_5_10libdiagnostics_win.c:2142) 0012f8a4 7c839b09 0012f8cc 00000000 0012f8cc 00000000 kernel32!_BaseProcessStart@4+0x0 (c:srcboincsvnbranchesboinc_core_release_5_10libdiagnostics_win.c:2142) FPO: [0,0,0] 0012f8cc 7c9037bf 0012f9b8 0012ffe0 0012f9d4 0012f98c kernel32!__except_handler3+0x0 (c:srcboincsvnbranchesboinc_core_release_5_10libdiagnostics_win.c:2142) FPO: [3,0,7] 0012f8f0 7c90378b 0012f9b8 0012ffe0 0012f9d4 0012f98c ntdll!ExecuteHandler2@20+0x0 (c:srcboincsvnbranchesboinc_core_release_5_10libdiagnostics_win.c:2142) 0012f9a0 7c90eafa 00000000 0012f9d4 0012f9b8 0012f9d4 ntdll!ExecuteHandler@20+0x0 (c:srcboincsvnbranchesboinc_core_release_5_10libdiagnostics_win.c:2142) 0012f9a4 00000000 0012f9d4 0012f9b8 0012f9d4 c0000005 ntdll!_KiUserExceptionDispatcher@8+0x0 (c:srcboincsvnbranchesboinc_core_release_5_10libdiagnostics_win.c:2142) FPO: [2,0,0] * Dump of the thread (7e4): * - Information - Status: Waiting, Kernel Time: 0.000000, User Time: 0.000000, Wait Time: 0.000000 - Registers - eax=71a5d5af ebx=c0000000 ecx=7c913288 edx=ffffffff esi=00000000 edi=71a87558 eip=7c90eb94 esp=014aff7c ebp=014affb4 cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 - Callstack - ChildEBP RetAddr Args to Child 014aff78 7c90e31b 71a5d609 0000010c 014affbc 014affb0 ntdll!_KiFastSystemCallRet@0+0x0 FPO: [0,0,0] 014aff7c 71a5d609 0000010c 014affbc 014affb0 014affa4 ntdll!_ZwRemoveIoCompletion@20+0x0 FPO: [5,0,0] 014affb4 7c80b683 71a5d8ec 0012f700 7c90ee18 0015c378 mswsock!_SockAsyncThread@4+0x0 014affec 00000000 71a5d5af 0015c378 00000000 000000c8 kernel32!_BaseThreadStart@8+0x0 * Debug Message Dump * Foreground Window Data *** Window Name : Window Class : Window Process ID: 0 Window Thread ID : 0 Exiting...
54) Message boards : BOINC Manager : Unable to connect to BOINC Client (Message 16244) Posted 31 Mar 2008 by Professor Ray Post: Yep, that'll work. But now one has to decide how long they want to wait for the LHC server to back on-line to upload outstanding WU's to get credit for processing time. In the meantime no new WU's can be received, and no other WU's can be uploaded either. Advice: check your project WU deadlines and adjudicate accordingly. There is a scheme to get rid of problem child LHC WU's stuck in the upload transfer queue.
55) Message boards : BOINC client : segmentation violation (Message 16243) Posted 31 Mar 2008 by Professor Ray Post: Would suspending the LHC project prevent attempts by LHC to communicate to the server if network connection was reestablished in the activity drop-down menu? No. As long as there's work to upload, suspending LHC or setting it to No new tasks won't work. The upload will try to continue, contact the scheduler, crash BOINC. Suspending network activity prevents everything from uploading/downloading/reporting. The problem is that we don't know for how long LHC is down. We don't even know why it's down. Could be they return in an hour, a day, a week. So teh suspending of network activity is only of temporary use, especially if you're connected to multiple projects. BUMMMERS. Well, my earliest deadline is 08 Apr 3 0539. The worst part is I've a Lattice Project WU download transfer pending. I'll sacrifice obtaining WU's as opposed to sacrificing credit for WU completed. Thanks for your feedback.
56) Message boards : BOINC client : segmentation violation (Message 16240) Posted 31 Mar 2008 by Professor Ray Post: its a completely different issue than what started the thread, but now there's this new problem. That problem is something the developers are aware of and they can't fix it in the present 5.10 range. It'll have to wait for BOINC 6. Sorry. edit: it's not confined to LHC only. Multiple projects have this problem with the application restarting. Roger, copy that. But Duuuuuuuude, why am I ONLY having that problem with LHC? I concede that I've heard what you say about the DLL init error problem, but I DON'T see the problem with any other BOINC client (EVER). They run flawlessly. Quite frankly, the problem strikes as a priority issue. It seems to behave akin to setting Spybot's scan priority to high (I lose control of the system for inordinate amounts of time).
57) Message boards : BOINC client : segmentation violation (Message 16236) Posted 31 Mar 2008 by Professor Ray Post: yup, worked for me, too. so, what now? get rid of the wu? Why not wait until the server comes back up. The LHC web-site displays the "down for maintenance" page. I've got 23.5 hrs into the WU I'm trying to upload. No way do I want to lose credit for that. Would suspending the LHC project prevent attempts by LHC to communicate to the server if network connection was reestablished in the activity drop-down menu?
58) Message boards : BOINC client : segmentation violation (Message 16234) Posted 31 Mar 2008 by Professor Ray Post: I'm in contact with one of the developers at this moment... Well, that's good that you're talking to "developers". Perhaps you can tell 'em that there IS a general issue with the BOINC manager specific to the LHC client. It causes repeated DLL init errors on my machine. There is a thread on the LHC forum regard that issue that I initiated some time ago, and no resolution yet (despite having migrated BOINC to the most current one). It appears that LHC WU are successfully completing in any case. Its just that using my machine while LHC is running is virtually impossible. What's most annoying about this problem is that it causes my machine to hang for as long as two minutes. Even so the mouse cursor moves, it remains frozen with the "hand pointer" icon (nothing else is accessible on the desktop, although sometimes I can access the auto-hide taskbar). The time period between "freezes" is variable, as is the time period of "freezing". The system invariably resumes whatever it was doing when it "wakes up". Sometimes, but not always there'll be an "DLL init" error message in the BOINC messages pane. There is NEVER a stderr.txt file in the LHC slot folder (and stderrdae.txt is empty also). No other BOINC client gives me this issue. 3/31/2008 6:29:09 PM\|rosetta@home\|URL: http://boinc.bakerlab.org/rosetta/; Computer ID: 609131; location: home; project prefs: home 3/31/2008 6:29:09 PM\|boincsimap\|URL: http://boinc.bio.wzw.tum.de/boincsimap/; Computer ID: 83721; location: home; project prefs: default 3/31/2008 6:29:09 PM\|Einstein@Home\|URL: http://einstein.phys.uwm.edu/; Computer ID: 1011976; location: home; project prefs: home 3/31/2008 6:29:09 PM\|lhcathome\|URL: http://lhcathome.cern.ch/lhcathome/; Computer ID: 9636853; location: home; project prefs: home 3/31/2008 6:29:09 PM\|SETI@home\|URL: http://setiathome.berkeley.edu/; Computer ID: 3829768; location: home; project prefs: home 3/31/2008 6:29:09 PM\|Spinhenge@home\|URL: http://spin.fh-bielefeld.de/; Computer ID: 100366; location: home; project prefs: default 3/31/2008 6:29:09 PM\|uFluids\|URL: http://www.ufluids.net/; Computer ID: 57580; location: home; project prefs: default 3/31/2008 6:29:09 PM\|The Lattice Project\|URL: http://boinc.umiacs.umd.edu/; Computer ID: 10196; location: home; project prefs: default 3/31/2008 6:29:09 PM\|Leiden Classical\|URL: http://boinc.gorlaeus.net/; Computer ID: 39374; location: home; project prefs: default So dunno what to tell you, and its a completely different issue than what started the thread, but now there's this new problem.
59) Message boards : BOINC client : segmentation violation (Message 16227) Posted 31 Mar 2008 by Professor Ray Post: Yeah, that worked for me too.

Previous 20

Copyright © 2023 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.