GC 3.0 termination of program

[Eugenio Di Lorenzo]

the same cobol source that in GC 2.2 correctly ends now with GC 3.0 ends with the attached message. I don't understand why.

[Mário Matos]

Hi, Eugenio

This is a Windows (edit)Application crash :-)

https://www.febooti.com/products/automation-workshop/online-help/events/run-dos-cmd-command/exit-codes/

3221225477
0xC0000005
-1073741819 Access violation.
Indicates that the executed program has terminated abnormally or crashed.

Attached sample information from my PC (not the same, but similar).

Probably something naughty has been made in your GnuCOBOL code that Windows doesn't like :-)

Cheers,
MM

[Simon Sobisch]

If you provide a minimal sample I may can share some insides (and fix a possible [but unlikely] bug).

Despite of the minimal sample:

• Did you CALL any non-COBOL parts (that may got updated in the meantime, too) in this source? This question also applies to non-COBOL programs CALLed, that use updated external libraries now.
• Was the COBOL source re-compiled with GC3? While this should not be necessary, it could be a reason if it wasn't. In this case please recompile (keeping the old binaries in a safe place) and retest - when it works now - please try to find out which program(s) were problematic.
• Can you reproduce the issue with latest version from trunk (if you are able to use it)?

[Anonymous]

Hi Simon, the sources are attached. You also need copy sorce to compile.
Just run the program and then type ESCAPE.
The program ends with the "strange" exit code message.

[Brian Tiffin]

Sorry, Eugenio, is this just the RETURN-CODE being in the 3billion range, or the

Press Enter to close this window part?

There is a new runtime.cfg setting, COB_EXIT_WAIT, defaults to ON, you'll want to set it to OFF. It was put in to avoid people wondering where the output went with extended IO and the curses shadow screen popping in and out without a pause. You can set the message with COB_EXIT_MSG, as a string, too.

If it's the 3billion range return value, not sure, yet. Depends on the first answer as to how much digging might need to be done.

Cheers,
Blue

[Eugenio Di Lorenzo]

Hi Brian, thanks for your advice.
In reality the message with incorrect exit code appeared only in some programs. for other programs the exit code was zero (?).

However I modified the runtime.cfg as follows.
now the message is an exit code = 2 (?)
the text COB_EXIT_MSG is not displayed instead.
See screenshot.

# Environment name:  COB_EXIT_WAIT
#   Parameter name:  exit_wait
#          Purpose:  to wait on main program exit if an extended screenio
#                    DISPLAY was issued without an ACCEPT following
#             Type:  boolean
#          Default:  true
#          Example:  COB_EXIT_WAIT off
COB_EXIT_WAIT off

# Environment name:  COB_EXIT_MSG
#   Parameter name:  exit_msg
#          Purpose:  string to display if COB_EXIT_WAIT is processed, set to ''
#                    if no actual display but an ACCEPT should be done
#             Type:  string
#          Default:  'end of program, please press a key to exit' (localized)
#          Example:  COB_EXIT_MSG ''
COB_EXIT_MSG 'Press a key. End of program'

[Simon Sobisch]

There was an error in the handling of this setting in 3.0. Can you use an updated version?
If not I'd suggest to ensure that the program does a final ACCEPT itself.

[Eugenio Di Lorenzo]

In order to use an updated version of the 3.0 compiler, help from Arnold would be necessary for me. If he could compile and make available on his site it would be very useful.
In my opinion it would be even more useful if an already compiled version was available on the GnuCOBOL website itself.

[Mário Matos]

