Fortran - Re: ifort bug

Author

Re: ifort bug

tholen@antispam.ham

2004-03-27, 12:16 am

Giulia Paramour writes:

[color=darkred]
> I had a very similar problem. It turned out to be because I was using
> a version of the glibc library that wasn't released yesterday.
> Basically, ifort will crash without warning if you have a glibc
> earlier than 2.2.5 (I was using 2.2.4).
>
> Which version of glibc do you have? ('rpm -q glibc').

glibc-2.3.2-27.9.7

I don't know how to interpret that string.

> I have encountered lots of other compiler errors with ifort -
> but I suspect the above might be the relevant one.

Today I encountered the most bizarre problem ever with any Fortran
compiler. Built a program, tested it, and it ran fine. Released
it for use by a colleague who has an account on the same machine.
When he runs the program, it spits out error messages that were
generated in subroutines (invalid arguments passed to the routine).
If I run the program from my office via an ssh process using the
exact same set of conditions, the error messages don't occur. If
I run the program from the console in my colleague's office, the
error messages occur. If I telnet from that console to a different
machine, then ssh from that different machine back into the machine
whose console I'm on, the program runs without the error messages.

Adding to the puzzle is the fact that the error messages get
generated when reading from one data file, but not from another.
But when I run the program over the network via ssh, both data
files are handled without error.

Mind boggling.

Pierre Asselin

2004-03-27, 12:16 am

tholen@antispam.ham wrote:

> Today I encountered the most bizarre problem ever with any Fortran
> compiler. Built a program, tested it, and it ran fine. Released
> it for use by a colleague who has an account on the same machine.
> When he runs the program, it spits out error messages that were
> generated in subroutines (invalid arguments passed to the routine).
> If I run the program from my office via an ssh process using the
> exact same set of conditions, the error messages don't occur. If
> I run the program from the console in my colleague's office, the
> error messages occur.

What happens if, from your colleague's console, you su to your account
and run the program? What happens if you "su -" ?

> If I telnet from that console to a different
> machine, then ssh from that different machine back into the machine
> whose console I'm on, the program runs without the error messages.

It sounds like a difference in user environment between your two
accounts. Ask the administrator to give you a completely uncustomized
temporary account for testing.

> Adding to the puzzle is the fact that the error messages get
> generated when reading from one data file, but not from another.
> But when I run the program over the network via ssh, both data
> files are handled without error.

What are the permissions on the offending file?

--
pa at panix dot com

Dr Chaos

2004-03-27, 12:17 am

tholen@antispam.ham <tholen@antispam.ham> wrote:
> Giulia Paramour writes:
>
>
>
> glibc-2.3.2-27.9.7
>
> I don't know how to interpret that string.
>
>
> Today I encountered the most bizarre problem ever with any Fortran
> compiler. Built a program, tested it, and it ran fine. Released
> it for use by a colleague who has an account on the same machine.
> When he runs the program, it spits out error messages that were
> generated in subroutines (invalid arguments passed to the routine).
> If I run the program from my office via an ssh process using the
> exact same set of conditions, the error messages don't occur. If
> I run the program from the console in my colleague's office, the
> error messages occur. If I telnet from that console to a different
> machine, then ssh from that different machine back into the machine
> whose console I'm on, the program runs without the error messages.
>
> Adding to the puzzle is the fact that the error messages get
> generated when reading from one data file, but not from another.
> But when I run the program over the network via ssh, both data
> files are handled without error.

It may be in the LD_LIBRARY_PATH or LD_ASSUME_KERNEL or something like
that.

I have this in my .tchsrc

if ( -f /autohome/local/intel/intel_fc_80/bin/ifortvars.csh ) then
source /autohome/local/intel/intel_fc_80/bin/ifortvars.csh
endif

>
> Mind boggling.
>

Rich Townsend

2004-03-27, 12:17 am

Dr Chaos wrote:
> tholen@antispam.ham <tholen@antispam.ham> wrote:
>
>
>
> It may be in the LD_LIBRARY_PATH or LD_ASSUME_KERNEL or something like
> that.
>

If it is an LD_LIBRARY_PATH problem -- where the executable is being dynamically
linked to different libraries when you are using different accounts -- then the
way to track it down is ldd. This useful proggy, which is a standard UN*X tool,
shows which libraries will be linked against at runtime. For example:

rhdt@cmell boojum_lite $ ldd boojum_lite
linux-gate.so.1 => (0xffffe000)
libg2c.so.0 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libg2c.so.0 (0x4001f000)
libm.so.6 => /lib/libm.so.6 (0x4003c000)
libcxa.so.5 => /opt/intel/intel_fc_80/lib/libcxa.so.5 (0x4005d000)
libunwind.so.5 => /opt/intel/intel_fc_80/lib/libunwind.so.5 (0x40083000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40089000)
libc.so.6 => /lib/libc.so.6 (0x400d9000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Dr Chaos

2004-03-27, 12:17 am

Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
> If it is an LD_LIBRARY_PATH problem -- where the executable is being dynamically
> linked to different libraries when you are using different accounts -- then the
> way to track it down is ldd. This useful proggy, which is a standard UN*X tool,
> shows which libraries will be linked against at runtime. For example:
>
> rhdt@cmell boojum_lite $ ldd boojum_lite
> linux-gate.so.1 => (0xffffe000)
> libg2c.so.0 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libg2c.so.0 (0x4001f000)
> libm.so.6 => /lib/libm.so.6 (0x4003c000)
> libcxa.so.5 => /opt/intel/intel_fc_80/lib/libcxa.so.5 (0x4005d000)
> libunwind.so.5 => /opt/intel/intel_fc_80/lib/libunwind.so.5 (0x40083000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x40089000)
> libc.so.6 => /lib/libc.so.6 (0x400d9000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Oooh, I hated that libcxa stuff.

There's an obscure option, finally documented long after it was there,

-static-libcxa

I generally want my programs to link only to standard distribution
libraries, and not Fortran specific libs, as much as possible.

Easier to move the binary.

tholen@antispam.ham

2004-03-27, 12:17 am

Pierre Asselin writes:

[color=darkred]
> What happens if, from your colleague's console, you su to your account
> and run the program? What happens if you "su -" ?

No longer matters. We solved the problem. Turns out that ifc
handled byte swapping by having the user set an environment variable
specifying the logical unit numbers that should be subjected to
byte swapping. My colleague had, a long time ago, set such an
environment variable to make another program work, so it dutifully
swapped the bytes of a data file that wasn't supposed to have its
bytes swapped. The result was a lot of negative numbers, and the
routines that couldn't swallow negative numbers would generate the
error messages. We much prefer the way that ifort handles byte
swapping. Now if only ifort could solve the segmentation fault
problem.

[color=darkred]
> It sounds like a difference in user environment between your two
> accounts. Ask the administrator to give you a completely uncustomized
> temporary account for testing.

[color=darkred]
> What are the permissions on the offending file?

Now immaterial.

Sponsored Links