Good suggestion - fixed on trunk in r32189
On Jul 9, 2014, at 2:30 PM, Paul Hargrove wrote:
> I agree with Gilles that there is not a "bug", but I believe that OMPI could
> do something better.
>
> First, I'll show that
> a) this is not a new behavior
> b) it is not limited to "less".
>
> $
I agree with Gilles that there is not a "bug", but I believe that OMPI
could do something better.
First, I'll show that
a) this is not a new behavior
b) it is not limited to "less".
$ (strace ompi_info -a | grep -m1 btl) 2>&1 | grep -e 'Open MPI:' -e SIGPIPE
write(1, "Open MPI: 1.
Mike,
how do you test ?
i cannot reproduce a bug :
if you run ompi_info -a -l 9 | less
and i press 'q' at the early stage (e.g. before all output is written to
the pipe)
then the less process exits and receives SIG_PIPE and crash (which is a
normal unix behaviour)
now if i press the spacebar un
mxm only intercept signals and prints the stacktrace.
happens on trunk as well.
only when "| less" is used.
On Tue, Jul 8, 2014 at 4:50 PM, Jeff Squyres (jsquyres)
wrote:
> I'm unable to replicate. Please provide more detail...? Is this a
> problem in the MXM component?
>
> On Jul 8, 2014
I'm unable to replicate. Please provide more detail...? Is this a problem in
the MXM component?
On Jul 8, 2014, at 9:20 AM, Mike Dubman wrote:
>
>
> $/usr/mpi/gcc/openmpi-1.8.2a1/bin/ompi_info -a -l 9|less
> Caught signal 13 (Broken pipe)
> backtrace
> 2 0x00054cac mxm_ha
$/usr/mpi/gcc/openmpi-1.8.2a1/bin/ompi_info -a -l 9|less
Caught signal 13 (Broken pipe)
backtrace
2 0x00054cac mxm_handle_error()
/var/tmp/OFED_topdir/BUILD/mxm-3.2.2883/src/mxm/util/debug/debug.c:653
3 0x00054e74 mxm_error_signal_handler()
/var/tmp/OFED_topdir/BUILD/m