Quasar
Moderator
Posts: 4615
Registered: 08-00 |
Ladna said:
It's practically impossible to figure anything out from these crash logs.
Oh really?
Graf Zahl said:
I very much doubt that many of the people experiencing such a crash would even be able to get a debugger running. But I agree that crash logs without a stack trace are useless (which is why ZDoom adds one...)
Without a stack trace? That's precisely what all that hex is. Well, it's a stack DUMP anyways. How do you get a "trace" out of a program compiled in release mode? It's not like there's debug information to use to get function names.
Anyway these are useful so long as they tell me what version of the EXE they're using and are accurate in giving me that information.
All I have to do is put the addresses you see at the crash location and in the stack dump into IDA Pro and it'll take me right to where Eternity crashed. I can then look up the name of the function I am inside in the .map file for that build. So, kindly don't tell my users that this isn't helpful when it actually is extremely useful.
Watch my system of reasoning as it played out in IRC:
code:
<Quasar`> 8B 44 8D 08 <- look familiar?
<Quasar`> Bytes at CS:EIP:
<Quasar`> 8b 44 8d 08
...
<Quasar`> this-> ECX: 0xffffa7ed
<Quasar`> is the problem
<Quasar`> that's texturecol.
<Quasar`> and it's negative.
<Quasar`> that shouldn't ever happen.
<CSG> ECX STRIKES AGIN
<CSG> :(
<Quasar`> column = (column_t *)((byte *)patch +
<Quasar`> SwapLong(patch->columnofs[texturecolumn]));
<Quasar`> I believe this is the line of code it crashed on.
<Quasar`> the [ebp+ecx*4+8] is patch->columnofs[texturecolumn]
<Quasar`> columnofs == offset 8 into patch_t I believe.
<CSG> and how would that crash?
<CSG> :P
<Quasar`> because texturecolumn is negative.
<Quasar`> 0xffffa7ed
<Quasar`> that is -22547
All of this information derived from his post, in concert with the .idb and .map.
The problem is, people aren't recording enough info about what they were doing when they got the crash.
CSonicGo can't figure out whether or not he might have been running a particular infamously bad mod at the time (his crash is inside V_DrawPatchInt, which, if it had a bleeding obvious bug, Eternity would crash here all the time - I suspect garbage in, garbage out).
Mordeth's crash is not in 3.40.11-win32p, because the location 004791FF is in the middle of an instruction in that version of the executable, and the bytes at EIP are nothing alike whatsoever. Also, Mordeth's crash strongly resembles the 3.40.10 PolyObject save loading crash which was already fixed (by 3.40.11).
Last edited by Quasar on 06-15-11 at 14:23
|
06-13-11 19:35 