As of "GnuCOBOL 3.0.2855", Simon patched "screenio.c" to deal with 64-bit CHTYPEs (and it's ok). I don't really know if the generated "config.h" for MinGW has been updated to make these character types as 32-bit by default. Most likely you are using a 64-bit CHTYPE, which may be the reason to crash your application. As far as I know, Arnold's last build is "GnuCOBOL 3.0.2793" which is older than the aforementioned patched version. Being the case, you have two options:

1. Use an older version of "GnuCOBOL" using PDCurses 3.4, like:
   "GnuCOBOL 3.0 RC1 (23APR2018) MinGW compiler for Windows XP/7/8/10 with COBOL ReportWriter. Includes VBISAM 2.01 for Indexed Sequential file access support (17.9 megabytes) and PDCurses 3.4. Rename .7z to .exe for self-extracting archive."
   http://www.arnoldtrembley.com/GC30RC1-VBI-rename-7z-to-exe.7z

2. Ask Arnold to build a fresh new one (using the newer version of PDCurses 4.0.4 (edit)also built with CHTYPE_32). Hopefully, the new generated "config.h" will set it to CHTYPE_32 by default.

(edit)PDCurses 4.0.4 build "MUST" be always use CHTYPE_32 also, otherwise you'll get garbage (at least). The best way is "build both 32/64-bit CHTYPE versions (just in case). :-)

But, I'm just wondering ... Simon should know better.

Cheers and best of luck
MM

[Arnold Trembley]

The most current tarball available is from last November 27, and I don't have the ability yet to create a tarball from checkout. I could try building a version with PDCurses 4.0.4, but I'm not sure if anything special needs to be done to switch between 32-bit and 64-bit CHTYPE.

I tried compiling the sample with 10 copybooks, but the compile failed with a SIGSEV on line 806 of ED000MAIN.CBL. It would compile with GC30RC2 in OCIDE, but execution failed with "Redirection is not supported". So I tried executing the OCIDE compile in a cmd.exe shell and it failed with a windows appcrash:

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: ED000MAIN.exe
  Application Version:  0.0.0.0
  Application Timestamp:    5c8f25ac
  Fault Module Name:    libcob-4.dll
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp:   00000000
  Exception Code:   c0000005
  Exception Offset: 0004b73e
  OS Version:   6.1.7601.2.1.0.256.48
  Locale ID:    1033
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

[Simon Sobisch]

How did you compile the sample to get a compiler crash?

A new curses version would be reasonable, but as long as no one changes the underlying curses dll the unpatched version of GnuCOBOL will still work.
The new version will just check if a possibly swapped curses dll is compatible.

Only disclaimer : if the COBOL code make direct calls to curses the signature must match.

[Arnold Trembley]

I downloaded all 11 source files (10 CPY files) into C:\COBOL, then set my environment variables:

COB_CONFIG_DIR        = c:\GC30XRC2-VBI\config
COB_COPY_DIR          = c:\GC30XRC2-VBI\copy
COB_CFLAGS            = -I"c:\GC30XRC2-VBI\include"
COB_LDFLAGS           = -L"c:\GC30XRC2-VBI\lib"
COB_LIBRARY_PATH      = c:\GC30XRC2-VBI\extras
COB_MAIN_DIR          = c:\GC30XRC2-VBI\

Then I ran a .cmd script which resulted in the following command:

cobc -x -W -F -fnotrunc -t C:\Users\Arnold\AppData\Local\Temp\ed000main.lst -o C
:\Users\Arnold\AppData\Local\Temp\ed000main.exe ed000main.cob

ED000MAIN.cob:804: warning: COMPUTE statement not terminated by END-COMPUTE
ED000MAIN.cob:805: warning: COMPUTE statement not terminated by END-COMPUTE
ED000MAIN.cob:806: warning: DISPLAY statement not terminated by END-DISPLAY

attempt to reference unallocated memory (signal SIGSEGV)

cobc: aborting codegen for ED000MAIN.cob (PROGRAM-ID: ED000MAIN)
cobc: Please report this!

GnuCOBOL Compile Returncode = 11
1 file(s) copied.

Apparently the compile abended, because the listing file just stops.

[Simon Sobisch]

Thank you for the report of cobc chrashing. I can reproduce it with both 3.0 and current dev.

Note: this compiler chrash only occurs when the listing is generated [bugs:#569] - so you may retry without the -t option.

Note #2: This may lead you to a missing entry curs_set - in this case you'll need to add -lcurses or -lpdcurses (depending on the environment). Using this the program starts for me but in one environment does nothing and in the other says "libcob: module 'GC01BOX' not found".

I'll give this another try later, maybe in about 12h.

[Mário Matos]

Hi, Arnold

Although I'm not a MinGW expert, I did some experiments :-)

Try the following:

Donwload the latest PDCurses 4.0.4 from:
https://github.com/Bill-Gray/PDCurses
and download the package by selecting "Clone or download" -> Download ZIP.
Save the "PDCurses-master.zip" wherever you want and unzip it in the same place (you'll get a subdirectory "PDCurses-master" (rename it with a sugestive name if you want).

Call the MinGW windows and change to the "wincon" subdirectory (e.g. cd C:/PDCurses-master/wincon). There you'll find a "make" file named "Makefile.mng" (to use with MinGW).

If you edit this file, you can see the following at the top:
"# GNU MAKE Makefile for PDCurses library - Windows console MinGW GCC"
"#"
"# Usage: make -f [path]Makefile.mng [DEBUG=Y] [DLL=Y] [WIDE=Y] [UTF8=Y] [target]"
"#"
"# where target can be any of:"
"# [all|demos|pdcurses.a|testcurs.exe...]"

Now, for a 32-bit chtype build, type in the MinGW windows the following:
$ make -f Makefile.mng DLL=Y WIDE=Y CHTYPE_32=Y | tee pdcurses_chtype32.log

In the end, you'l have a bunch of new files including a log file named "pdcurses_chtype32.log". Open it with an editor and see what the build did.

There are also some executables and the dynamic library "pdcurses.a/pdcurses.dll".

Don't execute them inside the MinGW window. You'll get the "Redirection is not supported." message. Open there a "CMD.EXE" window, instead and run "testcurs.exe".
Select some options, mainly "ACS Test", "Color Test" and "Wide Input".

The "ACS Test" will give you some extra information at the bottom, namely, the PDCurses version, the date, the size of the CHTYPE...

Close the "CMD.EXE" window and save the library somewhere (also some demos if you will).

Now, let's do it again but, this time for a 64-bit chtype:

Clean the current build with:
$ make -f Makefile.mng clean

Type the following:
$ make -f Makefile.mng DLL=Y WIDE=Y | tee pdcurses_chtype64.log

As in the previous step, the 64-bit chtype will be created and then again another bunch of files. Repeat the test execution an save the main files into someother directory.

Clean the current build again:
$ make -f Makefile.mng clean
and now only the "log" files remain (you may want to keep the for future reference).

Now, we have two 32-bit versions of "PDCurses"; one for 32-bit CHTYPEs and one for 64-bit CHTYPEs.

What's next ?

Build two versions of "GnuCOBOL 3.0.xxxx" with each version of "PDCurses-4.0.4".

For x64 build you'll need the 64-bit toolchain of MinGW.

All the the rest is, basically, the same :-)

Cheers,
MM

[Simon Sobisch]

@dilodilo as you've said you've worked around this issue with STOP RUN WITH NORMAL STATUS instead of STOP RUN I have a guess what's going on.

The most important part; some program (or C library function) you CALL returns a non-zero RETURN-CODE - and this is passed up to the end.

The most important part in the debugging is therefore to check the RETURN-CODE status register as this can, for example with CALLs into C functions also mean that you chrash the stack because of "using" a non-intreturn while it actually is something else (for example a char *.

Can you please verify in your orginal test environment on which CALL the RETURN-CODE register gets trashed?

Note: there was an old bug that the RETURN-CODE register is also set on a CALL ... RETURNING SOME-VAR - which is plain wrong and was fixed shortly before 3.1-rc1.