14 more days of crunching and no update but stackfile errors
16 Jul 2005 21:13:06 UTC
Topic 189555
(moderation:
Had some previous errors work themselves out (or you guys kindly fixed them - don't know) but again the Einstein pgm is developing errors (stackfile something or other, I think) and I'm getting no new updates on Richard Mangum account. Wish I knew more about all this but just enjoy running the programs on my otherwise mostly idle computer.
14 more days of crunching and no update but stackfile errors
)
Can you post a stackfile error on here? If all's well, you should be able to find them in Dr Watson.
Start->Run, type msinfo32 and hit Enter.
The Tools->Windows->Dr Watson.
Post the last one's entry here.
Also please check your Event Viewer.
Start->Control Panel->Administrative Tools->Event Viewer.
Check the systems log and application log at any time you had a stack error.
Post the event information here by clicking on the icon with the two leaves of paper, then posting the whole info here. Please uses spaces.
Might want to up date your
)
Might want to up date your drivers
***UNHANDLED EXCEPTION**** Reason: '(reason)'
From BOINCWiki
Table of contents [showhide]
1 General
2 Version Information
3 Example Log(s)
3.1 UNHANDLED EXCEPTION - Access Violation - Write Attempt
3.2 UNHANDLED EXCEPTION - Access Violation - Read Attempt
4 Other Related Messages
[edit]General
Message Type: Error Message
Actually, we geeks call this a "Fatal Error", this means that the whole world comes to an end …
This error can be the result of a programming error in the code for:
The BOINC Client Software
The Science Applications
Any other program running on the computer
The Operating System
On the other hand, it could be because it is Tuesday.
Seriously, this is a serious error within the running application program and it is one that computer hardware and Operating System manage when the program attempts to do something that is a no-no.
[edit]Version Information
None.
[edit]Example Log(s)
[edit]UNHANDLED EXCEPTION - Access Violation - Write Attempt
***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x00416611 write attempt to address 0x00A28FA0
1: 02/14/05 09:05:50
1: c:\boincsrc\main\boinc_public\client\file_xfer.c(127) +22 bytes (FILE_XFER::parse_upload_response)
1: c:\boincsrc\main\boinc_public\client\client_state.c(453) +17 bytes (CLIENT_STATE::do_something)
1: c:\boincsrc\main\boinc_public\client\client_state.c(453) +17 bytes (CLIENT_STATE::do_something)
1: c:\boincsrc\main\boinc_public\client\main.c(319) +16 bytes (boinc_main_loop)
1: c:\boincsrc\main\boinc_public\client\main.c(403) +5 bytes (main)
1: f:\vs70builds\3077\vc\crtbld\crt\src\crtexe.c(398) +14 bytes (mainCRTStartup)
Line-By-Line Explanation
***UNHANDLED EXCEPTION**** Reason: '(reason)'
There was an exception, in this case, an attempt to write into a memory location beyond those actually allocated to the program.
The remaining lines are data of interest to the Developers so that they can isolate the problem within the program that failed.
[edit]UNHANDLED EXCEPTION - Access Violation - Read Attempt
Many causes of 0xc0000005 errors are due to a device driver, and especially graphics drivers in the case of SETI@Home. But those usually occur not in the users program but in the driver. You can see by the instruction address thats not the case here.
This error occurs in BOINC Manager, as you can see by the messages in stderrgui.txt. And the offending instruction and program/function is shown in the following message line. If you look at the executing BOINC Manager with a debugger, you'll see that the instruction address where the error occurred is indeed CMainFrame::SaveState. Given that, I tend to believe the error really did occur there, and its "mistakenly" writing to location 00000000.
(Aside - when the error points to an instruction in a driver or system DLL, the error usually occurred earlier in the processing and what you "see" in the messages has very little to to with the actual problem)
The source code shows that function is storing the GUI state info to the registry. It first gets a pointer to the internal GUI state tables, then loops through writing registry keys. Rom answered a while back in the thread that the function that returns the state info pointer didn't. In this case it returned NULL which is quite unexpected. Hence the "00000000" thats being written to. Its supposed to be a valid pointer.
Two changes were made to the function, unfortunately "in the next release". First is the current BOINC Manager saves the state every minute. One of the changes is to save the state information less often.
The second change is to check the pointer, and not save the state if its NULL. The error is intermittent, so it will get saved. Both are quick fixes which addresses the abend but not why it got a zero pointer in the first place.
***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x00401560 read attempt to address 0x00000000
1: 03/28/05 08:31:01
1: c:\boincsrc\main\boinc_public\clientgui\boincbaseview.cpp(137) +0 bytes (CBOINCBaseView::FireOnChar)
Line-By-Line Explanation
***UNHANDLED EXCEPTION**** Reason: '(reason)'
There was an exception, in this case, an attempt to read from a memory location beyond those actually allocated to the program.
The remaining lines are data of interest to the Developers so that they can isolate the problem within the program that failed.
Link to Unofficial Wiki for BOINC, by Paul and Friends
You thought a link was too
)
You thought a link was too noisy here, Blank? ;)
Further questions: Did you
)
Further questions: Did you compile the Boinc client yourself?
Or did you get the Einstein Symbol file as well? That's a pdb file.
If you didn't, try to reset the Einstein project.
Go to Projects, click on the Einstein@Home project
Press Reset project on the left.
Press Yes.
All this with your internet connection on.
Then see if it downloads all the files, or that it may stall on a certain file or not.