bug-gnucobol
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-GnuCOBOL] Bug-GnuCOBOL Digest, Vol 3, Issue 1

From: Arnold Trembley
Subject: Re: [Bug-GnuCOBOL] Bug-GnuCOBOL Digest, Vol 3, Issue 1
Date: Wed, 29 Mar 2017 21:16:39 +0000 (UTC)
The source code had area-A starting in column 7 and area-B starting in column 11, so I had to shift everything over 1 byte to the right.

It won't compile in GnuCOBOL 2.0 RC2 MinGW using OpenCobolIDE, failing with the following errors:

cobc.exe -x -o C:\GCexe\testmove.exe -std=default -Wall -debug -fnotrunc testmove.cbl
testmove.cbl: 18: warning: handling of parameters passed BY VALUE is unfinished; implementation is likely to be changed
testmove.cbl: 20: error: executable program requested but PROCEDURE/ENTRY has USING clause

If I compile it with the "-m" option to create a .dll file instead of an .exe file, it still gets the warning for line 18, and no .dll file is built.

 
http://www.arnoldtrembley.com/


From: "address@hidden" <address@hidden>
To: address@hidden
Sent: Wednesday, March 29, 2017 8:40 AM
Subject: Bug-GnuCOBOL Digest, Vol 3, Issue 1

Send Bug-GnuCOBOL mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bug-GnuCOBOL digest..."


Today's Topics:

  1. produces uncompilable c code (folkert)
  2. segfaults during compile (folkert)
  3. Re: produces uncompilable c code (Edward Hart)
  4. segfault (folkert)
  5. Re: segfaults during compile (Edward Hart)


----------------------------------------------------------------------

Message: 1
Date: Wed, 29 Mar 2017 13:11:04 +0200
From: folkert <address@hidden>
Subject: [Bug-GnuCOBOL] produces uncompilable c code
Message-ID:
Content-Type: text/plain; charset=iso-8859-1

Hi,

The following cobol code (which runs fine on e.g. microfocus and
most mainframes) causes opencobol 1.1.0 and gnucobol 2.0.0 to produce
invalid C-code:

      IDENTIFICATION DIVISION.
      PROGRAM-ID. TESTMOVE.

      ENVIRONMENT DIVISION.
      CONFIGURATION SECTION.

      DATA DIVISION.
      WORKING-STORAGE SECTION.

      LINKAGE SECTION.
      01 GRP.
          03 BYTES      PIC 9(2) COMP-5 OCCURS 2.

      77  MEM-ADDR    POINTER.

      PROCEDURE DIVISION USING
              BY VALUE MEM-ADDR.

          SET ADDRESS OF BYTES(1) TO MEM-ADDR.

          GOBACK.

      END PROGRAM TESTMOVE.

This results in:

address@hidden:~/cob$ cobc -free test3.cob
/tmp/cob3587_0.c: In function ???TESTMOVE_???:
/tmp/cob3587_0.c:95:15: error: lvalue required as left operand of assignment
    (b_5 + 0) = (*(unsigned char **) (b_7));
              ^



Folkert van Heusden

--
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com



------------------------------

Message: 2
Date: Wed, 29 Mar 2017 11:41:00 +0200
From: folkert <address@hidden>
Subject: [Bug-GnuCOBOL] segfaults during compile
Message-ID:
Content-Type: text/plain; charset=us-ascii

Hi,

I'm trying to build some cobol code usng gnu cobol:
    cobc (GnuCOBOL) 2.0.0
    Packaged  Nov 06 2016 22:36:19 UTC
    C version "6.3.0 20170118"

During the compile the compiler segfaults constantly.
I ran it through valgrind and this found the following:

==2205== Invalid read of size 4
==2205==    at 0x170EA9: lookup_pic (codegen.c:904)
==2205==    by 0x171149: lookup_attr (codegen.c:972)
==2205==    by 0x171580: output_attr (codegen.c:1099)
==2205==    by 0x1723C1: output_field (codegen.c:1515)
==2205==    by 0x17517E: output_param (codegen.c:2777)
==2205==    by 0x175BCB: output_funcall (codegen.c:3012)
==2205==    by 0x17CFF0: output_stmt (codegen.c:6107)
==2205==    by 0x17D3C6: output_stmt (codegen.c:6289)
==2205==    by 0x17CC4F: output_stmt (codegen.c:6027)
==2205==    by 0x181044: output_internal_function (codegen.c:7727)
==2205==    by 0x183B88: codegen (codegen.c:8856)
==2205==    by 0x128ABD: process_translate (cobc.c:5200)
==2205==    by 0x12A700: main (cobc.c:6265)
==2205==  Address 0x686dbb8 is 40 bytes inside a block of size 48 free'd
==2205==    at 0x4C2CDDB: free (vg_replace_malloc.c:530)
==2205==    by 0x11E1FC: cobc_free (cobc.c:712)
==2205==    by 0x12A73F: main (cobc.c:6271)
==2205==  Block was alloc'd at
==2205==    at 0x4C2DBC5: calloc (vg_replace_malloc.c:711)
==2205==    by 0x11E5AB: cobc_parse_malloc (cobc.c:861)
==2205==    by 0x170F76: lookup_pic (codegen.c:926)
==2205==    by 0x171149: lookup_attr (codegen.c:972)
==2205==    by 0x171580: output_attr (codegen.c:1099)
==2205==    by 0x1723C1: output_field (codegen.c:1515)
==2205==    by 0x17517E: output_param (codegen.c:2777)
==2205==    by 0x175BCB: output_funcall (codegen.c:3012)
==2205==    by 0x17CFF0: output_stmt (codegen.c:6107)
==2205==    by 0x17D3C6: output_stmt (codegen.c:6289)
==2205==    by 0x17CC4F: output_stmt (codegen.c:6027)
==2205==    by 0x181044: output_internal_function (codegen.c:7727)
==2205==    by 0x183B88: codegen (codegen.c:8856)
==2205==    by 0x128ABD: process_translate (cobc.c:5200)
==2205==    by 0x12A700: main (cobc.c:6265)

