About 'error stop' statement

About 'error stop' statement

[Angelo Graziosi]

Consider the following test case:

$ cat foo.f90
program foo
   implicit none
   print *, 'Hello...'
   error stop
   print *, '..world!'
end program foo

and compile with:

$ gfortran foo.f90

I get the following.

(1) on MSYS2 (Windows), gfortran-6.3.0

$ ./a.exe
  Hello...
ERROR STOP

Error termination. Backtrace:

Program received signal SIGSEGV: Segmentation fault - invalid memory 
reference.

Backtrace for this error:


(2) on MSYS2/MINGW64 (Windows), gfortran-7.1.0

$ ./a.exe
  Hello...
ERROR STOP

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0  0xffffffff
#1  0xffffffff
#2  0xffffffff
#3  0xffffffff
#4  0xffffffff
#5  0xffffffff
#6  0xffffffff
#7  0xffffffff
#8  0xffffffff
#9  0xffffffff


(3) on MacPorts (macOS), gfortran 6.3.0

$ ./a.out
  Hello...
ERROR STOP

Error termination. Backtrace:
#0  0x10b907e46
#1  0x10b908718
#2  0x10b909326
#3  0x10b8ffe6a
#4  0x10b8ffea0


(4) on Windows Subsystem for Linux (Ubuntu 16.04.3 LTS), gfortran-5.4.0 
20160609

$ ./a.out
  Hello...
ERROR STOP

What is the right output? Sincerely, I don't understand WHY that output 
in (1), (2) and (3)...

Really in (1) it has to produce a Segm. Fault or BT in (2) and (3)?

Thanks,
    Angelo.

Re: About 'error stop' statement

[Anton Shterenlikht]

>What is the right output?
 
All of the above outputs are acceptable.
 
> Sincerely, I don't understand WHY that output
>in (1), (2) and (3)...
>
>Really in (1) it has to produce a Segm. Fault or BT in (2) and (3)?
>
>Thanks,
>    Angelo.
 
ERROR STOP initiates error termination.
The standard says, N2134, 5.3.7p3 [42:16-17]:
"When error termination on an image has been
initiated, the processor should initiate
error termination on other images as quickly
as possible."

Basically, anything can happen. 
If calling MPI_abort is deemed by the implementors
to be the quickest way, then this is acceptable.
If an image has initiated error termination, it's
data might or might not be accessible from other images.
If other images try to access it's data before they
realise that error termination was initiated, you 
can segfaults or MPI errors or any other error, really.
None of this matters, because the aim of error termination
is to quit the execution on all images as fast as possible.
The way this is achieved does not matter.

Anton

Re: About 'error stop' statement

[Angelo Graziosi]

Ciao Anton,

Il 06/08/2017 14:23, Anton Shterenlikht ha scritto:> All of the above 
outputs are acceptable.
> ERROR STOP initiates error termination.
> The standard says, N2134, 5.3.7p3 [42:16-17]:
> "When error termination on an image has been
> initiated, the processor should initiate
> error termination on other images as quickly
> as possible."
> 
> Basically, anything can happen.
> If calling MPI_abort is deemed by the implementors
> to be the quickest way, then this is acceptable.
> If an image has initiated error termination, it's
> data might or might not be accessible from other images.
> If other images try to access it's data before they
> realise that error termination was initiated, you
> can segfaults or MPI errors or any other error, really.
> None of this matters, because the aim of error termination
> is to quit the execution on all images as fast as possible.
> The way this is achieved does not matter.

when this morning I saw "Program received signal SIGSEGV: Segmentation 
fault - invalid memory reference." in the example n. (1), I tried to 
figure out what was happening in my apps because, a few months ago, it 
did not occur.. and so I tried with the test case..

So a change between versions 5.x and 6.x of gfortran is causing this, 
likely because now 'error stop' is more standard conform.

Really I consider this very misleading, maybe I have to replace the new 
"error stop" with the old 'stop' statement.

Thanks for clarification.

Ciao,
  Angelo.

Re: About 'error stop' statement

[Anton Shterenlikht]

From angelo.graziosi@alice.it Sun Aug  6 16:21:15 2017
>
>Really I consider this very misleading, maybe I have to replace the new 
>"error stop" with the old 'stop' statement.

STOP and ERROR STOP are designed for different situations.
They behave in different ways.
So you need to decide what behaviour you need
and use an appropriate statement.
It is normal for coarray codes to use STOP
in some places and ERROR STOP in others.

