Ralph,
The changeset avoids SIGSEGV by calling mpi_abort before bad things happen.
The attached patch seems to fix the problem (and makes the changeset kind of
useless).
Once again, the patch was very little tested and might break other parts of
coll/m.laposte
Cheers,
Gilles
Ralph Castain w
Usually we have trouble with coll/ml because the process locality isn't being
reported sufficiently for its needs. Given the recent change in data exchange,
I suspect that is the root cause here - I have a note to Nathan asking for
clarification of the coll/ml locality requirement.
Did this pat
Gilles,
Thank you for your fix. I successfully compiled it with PGI, although
I could not check it executing actual test run.
Tetsuya
> Mishima-san,
>
> the root cause is macro expansion does not always occur as one would
> have expected ...
>
> could you please give a try to the attached patch
Folks,
mtt recently failed a bunch of times with the trunk.
a good suspect is the collective/ibarrier test from the ibm test suite.
most of the time, CHECK_AND_RECYCLE will fail
/* IS_COLL_SYNCMEM(coll_op) is true */
with this test case, we just get a glory SIGSEGV since OBJ_RELEASE is
called on
Jeff,
i did not get any reply :-(
from the OpenSHMEM 1.1 specs :
Data object on the PE identified by pe that contains the data to be
copied. This data object must be remotely accessible.
so i assumed the test was incorrect and i commited a new one (r2418)
Cheers,
Gilles
On 2014/08/29 23:41,
Mishima-san,
the root cause is macro expansion does not always occur as one would
have expected ...
could you please give a try to the attached patch ?
it compiles (at least with gcc) and i made zero tests so far
Cheers,
Gilles
On 2014/09/01 10:44, tmish...@jcity.maeda.co.jp wrote:
> Hi
