Re: [Bug-GnuCOBOL] segfaults during compile

[Edward Hart]

Would you mind sending a copy of valgrind's output with the newer GnuCOBOL version?

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

yes, that fails as well

On Wed, Mar 29, 2017 at 02:51:31PM +0100, Edward Hart wrote:
> Yes.
>
> On 29 March 2017 at 14:44, folkert <address@hidden> wrote:
>
> > The svn version?
> > Yes (I did an svn update moments ago)
> >
> > On Wed, Mar 29, 2017 at 02:39:56PM +0100, Edward Hart wrote:
> > > 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
> > > >
> >
> >
> > Folkert van Heusden
> >
> > --
> > Ever wonder what is out there? Any alien races? Then please support
> > the address@hidden project: setiathome.ssl.berkeley.edu
> > ----------------------------------------------------------------------
> > Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
> >

Folkert van Heusden

--
MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen
kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff-
view', vs.  http://www.vanheusden.com/multitail/

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