There's no generic crash log: each one is different, and depends entirely on what generated it and how; unless you're the one who wrote the code, the best you can do is guess.
That said, guessing can get you a fair way forward, especially when methods are named sanely. Take
this example, for instance -- the stack trace (in Java, this is always latest-first) tells what happened in almost plain English. I'll admit to have cheated a bit and read the Logistics Pipes source to find out the ultimate source of the crash, but everything leading up to it was sufficiently straightforward.
The worst crashes, from this point of view, are the ones that happen wholly inside Minecraft's code due to some data that was mis-initialized or just plain broken. There's usually no indication of what got Minecraft in that broken state to begin with, so you end up with
threads like this. In those cases, your only defense is to find someone who's seen it before (and be fairly certain it's the same crash!); sometimes you can take educated guesses, but it doesn't get much better than "it could possibly be X".
Well, okay, there is one other thing -- if a lot of people use OpenEye, and get the same crash on many different mod packs, you can eventually get enough statistical data to be able to point a finger at a specific mod (by eliminating all the other mods that were only present in
some of the reports of the same crash). I've yet to see that actually work, though -- most mod packs are too similar to be able to exclude enough mods, and most crashes are of the simpler variety as in my second paragraph. Nonetheless, it's technically possible.
As to your more specific questions:
for example, where do you start if you want to figure out a crash through a crashlog?
Typically, start with the stack trace. That tells you what the exception was, where it happened, and what called what to get to that point.
what do certain words or phrases mean? what is the crashlog trying to tell you?
Uh, how much programming do you know? I'll try to be very basic:
- Java programs are composed of functions, which contain specific bits of behaviour, and may call other functions.
- As functions call into other functions, the callers get put into a call stack, so the Java virtual machine knows where to return when the callees finish their operation.
- As part of their behaviour, functions operate on data, but some operations may raise errors (e.g. because the data doesn't exist).
- Functions can catch the raised errors, but if they don't, the JVM tries to find error handlers higher in the call stack ("maybe the one who called you knows how to deal with this").
- If nobody handles it all the way up to the Minecraft launcher, then the game is halted, a crash log is generated, and you have to launch the game again.
Important key phrases to look out for:
- [whatever]Exception (e.g. java.util.ConcurrentModificationException) -- what went wrong
- Stacktrace -- how we got there
Occasionally, there may be useful information in the entity dump, and there's always the possibility of spotting a couple of mods that really don't work well together in the mod list, but for the general case, this is all you have that's likely to be useful. This is probably why that's the first section of the crash report.
