Ralph Castain 8ea576c870 I have no idea how they did it, but someone managed to write a test that circled around and around and eventually reached this point with a NULL pointer. So protect against that possibility. ...

This commit was SVN r32434.

2014-08-05 16:20:46 +00:00

..

base.h

orte: fix several small memory leaks

2014-05-15 15:06:27 +00:00

Makefile.am

As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:

2013-08-22 16:37:40 +00:00

rml_base_contact.c

As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:

2013-08-22 16:37:40 +00:00

rml_base_frame.c

This isn't as big a change as it appears - a change in one place caused a whole bunch of files to require updated #include's due to some arcane linkage. Rework the orte_wait code to reflect the introduction of the state machine. If we are in cleanup mode and just want to kill all our local children, then there is no reason to be polite about it as that introduces *very* long delays at scale. Just kill the procs and move on.

2014-06-17 17:57:51 +00:00

rml_base_msg_handlers.c

I have no idea how they did it, but someone managed to write a test that circled around and around and eventually reached this point with a NULL pointer. So protect against that possibility.

2014-08-05 16:20:46 +00:00

rml_base_null_fns.c

As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:

2013-08-22 16:37:40 +00:00

rml_base_receive.c

As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:

2013-08-22 16:37:40 +00:00

rml_contact.h

- Update comment

2009-05-14 00:32:43 +00:00