posted
So I've got a program I'm trying to profile; the difficulty is, when I add '-pg' to my compile and link options, it crashes, somewhere in the static initialisation - before main. So, I stripped it down to the minimum that will still produce this crash, which is surprisingly small:
code:
#include <iostream>
class TestClass { public: TestClass ();
private: double* testarray; };
TestClass::TestClass () { testarray = new double[40]; }
This program, which does absolutely nothing, manages to segviol; here's the gdb trace:
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 ()
posted
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.
Posts: 10645 | Registered: Jul 2004
| IP: Logged |
posted
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.
Posts: 15770 | Registered: Dec 2001
| IP: Logged |
posted
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.
Posts: 10645 | Registered: Jul 2004
| IP: Logged |
posted
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.
Posts: 15770 | Registered: Dec 2001
| IP: Logged |
posted
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.
Posts: 10645 | Registered: Jul 2004
| IP: Logged |