seg fault problems

my program was generating a "Segmentation fault" and i finally narrowed down where it was occuring. i have developed a simple program below that re-creates the seg fault.

the seg fault occurs in the testLoop on the line "if ( clock() < $min_calc )". it does not seem to happen if i comment out the "const long double" line and replace "$min_calc" with "GLOB_min_calc_time".

can someone please either let me know why this is happening or if i have other errors in my code that are causing this?

i using FreeBSD 5.3 and GCC 4.1

thanks so much!

Code:

---

#include <iostream>
#include <ctime>

bool testLoop ( int * const $calc_val );

long double  GLOB_min_calc_time = 0;
int          GLOB_min_secs      = 5;

using namespace std;

int main( const int $argc, const char * $argv_arr[]){

  int * $calc_val = new int;
  *$calc_val = 2;

  long double $clock_start = clock();
  GLOB_min_calc_time = (long double)(clock() + (GLOB_min_secs * CLOCKS_PER_SEC)); //CLK_TCK
  testLoop($calc_val);
  long double $clock_end = clock();

  cout << "calc_val: " << *$calc_val << endl;
  cout << (long double)( $clock_end - $clock_start ) / (long double)CLOCKS_PER_SEC << " secs" << endl;

  delete $calc_val;

  return 0;
}


bool testLoop ( int * const $calc_val ){

  const long double $min_calc = GLOB_min_calc_time;

  *$calc_val = *$calc_val; //do some calculations

  if ( clock() < $min_calc ){
      testLoop($calc_val);
  }

  return true;
}

---

Well, clock returns an unsigned value (clock_t, to be exact), and $min_calc (let's hope you have dollars signs in identifiers enabled) is 0, so your calculation would never be true. It would be an infinite loop.

I think your segfault occurs elsewhere. Or maybe it's due to floating-point inaccuracies. No, it can't be.

Would you quit using dollars signs? My eyes are going screwy. :)

I know what your segfault is! You run out of stack space, because of your infinite recursive loop. Make it finite.

> can someone please either let me know why this is happening
Yes, your test code is stupidly recursive and it runs out of stack space long before the clock() has had chance to tick over to anything meaningful.

And what's with all that $ crap in all the variable names.

Quote:

---

Originally Posted by Salem

And what's with all that $ crap in all the variable names.

---

lol

Maybe we should have a shell scripting forum.

Thanks for repeating me, Salem. :D

Code:

---

long double $clock_start = clock();

---

clock() always returns 0 on its first call. And it returns type clock_t besides.

thanks for all the wonderfull help.....
i will name my vars how i wish... thank you.

how is this an infinite loop? i must be missing something!??
are you saying it is because of the long double instead of the clock_t?

also did any of you read this line in my question....

Quote:

---

it does not seem to happen if i comment out the "const long double min_calc" line and replace "min_calc" with "GLOB_min_calc_time".

---

below, i have taken out all un-needed code and $... so it simplifies this even more.

Code:

---

#include <ctime>

bool testLoop ( int * const calc_val );

long double  GLOB_min_calc_time = 0;
int          GLOB_min_secs      = 5;

using namespace std;

int main( ){

  int * calc_val = new int;
  *calc_val = 2;

  GLOB_min_calc_time = (long double)(clock() + (GLOB_min_secs * CLOCKS_PER_SEC));
  testLoop(calc_val);

  delete calc_val;

  return 0;
}


bool testLoop ( int * const calc_val ){

  const long double min_calc = GLOB_min_calc_time;

  *calc_val = *calc_val; //do some calculations

  if ( clock() < min_calc ){
      testLoop(calc_val);
  }

  return true;
}

---

> i will name my vars how i wish... thank you.
Then you're in a minority of 1, or you've mistaken C++ for being perl.

Besides, I thought it was an illegal character in an identifier, otherwise why would gcc have a specific compiler flag to allow $ in identifiers...

> how is this an infinite loop? i must be missing something!??
It isn't infinite, but it is very large.

> *calc_val = *calc_val; //do some calculations
This takes lets say a very generous 1uS

> testLoop(calc_val);
Ooh, a function call - that's another 1uS

Now clock() has a granularity measured in say seconds, that's looking a lot like say 0.5M recursive calls - pushing say 16 bytes onto the stack with each stack frame.
So before you can say "boo", you've eaten 8MB of stack space.

Compare with this non-recursive function

Code:

---

bool testLoop ( int * const calc_val ){
  const long double min_calc = GLOB_min_calc_time;
  while ( clock() < min_calc ){
      *calc_val = *calc_val; //do some calculations
  }
  return true;
}

---

Finally a intelligent and informative response. Thanks Salem for your knowledge and excellent response.

Although my example looks silly and your non-recursive function fits my example code much better, in my real application using a non-recursive function does not make any sense.

Is it possible to have a recursive function with the timing feature like my example that will not seg fault or eat up stack space like you are saying it is doing?

Thanks

Quote:

---

Is it possible to have a recursive function with the timing feature like my example that will not seg fault or eat up stack space like you are saying it is doing?

---

Maybe -- but a loop would be much simpler. [edit] And a recursive function might use up some time unrolling the stack, depending on how accurate you want your timing to be. [/edit]

Recursion isn't some kind of magic, it's only a disguised loop. Basically everything you can do with recursion can also be achieved with a loop (albeit with some extra effort in some cases).

> Is it possible to have a recursive function with the timing...
You could always pass a depth parameter to stop it going too far
eg. testLoop(calc_val,depth+1);
And stop if depth gets too deep for you.

Also, doing a lot more work than you're doing at the moment will help to limit the number of calls per second.

thanks salem... the actual loop is doing much more and the depth limit is working well. i think i may also use getrlimit and monitor the memory usage.