This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Undef_handler ???

My code, (MCB2300 and RL-ARM) which parses a file on SDcard for execution commands, was working fine (theoretically) until today it's being thrown into the Undef_hander. If I make small modificatons to the source, it happens at different points in parsing, so it's not a hard error in the input. I can't find anything in the forums or docuementation on what throws this error. I've tried looking at stacks, etc. to no avail. It seems to happen in ftell() but I haven't pinned it down yet. Anyone have any insights?

Parents
  • "I've put more checks in to test the input code..."

    That is always a recommended thing to do. Expect everything to fail. So check everything. Even the things that really should not be able to fail - tomorrow you make an unrelated change somewhere else suddenly make it possible to fail ;)

    - Check all input parameters for reasonable values.
    - Check that produced return value seems reasonable before returning it.
    - Does function documentation actually document above "contract" requirements?
    - Consider what to do for switch values not covered.
    - Can any input parameter set result in internal evaluation overflows?
    - Verify every array access.
    - Keep depth counter for every recursive function call.
    - Add timeouts to every wait.
    - Do functions need parameters that allows global data to be modified?
    - Is const/static data properly "protected" by being stored in read-only code space?
    - Is nonvolatile configuration actually valid configuration or garbage or possibly having partial update?
    - Can "finite" loops fail to exit?
    - Are every variable given a start value?
    - Can program get in fight for critical resource?
    - Can "producer" overrun "consumer"?
    - Are all "tasks" actually running when they should run?
    - Are any large variables stored on stack - and is it ok based on stack size and call tree?
    - Can max "input load" starve main program? Indirectly - can there be external stimuli that makes program to fail even when the device should by specification be able to supply a specific service?
    ...

Reply
  • "I've put more checks in to test the input code..."

    That is always a recommended thing to do. Expect everything to fail. So check everything. Even the things that really should not be able to fail - tomorrow you make an unrelated change somewhere else suddenly make it possible to fail ;)

    - Check all input parameters for reasonable values.
    - Check that produced return value seems reasonable before returning it.
    - Does function documentation actually document above "contract" requirements?
    - Consider what to do for switch values not covered.
    - Can any input parameter set result in internal evaluation overflows?
    - Verify every array access.
    - Keep depth counter for every recursive function call.
    - Add timeouts to every wait.
    - Do functions need parameters that allows global data to be modified?
    - Is const/static data properly "protected" by being stored in read-only code space?
    - Is nonvolatile configuration actually valid configuration or garbage or possibly having partial update?
    - Can "finite" loops fail to exit?
    - Are every variable given a start value?
    - Can program get in fight for critical resource?
    - Can "producer" overrun "consumer"?
    - Are all "tasks" actually running when they should run?
    - Are any large variables stored on stack - and is it ok based on stack size and call tree?
    - Can max "input load" starve main program? Indirectly - can there be external stimuli that makes program to fail even when the device should by specification be able to supply a specific service?
    ...

Children
No data