Charm++ parallel programming system

[Matthias Diener <matthias.diener AT gmail.com>]

Hi Jozsef,

A bit of context regarding the second part of your question:
Since https://charm.cs.illinois.edu/gerrit/#/c/charm/+/3720/ , Charm++
calls CkAbort() when there are unhandled C++ exceptions in user code.
Charm++ itself does not use exceptions.

You could override Charm++'s uncaught exception handler in the mainchare,
for
example, by specifying your own set_terminate handler:

// in Main():
std::set_terminate([](){ CkPrintf("Warning: Unhandled exception in user
code.\n"); abort();});

Regards,
Matthias
On Wed, 16 May 2018 at 08:09, Jozsef Bakosi 
<jbakosi AT lanl.gov>
 wrote:

> Hi folks,

> When exceptions are thrown from chare arrays or groups, how/where one is
> supposed to catch them?

> Ideally, I would like to catch exceptions at the outermost layer, e.g.,
outside
> of some driver, from where everything else is instantiated and called,
but that
> way not every exception is caught.

> I attach an example with the simplearrayhello test augmented and commented
> highlighting the problem/question.

> In addition, I also set signal handlers to throw exceptions (and produce
nice
> stack traces) when, e.g., segfaults happen and redirect them to the same
code
> that handles exceptions and produce stack traces, but when exceptions are
not
> caught that is useless.

> Alternatively, is it possible to override Charm++'s exception handling,
that
> sometimes produces outputs like the following:

> ------------- Processor 0 Exiting: Called CmiAbort ------------
> Reason: Unhandled C++ exception in user code.

> [0] Stack Traceback:
>     [0:0]   [0x592cfe]
>     [0:1]   [0x58f9f8]
>     [0:2]   [0x41b908]
>     [0:3]   [0x41b8e9]
>     [0:4] +0x22763  [0x7ffff736d763]
>     [0:5] +0x25516  [0x7ffff7370516]
>     [0:6] +0x254af  [0x7ffff73704af]
>     [0:7]   [0x414829]
>     [0:8]   [0x413091]
>     [0:9]   [0x434f30]
>     [0:10]   [0x46f99a]
>     [0:11]   [0x440c2d]
>     [0:12]   [0x437491]
>     [0:13]   [0x436e11]
>     [0:14]   [0x596417]
>     [0:15]   [0x596744]
>     [0:16]   [0x59646a]
>     [0:17]   [0x5929d1]
>     [0:18]   [0x592283]
>     [0:19]   [0x417c95]
>     [0:20] __libc_start_main+0xe7  [0x7ffff621aa87]
>     [0:21]   [0x411f1a]
> --------------------------------------------------------------------------
> MPI_ABORT was invoked on rank 0 in communicator MPI COMMUNICATOR 3 DUP
FROM 0
> with errorcode 1.

> NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
> You may or may not see output from other processes, depending on
> exactly when Open MPI kills them.
> --------------------------------------------------------------------------

> Thanks,
> Jozsef