I am writing a program with SBCL and building it with Buildapp.
Currently when error occurs it starts debugger. I want it to die in the same manner as other simple (C) programs do. What can I do for this?
One option is to put (sb-ext:disable-debugger) early in your startup function. When an error occurs and there is no handler, SBCL will print an error and a backtrace and exit.
Another option is to write a function that does what you want on error and set it as your debugger hook; see command-line-debugger in buildapp itself for an example.
Related
I am working on a project using Eclipse CDT and am encountering what seems to be an infinite loop.
When debugging an application from within Eclipse, I can easily retrieve and examine the call stack when the process terminates abnormally (segfault being the most common one) or when I hit a breakpoint.
If I run into an infinite loop without knowing which statements are looping, a stack trace would give me a rough idea of the functions to look at. How can I tell Eclipse to get me a stack trace of whatever the process is doing right now (in the absence of a breakpoint or segfault)?
My hack for that so far is
killall -SIGSEGV $process_name
(replacing $process_name with the name of the process you are trying to debug). This will cause the process to behave as if it had segfaulted, i.e. stopping it and giving you the call stack of whatever the process was executing at the time.
Is there a cleaner way of achieving the same?
A slightly cleaner way is:
killall -SIGCONT $process_name
This sends a CONT (continue) signal to the process. The primary purpose of this signal is to continue a process after it has been sent a STOP signal. When sent to a process that isn’t stopped, it does nothing.
However, if the process is being debugged in Eclipse (which in turn relies on gdb for debugging), this will stop execution and cause a stack trace to displayed.
Unlike with -SIGSEGV (or other signals that tell the process to dump its core or terminate), you can then hit the Resume button and continue to run your process. The UX is close to what would happen after hitting a breakpoint, except Eclipse will report a different reason for suspending execution.
Note that if you are doing anything that messes with signal processing by your process, this might not work as expected.
No idea if there’s anything that can be triggered from the Eclipse UI, though.
I am trying to use Clojure with emacs and cider for a project of mine, and often exceptions occur while executing my code. When an exception occurs, cider provides me a stack trace, but often that is not sufficient to quickly identify what went wrong. I am looking for some way to make CIDER initialize a REPL when the exception occurs, that will allow me to examine the values of locals at the point of occurring of exception and perhaps even change some of the values and continue execution from that point. Is it possible with Clojure, Emacs and Cider?
AFAIK, such feature is not available neither in CIDER nor in other IDEs (Cursive, LightTable).
The most you can do is to insert a breakpoint before erroneous form and, when debugger has popped up, inspect locals there.
I wonder what the difference is between entering a few lines in the command window, or letting a script execute them.
In the question Escape from nested try - catch statement I have an example function. I have put the selected code in a script and called it, however then it does not work properly. On the other hand, when I
select the lines and hit f9, it works as expected.
The lines are:
dbclear all
dbquit
dbstop if caught error
I call the example function as such:
dbstop if caught error
mytestmain
And the example function is:
function mytestmain
try
mytestsub
catch
end
% Definition of subfunction, may or may not be in the same .m file
function mytestsub
try
a=b; %Intentionally generate an error as b is not defined
catch
end
I think it's related to MATLAB's just-in-time (JIT) compiler, which compiles functions before it runs them.
It seems that it compiles functions differently if dbstop is set or not (see here for reference). As it currently stands, MATLAB can not recompile a function while it is run (just try saving a changed function during a dbstop, and you will get a message informing you). As you can add and remove breakpoints during a dbstop I think you can also do so programmatically, but it should be impossible to "turn on" debugging if it wasn't turned on at "compile time"
So in your cases:
Using F9 it's just pasted and parsed as if you input it manually. So first dbstop is set, then mytestmain gets compiled and executed.
Running as a script will first compile the script and mytestmain and then execute it - so dbstop would be set after compilation and therefore not in effect.
Depending on what you mean by "doesn't work", it could just be because the debugger is a special context and certain debugger commands - dbup, dbdown, and dbquit - only work when you're at a debugger "K>>" prompt. Once you call a script, you're no longer at the debugger prompt but in normal code execution - inside a nested M-code call stack - and they just don't work there. When you F9, it does the lines individually, so each one is done from the prompt.
As a workaround, if you really want to execute a sequence of debugger commands like this, you could write a little Java Swing widget to enter the text in to the command window just as though you were typing it in.
I have a compiled matlab program that runs as a dos box basically (ie no GUI). Is there a way to get code to execute when someone closes the program? Specifically closing by clicking on the X?
I suggest to define a cleanup task. This will be executed whenever a function is terminated (by whatever means), so as long as closing the program is not done with a kill -9 command or similar, the code is being run.
I'm having a problem with an Emacs lisp package that I pulled down from the ubuntu distribution. The package is JDEE, and it complains of Args out of range: "63", 0, 4 in the mini buffer and the *Messages* buffer whenever I open a file. This bug appears to have been reported last September but no action has been taken. I'm not an emacs newbie, having written some Elisp code myself, but I've never attempted to debug anything like this. I would like to stop the file load in a debugger when this error happens to at least get an idea of where the problem is coming from. I've read section 18.1.1 of the Elisp manual on "Entering the debugger on error" but trying to load the file after playing with various combinations of values for debug-on-error, debug-ignored-errors, and debug-on-signal appears to have no effect. Has anybody got any suggestions for my next step?
If debug-on-error isn't working, I'd start with the source itself. Find the keybinding/event that is causing the problem, and locate the function.
C-h k <keystrokes>
M-x find-function <function-name-from-above>
Now, once you are at the source
M-x edebug-defun
And the next time you hit the key, you should be able to step through the program. At that point, you can see which portion causes an error - and drill down that way.
You can also try setting the variable 'stack-trace-on-error to see if you can find the culprit (though 'debug-on-error usually works for me, not sure why it doesn't for you).
As a last resort (if edebug-defun doesn't work), you can redefine the routine with a call to (debug) in it, sort of does the same.
I suppose JDEE is somehow inhibiting debug-on-error. Perhaps grep through its files for the error message "Args out of range". While debugging, make sure to load the uncompiled .el files, not the byte-compiled .elc files (you will notice it in the debugger if you are running byte-compiled code) by entering commands like (load "foo.el") instead of (load "foo").
I got the same error when using find-grep after accidentally redefining (current-time-string) in one of my own scripts.
Using the M-x edebug-defun tip posted above I managed to find the issue when I stepped through the code giving the error seeing the call to (current-time-string).
Not sure how helpful this is in your case.