Attempt to reference unallocated memory (signal SIGSEGV) abnormal termination

[Anshul Agrawal]

Getting issue for unallocated memory in PROCOBOL program:

**I am using dynamic sql query to fetch the 100 rows based on condition: **

Below are the Prepare statement:

SQL-PREP-STMT: SELECT SESSION_ID, SENDER, RECEIVER, APRF   FROM BRIDGE WHERE EXPORT_STATUS = 'C' AND SESSION_ID LIKE '1%%%%%%%%%%%%%%%%%%' AND ROWNUM <= 100 FOR UPDATE SKIP LOCKED                                                                                                              
SQLCODE FOR PULL:-0000003113
 SQL ERROR ON PREPARE, CODE: -0000003113
20250401-140529 :ORA-03113: end-of-file on communication channel
Process ID: 1526

 PERFORM VARYING WA-SUB1 FROM 1 BY 1 
           UNTIL WA-SUB1 > 100 OR WA-EOF = 1
           EXEC SQL 
              FETCH D01SESSION INTO :SQL-TEMP-SESSION-ID,
                    :SQL-SENDER,
                    :SQL-RECEIVER, :SQL-APRF 
           END-EXEC

The above process gets restart the logic in case of failure (maximum 3 times) however I will get the issue for unallocated memory while inserting the data in Payload table in the same program:

           EXEC SQL
              INSERT INTO PAYLOAD(PAYLOAD_REF,
                                      SENDER,
                                      RECEIVER,
                                      APRF,
                                      LOOKUP,
                                      PAYLOAD_DATA)
                              VALUES (:SQL-PAYLOAD,
                                      :SQL-SENDER,
                                      :SQL-RECEIVER,
                                      :SQL-APRF,
                                      :SQL-LOOKUP,
                                      empty_blob() )
           END-EXEC.

attempt to reference unallocated memory (signal SIGSEGV)
abnormal termination - file contents may be incorrect.

GNU : 2.2 version in RH7 environment.

[Simon Sobisch]

How are the bind variables defined (EXEC SQL VAR and/or COBOL definition part of EXEC SQL DECLARE)?

To check where the SIGSEGV really happens I suggest to:

• compile at least this program with cobc -g (compiling all with -g is commonly reasonable)
• run the process under valgrind, if possible: COB_PHYSICAL_CANCEL=NEVER valgrind --track-origins=yes --suppressions=ora.supp --leak-check=no cobcrun yourprog (you can also run without the suppression file but I'll attach the one I use for procob enabled programs - you possibly have to adjust the oracle path in that file)
  
  Side note: Both RH7 and GC2.2 are heavily outdated - you'd likely want to at least move to GC 3.2 (even if you don't recompile your COBOL programs - GC32 can load modules generated by GC22, is faster and has a better exception/abort handling).

[Anshul Agrawal]

Bind variable defined underworking storage with Begin/End section:

EXEC SQL BEGIN DECLARE SECTION END-EXEC
EXEC SQL END DECLARE SECTION END-EXEC

**Compilation: **
cobc -std=mf -ftraceall -fbinary-size=1--8 -fsynchronized-clause=ignore -g payload.cbl

O/P: payload.so (we are generating .so file)

I have never used valgrind. Need to check and then get back to you. We are upgraded into RH8 GNU 3.2, but this issue reported in RH7 (GNU 2.2).

Just to add the actual steps followed:

1: We are forcefully shutdown the db instance as soon as the process get start. Getting error

SQL ERROR ON PREPARE, CODE: -0000003113
20250401-140529 :ORA-03113: end-of-file on communication channel

2: With the current code , we have handled ORA-3113/-3114 and start the process again. As soon as I started within a minute my process gets an error: attempt to reference unallocated memory (signal SIGSEGV).

[Simon Sobisch]

Before running the process under valgrind, it may be reasonable to check for COBOL errors directly, compiling this program and at least its COBOL callers (better all COBOL) with an additional --debug (enable all runtime-checks) and see what comes up when running the program, especially under GC 32 (that includes additional memory checks and checking of LINKAGE vs. CALL USING [you can have "valid" memory even if that check fails, in which case you may disable this single check]).

[Vincent (Bryan) Coen]

On 03/04/2025 02:19, Anshul Agrawal wrote:

Bind variable defined underworking storage with Begin/End section:

|EXEC SQL BEGIN DECLARE SECTION END-EXEC EXEC SQL END DECLARE SECTION
END-EXEC |

**Compilation: **
|cobc -std=mf -ftraceall -fbinary-size=1--8
-fsynchronized-clause=ignore -g payload.cbl|

O/P: payload.so (we are generating .so file)

I have never used valgrind. Need to check and then get back to you. We
are upgraded into RH8 GNU 3.2, but this issue reported in RH7 (GNU 2.2).

Just to add the actual steps followed:

1: We are forcefully shutdown the db instance as soon as the process
get start. Getting error

|SQLERRORONPREPARE,CODE:-0000003113
20250401-140529:ORA-03113:end-of-fileoncommunicationchannel |

2: With the current code , we have handled ORA-3113/-3114 and start
the process again. As soon as I started within a minute my process
gets an error: attempt to reference unallocated memory (signal SIGSEGV).

When compiling add -d -g -fdump=ALL and -T progname.prn

Now using the .prn file look at ALL variables used and you should be
getting a msg showing exactly the vars causing the issue.

Check fields above as well as the one specified and see if there is ANY
possibility of a field overflow in usage ANYWHERE.

If in doubt make fields larger assuming that are not part of a file
record,  double check that and references to occurs fields are not being
used out of range i.e., occurs 10  make sure that the ref var is within
range 1 through 10. Note the start of 1.

Sorry had this issue this week for a program that has been running for
some time, but some conditions have shown up where the subscript can get
out of range on a block of vars that are redefined with a reduced size
as defined by occurs and the code was still programmed for using the
larger size - Wrong.

Your issue could be something of a similar nature.

If not using occurs, still check that a field cannot be over run and
remember to look at earlier fields within the group (i.e., 01 level etc.

The use of -d -g and -fdump=all will help to show where the problem is.

[Anshul Agrawal]

After executing an INSERT statement, the BLOB variable is not properly initializing or handling memory, which leads to unexpected behavior. This is not an ideal scenario for such an issue to arise.

I have added a ALLOCATE to allocate a locator for handling LOB.

EXEC SQL ALLOCATE: SQL-PAYLOAD-DATA END-EXEC

Thanks Simon and Vincent for suggestions.