Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] opal_util_register_stackhandlers()
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-03-19 21:20:39

Thanks for the bug report!

I've just changed the behavior to emit a warning and *not* intercept a
signal if the old signal action is neither SIG_DFL nor SIG_IGN. The
opal_signal MCA parameter can be set to determine which signals you
want to intercept; it defaults to the integer values of SIGABRT,
SIGBUS, SIGFPE, SIGSEGV on your system.

We can probably get this in OMPI v1.3.2.

On Mar 19, 2009, at 11:13 AM, Kees Verstoep wrote:

> Hi,
> Currently, opal_util_register_stackhandlers() in opal/util/
> stacktrace.c
> calls sigaction() with a third NULL argument, meaning you don't look
> at possibly previously installed signal handlers, and always override
> them with print_stackframe().
> But there are actually realistic scenarios where an application
> actively
> uses these signals, and also wants to use MPI. As an example, the
> default
> opal "signal" parameter settings are such that SIG_SEGV is redirected.
> Typically, indeed, SIG_SEGV indicates a bug somewhere, and the
> stacktrace
> from Open MPI is a nice bonus. However, the Sun Java JDK uses
> to detect when stacks should be automatically extended, and it stops
> working
> rather ungracefully when that handler gets replaced.
> (BTW, we stumbled on this recently when we added an MPI backend for
> our
> Ibis grid programming environment. It took a bit of time to figure
> out
> what was happening, since we got no usable stacktrace for the thread
> that
> got bitten. We suspected a bug in our native code mapping at first,
> but MPICH did not have this problem).
> In most cases, you can of course work around it by manually changing
> the opal "signal" list, but it would be nicer if Open MPI would detect
> the situation, and e.g. only install the stack printer when there is
> no handler yet, or at least warn about the possible clash.
> Thanks!
> Kees Verstoep
> _______________________________________________
> devel mailing list
> devel_at_[hidden]

Jeff Squyres
Cisco Systems