C++: Difference between revisions

From Flooxs
Jump to navigation Jump to search
(New page: You can't use a debugger directly on your tcl script. But you can use a debugger on flooxs as it is running, because flooxs is c++ under the hood. Below gives an example of how to use [htt...)
 
No edit summary
Line 1: Line 1:
You can't use a debugger directly on your tcl script. But you can use a debugger on flooxs as it is running, because flooxs is c++ under the hood. Below gives an example of how to use [http://en.wikipedia.org/wiki/GNU_Debugger gdb], the GNU debugger. From bash, run:
You can't use a debugger directly on your tcl script. But you can use a debugger on flooxs as it is running, because flooxs is c++ under the hood. Below gives an example of how to use [http://en.wikipedia.org/wiki/GNU_Debugger gdb], the GNU debugger. From the Unix command line, type:
$ gdb $FLXHSOME/src/flooxs.new
Gdb takes as its argument the compiled C++ executable flooxs.new.  "floods" is an alias, and because it comes second on the command line it wouldn't get expanded.  Aliases only expand when they get used as the first thing.


  $ gdb $FLXSHOME/src/flooxs.new
You'l then see the gdb prompt:
(gdb)
at least it looks like that on most systems.
 
You can then run the code with:
  (gdb) run -device zerobias.tcl
or some variation of that.  Anything after the run command will be passed as arguments for flooxs.  flooxs.new -device is what floods is aliased to.
 
You probably want to set a break point in FLPS_panic.
  (gdb) break FLPS_panic
  (gdb) break FLPS_panic
(gdb) run -device zerobias.tcl


then, when it breaks, use these common gdb commands:
Once you hit the break point, the execution will stop and put you back at the gdb prompt. From here, you can type a variety of commands:
where - it will do a stack trace and show the calling sequence.
cont - continue executing
step - step over a single line of code
next - step over a subroutine call
print var - print a variable named var
list - list the code where you are
list device_tcl - list the code in that subroutine (for classes, you have to do something like Node::Size)
list 10,30 list line 10 to 30 in the current file


where (stack trace and calling sequence)
You should be able to use these to figure out what the pdb call was the created the problem.
cont (continue executing)
step
next
print var
list
list device_tcl
list 10,30


other options:
Some other options are:
  (gdb) break Newton::Solve  (run code)
  (gdb) break Newton::Solve  (run code)
  (gdb) set var UpdateDebug=1 (continues)
  (gdb) set var UpdateDebug=1 (continues)

Revision as of 23:31, 28 September 2010

You can't use a debugger directly on your tcl script. But you can use a debugger on flooxs as it is running, because flooxs is c++ under the hood. Below gives an example of how to use gdb, the GNU debugger. From the Unix command line, type:

$ gdb $FLXHSOME/src/flooxs.new

Gdb takes as its argument the compiled C++ executable flooxs.new. "floods" is an alias, and because it comes second on the command line it wouldn't get expanded. Aliases only expand when they get used as the first thing.

You'l then see the gdb prompt:

(gdb)

at least it looks like that on most systems.

You can then run the code with:

(gdb) run -device zerobias.tcl

or some variation of that. Anything after the run command will be passed as arguments for flooxs. flooxs.new -device is what floods is aliased to.

You probably want to set a break point in FLPS_panic.

(gdb) break FLPS_panic

Once you hit the break point, the execution will stop and put you back at the gdb prompt. From here, you can type a variety of commands:

where - it will do a stack trace and show the calling sequence.
cont - continue executing
step - step over a single line of code
next - step over a subroutine call
print var - print a variable named var
list - list the code where you are
list device_tcl - list the code in that subroutine (for classes, you have to do something like Node::Size)
list 10,30 list line 10 to 30 in the current file

You should be able to use these to figure out what the pdb call was the created the problem.

Some other options are:

(gdb) break Newton::Solve  (run code)
(gdb) set var UpdateDebug=1 (continues)