On Thu, Feb 12, 2009 at 10:02 PM, Jeff Squyres wrote:
> On Feb 11, 2009, at 8:24 AM, Lisandro Dalcin wrote:
>
>> Below a list of stuff that I've got by running mpi4py testsuite. Never
>> reported them before just because some of them are not actually
>> errors, but anyway, I want to raise the disc
Just found something new to comment after diving into the actual sources
On Thu, Feb 12, 2009 at 10:02 PM, Jeff Squyres wrote:
> On Feb 11, 2009, at 8:24 AM, Lisandro Dalcin wrote:
>>
>> 1) When passing MPI_COMM_NULL, MPI_Comm_get_errhandler() fails with
>> MPI_ERR_ARG. I would expect MPI_ERR_COM
What: Proposal for a new release methodology for the Open MPI Project.
Why: We have [at least] 2 competing forces in Open MPI:
- desire to release new features quickly. Fast is good.
- desire to release based on production quality. Slow is good.
The competition between these two forces h
This commit seems to have broken the tools. If I use orte-ps then on
finalize I get an abort() with the following stack:
shell$ orte-ps
...
(gdb) bt
#0 0x2bcee155 in raise () from /lib64/libc.so.6
#1 0x2bcefbf0 in abort () from /lib64/libc.so.6
#2 0x2bce75d6 in __asse
The basic mechanics of this is similar to the problem with the portals
BTL that I fixed. However, in my case, the problem manifested itself
with the Intel test MPI_Send_Fairness_c (and MPI_Isend_Fairness_c) at
60 processes (the limit that MTT imposes on the Intel tests).
The original code foll
Sorry about the premature send...
The basic mechanics of this is similar to the problem with the portals
BTL that I fixed. However, in my case, the problem manifested itself
with the Intel test MPI_Send_Fairness_c (and MPI_Isend_Fairness_c) at
60 processes (the limit that MTT imposes on the In
Josh,
Spending few minutes to understand, could have pinpointed you to the
real culprit: the tool itself!
The assert in the code state that on finalize there is still a
registered signal handler. A quick gdb show that this is for the
SIG_CHLD. Tracking the signal addition in the tool (bre
George --
Will you commit?
On Feb 16, 2009, at 2:59 PM, George Bosilca wrote:
Josh,
Spending few minutes to understand, could have pinpointed you to the
real culprit: the tool itself!
The assert in the code state that on finalize there is still a
registered signal handler. A quick gdb s
Never mind -- you just did. Thanks! :-)
On Feb 16, 2009, at 3:07 PM, Jeff Squyres wrote:
George --
Will you commit?
On Feb 16, 2009, at 2:59 PM, George Bosilca wrote:
Josh,
Spending few minutes to understand, could have pinpointed you to
the real culprit: the tool itself!
The assert
Thanks for the fix.
-- Josh
On Feb 16, 2009, at 2:59 PM, George Bosilca wrote:
Josh,
Spending few minutes to understand, could have pinpointed you to
the real culprit: the tool itself!
The assert in the code state that on finalize there is still a
registered signal handler. A quick gdb s
Unfortunately, this doesn't fully fix the problem -- I'm still getting
bad frees:
[16:47] svbu-mpi:~/mpi % ./hello
stdout: Hello, world! I am 0 of 1 (svbu-mpi.cisco.com)
stderr: Hello, world! I am 0 of 1 (svbu-mpi.cisco.com)
malloc debug: Invalid free (min_heap.h, 58)
[16:48] svbu-mpi:~/mpi
r20569 fixes the problem, but I'm not 100% sure it's the Right Way.
Short version: now that we're guaranteeing to free the event base,
we're exercising a code path that was never used before. Apparently
the orted initializes the ev->timebase min_heap_t structure, but then
never uses it. S
Based on several man pages, free is capable of handling a NULL
argument. What is really puzzling is that on your system it doesn't ...
I tried on two system a 64 bits Debian and on my MAC OS X with all
memory allocator options on, and I'm unable to get such a warning :(
george.
On Feb 16
13 matches
Mail list logo
