I was working with another brand of CPU tonight when the program crashed. On this chip I get a hard fault and the debugger stops in the HF handler so immediately I know there's a problem, I could look at the stack frame but I'm lazy and decide to just single-step while looking at various structures and variables until it crashes, a few minutes later I find a pointer to one of the UARTs that's being used before being set.
On the Arduino that would have taken ages to find, staring at a non-working chip then eventually realising it wasn't the last code change and seeding the program with Serial.print()s.
Lately I've been using Visual Micro a lot for Arduino, that's pretty damn good and a 1000% better than the IDE, it even has a debugger (that I confess I haven't been using much), but to have a real debugger integrated into the IDE is fantastic.
Code Blocks (free and full) has an Arduino add-on or version but I've not used it mainly because I've not needed it. The IDE is enough for the little things I do.
There's a limit to what the IDE can do. The Atmega328P doesn't really crash, it is just doing something different to what you want it to do.
Although I was reading about the 6502 chips. Apparently some non-implemented hardware instructions could actually cause the processor to lock up inside one instruction, basically because the chip state machine did not get into a state where it moved onto the next instruction (incrementing the state counter).
To have something like what you describe, you would have to have protected memory, etc. After all, if you exceed an array bounds and start writing all over memory, how is the hardware to know you didn't really want to do that?
In this example the pointer was still raw RAM, and as I fill the area between the heap the stack with 0xAA the pointer had the value 0xAAAAAAAA, that was easily trapped by the CPU hardware as there's no way it's a valid RAM address.
But you're right about array bounds, that would not be trapped by anything and all bets would be off. I partially guard against such things by having guard bytes at the start and end of every structure but there isn't a lot you can do about a rogue pointer that's still pointing into a valid address space.
The Atmega328P doesn't really crash, it is just doing something different to what you want it to do.
That's the point about having a debugger, when the lights go out you pause the program and see exactly what code it's executing rather than scratching your head and willing it to work.
The AVR studio 4.0 that I use is also a fantastic tool.
also there's a good AVR plugin out there for AVR's too that gets hooked to good old eclipse IDE.
I've been using VS2008 with the Visual Micro plugin and that's very good. Just downloaded AS6.1 though and will start using that I think (also with VM).
I actually prefer Eclipse and there is Janjte's plugin, I might give that a try but there's no debugger AFAIK.