So apparently lookup_pic allocates a block of memory which main frees
and then lookup_pic is trying to use it again.

It looks like cobc_parsemem_base is freed but pic_cache in codegen.c is
still referring to the same address which explodes.

Removing the free()-code (as a test) "solves" the problem (albeit with a
memory leak of course).


Folkert van Heusden

--
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com



------------------------------

Message: 3
Date: Wed, 29 Mar 2017 14:12:32 +0100
From: Edward Hart <address@hidden>
To: folkert <address@hidden>
Subject: Re: [Bug-GnuCOBOL] produces uncompilable c code
Message-ID:
    <CANV9pvvnrDD6ZdPmTQojRMQ_HXWSSU3_xE5SVV0Q-tg4746=address@hidden>
Content-Type: text/plain; charset="utf-8"

Thanks for the report, Folkert. I've added added it as bug #366
tracker and I'll look into it shortly.

Edward

On 29 March 2017 at 12:11, folkert <address@hidden> wrote:

> Hi,
>
> The following cobol code (which runs fine on e.g. microfocus and
> most mainframes) causes opencobol 1.1.0 and gnucobol 2.0.0 to produce
> invalid C-code:
>
>        IDENTIFICATION DIVISION.
>        PROGRAM-ID. TESTMOVE.
>
>        ENVIRONMENT DIVISION.
>        CONFIGURATION SECTION.
>
>        DATA DIVISION.
>        WORKING-STORAGE SECTION.
>
>        LINKAGE SECTION.
>        01 GRP.
>          03 BYTES      PIC 9(2) COMP-5 OCCURS 2.
>
>        77  MEM-ADDR    POINTER.
>
>        PROCEDURE DIVISION USING
>                BY VALUE MEM-ADDR.
>
>            SET ADDRESS OF BYTES(1) TO MEM-ADDR.
>
>            GOBACK.
>
>        END PROGRAM TESTMOVE.
>
> This results in:
>
> address@hidden:~/cob$ cobc -free test3.cob
> /tmp/cob3587_0.c: In function ???TESTMOVE_???:
> /tmp/cob3587_0.c:95:15: error: lvalue required as left operand of
> assignment
>      (b_5 + 0) = (*(unsigned char **) (b_7));
>                ^
>
>
>
> Folkert van Heusden
>
> --
> ----------------------------------------------------------------------
> Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 4
Date: Wed, 29 Mar 2017 15:38:16 +0200
From: folkert <address@hidden>
Subject: [Bug-GnuCOBOL] segfault
Message-ID:
Content-Type: text/plain; charset=us-ascii

Hi,

I have the following two sources. When run, it runs fine under micro
focus but segfaults under opencobol 1.1.0.
I'm not 100% sure this is valid cobol code, only a beginner :-)

test3.cob
---------
      IDENTIFICATION DIVISION.
      PROGRAM-ID. TESTD.

      ENVIRONMENT DIVISION.
      CONFIGURATION SECTION.

      DATA DIVISION.
      WORKING-STORAGE SECTION.

      PROCEDURE DIVISION.
      MAIN.
          CALL 'SOMEFUNC' USING 5, 'TESTD'
          GOBACK.
      END PROGRAM TESTD.


SOMEFUNC.cbl
------------
      IDENTIFICATION DIVISION.
      PROGRAM-ID. SOMEFUNC.

      ENVIRONMENT DIVISION.

      DATA DIVISION.
      WORKING-STORAGE SECTION.

      LINKAGE SECTION.
      01 ARG-LEN      PIC S9(09) COMP.
      01 PGM-NAME    PIC X(20).

      PROCEDURE DIVISION USING ARG-LEN, PGM-NAME.
          DISPLAY '==> Starting ', PGM-NAME(1:ARG-LEN)
          GOBACK.

      END PROGRAM SOMEFUNC.



Folkert van Heusden

--
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com



------------------------------

Message: 5
Date: Wed, 29 Mar 2017 14:39:56 +0100
From: Edward Hart <address@hidden>
To: folkert <address@hidden>
Subject: Re: [Bug-GnuCOBOL] segfaults during compile
Message-ID:
Content-Type: text/plain; charset="utf-8"

