While writing a simple game using SBCL, CL-OPENGL, and Lispbuilder-SDL, I can across a strange error. Soon after I got the game working, I decided to clean out all my debugging cruft (print statements, etc). I did so, but when I ran the game afterwards I received the message "Aborted" and my entire Lisp process died, with no other error message and no debugger prompt. Using print statements I managed to isolate the problem to a call to gl:translate. The strange thing is, if I put a break statement before that line and attempt to single-step, I receive no error and the code runs fine. Seems like a race condition almost, but I'm not using threads. Any ideas?
EDIT: It appears that the call to gl:translate isn't the problem. If I do something like the following:
(print 'first)
(print 'second)
(gl:translate ...)
I get the output
FIRST
Aborted
Like I said, I'm not using threads.
EDIT 2:
It works in CLisp.
EDIT 3:
Nevermind, it doesn't.
I fixed it by switching back to pure SDL, which is disappointing, but it works.
Related
I am developing a computational geometry application in c++. This runs in parallel using threads and openmp. So, I get some geometrical values (such as nodes, edges, etc) and produce an output. This is working almost always perfect. However, there are cases like 1% that I get this messed up result. The application doesn't crash but I get really bad results, such as my output has random memory values. But even if I run on the same data twice, the second time it's gonna run fine. I used valgrind and helgrind but they didn't detect any related error. So, I am starting to run out of ideas how to trace it. Is there any other tool to try that detects possible thread errors better than helgrind? Or is there any idea on how to replicate such a problem and how to record the exact state that led to that bug?
Disclaimer: I have not used the approach below using OpenMP but based on what I just looked up it seems to be possible.
I have had a similar bug I needed to reproduce in GDB. This post helped me to run the application indefinitely until a segmentation fault occured.
We could adapt this answer to answer your question by adding a conditional break point that hits when the output value is not as expected.
set pagination off
break exit
commands
run
end
break file.cpp:123 if some_condition_holds
Now, if you would run the above with GDB it would run indefinitely until the bad result occurs (some_condition_holds is true). Then we can switch to the correct thread by using the inferior commands:
info inferiors
inferior inferior_num
I am working with eclipse using C++. It was working fine till yesterday. Now when I use break points and debug I get a stopped,reason="breakpoint-hit" error and then eclipse stops. Has anyone seen this error and anyone know how to fix it?
I have used breakpoints before to help me debug. Instead of the step into, step over, and step out options, Eclipse stops running. I am not doing anything out of the usual with breakpoints, I tried them at several different points and got the same problem.
Eclipse obviously has problems with debugging while you use the console for typing in input. Is that your case? I had that problem and while googling for a solution, I finally came upon a recommendation that while debugging, you should pass input to your program from a file rather than typing it to the console.
The recommendation can be found here:
http://webcourse.cs.technion.ac.il/234122/Spring2011/en/faq_Working%20with%20Eclipse%20CDT.html
(It's the question that starts with "I have a problem with debugging in Eclipse.".)
Hope this helps.
I have a really large code and when I try to run it in codelite, the codelite interface becomes non-responsive and I have to kill it. This usually happens in case of infinite loops.
I tried to put breakpoints in multiple places of the code to find the problem, but no luck so far. The execution halts after a while from the time that I start running the program. What is the best way of detecting such infinite loops? Codelite doesn't have a "stop" button AFAIK.
EDIT:
I ended up adding a lot of cout statements and ran the executable in a terminal rather than gdb. This helped finding what the program is doing after a really long time.
The simplest approach is to run the code for a while and then use the debugger to suspend execution without using breakpoints. If you are lucky, the call stack should indicate the bit of code that you are getting stuck in.
Failing that you will need to pepper your code with logging statements.
I've been messing around with developing a game in clojure, and one thing I've been really excited about is hot swapping in code.
I've been using swank clojure and emacs with the lein-swank plugin.
My main problem has been that of typos. Say I update a function, make a small error, and then hit Ctrl-C Ctrl-C to send it off to the REPL:
(if (> (rand) .5) (println "yay") (println "boo"))
(I should have written 0.5, not .5.)
In that case, the entire program will simply crash and burn, and I'll need to restart the whole thing. Hot swapping is great, but if I can't make even a tiny error then what's the point?
So what exactly is the workflow here? Am I missing something? Or is there a way to make swank clojure more resilient to these little errors? (I imagine that the best thing would simply be to reset to a previous working state, although that may be a little difficult.)
Thanks!
The program shouldn't “crash and burn”—it should raise an exception and throw you into the debugger, which you can dismiss by hitting Q (sldb-quit). After dismissing the debugger, the program is supposed to continue running normally. If this is not what happens, your SLIME configuration is probably broken somehow.
Personally I recommend C-M-x over C-c C-c. I don't think either one should have the problem you're experiencing, though, so switching may not fix it.
Well. that´s the question. Just that.
I got an app made with SDL and OpenGL. SDL opens an extra window (which is the console) additional to the graphical one. When i execute i´m getting a 3 output error, the console tells me. And it gets closed (the graphical one).
But i know this happens when a SIGSEGV signal is received (don´t know how to capture it) and it appears in my IDE (Code::blocks) while debugging. But this time nothing appears, and everything works all right. But when executing it crashes..
What the...
What kind of error can i expect?. Sometimes it gets closed, sometimes it doesn´t. How to know what kind of problem i got?.
SIGSEGV is a segmentation fault, you're trying to access memory that isn't accessible to your process.
Assuming you're on a UNIXy system, you should be able to get the program to core dump and then look at the core dump in a debugger; alternatively, use a memory debugger like Valgrind to pinpoint the memory management issue that's causing this problem.