|
From: | Marcus G. Daniels |
Subject: | Re: [Swarm-Support] batchswarm problem - getActivity |
Date: | Mon, 24 Mar 2008 20:09:25 -0600 |
User-agent: | Thunderbird 2.0.0.12 (X11/20080226) |
Hi Corinne,
Hmm, I don't see any error message there. You've set a breakpoint in your program (apparently in a stopRunning method), and it hits it. This seems completely reasonable. Do you have reason to believe something bad happens there?With my code as is, this is the error message.
You should be aware that GDB can misinform you and often will. This comes about because the compiler's optimizer can make the executable code difficult to follow in a precise way (as it may restructure it for efficiency gains). Also there's the possibility of the stack being destroyed by dramatic failures of the code, e.g. array overruns. These problems are fairly common because both Swarm and models built with Swarm will use lots of optimization.
The main way I tend to use debuggers is to attach to a long running process to look around in it. When I have control of the source code (such as with a model), it's often easier to put in diagnostic messages in the code itself and then make a log to study, or just watch it print out those messages to the console. One way to make this easier to manage is to use this kind of idiom in your code:
#ifdef DEBUG raiseEvent (WarningMessage, "Here I am"); #endif Then compile with: make EXTRACPPFLAGS=-DDEBUGThat way, you can leave the diagnostics in your code, and activate them when needed. Afterwards removing the object files and rebuilding with simply "make" will not put them in and thus won't produce noise or slow your code. raiseEvent is just a macro in Swarm that tells you what line and file the diagnostic is in, simple printfs are otherwise just as good.
Marcus
[Prev in Thread] | Current Thread | [Next in Thread] |