code:

---

#include <iostream>

class TestClass {
public:
  TestClass ();

private:
  double* testarray;
};


TestClass::TestClass () {
  testarray = new double[40];
}

int main (int argc, char** argv) {
  return 0;
}

---

code:

---

g++  -Wall -fPIC  -O2 -g -pg  -c -o Test.o Test.cc
g++ -Wall -fPIC  -O2 -g -pg   -pthread  Test.o  -o  blah

---

code:

---

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218574944 (LWP 27213)]
0x0076e2c7 in _int_free () from /lib/tls/libc.so.6
(gdb) bt
#0  0x0076e2c7 in _int_free () from /lib/tls/libc.so.6
#1  0x0076d278 in free () from /lib/tls/libc.so.6
#2  0x007dac28 in _mcleanup () from /lib/tls/libc.so.6
#3  0x007268f3 in exit () from /lib/tls/libc.so.6
#4  0x007117fc in __libc_start_main () from /lib/tls/libc.so.6
#5  0x0804853d in _start ()

---

• Do not include iostream.
• Set the optimisation level to zero.
• Compile without the profiling option.
• Comment out the allocation of testarray.

Any suggestions for how I can debug this?

ETA: gcc 3.2.3, Linux24SL3.
 

---

Posted by Blayne Bradley (Member # 8565) on :
 
Try putting it into the Microsoft Visual studios and see what happens.
 

---

Posted by King of Men (Member # 6684) on :
 
I've already tried it with a different compiler, which removes the crash. And anyway, I'd need to set up a whole dev environment on a Windows box, which seems like a lot of work for one dang profiling.
 

---

Posted by Alcon (Member # 6645) on :
 
What distro of linux, where does the libC6 come from - distro packaged version or custom compiled? What version of libC6 do you have?

Also, update both gcc and G++ 3.2.3 is a pretty old version. [Edit]Actually we're up to version 4.4.[/Edit]

And if there's an update for libC6 I'd just grab that as well.
 

---

Posted by fugu13 (Member # 2859) on :
 
I have two main candidates: there was a bug in the profiler in that version of gcc, or there is a version mismatch somewhere between your compiler and your libraries -- which would, of course, be another bug, because if it runs at all with differently compiled libraries, it is supposed to work.

In either case, upgrading should almost certainly fix, but given what computers you're running on, might not be feasible.

My best suggestion for working it out would be to go to a gcc IRC channel and ask around. Even verifying that it is a bug would be valuable.
 

---

Posted by King of Men (Member # 6684) on :
 
Upgrading my gcc version would be difficult; however, I switched to icpc, which was already installed, and that worked. (Even with the non-stripped version of the code.) Incidentally, it turns out you can reduce from 25 ms/cycle down to 19 just with -DNDEBUG; perhaps I went a bit overboard on the asserts.
 

---

Posted by fugu13 (Member # 2859) on :
 
I'm guess you were using a lot of asserts or a library with lots of asserts?

And yeah, intel's compiler is pretty good (and I suspect the version installed is based on a more recent gcc version than the gcc installed). You should see some nice speedups over certain sorts of array math with the right compiler flags, too; the compiler can vectorize some things automatically.
 

---

Posted by King of Men (Member # 6684) on :
 
Ah-hah! If you fix the bad design that leads to getting close to the equilibrium position and then bouncing up because it goes just below it and divides by a small number, not only do you remove the enormous swings, it speeds up by two orders of magnitude because it's not constantly running into the iteration limit.

So yeah, lots of asserts, but that's not the actual problem.
 

---

Posted by fugu13 (Member # 2859) on :
 
Lots of asserts is why DNDEBUG made it so much faster.

But yes, fixing the algorithm is generally where the most speed gains come from
 

---

Posted by King of Men (Member # 6684) on :
 

quote:

---

Lots of asserts is why DNDEBUG made it so much faster.

---