Menu
▾
▴
#897 attempt to reference unallocated memory
cobc -V
cobc (GnuCOBOL) 3.1.2.0
Copyright (C) 2020 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 Jun 16 2023 04:35:55
Packaged Dec 23 2020 12:04:58 UTC
C version "10.2.1 20210110"
Source:
IDENTIFICATION DIVISION.
PROGRAM-ID. L0-A.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
MAIN.
CALL "L0-D".
STOP RUN.
*--====================--*
IDENTIFICATION DIVISION.
PROGRAM-ID. L0-B.
DATA DIVISION.
WORKING-STORAGE SECTION.
77 ss PIC X(10).
PROCEDURE DIVISION.
MAIN.
DISPLAY "--> L0-B".
DISPLAY ss.
DISPLAY ss.
END PROGRAM L0-B.
*--====================--*
IDENTIFICATION DIVISION.
PROGRAM-ID. L0-C.
DATA DIVISION.
WORKING-STORAGE SECTION.
77 ss PIC X(10).
PROCEDURE DIVISION.
MAIN.
DISPLAY "--> L0-C".
DISPLAY ss.
END PROGRAM L0-C.
*--====================--*
IDENTIFICATION DIVISION.
PROGRAM-ID. L0-D.
DATA DIVISION.
WORKING-STORAGE SECTION.
78 maxLen VALUE 80.
PROCEDURE DIVISION.
MAIN.
DISPLAY "--> L0-D".
SET 80 TO maxLen.
END PROGRAM L0-D.
END PROGRAM L0-A.
Output:
cobc -x -o "test" "test.cob"
attempt to reference unallocated memory (signal SIGSEGV)
cobc: aborting compile of test.cob at line 41 (PROGRAM-ID: L0-D)
cobc: Please report this!
where line 41 is:
SET 80 TO maxLen.
Best regards
You have the END PROGRAM statement incorrectly placed.
Move all END PROGRAM to the end in reversed order ie D, then C then B and A.
Retry
here is my output... Note that this was using the latest build of GNUCOBOL at commit R5112.
After making the coding fix to the L0-D program it compiled and executed successfully
it then compiled and ran successfully...
So I will mark this a closed as it is a simple coding mistake.
====> note that in program L0-D the maxLen variable was changed to a level 77 and the SET 80 TO maxLen was changed to be a MOVE rather than a SET (the SET verb is used to modify indexes, pointers).
I want to clarify that this error is not related to my demonstration code, which was specifically designed to showcase that there exists a byte sequence indicating a breakdown in the GNUCOBOL compiler's logic.
This error is of utmost importance as it causes a complete the GNUCOBOL compiler crash.
The issue at hand is as follows: when providing input data that contains "garbage" or incorrect values, the program unexpectedly terminates.
Just for fun -- comment out, say, Line 19, in my demonstration code,
where line 19 is:
It then compiled.
When testing a compiler for its resistance to incorrect input, there are several common testing techniques. These techniques help identify potential vulnerabilities and ensure the compiler handles invalid or malformed input gracefully. Here are some commonly used techniques:
Boundary Testing: This technique involves testing inputs that are at the boundaries of the valid input range. It includes testing inputs with the minimum and maximum values allowed, as well as inputs just below or above these limits.
Fuzz Testing: Fuzzing involves providing random or mutated inputs to the compiler to observe its behavior. The goal is to identify unexpected or undefined behavior caused by malformed input. Fuzz testing tools can generate a wide variety of input patterns to stress test the compiler.
Negative Testing: Negative testing involves deliberately providing inputs that violate the expected rules or specifications. This includes inputs with syntax errors, conflicting declarations, or other forms of invalid code. The purpose is to verify that the compiler detects and reports errors correctly.
Robustness Testing: This technique focuses on testing the compiler's ability to handle exceptional or unusual inputs gracefully. It includes testing inputs with missing or mismatched components, as well as unexpected or ambiguous constructs. The aim is to assess how well the compiler recovers from errors and produces meaningful error messages.
.---
Best regards
Meerkut,
could you please run this command cobc --info
then post the results here...
here is the output from my environment (I just built the compiler on July 7, 2023).
with your original source posted above... and line 19 commented out...
same compile error.....
so I have not been able to reproduce the problem you mention using the source code you provided...
Chuck,
Here is the output:
Thank you for edge-testing the compiler! Complete chrashes are to prevented, but this specific issue was fixed.
If you do edge case testing it is always most reasonable to recheck with the most current version (as @chaat did). So thanks to both of you for testing and for check-closing.
Just out of curiosity I've had a look at this, starting with a debug version of the 3.1.2 compiler (that includes
--enable-cobc-internal-checkswhich slows down the compiler) as most SIGSEGV are about internal casting issues and this does a data-driven check for the validity of casts.Result:
Then I've compared the code around that with the current one and spot the additional check we now do there;
svn annotatebrought up the revision for that, so... fixed in [r4875], which has a good reference so we can also mark that as duplicate of [bugs:#643], which may would be able to find using the search option (you find that on the upper left of this page as "Search Bugs").Related
Bugs:
#643Commit: [r4875]