[go: up one dir, main page]
Menu ▾ ▴

#1071 cobc crashes when replacing by nothing

GC 3.x
accepted
Simon Sobisch
cobc (110) SIGSEGV (37) preprocessor (3)
5 - default
2025-04-04
2025-04-04
Ribbon Otter
No

I am currently learning COBOL and upon learning COPY thought that maybe I could use it to create recursive loops. Instead, makes gnuCOBOL crash.

When I run cobc -free -O -C main.cob, I get this error:

unknown (signal)

cobc: aborting compile of fab.cob at line 5 (unknown: unknown)
cobc: Please report this!

I don't know if my code is valid COBOL, but presumably it shouldn't crash.

My output of cobc --version is

cobc (GnuCOBOL) 3.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built     Apr 03 2025 01:34:43
Packaged  Jul 28 2023 17:02:56 UTC
C version "14.2.1 20250207"

more specifically, the one that is automatically downloaded and compiled using this AUR script: https://aur.archlinux.org/packages/gnucobol

Sorry for not testing if this error also exists in trunk. I attempted to build trunk manually, and after running a ./autogen.sh and ./configure , make failed with 

[...]
make  all-recursive
make[1]: Entering directory '/home/plum/patches/gnucobol-code'
Making all in .
make[2]: Entering directory '/home/plum/patches/gnucobol-code'
make[2]: Leaving directory '/home/plum/patches/gnucobol-code'
Making all in lib
make[2]: Entering directory '/home/plum/patches/gnucobol-code/lib'
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..  -I..   -O2 -pipe -finline-functions -fsigned-char -Wall -Wwrite-strings -Wmissing-prototypes -Wno-format-y2k -MT dummymac.lo -MD -MP -MF .deps/dummymac.Tpo -c -o dummymac.lo dummymac.c
libtool: Version mismatch error.  This is libtool 2.5.3, but the
libtool: definition of this LT_INIT comes from libtool 2.5.4.1-baa1-dirty.
libtool: You should recreate aclocal.m4 with macros from libtool 2.5.3
libtool: and run autoconf again.
make[2]: *** [Makefile:536: dummymac.lo] Error 63
make[2]: Leaving directory '/home/plum/patches/gnucobol-code/lib'
make[1]: *** [Makefile:698: all-recursive] Error 1
make[1]: Leaving directory '/home/plum/patches/gnucobol-code'
make: *** [Makefile:606: all] Error 2

I unfortunately have other things to do today than debug that. (I am also unfamiliar with GNU autoconfigure and related tools so it would take extra time)

2 Attachments
fab.cob
main.cob

Discussion

  • Simon Sobisch

    Simon Sobisch - 2025-04-04
    • labels: --> cobc, SIGSEGV, preprocessor
    • summary: Crash translating --> cobc crashes when replacing by nothing
    • status: open --> accepted
    • assigned_to: Simon Sobisch
    • Group: unclassified --> GC 3.x
     

  • Simon Sobisch

    Simon Sobisch - 2025-04-04

    Thank you for this nice reproducer. With current 3.3 nightly and C sanitizers enabled I see:

    ../../cobc/ppparse.y:169:27: runtime error: member access within null pointer of type 'const struct cb_text_list'

attempt to reference invalid memory address (signal SIGSEGV)

cobc: aborting compile of fab.cob at line 5 (unknown: unknown)
cobc: Please report this!

    That is

    167     /* Use replacement text to decide strictness of partial match */
168     const unsigned char *c;
169     int has_space = new_text->next != NULL;
170     for (c = (unsigned char *) new_text->text; !has_space && *c; c++) {
171        has_space = isspace(*c);
172     }

    and gdb shows that new_text (a parameter passed by the caller) is indeed NULL.

    backtrace:

    (gdb) bt
#0  0x0000555555ab1a57 in ppp_replace_list_add (list=0x0, src=0x504000001168, new_text=0x0, lead_or_trail=2) at ../../cobc/ppparse.y:169
#1  0x0000555555abf45d in ppparse () at ../../cobc/ppparse.y:1697
#2  0x0000555555a8b4fb in preprocess (fn=0x50d000000058) at ../../cobc/cobc.c:5374
#3  0x0000555555aaec65 in process_file (fn=0x50d000000058, status=0) at ../../cobc/cobc.c:9270
#4  0x0000555555ab0a5e in main (argc=5, argv=0x7fffffffd328) at ../../cobc/cobc.c:9563

    Which gets us to

    1695    | lead_trail text_partial_src BY text_partial_dst
1696      {
1697            $$ = ppp_replace_list_add (NULL, $2, $4, $1);
1698      }

    so this is about the replacement... which gives us an ever more simple reproducer:

           REPLACE TRAILING ==a== BY ====.
       IDENTIFICATION DIVISION.
       PROGRAM-ID. HELLO.

    cobc -E main.cob -o /dev/null

    I'll take care of this issue very soon, possibly also adjusting the message to drop the "(unknown: unknown)" part and try to get actual data in up-front.

    You could try the following in ppparse.y (and/or ppparse.c directly to drop the need to regenerate it), which should fix that specific abort (but I haven't checked if this solves all issues around empty replacements):

        if (!lead_or_trail) {
        /* Strictness flag is irrelevant for non-LEADING nor TRAILING
           replacements */
        src->strict = 0;
-   } else {
+   } else if (new_text) {
     
    ❤️
    1

  • Simon Sobisch

    Simon Sobisch - 2025-04-04

    Just FYI: You likely want to do the following to main.cob:

    ->>SOURCE FREE
+       >>SOURCE FREE

    as the first only changes the source format if if is in non-fixed form already, while the second works on all formats (and also allow you to drop the -free during your compiles).

     

    • Ribbon Otter

      Ribbon Otter - 2025-04-04

      oh that is really clever and a good point, thank you for your help.

       

      Last edit: Simon Sobisch 2025-06-25

Log in to post a comment.