I am using sbcl 1.0.57.0 and want to start a program via --eval which should generate some output, but in case that there is an uncaught error it shall exit.
I figured the easiest way to accomplish that would be by using unwind-protect:
(unwind-protect (error 'simple-error)
(progn (FORMAT t "IAMREACHED~%") (sb-ext:exit)))
As (sb-ext:exit) should be executet incase there is an uncaught error.
But it doesn't!
* (unwind-protect (error 'simple-error)
(progn (FORMAT t "IAMREACHED~%") (sb-ext:exit)))
debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {1002979193}>:
(A SIMPLE-ERROR was caught when trying to print *DEBUG-CONDITION* when entering
the debugger. Printing was aborted and the SIMPLE-ERROR was stored in
SB-DEBUG::*NESTED-DEBUG-CONDITION*.)
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(#:EVAL-THUNK)
0] 0
IAMREACHED
What is my misconception about the workings of unwind-protect?
UNWIND-PROTECT is an analogue of finally clause in Java or Python, so it's not a catch-all clause, that will intercept any unhandled condition. For that you need a HANDLER-CASE with a handler clause for type CONDITION.
UNWIND-PROTECT actually works in your case. The only "unexpected" behaviour is that the debugger is invoked before the body of UNWIND-PROTECT is executed. The reason for this is not to lose the current context and be able to restart execution. It is (probably) achieved via HANDLER-BIND. You can learn more about that in PCL chapter "Conditions and Restarts".
Maybe you want to disable the debugger, see SBCL Toplevel Options
You could use (ignore-errors) for the purpose of silently omitting errors.
Or you could call sb-ext:disable-debugger early to only see error message without the debugger launch.
Related
What can the following be due to / how to debug it? it happens when closing my MPI application
[1612979755.727913] [compute-0-9:21112:0] tag_match.c:61 UCX WARN unexpected tag-receive descriptor 0x2b2bf64cdbc0 was not matched
Assuming the application exited normally, this probably means that some process sent a message (e.g. calling MPI_Send) to a destination process that did not post a matching receive before calling MPI_Finalize. See https://github.com/openucx/ucx/issues/6331#issuecomment-778428537
I wrote a SBT task to run cssLint for my project using rhino. cssLint returns exit code to my SBT task.
My question is how to make the task fail if the exit code is non-zero?
I don't want to throw any exceptions. I want my last line of the task result to show [Failed] instead of [success] and exit code of my SBT task to be non-zero.
SAMPLE
MyTask {
val exitcode = //rhino functions
//what to do??
}
The actual intent is to fail the build if css errors are present.
The way of failing the build without producing the stacktrace on the console is using the exceptions that are specifically handled:
for sbt.MessageOnlyException an error message is logged twice (without task name and then with task name) and the build is stopped
mix in sbt.FeedbackProvidedException or sbt.UnprintableException to implement custom exceptions for which sbt does not print a stacktrace. The string with task name and exception's toString is logged on the top level once and the build is stopped. It is expected that essential information for the user is already logged before throwing these.
Disclaimer: I've not seen this information in sbt manual. Extracted from the sources of sbt 0.13.16. sbt.FeedbackProvidedException is used this way by sbt compiler, sbt tests and by sbt-web and Play sbt plugins.
My understanding is that the success message is printed out always unless
showSuccess setting is set to false or
a task throws an exception.
In your particular case you want to report an error and so you should throw an exception or a value of the type of the result that might be considered a sort of exception like None or Failure.
Say, you've got the following task defined in build.sbt:
lazy val tsk = taskKey[Unit]("Task that always fails")
tsk := {
throw new IllegalStateException("a message")
}
When you execute the tsk task, the exception is printed out with no [success] afterwards.
[no-success]> tsk
[trace] Stack trace suppressed: run last *:tsk for the full output.
[error] (*:tsk) java.lang.IllegalStateException: a message
[error] Total time: 0 s, completed Feb 15, 2014 11:45:27 PM
I would rather prefer avoiding this style of programming and rely on Option as a way to report an issue with processing.
With the following tskO definition:
lazy val tskO = taskKey[Option[String]]("Task that reports failure as None")
tskO := None
you'd then check the result and if it's None you'd know it's a failure.
I use Quicklisp to load systems, and I debug my code with Slime. Quicklisp loads many systems successfully except cl-postgresql.
When evaluating (ql:quickload "clsql-postgresql") in slime, the inferior lisp exits.
Slime prints
Lisp connection closed unexpectedly: connection broken by remote peer
in minibuffer and
Process inferior-lisp trace/BPT trap: 5
in *inferior-lisp* buffer.
But evaluating (ql:quickload "clsql-postgresql") in SBCL without Slime won't cause any error.
I have searched "trace/BPT trap: 5" with Google. The message seems indicating problems in loading dynamic libraries. I suppose the error is caused by wrong search paths set by Slime. According to http://clsql.b9.com/manual/appendix.html, I checked CLSQL:*FOREIGN-LIBRARY-SEARCH-PATHS* in bare SBCL and Slime environment, but they were both nil.
Why did clsql-postgresql fail to be load when using Slime?
Environment:
SBCL 1.1.8
OS X 10.8.4
latest quicklisp
latest slime
emacs 24.3
(sorry for my English, I'm not a native speaker)
I checked User Diagnostic Report. And I found the following lines:
Thread 7 Crashed:
0 com.apple.CoreFoundation 0x00007fff8fab52d5 __CFInitialize + 69
1 dyld 0x00007fff6f56d256
So I googled "CoreFoundation". It said that CoreFoundation must be loaded by the main thread, otherwise it would signal SIGTRAP. It's a rule of OS X.
See: Debugging a crash when a library is opened via dlopen on OSX
In bare SBCL, ql:quickload is directly evaluated in the main thread. But under SLIME, forms are evaluated with a separated thread started by SWANK.
The solution is to evaluate (ql:quickload "clsql-postgresql") in *inferior-lisp*, instead of *slime-repl*, when libpg is the first foreign library depending on CoreFoundation to be loaded.
I've modified the code at http://www.switchonthecode.com/tutorials/using-core-plot-in-an-iphone-application to run on xcode4, I have a view that I put into my ConsoleViewControllor.xib with its class as CPTGraphHostingView.
Compiles great, at runtime however, I get a SIGABRT at line
hostingView.hostedGraph = graph; with the error
* Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UIView setHostedGraph:]: unrecognized selector sent to instance 0x5910d40'
* Call stack at first throw:
Anyone else run into this issue? I'm more than willing to give you code and answer more questions. Thanks in advance!
Check the setup in your .xib again. -[UIView setHostedGraph:] means that Xcode created a UIView, not a CPTGraphHostingView.
I run an Qt app I've built:
./App
Segmentation fault
I run it with strace:
strace ./App
execve("./App", ["./App"], [/* 27 vars */]) = 0
--- SIGSEGV (Segmentation fault) # 0 (0) ---
+++ killed by SIGSEGV +++
Process 868 detached
Again, no useful info.
I run it with gdb:
(gdb) run
Starting program: /root/test/App
Reading symbols from shared object read from target memory...(no debugging symbols found)...done.
Loaded system supplied DSO at 0xffffe000
Program received signal SIGSEGV, Segmentation fault.
0x00000001 in ?? ()
Again, nothing.
I run it with valgrind:
==948== Process terminating with default action of signal 11 (SIGSEGV)
==948== Bad permissions for mapped region at address 0x0
==948== at 0x1: (within /root/test/App)
Even if I put in debugging symbols, it doesn't give any more useful info. ldd shows all libraries being linked properly.
Is there any other way I can find out what's wrong? I can't even do standard printf, cout, etc debugging. The executable doesn't even seem to start running at all.
I rebuilt with symbols, and tried the suggestion below
(gdb) break main
Breakpoint 1 at 0x45470
(gdb) run
Starting program: /root/test/App
Breakpoint 1 at 0x80045470
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xffffe000
Program received signal SIGSEGV, Segmentation fault.
0x00000001 in ?? ()
I checked for static initializers and I don't seem to have any.
Yep, I tried printf, cout, etc. It doesn't even make it into the main routine, so I'm looking for problems with static initializers in link libraries, adding them in one-by-one. I'm not getting any stack traces either.
Try running it through strace, it might give you at least some hints what happens before the program crashes. Also, does a backtrace in gdb not work?