abstract C++ question

[sanctus]

How is the following possible?

1) I have a running program with the an option, say A, set to false; i.e.

A=false;

2) I set

A=true;

and get an error (it still runs but doesn't calculate because always out of bounds)

3) I set again

A=false;

and get still the same error as after 2...

This is not clear at all to me because between every numbered step (i.e. 1 and 2 and 2 and 3) there is a make clean and then a make...so it shouldn't know anything from the preceeding right?

[alexander]

it does not matter how many times you set a, as long as you are not accidentally redefining it (in which case you will get an error)

i can however see a possible problem with you using A in calculations, i would type cast it as int just to be on a safe side. i know posting the whole code may not be possible, but could you perhaps post more pieces that may give us a better picture of what may be happening?

[Buffy]

This is the kind of bug for which a debugger is pretty much invaluable. Have you got one? You need to either have a break on change in value or step through the code starting where its "not the right value."

I had a developer not too long ago who thought he was such a hotshot that he could get by without using a debugger, just traces. He did not last long!

Step into,
Buffy

[alexander]

mmmm, GDBlicious

[LaurieAG]

Originally Posted by sanctus

This is not clear at all to me because between every numbered step (i.e. 1 and 2 and 2 and 3) there is a make clean and then a make...so it shouldn't know anything from the preceeding right?

Hi Sanctus,

It may be due to your 'A' being a restricted system variable name. Your documentation should provide a list of any restricted variable names.

[sanctus]

Actually the code was not written by me, I just modified some parts (nothing though related to that). The code is too complicated to post it here giving a clue...'A' is just a name of an experience to use or not for computing the likelihood...
The problem with gdb is that I run this program on different (9) machines at university, so I don't really know how to use gdb. Additionally thing is that looking at the output on the different machines there isn't really an error of compilation but one written in the code (something like "in spline # x out of bounds") so it actually keeps turning but calculates nothing because out of bounds...but why in the beginning x was in bounds and then changing from false to true back to false it is out of bounds (as it was when it was true)?

[Buffy]

Originally Posted by sanctus

The problem with gdb is that I run this program on different (9) machines at university, so I don't really know how to use gdb.

Learn it on the one machine that has it installed! You'll be glad you did!

Why? Well...

Originally Posted by sanctus

...there isn't really an error of compilation but one written in the code...

Debuggers are what you use when it compiles fine, but theres something in your algorithm that isn't working and you have to go in and watch what's going on in order to find where the flaw is.

But if you don't have the time to learn gdb (and really all you need to know is how to set a breakpoint and then inspect the variables that are making you miserable), then you need to "instrument" the app, which basically just means putting "writes" or "alerts" in your code at strategic places and see when x and a are changing. Put these in before and after every reference to them in the code that's not working.

Quite often when you have problems like you're describing, its either due to hidden side-effects (something is buried one level down in a function), or you've got scoping errors (x is a local variable that gets set in one place, goes out of scope and then gets recreated but now has no value).

If you were using C instead of C++, I'd also be looking for arrays that are going past their declared sizes and munging data in other variables that get allocated nearby on the heap, but you should be getting run-time errors for that (unless you were using an old generic unix "cc").

printf("It hasn't worked for the last %d loops.", i),
Buffy

[alexander]

g++ -ggdb -o prog prog.cpp

gdb prog

run

[sanctus]

I know the basics of gdb, so that is not the problem. The problem is that all machines are far away and on mine it takes about 1 hour to get to point where it starts calculating...so I can't try it on the machine that has it installed.

Alex to compile the program there is a makefile and I added the thing for gdb in the makefile:

FLAGS = -ggdb3 -Wall -DQT_THREAD_SUPPORT  -DPRERELEASE $(WMAPDEFINE)
//ggdb3 added by me

It works fine when not running a montecarlo simulation since then I use my machine. I also tried the following:
when you are, via ssh, on the other machines you usually write
$ qsub -l nodes=9 -l walltime=500:00:00 ./mcrun

to use 9 machines that calculate for 500h. So I tried something like (it calculated so I did it the right way then)
$ gdb qsub -l nodes=9 -l walltime=500:00:00 ./mcrun
$ run

it calculated but since it does not give real errors only try-catch error written by the original coder gdb or not doesn't change much.
Now (I said I know a little gdb, but maybe I exarated) how do I set a breakpoint so that the program stops at a given point (i.e. when the catch error comes)?

[sanctus]

Now this is what I did:

$gdb mc_general
(gdb) break fastsplint()
Function "fastsplint()" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (fastsplint()) pending.
(gdb) exec qsub -l nodes=9 -l walltime=500:00:00 ./mcrun
(gdb) run

And then it starts and stops doing anything after:

Starting program: /usr/bin/qsub 
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xffffe000

Any idea?