If you are attempting to debug a feature implemented as a macro like symex-define-command, you would need to evaluate the primitive functions for debugging, rather than the macro, or if necessary, copy the contents of the command to a new function and call that function from the macro, in order to be able to debug it. To be clear, you would need to evaluate the function for debugging rather than the macro. Naively, if you attempt to debug the macro, the debugger is triggered at compile time (i.e., as soon as you attempt to evaluate it for debugging!) and not at runtime when you’re actually interested in using it. For the same reason, if you attempt to “step into” a macro invocation while the debugger is active, it won’t do anything. You can only debug functions. If what you are interested in debugging is not a function, then put it in a function and debug that.
If you’re an Evil user, sometimes, the debugger appears to get overridden by Evil keybindings, complaining that the “Buffer is read-only” when you attempt to s to step forward. Saving the buffer (as opposed to debugging an unsaved buffer) seems to solve these issues, and if not, killing and reopening the buffer does.
The Symex modal UI is written in Lithium which wraps the underlying Symex commands with error handling, and this wrapping code may be byte-compiled. This could make the stack traces hard to read in the event of an error, so if you are encountering an issue with an interactive feature that you are using through the modal UI, then debug it by invoking that function directly, using M-x <symex-command-name> or via programmatic invocation in IELM or via M-:. That will show you a clean stack trace.
For instance, instead of x in Symex mode, use M-x symex-delete.