Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28381 Discussions

Transfer of control specifiers END ERR 10.1.015 problem

Rich_F_1
New Contributor I
465 Views
I ran into an odd problem with the Transfer of control specifiers END ERR
when I recompiled all our code with ifort and icc versions 10.1.015.

The premier support team has punted on this issue probably because
the problem only shows up when the code is run by an apache server
version Apache/2.2.3 (Linux/SUSE)

It runs fine in the debugger and when the code is compiled with
ifort version 9.1.052 and icc version 9.1.053

I have put together an example that reads two namelist files. The
second file does not have the second namelist thus invoking
the ERR transfer of control condition. With the older
compiler version 9.1 it works fine with the apache server.
With the new compiler version 10.1 the apache server throws
a Premature end of script header error when it hits the ERR
condition when trying to read the missing namelist.

I am hoping there is a simple fix for this problem since
I do not want to be stuck at version 9.1 of the compilers.

Attached is a zip file which contains an example
which demonstrates the problem and the cgic code
needed to work with the apache server.

The test_file_read.zip also contains the generated assembly
code for 9.1.052 and 10.1.015. I cannot see any
significant differences but then again my assembly
skills are 20 years out of date.

Any help with problem would be appreciated.

Please feel free to contact me if you have any questions.

Rich Fleck

0 Kudos
9 Replies
Steven_L_Intel1
Employee
465 Views
Whatever the difference is, it is likely to be in the run-time library and not the compiler, so the ASM file is probably not useful. To test that, take the .o compiled with 9.1 and link it with 10.1 and see if the problem persists.

Can you come up with a standalone reproducer that does not require running this in the context of Apache? I don't know anything about the Apache environment.
0 Kudos
Rich_F_1
New Contributor I
465 Views
I took the 9.1 version .o file and linked it with the 10.1 compiler environment
and the problem persisted.

I then took the 10.1 .o file and linked it with the 9.1 compiler environment
and the code worked fine with the apache server.

I cannot come up with a standalone reproducer. That is what
makes this problem so vexing. It seems like there is an error signal
being thrown that the apache server catches and uses to
terminate the execution.

I am slogging my way through the apache documentation but
have not come up with any configuration setting that might
help in diagnosing the problem.


Rich

0 Kudos
Steven_L_Intel1
Employee
465 Views
If you can, define the environment variable FOR_DIAGNOSTIC_LOG_FILE to be a file path before running the program. This will cause the Fortran run-time system to write any error messages to the specified file rather than to the "console". You can also use selective writes to a file to determine which specific operation triggers the error.

How is the data file produced? Is it an actual file or is it a pipe or something like that?
0 Kudos
Rich_F_1
New Contributor I
465 Views

After spending too much time with this problem,
my best guess is the NLSPATH implementation
for looking up the ifcore_msg.msg file and
reading the error message in it
does not work properly in a mixed language application
compiled with 10.1 when called by an apache server.

When the program is split into a C++ cgi frontend
which uses a simple system call to a test_file_read backend
compiled with 10.1 the apache server has no problem.

I am curious as to why the need to set the
NLSPATH environment variable is not necessary
in the 9.1 compiler. Was it dropped because
of problems?

Setting the FOR_DIAGNOSTIC_LOG_FILE did not help
I even tried setting TBK_ENABLE_VERBOSE_STACK_TRACE

As for the data file in this pared down test case
it is just sitting in /usr/tmp directory.
The 9.1 compiler has no problem handling it properly.

Rich

0 Kudos
Steven_L_Intel1
Employee
465 Views
Sigh - I gave you the wrong environment variable. It's FOR_DIAGNOSTIC_LOGFILE.

I have a vague memory that we were not using NLSPATH in 9.1. I will have to ask someone else about this.
0 Kudos
Rich_F_1
New Contributor I
465 Views
No Steve you were right it is FOR_DIAGNOSTIC_LOG_FILE
according to the
Setting Run-Time Environment Variables page.

I called the mixed language program using a system call and strace
through the apache server and got this.

31854 write(3, " before Reading NAMELIST_2 ", 28) = 28
31854 read(10, " $NAMELIST_1 character_string "..., 4096) = 132
31854 read(10, "", 4096) = 0
31854 open("/CDs/opt/intel/fce/10.1.015/lib/locale/en_US", O_RDONLY) = 11
31854 fstat(11, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
31854 close(11) = 0
31854 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
31854 +++ killed by SIGSEGV +++

Where as I get this when I call the mixed language program
from the command line with strace

32027 write(3, " before Reading NAMELIST_2 ", 28) = 28
32027 read(4, " $NAMELIST_1 character_string "..., 4096) = 132
32027 read(4, "", 4096) = 0
32027 open("/CDs/opt/intel/fce/10.1.015/lib/locale/en_US", O_RDONLY) = 5
32027 fstat(5, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
32027 close(5) = 0
32027 open("/CDs/opt/intel/fce/10.1.015/lib/locale/en_US", O_RDONLY) = 5
32027 fstat(5, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
32027 close(5) = 0
32027 write(3, " after continue ", 18) = 18

The apache server has a problem with the second attempt to open
the NLSPATH file.

I'm curious as to why the open does not say
open("/CDs/opt/intel/fce/10.1.015/lib/locale/en_US/ifcore_msg.msg", O_RDONLY)

Rich


0 Kudos
Steven_L_Intel1
Employee
465 Views
The open is correct - it's looking to see if the directory exists.

Is the LANG value defined in this environment, and if so, to what?
0 Kudos
Rich_F_1
New Contributor I
465 Views
Bingo!

LANG was not set.

Adding

SetEnv LANG en_US.UTF-8

to the httpd.conf.local fixed the problem.

So it is checking to see if the file exists upon every ERR or END
transfer but not reading it?

Thank you for your help in tracking down this problem.
I did not want to get stuck on version 9.1

Rich
0 Kudos
Steven_L_Intel1
Employee
465 Views
Any time an error condition occurs, it looks for the message catalog. In my discussion with the libraries developmemt lead engineer, he noted that there could be a problem if LANG was not defined or had a value longer than 40 characters. I'll report to him that this was your problem and ask him to fix this for a future version.
0 Kudos
Reply