Jeff,
Can you disassemble this function (from gdb) and post the assembly
code ? This might help us to see what's wrong there.
Thanks,
george.
On Jul 28, 2007, at 8:42 AM, Jeff Squyres wrote:
Ricardo was generous to give me access to two configurations with the
Intel 10 compilers:
1.
Ricardo was generous to give me access to two configurations with the
Intel 10 compilers:
1. 64 bit EMT64 desktop / server
2. 32 bit centrino-based laptop
On the 64 bit platform, both the 32 bit and 64 bit intel compilers
worked fine with Open MPI.
On the 32 bit platform, I was able to rep
> > From: Jeff Squyres
> >
> > Can you be a bit more specific than "it dies"? Are you talking about
> > mpif90/mpif77, or your app?
>
> Sorry, tuspid me. When executing mpif90 or mpif77 I have a segfault and it
> doesn't compile. I've tried both with or without input (i.e., giving it
> something t
On Fri, 13 Jul 2007, Jeff Squyres wrote:
Ah -- intel 10. I think you said this before but I blew right past
it. I have not personally tested with intel 10; I don't know if
anyone else on the team has.
I've just installed, compiled and tested OMPI with intel 10. in a PentIV
with EMT64 and it
Ah -- intel 10. I think you said this before but I blew right past
it. I have not personally tested with intel 10; I don't know if
anyone else on the team has.
My support guy here at Cisco tells me that he's got a license for it
and has been looking for an excuse to spend some time to ins
On Thu, 12 Jul 2007, Jeff Squyres wrote:
I admit to being baffled. :-(
My systems seem to have that effect on people... :)
If general C++ applications seem to be working with icc/icpc, I do
not know why OMPI would fail for you with icc/icpc (especially while
accessing stack memory). What v
I admit to being baffled. :-(
If general C++ applications seem to be working with icc/icpc, I do
not know why OMPI would fail for you with icc/icpc (especially while
accessing stack memory). What version of icc/icpc are you using?
There were some bugs in the 8.x series that caused proble
On Wed, 11 Jul 2007, Jeff Squyres wrote:
LAM uses C++ for the laminfo command and its wrapper compilers (mpicc
and friends). Did you use those successfully?
yes, no problem.
attached out from laminfo -all
strace laminfo
greets,
Ricardo Reis
'Non Serviam'
PhD student
On Jul 11, 2007, at 10:52 AM, Ricardo Reis wrote:
Whoa -- if you are failing here, something is definitely wrong: this
is failing when accessing stack memory!
Are you able to compile/run other trivial and non-trivial C++
applications using your Intel compiler installation?
Please ignore my la
On Tue, 10 Jul 2007, Jeff Squyres wrote:
Whoa -- if you are failing here, something is definitely wrong: this
is failing when accessing stack memory!
Are you able to compile/run other trivial and non-trivial C++
applications using your Intel compiler installation?
Please ignore my last reply.
On Tue, 10 Jul 2007, Jeff Squyres wrote:
Whoa -- if you are failing here, something is definitely wrong: this
is failing when accessing stack memory!
Are you able to compile/run other trivial and non-trivial C++
applications using your Intel compiler installation?
I don't have trivial or non-
Whoa -- if you are failing here, something is definitely wrong: this
is failing when accessing stack memory!
Are you able to compile/run other trivial and non-trivial C++
applications using your Intel compiler installation?
On Jul 10, 2007, at 12:10 PM, Ricardo Reis wrote:
On Mon, 9 Jul
On Mon, 9 Jul 2007, Jeff Squyres wrote:
Ok, that unfortunately doesn't make much sense -- I don't know what
opal_event_set() inside opal_event_init() would cause a segv.
Can you recompile OMPI with -g and re-run this test? The "where"
information from gdb will then give us more information.
Ok, that unfortunately doesn't make much sense -- I don't know what
opal_event_set() inside opal_event_init() would cause a segv.
Can you recompile OMPI with -g and re-run this test? The "where"
information from gdb will then give us more information.
On Jul 5, 2007, at 12:38 PM, Ricardo
Has requested:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1214711408 (LWP 23581)]
0xb7eb9d98 in opal_event_set ()
from /usr/local/share/openmpi-1.2.3.icc.ifort/lib/libopen-pal.so.0
(gdb) where
#0 0xb7eb9d98 in opal_event_set ()
from /usr/local/share/openm
There is another piece of information that can be useful in order to
figure out what's wrong. If you can execute the ompi_info directly in
gdb, run it until it segfault and then send us the output of "where"
and "shared" (both are gdb commands). This will give us access to the
exact locatio
On Thu, 5 Jul 2007, Jeff Squyres wrote:
Yoinks -- that's not good.
I suspect that our included memory manager is borking things up
(Brian: can you comment?). Can you try configuring OMPI --without-
memory-manager?
Yes. It compiles and links OK (execution of mpif90).
Trying to run (mpirun -n
Yoinks -- that's not good.
I suspect that our included memory manager is borking things up
(Brian: can you comment?). Can you try configuring OMPI --without-
memory-manager?
On Jul 4, 2007, at 5:52 PM, Ricardo Reis wrote:
From: Jeff Squyres
Can you be a bit more specific than "it die
From: Jeff Squyres
Can you be a bit more specific than "it dies"? Are you talking about
mpif90/mpif77, or your app?
Sorry, tuspid me. When executing mpif90 or mpif77 I have a segfault and it
doesn't compile. I've tried both with or without input (i.e., giving it
something to compile or ju
19 matches
Mail list logo