Anton

Re: About 'error stop' statement

[Angelo Graziosi]

Ciao Damian,

I am afraid but I never used OpenCoarrays and that kind of programming..

Does this test case

$ cat foo.f90
program foo
   implicit none
   print *, 'Hello...'
   error stop
   print *, '..world!'
end program foo

use coarrays? Why should 'error stop' flag that there was a segfault and 
memory corruption? reread my OP...

For what I can see, some changes between 5.x and >= 6.x cause this. When 
I used 5.x on MSYS2/MINGW32/MINGW64 on Windows or on OSX (aka macOS) or 
on GNU/Linux Mint, there only was the output of example (4) in my OP.

In any case, now I am returning to the old STOP statement...

Thanks,
  Angelo.

Il 07/08/2017 02:06, Damian Rouson ha scritto:
> Hi Angelo,
> 
> I agree that the seg fault is confusing.  Because you’re using gfortran 5.4 in the Windows Subsystem for Linux, I’m guessing you used the OpenCoarrays windows-install.sh installs.  If you have no need for multi-image execution, then switching to STOP might be the easiest solution for you.
> 
> If you do want multi-image execution, then it would be really helpful to the OpenCoarrays project if you could research and share how to install a newer version of the OpenCoarrays prerequisites.  That would reduce the number of versions that need to be supported by OpenCoarrays contributors, who are all volunteers or contractors working on specific pre-assigned tasks.  I wrote the OpenCoarrays windows-install.sh script and I’d be glad to update it to install a newer gfortran if someone can explain the steps.  The results of my attempts are described in OpenCoarrays issue 227.  Building MPICH and CMake failed.  Unfortunately, MPICH no longer supports Windows.
> 
> Damian
> On August 6, 2017 at 8:53:34 AM, Anton Shterenlikht (mexas@bris.ac.uk) wrote:
> 
>From angelo.graziosi@alice.it Sun Aug 6 16:21:15 2017  
>>   
>> Really I consider this very misleading, maybe I have to replace the new
>> "error stop" with the old 'stop' statement.
> 
> STOP and ERROR STOP are designed for different situations.
> They behave in different ways.
> So you need to decide what behaviour you need
> and use an appropriate statement.
> It is normal for coarray codes to use STOP
> in some places and ERROR STOP in others.
> 
> Anton
> 

Re: About 'error stop' statement

[Angelo Graziosi]

Sorry if I insist on this,

Il 07/08/2017 02:06, Damian Rouson ha scritto:
> for Linux, I’m guessing you used the OpenCoarrays windows-install.sh installs


Anton Shterenlikht wrote:
> If calling MPI_abort is deemed by the implementors
> to be the quickest way, then this is acceptable.
> If an image has initiated error termination


but why do you thing I am using coarrays? I never used that and know 
almost nothing about that. The foo.f90 example, I cited, really use 
coarrays?

I knew about 'error stop' reading code on the WEB and that DID NOT use 
coarrays at all (simple rewrite of old code). So all this is very 
confusing, now..

Hmm... sure there isn't a bug somewhere?

Re: About 'error stop' statement

[Janne Blomqvist]

On Mon, Aug 7, 2017 at 9:59 AM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:
> Sorry if I insist on this,
>
> Il 07/08/2017 02:06, Damian Rouson ha scritto:
>>
>> for Linux, I’m guessing you used the OpenCoarrays windows-install.sh
>> installs
>
>
>
> Anton Shterenlikht wrote:
>>
>> If calling MPI_abort is deemed by the implementors
>> to be the quickest way, then this is acceptable.
>> If an image has initiated error termination
>
>
>
> but why do you thing I am using coarrays? I never used that and know almost
> nothing about that. The foo.f90 example, I cited, really use coarrays?
>
> I knew about 'error stop' reading code on the WEB and that DID NOT use
> coarrays at all (simple rewrite of old code). So all this is very confusing,
> now..
>
> Hmm... sure there isn't a bug somewhere?
>

I think the discussion of co-arrays here is entirely irrelevant.
You're not using co-arrays, and no co-array library should be linked
into your binary. What I think you're seeing is

a) In GCC 6, there is some bug in libbacktrace (the library GFortran
uses to print backtraces) on Windows, causing a segfault. This seems
to have been fixed in GCC 7. (I'm blaming libbacktrace here, because
the GFortran ERROR STOP implementation has not changed between 6 and
7. Though it could be some other change in the GCC Windows target
support as well, I guess.)

