Ticket #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 |
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
Change History
comment:2 Changed 3 years ago by Philip
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 Changed 3 years ago by Ikkerens
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?
comment:4 Changed 3 years ago by Philip
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 Changed 3 years ago by Ikkerens
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 Changed 3 years ago by Philip
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.)
comment:7 Changed 3 years ago by Ikkerens
Used the original pyrogenesis, see crashlog_original.dmp and crashlog_original.txt
comment:8 Changed 3 years ago by Philip
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 Changed 3 years ago by Philip
(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 Changed 3 years ago by Ikkerens
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:11 Changed 3 years ago by Philip
Have you tried recompiling in debug mode?
comment:12 Changed 3 years ago by Ikkerens
Jup, still no luck.
comment:13 Changed 3 years ago by jan
- Cc jan 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 Changed 3 years ago by Philip
comment:15 Changed 3 years ago by jan
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 Changed 3 years ago by Philip
The autobuilder is VC2008 SP1 - maybe the PDB files are too new VC2005 to load?
comment:17 Changed 3 years ago by jan
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:18 Changed 3 years ago by anonymous
- Milestone Unclassified deleted
Milestone Unclassified deleted
comment:20 Changed 2 years ago by historic_bruno
- Status changed from new to closed
- Resolution set to invalid
- Summary changed from Access violation writing 0x0B69CA40 to [NEEDS INFO] Access violation writing 0x0B69CA40
Please provide more info for this ticket to be reopened.
comment:21 Changed 2 years ago by k776
- Status changed from closed to reopened
- Resolution invalid deleted
comment:22 Changed 2 years ago by k776
- Status changed from reopened to closed
- Resolution set to worksforme

Forgot to say, can't find crashlog.dmp and crashlog.txt on my whole comp. (C:\ search) Do have this, the log of vs2008: