Re: [Bug-GnuCOBOL] segfaults during compile

[Edward Hart]

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
> <https://sourceforge.net/p/open-cobol/discussion/cobol/thread/85e8c88b/>,

> 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.
http://www.vanheusden.com/multitail/

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