b) As of GCC 6, it was decided that ERROR STOP should print a
backtrace (IIRC it was discussed on this list, maybe you can dig it up
if you're curious..), which is why you're not seeing it when compiling
with GFortran 5.

-- 
Janne Blomqvist

Re: About 'error stop' statement

[Anton Shterenlikht]

In short, if you know nothing about coarrays
and don't want to use coarrays, then do not
use ERROR STOP.

ERROR STOP was introduced in f2008 specifically
to inititiate error termination in coarray
prorgrams. 

Read the standard, or MFE, or another book
with Fortran 2008 explained.

Anton

Re: About 'error stop' statement

[Damian Rouson]

 



On August 7, 2017 at 2:08:31 AM, Janne Blomqvist (blomqvist.janne@gmail.com(mailto:blomqvist.janne@gmail.com)) wrote:

> On Mon, Aug 7, 2017 at 9:59 AM, Angelo Graziosi  
> wrote:  
>  
>  
> I think the discussion of co-arrays here is entirely irrelevant.  
> You're not using co-arrays, and no co-array library should be linked  
> into your binary.  

I agree. FWIW, I asked whether he used the OpenCoarrays installer, not
whether he’s using coarrays.  He is using the Windows Subsystem for Linux 
(which is not yet common) and GCC 5, which matches what the OpenCoarrays 
requires (WSL) and installs (GCC 5). Also, the use of ERROR STOP seemed
like an indication that the submitted code might have been simplified 
from an application that runs in multiple images (with or without coarrays).

> What I think you're seeing is  
>  
> a) In GCC 6, there is some bug in libbacktrace (the library GFortran  
> uses to print backtraces) on Windows, causing a segfault. This seems  
> to have been fixed in GCC 7. (I'm blaming libbacktrace here, because  
> the GFortran ERROR STOP implementation has not changed between 6 and  
> 7. Though it could be some other change in the GCC Windows target  
> support as well, I guess.)

which is why I’m hoping he’ll solve the issue by upgrading to a newer
version of GCC on WSL and share how he managed to do so.  The only way
I found to do it was to build GCC from source.  I’m hoping there’s a 
way to install a newer version of GCC on WSL via package management.


Damian

Re: About 'error stop' statement

[Tim Prince via fortran]

This week I was able to build and test gcc trunk on wsl.  Recent Microsoft upgrades appear to help.  There was an out of memory condition (6 GB installed) during gcc testsuite as if memory is leaking.

Sent from my Dell Venue8 with Intel RealSense Snapshot.On Aug 7, 2017 12:56, Damian Rouson <damian@sourceryinstitute.org> wrote:
>
>   
>
>
>
> On August 7, 2017 at 2:08:31 AM, Janne Blomqvist (blomqvist.janne@gmail.com(mailto:blomqvist.janne@gmail.com)) wrote: 
>
> > On Mon, Aug 7, 2017 at 9:59 AM, Angelo Graziosi  
> > wrote:  
> >  
> >  
> > I think the discussion of co-arrays here is entirely irrelevant.  
> > You're not using co-arrays, and no co-array library should be linked  
> > into your binary.  
>
> I agree. FWIW, I asked whether he used the OpenCoarrays installer, not 
> whether he’s using coarrays.  He is using the Windows Subsystem for Linux  
> (which is not yet common) and GCC 5, which matches what the OpenCoarrays  
> requires (WSL) and installs (GCC 5). Also, the use of ERROR STOP seemed 
> like an indication that the submitted code might have been simplified  
> from an application that runs in multiple images (with or without coarrays). 
>
> > What I think you're seeing is  
> >  
> > a) In GCC 6, there is some bug in libbacktrace (the library GFortran  
> > uses to print backtraces) on Windows, causing a segfault. This seems  
> > to have been fixed in GCC 7. (I'm blaming libbacktrace here, because  
> > the GFortran ERROR STOP implementation has not changed between 6 and  
> > 7. Though it could be some other change in the GCC Windows target  
> > support as well, I guess.) 
>
> which is why I’m hoping he’ll solve the issue by upgrading to a newer 
> version of GCC on WSL and share how he managed to do so.  The only way 
> I found to do it was to build GCC from source.  I’m hoping there’s a  
> way to install a newer version of GCC on WSL via package management. 
>
>
> Damian 
>
>