On 21 Aug 2014, at 15:19, Ian Smith the.pond@dsl.pipex.com wrote:
On 21/08/14 14:08, Erik Schnetter wrote:
Ian
We've been running on 64-bit systems since Cactus was designed... I doubt that a 64-bit issue is the problem here.
(Historical factoid: This was one of the motivations for introducing CCTK_REAL. The early Cray 64-bit systems defined the "integer" to be 64 bit, as one would naively expect. The Fortran standard the requires "single precision" floating point numbers to be 64-bit as well, so that one would want to use "single precision" on such a system, not "double precision" that would have 128 bits and be very slow. So -- CCTK_REAL, which has the same number of bits on all systems.)
Yes, we've encountered and dealt segfaults before. Can you give us more information? I recommend you open a bug report on trac.einsteintoolkit.org http://trac.einsteintoolkit.org where you can easily attach information, and then attach your option list, parameter file, machine configuration, as well as the exact commands you used to build your executable and run your job.
-erik
Hi Erik,
OK, I saw the list of supported architectures and noticed it contains IA64 but not AMD64 if I read it correctly.
I'll investigate and see if I can get more debug for you. In the meantime I have a 32-bit machine to run on so I can study the examples as well.
Try to get a backtrace to find out where the segfault occurred. You can set "ulimit -c unlimited" in the shell you use to run Cactus, and this should cause core dump files to be generated when the crash happens. You can then read these with gdb:
gdb exe/cactus_sim core.XXXXX
Then type "backtrace" to get the backtrace.