#469 closed defect (worksforme)
[NEEDS INFO] Access violation writing 0x0B69CA40
Reported by: | Ikkerens | Owned by: | |
---|---|---|---|
Priority: | Release Blocker | Milestone: | Alpha 3 |
Component: | Core engine | Keywords: | |
Cc: | Jan Wassenberg | Patch: |
Description
Much to our regret we must report the program has encountered an error.
Please let us know at http://trac.wildfiregames.com/ and attach the crashlog.txt and crashlog.dmp files.
Details: unhandled exception (Access violation writing 0x0B69CA40)
Location: unknown:0 (?)
Call stack:
0B69CA40
errno = 0 (?) OS error = 487 (Poging om toegang te verkrijgen tot ongeldig adres.) Above translated: Attempt to access a invalid adress.
When debugging in vs2008, stops at this part (green arrow pointing at second line): File: unifont.cpp
// [cumulative for 12: 20ms] (*f->glyphs_id)[(wchar_t)Codepoint] = (unsigned short)i; (*f->glyphs_size)[(wchar_t)Codepoint] = Advance;
Attachments (6)
Change History (29)
comment:1 by , 14 years ago
by , 14 years ago
Attachment: | crashlog.dmp added |
---|
by , 14 years ago
Attachment: | crashlog.txt added |
---|
by , 14 years ago
Attachment: | system_info.txt added |
---|
comment:2 by , 14 years ago
I think OpenLogsFolder.bat
(in the SVN checkout) opens the folder which may have the crashlog files in it, though I'm not certain about that.
At what time did this error occur? (e.g. did it display the main menu or not?)
Is this a repeatable problem? If so, can you copy the output from the debugger's Call Stack and Locals windows at the point where it crashes?
comment:3 by , 14 years ago
Already found the files, went trough some forum browsing. The error occurs as soon as the primariy window is given the 0 A.D. title. (See screenshot I uploaded)
I don't understand your last question, its a repeatable problem (game won't even start up), but where can I find the debugger's Call Stack?
by , 14 years ago
Attachment: | timeoferror.jpg added |
---|
comment:4 by , 14 years ago
If you do "Break" and get into the VS2008 debugger, then that should have a Call Stack window somewhere (or use the Debug menu -> Windows -> Call Stack to show it).
It looks like you're using a version you've compiled yourself (is that correct?). It also looks like it's a Release build rather than Debug build, which makes these problems harder to debug - if you change it back to the default build configuration (Debug), does it work and/or give more error information?
Also, if you revert to the standard pyrogenesis.exe/.pdb files from SVN (via some TortoiseSVN "revert" option etc), and run those without recompiling, does it work?
comment:5 by , 14 years ago
Already tried the original pyrogenesis.exe, giving the same error. And yes, I have compiled my own version, at least tried to, but it gave no errors. Il recompile as debug, and show you what il get.
comment:6 by , 14 years ago
If you can't get the debug build to work, then it'd be helpful to upload crashlog.dmp after running (and crashing) the original pyrogenesis.exe. (The .dmp files work best when they come from a standard version of the .exe where we have all the matching debug symbol files.)
by , 14 years ago
Attachment: | crashlog_original.dmp added |
---|
by , 14 years ago
Attachment: | crashlog_original.txt added |
---|
comment:7 by , 14 years ago
Used the original pyrogenesis, see crashlog_original.dmp and crashlog_original.txt
comment:8 by , 14 years ago
Hmm, unfortunately that doesn't help much, it just says
> pyrogenesis.exe!PerformErrorReaction(ErrorReaction er=ER_BREAK, unsigned int flags=0x00000000, unsigned char * suppress=0x00000000) Line 426 C++ pyrogenesis.exe!debug_DisplayError(const wchar_t * description=0x0024cfd8, unsigned int flags=0x00000000, void * context=0x0024dd0c, const wchar_t * lastFuncToSkip=0x00f8bf4c, const wchar_t * pathname=0x0024cde4, int line=0x00000000, const char * func=0x0024cdcc, unsigned char * suppress=0x00000000) Line 494 + 0xd bytes C++ pyrogenesis.exe!wseh_ExceptionFilter(_EXCEPTION_POINTERS * ep=0x0024dbcc) Line 289 + 0x65 bytes C++ pyrogenesis.exe!CallStartupWithinTryBlock() Line 363 + 0x9 bytes C++ pyrogenesis.exe!_except_handler4(_EXCEPTION_RECORD * ExceptionRecord=0x7ffde000, _EXCEPTION_REGISTRATION_RECORD * EstablisherFrame=0x0024fd40, _CONTEXT * ContextRecord=0x7760e4b6, void * DispatcherContext=0x7ffde000) + 0x20 bytes C kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
which I suppose makes sense because it'll unwind the stack before reporting access violations. So that's not going to work.
Only potentially useful thing is
- ContextRecord 0x0024dd0c {ContextFlags=0x0001003f Dr0=0x00000000 Dr1=0x00000000 ...} _CONTEXT * ContextFlags 0x0001003f unsigned long Dr0 0x00000000 unsigned long Dr1 0x00000000 unsigned long Dr2 0x00000000 unsigned long Dr3 0x00000000 unsigned long Dr6 0x00000000 unsigned long Dr7 0x00000000 unsigned long + FloatSave {ControlWord=0xffff027f StatusWord=0xffff0122 TagWord=0xffffffff ...} _FLOATING_SAVE_AREA SegGs 0x00000000 unsigned long SegFs 0x0000003b unsigned long SegEs 0x00000023 unsigned long SegDs 0x00000023 unsigned long Edi 0x0b0d1600 unsigned long Esi 0x0b22ca40 unsigned long Ebx 0x0a71d380 unsigned long Edx 0x00000004 unsigned long Ecx 0x0b086b80 unsigned long Eax 0x0b01c078 unsigned long Ebp 0x690d76f0 unsigned long Eip 0x0b22ca40 unsigned long SegCs 0x0000001b unsigned long EFlags 0x00010202 unsigned long Esp 0x0024dfd8 unsigned long SegSs 0x00000023 unsigned long
Probably would be best if you can run in debug mode :-)
comment:9 by , 14 years ago
(Oh, actually the stack trace thing doesn't make sense like that, I'm just forgetting how SEH works. Not sure what's up with it, then.)
comment:10 by , 14 years ago
Ok, another change: If I use vista to run the game in XP SP2 compitablity mode (using fancywater = false) The game stucks at 3 mb ram in the process list doing nothing. Waited for like 15 minutes.
comment:13 by , 14 years ago
Cc: | added |
---|
hm, unfortunately it's almost impossible to diagnose this with the current information.
1) when debugging in VS: what is the value of Codepoint when you hit the error? BTW, you can disable the error dialog (in the hope that the VS debugger is more successful at breaking to the locus of the error) by commenting out the
__try
and__except
near the end of source\lib\sysdep\os\win\wseh.cpp .
2) the PDB in SVN (revision 7347, as indicated in the crashlog) does not match the crashlog_original.dmp. Can you please upload the exact EXE and PDB that generated the .dmp?
comment:14 by , 14 years ago
comment:15 by , 14 years ago
My mistake, thanks for pointing that out. However, even after reverting to 7348 and copying the resulting PDB to d:\0ad\svn\binaries\system (the path referenced in the dmp), VC2005 is reporting missing or mismatched symbols for both .dmp files. What are you doing differently?
comment:16 by , 14 years ago
The autobuilder is VC2008 SP1 - maybe the PDB files are too new VC2005 to load?
comment:17 by , 14 years ago
Yep, looks like that was the cause, they match with VC2008SP1.
Since the call stack doesn't show anything before the exception filter, it looks like remote debugging isn't going to work. The two alternatives are commenting out the __try
and __except
at the bottom of wseh.cpp, recompiling, and uploading the EXE, PDB and DMP, or continuing in your local debugger. The f->glyphs_size
line looks promising; if you hover with the mouse over the "Codepoint" text, what value does it show?
comment:19 by , 14 years ago
Milestone: | → Backlog |
---|
comment:20 by , 13 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Summary: | Access violation writing 0x0B69CA40 → [NEEDS INFO] Access violation writing 0x0B69CA40 |
Please provide more info for this ticket to be reopened.
comment:21 by , 13 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
comment:22 by , 13 years ago
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
comment:23 by , 13 years ago
Milestone: | Backlog → Alpha 3 |
---|
Forgot to say, can't find crashlog.dmp and crashlog.txt on my whole comp. (C:\ search) Do have this, the log of vs2008: