|
Post by Frisbone on Feb 9, 2014 16:34:25 GMT -5
I've been trying to figure out why my code simply exits for no explanation and had been assuming that some critical error is being generated and not caught (like dereferencing bad pointer, divide by zero, etc) - but some testing today revealed that:
- Intentionally dereferencing null pointer indeed does cause a seg fault - divide by zero causes floating point exception - screwing up the stack in a function call (obliterating it really) - does nothing bad
It used to be that the program counter was stored on the stack along with local variables and parameters - is this no longer the case? How can I obliterate the stack (well before the beginning pointer, well after - yet have the program terminate normally.
I'm very confused. The very types of errors that would have cause behavior like I'm seeing can't be causing it - not sure how to explain it. Any ideas?
|
|
|
Post by Frisbone on Feb 9, 2014 20:10:16 GMT -5
Well, I put a signal handler in and determined that a SIGSEGV signal is being triggered - its just not being handled as I'm expecting. Not sure why. Now I just need to get a coredump going somehow.
|
|
|
Post by Frisbone on Feb 9, 2014 21:21:12 GMT -5
Eh, got gdb going and found the bug - stupid overflow problem. After that found a problem where the interrupts would stop coming (remembering that you need to sucessfully poll for data to clear the flag and allow another interrupt to occur). It seems that the output PWM cycle was causing this to occur because if I leave everything else in and just take the output out (which is an I2C write cycle) - it seems to go on for some time.
|
|