Can you check if this problem also occurs with the version in the repo?

On 29 March 2017 at 14:08, folkert <address@hidden> wrote:

> Hi Edward,
>
> I can reproduce the problem. The problem is in a closed source component
> unfortunately so I can't share it.
>
> On Wed, Mar 29, 2017 at 01:56:19PM +0100, Edward Hart wrote:
> > Hi Folkert,
> >
> > Thanks for the bug report. Are you able to give us a small COBOL sample
> > which demonstrates the bug? I think this bug has been reported before
> >,
> > but we've been unable to reproduce it. We could then also integrate the
> > sample into GnuCOBOL testsuite.
> >
> > Edward
> >
> > On 29 March 2017 at 10:41, folkert <address@hidden> wrote:
> >
> > > Hi,
> > >
> > > I'm trying to build some cobol code usng gnu cobol:
> > >        cobc (GnuCOBOL) 2.0.0
> > >        Packaged  Nov 06 2016 22:36:19 UTC
> > >        C version "6.3.0 20170118"
> > >
> > > During the compile the compiler segfaults constantly.
> > > I ran it through valgrind and this found the following:
> > >
> > > ==2205== Invalid read of size 4
> > > ==2205==    at 0x170EA9: lookup_pic (codegen.c:904)
> > > ==2205==    by 0x171149: lookup_attr (codegen.c:972)
> > > ==2205==    by 0x171580: output_attr (codegen.c:1099)
> > > ==2205==    by 0x1723C1: output_field (codegen.c:1515)
> > > ==2205==    by 0x17517E: output_param (codegen.c:2777)
> > > ==2205==    by 0x175BCB: output_funcall (codegen.c:3012)
> > > ==2205==    by 0x17CFF0: output_stmt (codegen.c:6107)
> > > ==2205==    by 0x17D3C6: output_stmt (codegen.c:6289)
> > > ==2205==    by 0x17CC4F: output_stmt (codegen.c:6027)
> > > ==2205==    by 0x181044: output_internal_function (codegen.c:7727)
> > > ==2205==    by 0x183B88: codegen (codegen.c:8856)
> > > ==2205==    by 0x128ABD: process_translate (cobc.c:5200)
> > > ==2205==    by 0x12A700: main (cobc.c:6265)
> > > ==2205==  Address 0x686dbb8 is 40 bytes inside a block of size 48
> free'd
> > > ==2205==    at 0x4C2CDDB: free (vg_replace_malloc.c:530)
> > > ==2205==    by 0x11E1FC: cobc_free (cobc.c:712)
> > > ==2205==    by 0x12A73F: main (cobc.c:6271)
> > > ==2205==  Block was alloc'd at
> > > ==2205==    at 0x4C2DBC5: calloc (vg_replace_malloc.c:711)
> > > ==2205==    by 0x11E5AB: cobc_parse_malloc (cobc.c:861)
> > > ==2205==    by 0x170F76: lookup_pic (codegen.c:926)
> > > ==2205==    by 0x171149: lookup_attr (codegen.c:972)
> > > ==2205==    by 0x171580: output_attr (codegen.c:1099)
> > > ==2205==    by 0x1723C1: output_field (codegen.c:1515)
> > > ==2205==    by 0x17517E: output_param (codegen.c:2777)
> > > ==2205==    by 0x175BCB: output_funcall (codegen.c:3012)
> > > ==2205==    by 0x17CFF0: output_stmt (codegen.c:6107)
> > > ==2205==    by 0x17D3C6: output_stmt (codegen.c:6289)
> > > ==2205==    by 0x17CC4F: output_stmt (codegen.c:6027)
> > > ==2205==    by 0x181044: output_internal_function (codegen.c:7727)
> > > ==2205==    by 0x183B88: codegen (codegen.c:8856)
> > > ==2205==    by 0x128ABD: process_translate (cobc.c:5200)
> > > ==2205==    by 0x12A700: main (cobc.c:6265)
> > >
> > > So apparently lookup_pic allocates a block of memory which main frees
> > > and then lookup_pic is trying to use it again.
> > >
> > > It looks like cobc_parsemem_base is freed but pic_cache in codegen.c is
> > > still referring to the same address which explodes.
> > >
> > > Removing the free()-code (as a test) "solves" the problem (albeit with
> a
> > > memory leak of course).
> > >
> > >
> > > Folkert van Heusden
> > >
> > > --
> > > ----------------------------------------------------------------------
> > > Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
> > >
> > >
>
>
> Folkert van Heusden
>
> --
> Multi tail barnamaj mowahib li mora9abat attasjilat wa nataij awamir
> al 7asoub. damj, talwin, mora9abat attarchi7 wa ila akhirih.
> ----------------------------------------------------------------------
> Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
>
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Subject: Digest Footer

_______________________________________________
Bug-GnuCOBOL mailing list


------------------------------

End of Bug-GnuCOBOL Digest, Vol 3, Issue 1
******************************************


reply via email to
[Prev in Thread] Current Thread [Next in Thread]