[Bug fortran/56581] New: seg fault

[Bug fortran/56581] New: seg fault

[walt.brainerd at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581

             Bug #: 56581
           Summary: seg fault
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: walt.brainerd@gmail.com


Created attachment 29630
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29630
Fixed-form Fortran source

The code is in error as the statement function
is commented out, but seg error . . .

$ gfortran -c rate1.f
rate1.f: In function 'rate1':
rate1.f:36:0: internal compiler error: Segmentation fault
       END                                                              
MCL23370
 ^
libbacktrace could not find executable to open

========================

$ gfortran --version
GNU Fortran (GCC) 4.8.0 20130302 (experimental) [trunk revision 196403]
Copyright (C) 2013 Free Software Foundation, Inc.

========================

Windows 7 running under cygwin, bash.

[Bug fortran/56581] seg fault

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu.org

--- Comment #1 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-03-10 12:22:54 UTC ---
Unfortunately, I cannot reproduct this on Linux (also not
with valgrind).

> The code is in error as the statement function
> is commented out, but seg error . . .

> Windows 7 running under cygwin, bash.

The code, as attached, has

C                                                                      
MCL23200
      AKF(A,B,E,X)=A*EXP(-B*E)*X                                       
MCL23210

which I presume is the statement function.  It is not commented out,
as far as I can see.

Is it possible for you to run f951.exe under gdb?  This might
give us some more information to work on.

[Bug fortran/56581] seg fault

[walt.brainerd at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581

--- Comment #2 from Walt Brainerd <walt.brainerd at gmail dot com> 2013-03-10 16:03:37 UTC ---
Sorry, I was trying lots of different experiments and apparently
removed the ! before attaching the file.

I put it back in and now cannot reproduce the error.

Ignore this for now and I will let you know if I come up with
something again that is more useful to you.

After sending the bug report, I discovered another strange thing.
The first 24? bits of the file are junk that does not show up in any
editor. "cat" shows a little open rectangle and "od" shows it.
(These files were sent to me by somebody else.)

Sorry to trouble you and thanks for the work you guys do
on gfortran.

On Sun, Mar 10, 2013 at 5:22 AM, tkoenig at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> wrote:

>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581
>
> Thomas Koenig <tkoenig at gcc dot gnu.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |tkoenig at gcc dot
> gnu.org
>
> --- Comment #1 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-03-10
> 12:22:54 UTC ---
> Unfortunately, I cannot reproduct this on Linux (also not
> with valgrind).
>
> > The code is in error as the statement function
> > is commented out, but seg error . . .
>
> > Windows 7 running under cygwin, bash.
>
> The code, as attached, has
>
> C
> MCL23200
>       AKF(A,B,E,X)=A*EXP(-B*E)*X
> MCL23210
>
> which I presume is the statement function.  It is not commented out,
> as far as I can see.
>
> Is it possible for you to run f951.exe under gdb?  This might
> give us some more information to work on.
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>

[Bug fortran/56581] seg fault

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-03-10
     Ever Confirmed|0                           |1

--- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-03-10 16:29:19 UTC ---
No problem :-)

Changing the bug status to WAITING, then.

[Bug fortran/56581] seg fault

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-03-10 19:24:31 UTC ---
(In reply to comment #2)
> After sending the bug report, I discovered another strange thing.
> The first 24? bits of the file are junk that does not show up in any
> editor. "cat" shows a little open rectangle and "od" shows it.
> (These files were sent to me by somebody else.)

The extra bytes could be a Unicode byte-order marker? Especially under Windows,
some editors like to insert them:
https://en.wikipedia.org/wiki/UTF-8#Byte_order_mark

[Bug fortran/56581] seg fault

[walt.brainerd at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581

--- Comment #5 from Walt Brainerd <walt.brainerd at gmail dot com> 2013-03-10 19:39:42 UTC ---
I think that is exactly what they were (wrote a little
program to get rid of them).

The files were produced by OCR and then edited (not by me), so that
is all possible.

Thanks for pointing this out to me.

The Intel compiler seemed to completely ignore them,
but gfortran sometimes bombed and sometimes didn't
with f951.exe: out of memory . . . gfortran compiles all
the files in the set without a problem now. It is possible
that also caused the internal compiler error, but who knows.

On Sun, Mar 10, 2013 at 12:24 PM, burnus at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> wrote:

>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581
>
> Tobias Burnus <burnus at gcc dot gnu.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |burnus at gcc dot gnu.org
>
> --- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-03-10
> 19:24:31 UTC ---
> (In reply to comment #2)
> > After sending the bug report, I discovered another strange thing.
> > The first 24? bits of the file are junk that does not show up in any
> > editor. "cat" shows a little open rectangle and "od" shows it.
> > (These files were sent to me by somebody else.)
>
> The extra bytes could be a Unicode byte-order marker? Especially under
> Windows,
> some editors like to insert them:
> https://en.wikipedia.org/wiki/UTF-8#Byte_order_mark
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>

[Bug fortran/56581] seg fault

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-11 10:17:47 UTC ---
Thus all fine.

[Bug fortran/56581] Segfault when reading source file which starts with a byte-order mark (-cpp works)

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |
            Summary|seg fault                   |Segfault when reading
                   |                            |source file which starts
                   |                            |with a byte-order mark
                   |                            |(-cpp works)
     Ever Confirmed|1                           |0

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-03-11 10:51:32 UTC ---
For completeness, the first line of the attachment starts with (od -x):

0000000 bbef 43bf 2020 2020 2020 2020 2020 2020

EF BB BF  is the byte-order mark. (Followed by "C" and " ".)


It works if one uses "-cpp" as, seemingly, libcpp supports this. I think we
should consider supporting those BOM.

[Bug fortran/56581] Segfault when reading source file which starts with a byte-order mark (-cpp works)

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code,
                   |                            |rejects-valid
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|2013-03-10 00:00:00         |2013-03-12
     Ever Confirmed|0                           |1

--- Comment #8 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-03-12 22:05:12 UTC ---
We try to support this, but apparently it doesn't work
(see line 2015 and following of scanner.c).

Same thing happens for 4.6 and 4.7.

Valgrind tells me

==11226== Memcheck, a memory error detector
==11226== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==11226== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==11226== Command: /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/f951 ice.f
==11226== 
==11226== Invalid write of size 4
==11226==    at 0x580400: load_line(_IO_FILE*, unsigned int**, int*, int
const*) (scanner.c:1646)
==11226==    by 0x5811C3: load_file(char const*, char const*, bool)
(scanner.c:2009)
==11226==    by 0x582F82: gfc_new_file() (scanner.c:2120)
==11226==    by 0x5A1DA7: gfc_init() (f95-lang.c:224)
==11226==    by 0x94F286: toplev_main(int, char**) (toplev.c:1700)
==11226==    by 0x5A38454: (below main) (in /lib64/libc-2.15.so)
==11226==  Address 0x5ea3e30 is 0 bytes after a block of size 288 alloc'd
==11226==    at 0x4C292B8: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11226==    by 0xE54110: xcalloc (xmalloc.c:162)
==11226==    by 0x58155E: load_file(char const*, char const*, bool)
(scanner.c:2030)
==11226==    by 0x582F82: gfc_new_file() (scanner.c:2120)
==11226==    by 0x5A1DA7: gfc_init() (f95-lang.c:224)
==11226==    by 0x94F286: toplev_main(int, char**) (toplev.c:1700)
==11226==    by 0x5A38454: (below main) (in /lib64/libc-2.15.so)

[Bug fortran/56581] Segfault when reading source file which starts with a byte-order mark (-cpp works)

[walt.brainerd at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581

--- Comment #9 from Walt Brainerd <walt.brainerd at gmail dot com> 2013-03-13 16:12:35 UTC ---
Thanks for sending me this.

Maybe I did after all provide something that will help you.

On Tue, Mar 12, 2013 at 3:05 PM, tkoenig at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> wrote:

>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581
>
> Thomas Koenig <tkoenig at gcc dot gnu.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>            Keywords|                            |ice-on-invalid-code,
>                    |                            |rejects-valid
>              Status|UNCONFIRMED                 |NEW
>    Last reconfirmed|2013-03-10 00:00:00         |2013-03-12
>      Ever Confirmed|0                           |1
>
> --- Comment #8 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-03-12
> 22:05:12 UTC ---
> We try to support this, but apparently it doesn't work
> (see line 2015 and following of scanner.c).
>
> Same thing happens for 4.6 and 4.7.
>
> Valgrind tells me
>
> ==11226== Memcheck, a memory error detector
> ==11226== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==11226== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==11226== Command: /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/f951
> ice.f
> ==11226==
> ==11226== Invalid write of size 4
> ==11226==    at 0x580400: load_line(_IO_FILE*, unsigned int**, int*, int
> const*) (scanner.c:1646)
> ==11226==    by 0x5811C3: load_file(char const*, char const*, bool)
> (scanner.c:2009)
> ==11226==    by 0x582F82: gfc_new_file() (scanner.c:2120)
> ==11226==    by 0x5A1DA7: gfc_init() (f95-lang.c:224)
> ==11226==    by 0x94F286: toplev_main(int, char**) (toplev.c:1700)
> ==11226==    by 0x5A38454: (below main) (in /lib64/libc-2.15.so)
> ==11226==  Address 0x5ea3e30 is 0 bytes after a block of size 288 alloc'd
> ==11226==    at 0x4C292B8: calloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==11226==    by 0xE54110: xcalloc (xmalloc.c:162)
> ==11226==    by 0x58155E: load_file(char const*, char const*, bool)
> (scanner.c:2030)
> ==11226==    by 0x582F82: gfc_new_file() (scanner.c:2120)
> ==11226==    by 0x5A1DA7: gfc_init() (f95-lang.c:224)
> ==11226==    by 0x94F286: toplev_main(int, char**) (toplev.c:1700)
> ==11226==    by 0x5A38454: (below main) (in /lib64/libc-2.15.so)
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>