Internal Error #650

  (#95972) Problem occurred during block evaluation from within a custom
  error handler?  A message preceding the error indicated that the
  program had run out of stack space: "Processor Stack Overflow."

  () I got this error to occur by specifying an undefined ERRORBLOCK().
  In other words, the function call in the codeblock that I passed to
  ERRORBLOCK() had a symbol reference in it that was not linked to the
  program.  .RTLink generated an "unresolved externals" message and
  indicated that "EXE may not execute properly."  I suspect, however,
  that this error has nothing at all to do with ERRORBLOCK()s in
  general, but, instead, has something to do with the evaluation of
  a NIL or undefined codeblock.

  (#111301) This thread seemed to indicate that 650's real nature has
  something to do with a stack overflow.  Increasing stack space may
  help to remedy the situation.  Checking your code for recursion may
  help as well (especially if you hadn't intended that there be any
  recursion).

  (#113260) This error occurred for one user in a 500 line test program with
  some ASM modules linked in (though they did not appear to be the problem).
  After this user changed a few static variable names, 650 began appearing
  in _APPINIT(0) (a Clipper internal).

  (#117157) One user got this error when he named a program ACHOICE.PRG     ~
  and compiled it to ACHOICE.EXE.  There can only be one symbol name
  for a procedure or a function.  If you have an ACHOICE.prg and you are
  not compiling with the /n switch, any calls to ACHOICE() will cause the
  assumed procedure ACHOICE to be executed. This results in recursion and
  an eventual 650 stack overflow.  Remember, functions and procedures
  are essentially the same.