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
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
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
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
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo
