George Bosilca wrote:
Stephan,
The fix was committed in the trunk (revision 19778). Fixes for the
1.2, as well as the 1.3 are pending.
Thanks for your help,
george.
Ah brilliant. Yes, modulos get me confused in Fortran as well (there are
2 functions in the standard!). Glad, that's
Stephan,
The fix was committed in the trunk (revision 19778). Fixes for the
1.2, as well as the 1.3 are pending.
Thanks for your help,
george.
On Oct 20, 2008, at 5:43 PM, George Bosilca wrote:
Stephen,
I think you're completely right, and that I had a wrong
understanding of the
George Bosilca wrote:
Stephan,
You might be right. intptr_t is a signed type, which allows the result
of % to be potentially negative. However, on the other side, mod is
defined as a size_t which [based on my memory] is definitively
unsigned as it represent a size.
Did you try to apply
Stephan,
You might be right. intptr_t is a signed type, which allows the result
of % to be potentially negative. However, on the other side, mod is
defined as a size_t which [based on my memory] is definitively
unsigned as it represent a size.
Did you try to apply your patch to Open MPI
George Bosilca wrote:
I did investigate this issue for about 3 hours yesterday. Neither
valgrind nor efence report any errors on my cluster. I'm using debian
unstable with gcc-4.1.2. Adding printfs doesn't shows the same output
as you, all addresses are in the correct range. I went over the
I did investigate this issue for about 3 hours yesterday. Neither
valgrind nor efence report any errors on my cluster. I'm using debian
unstable with gcc-4.1.2. Adding printfs doesn't shows the same output
as you, all addresses are in the correct range. I went over the code
manually, and
Would someone mind having another look at the bug reported below? I'm
hitting exactly the same problem with Debian Unstable, openmpi
1.2.7~rc2. Both valgrind and efence are indispensable tools for any
developper, where both may catch errors the other won't report.
Electric fence is
Patrick,
I'm unable to reproduce the buffer overrun with the latest trunk. I
run valgrind (with the memchekcer tool) on a regular basis on the
trunk, and I never noticed anything like that. Moreover, I went over
the code, and I cannot imagine how we can overrun the buffer in the
code you
