cumulativeEF weird behavior

Kevin Glynn glynn at info.ucl.ac.be
Thu Jun 16 08:23:50 CEST 2005


Filip Konvièka writes:
 > Well, sadly no one seems to have time for this, so I'm thinking of 
 > debugging the code myself.
 > 
 > Hackers, please, how do you usually debug ozengine?  Do you simply load 
 > ozengine.exe into gdb and set a breakpoint somewhere in, say, scheduling.cc?
 > 

I've never (thankfully) debugged constraint propogators. This might
all be obvious to you, but you asked ....

To build a debugging emulator add --enable-opt=debug to configure.
You might want to do this after you have first built mozart without
debugging, then just rebuild the emulator. (Compiling all the oz files
with a debugging emulator used to be really slooow, but its not bad on
modern machines now).

Start the OPI and grab the emulator process with gdb.  Set your
breakpoints and away you go.  From a quick look, I think
sched_cpIterateCap is the start builtin you are interested in. 

Presumably the propagator will be called over and over, and you might
need to set watchpoints to stop at an interesting time.

Often,  it can be easier to just instrument with printfs and analyse
the log later at your leisure, at least to narrow down the problem and
be sure you understand the flow of control.

There are other tricks (such as being able to print the mozart
bytecode being executed at the time of a breakpoint). Let us know when
you have more specific needs / problems. And let us know your tips for
debugging the emulator!

k





More information about the mozart-hackers mailing list