Thanks Terje. I think I must be missing something because both your profiling and "waiting until you are in the situation then use trace on candidate culprits" ideas sound great IF I could do ANYTHING when I'm in the problematic situation. But I can't. My REPL is frozen and unresponsive to anything except cntrl-z (not even cntrol-c works) but I can tell from top that it's cranking CPU, maxing out all cores.
UPDATE to Richard: One of those SIGQUIT instructions DID eventually get through the process and spill stacktrace info to the terminal. And I see some of my own function names there, so this is excellent and I have a starting point for further investigation. It took several minutes to have an effect, so I just thought it was a lost cause. It'd still be even nicer to be able to get some info without quitting, but this is definitely an improvement! -Lee On Mar 17, 2010, at 2:04 PM, Terje Norderhaug wrote: > On Mar 17, 2010, at 8:14 AM, Lee Spector wrote: >> The root problem is that I think I have an infinite loop somewhere in my >> code and I'm having a hard time tracking it down. [...] In Common Lisp I >> would wait until I think I'm in trouble, break execution with a keyboard >> interrupt, look at the function call stack (and local vars, if I'm in a nice >> CL environment), and probably figure it out pretty quickly.[...] Is there is >> a way to break and look around under slime? [...] >> >> I've also been doing some runs under MCLIDE, with help from Terje >> Norderhaug, and there I can indeed issue a break from a menu and get a >> backtrace of sorts... but so far I have not been able to get a backtrace >> that shows me what I need -- that is, I don't see any of my own functions, >> presumably because the break changed the context... I'm not sure what's >> going on there. > > MCLIDE gets the same backtrace items from swank-clojure as does emacs SLIME. > I believe the issue is that the JVM only provides limited stacktrace > information (at least compared to what Common Lisp developers are used to). > > A good backtrace is essential for efficient debugging. Are there any ways to > improve the backtrace provided by swank-clojure? > >> An alternative: Is there a way to watch my running Clojure program without >> breaking it, that is to observe the recent call history (of my own >> definitions, either all of them or specifically marked ones) from outside >> the process? > > You could use a profiler to see which of your Clojure functions monopolize > the execution. > >> I can think of some clumsy ways to roll my own version of this, e.g. using >> trace and sending the trace output to a file, but I don't think this will be >> practical because I generally only get these errors after long stretches of >> intensive computation that will involve many many calls to the potentially >> problematic functions. So I think there'll be too much trace output to save >> on disk, and the slowdown from tracing all of the calls may prevent me from >> ever reaching a problematic state (although I haven't tried this to be sure >> of the timing). > > Consider waiting until you are in the situation then use trace on candidate > culprits. > >> And in spite of the problems listed above I'm having a great time in the >> Clojureverse! > > > -- Terje Norderhaug > te...@in-progress.com > > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.com/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
