2.5.5. My application crashes. What can I do?

2.5.5.1. Does it crash at the beginning or at the end?

Check if Nanos++ was built with the allocator disabled.

2.5.5.2. Get a backtrace

The first step would be to obtain a backtrace using gdb. (see GNU GDB website).

2.5.5.2.1. Ways to run gdb

A typical approach could be:

$ gdb --args program parameters

If your applications needs some NX_ARGS you can pass them like this:

$ NX_ARGS="..." gdb --args program parameters

or set in the environment using export or setenv as usual before running gdb.

If you are running in a batch queue (not interactively) you will have to use gdb in batch mode. Pass the flags --batch and -ex like this:

$ NX_ARGS="..." gdb --batch -ex "run" -ex "some-gdb-command" program parameters

You may pass more than one -ex command and they will be run sequentially.

Instead of -ex you may write the commands in a file and pass the parameter --command. Check the GNU GDB documentation.

2.5.5.2.2. Backtrace

Once the program crashes inside gdb it is time to get a backtrace. If your program has more than one thread the usual backtrace (or its short form bt) will not give all the information we want. Make sure you use thread apply all backtrace command (or its short form thread apply all bt).

If you are running in batch, your command will look as follows:

$ NX_ARGS="..." gdb --batch -ex "run" -ex "thread apply all bt" program parameters

2.5.5.3. I cannot get a backtrace

If there is no backtrace, this can be a symptom of a low stack size. You can increase it with NX_STACK_SIZE (see Running OmpSs Programs).

If this does not solve your problem, we suggest to follow these steps:
  • Comment all tasks.
  • Run with only one thread.
  • Activate the tasks again, but follow them by a #pragma omp taskwait
  • Remove the unneeded taskwait one by one.
  • Increase the number of threads.

Chances are that you will be able to diagnose your problem after one of these steps.