Re: [Bug-GnuCOBOL] Cobc: Unallocated memory (signal SIGSEGV) - GnuCobol Version 3 Release 1 aunder MinGW

[Simon Sobisch]

Hi Bruce,

I've just checked a Visual Studio build:

Test 1 changed the program to define the correct WINAPI 74 and use it by
changing the

    CALL VARNAME
to
    CALL WINAPI VARNAME
(cobc complained "STATIC CALL convention requires a literal program
name", therefore adjusted the VARNAMEs to be constants).

Result:
Compiles fine with the command line you've used (no additional library
needed, cobc does (which is shown when -v is added):

executing:      cl.exe -I "C:\dev\gnucobol" -I
"C:\dev\gnucobol\build_windows"
                /nologo /MD /LD /Fe"VFILE1.dll" /Fo"VFILE1" ".\cob2792_0.c"
                /link /manifest /nologo /incremental:no
                /LIBPATH:"C:\dev\gnucobol\build_windows\win32\release"
                libcob.lib
return status:  0
executing:      mt /nologo /manifest "VFILE1.dll.manifest"
                /outputresource:"VFILE1.dll";#2
return status:  0

Running the main program results in:

ENTERING VFILE
RETURN FROM VFILE
IN OPEN V
AFTER ALLOC RC =:0051138592
AFTER ALLOC RC =:+0010000000
AFTER UNLOCK
GOBACK FROM CBL_OPEN_VFILE
RETURN FROM WRITE 2 VFILE

I assume this is the expected result.


Test 2: changing the WINAPI to remove the STATIC part (but still leaving
the rest in, otherwise the stdcall part would be missing). Checked that
this worked:

.\TESTVFX
libcob: module 'GlobalAlloc' not found

This is expected as the program doesn't preload USER32.dll on its own.
Doing this via runtime:

set COB_LIBRARY_PATH=.;%WINDIR%\SysWOW64
set COB_PRE_LOAD=user32

check that this actually leads to a pre-loaded module:

cobcrun --runtime-conf  shows:

CALL configuration
    : COB_LOAD_CASE          : not set
    : COB_PHYSICAL_CANCEL    : false  (default)
 env: COB_PRE_LOAD           : user32
eval: COB_PRE_LOAD           : 'C:\WINDOWS\SysWOW64\user32.dll'
 env: COB_LIBRARY_PATH       : .;C:\WINDOWS\SysWOW64

--> all fine so far.

.\TESTVFX
libcob: module 'GlobalAlloc' not found

--> doesn't work, but I think it should, I'll have to recheck with a
clean version.


Test 3 doing test 2 with Arnold's GC3.0RC1 build - same problem.


Test 4 doing test1  with Arnold's GC3.0RC1 build: the linker complains
this time:

executing:      gcc -I"D:\dev\GC30XRC1-VBI\include"
                -shared -DDLL_EXPORT -DPIC -Wl,--export-all-symbols
                -Wl,--enable-auto-import -Wl,--enable-auto-image-base -o
                "VFILE1.dll" ".\cob16700_0.c"
                -L"D:\dev\GC30XRC1-VBI\lib"
                -L/mingw/lib -lcob -lm -lvbisam -lgmp -L/mingw/lib -lintl
                -lpdcurses
D:\Temp\ccUqPB7s.o:cob16700_0.c:(.text+0x6d7): undefined reference to
address@hidden'
D:\Temp\ccUqPB7s.o:cob16700_0.c:(.text+0x75a): undefined reference to
address@hidden'
D:\Temp\ccUqPB7s.o:cob16700_0.c:(.text+0x7fc): undefined reference to
address@hidden'
collect2.exe: error: ld returned 1 exit status
return status:  1

The @0 looks wrong. To be more "windows-like" I've added the following
options to cobc:

generate C source only: -C
don't generate function stubs: -fno-gen-c-decl-static-call


As result, we have the C sources. Changing VFILE1.c to include
<windows.h> and compiling it with the same command line as before, but
now using VFILE1.c instead of VFILE1.COB results in a warning:

VFILE1.c: In function 'VFILE1_':
VFILE1.c:341:21: warning: passing argument 1 of 'GlobalSize' makes
pointer from integer without a cast [-Wint-conversion]
   b_2 = GlobalSize ((cob_s32_t)((*(unsigned int *)(b_37 + 40))));
                     ^
In file included from d:\dev\gc30xrc1-vbi\include\windows.h:44:0,
                 from VFILE1.c:15:
d:\dev\gc30xrc1-vbi\include\winbase.h:1956:25: note: expected 'HGLOBAL
{aka void *}' but argument is of type 'int'
 WINBASEAPI DWORD WINAPI GlobalSize (HGLOBAL);
                         ^~~~~~~~~~

Changed the USING to use the pointer instead of the redefined integer,
compiling and linking and retesting:

ENTERING VFILE
RETURN FROM VFILE
IN OPEN V
AFTER ALLOC RC =:0044716064
AFTER ALLOC RC =:+0010000000
AFTER UNLOCK
GOBACK FROM CBL_OPEN_VFILE
RETURN FROM WRITE 2 VFILE


Conclusion:

1. Dynamic CALLs to STDCALL functions seem to be broken.
2. Static CALLs to WINAPI works (no need to specify any library when
user32/kernel32 functions are used), currently manual inclusion of
windows.h needed for MinGW builds.
3. In general when calling non-COBOL functions: ensure to use the
correct parameters and return types.

ToDo:

1. Inclusion of any C header should be possible with a one-pass
compilation (=direct from within cobc without manual changes of the
generated sources) [there is a FR from last year open...]
2. The function declarations (found in c.l.h, if not suppressed by the
switch mentioned above) should (optionally) be better derived from the
actual CALL - changing it to
   extern unsigned long __stdcall GlobalSize (void *);
leads to the linker being able to resolve the function.

I hope the conclusions 1-3 help you.
Simon

Am 04.06.2018 um 23:48 schrieb Bruce Zupek:
> All of the Window API calls have been vetted, via return code, return
> results, and expected behavior.
> If you change the dynamic calls to static calls (adding quotes
> surrounding the module) and link with the .LIB's (GNU .A's) the behavior
> is still as indicated.
> I am using the the same calls for the copy / cut and paste routines and
> they are functional. However both are COPY / CUT and PASTE are .EXE
> routines - terminating with Stop Run or Exit Program.
> Bruce
> 
> 
> On 6/4/2018 5:35 PM, Bruce Zupek wrote:
>> It requires USER32.DLL to be accessible (perhaps Kernel32 as well).
>> I thought about call convention as well.
>> In fact I tried all valid call conventions - in the caller (TESTVFX)
>> as well as the called (VFILE1) no difference.
>> GlobalAlloc, GlobalLock / Unlock are all Window's API's.
>> Thank you for the follow-up
>> Bruce Zupek
>>
>> On 6/4/2018 5:18 PM, Simon Sobisch wrote:
>>> Hi Bruce,
>>>
>>> I'd like to have a look at this, but something seems to be missing:
>>>
>>>   ENTERING VFILE
>>>   RETURN FROM VFILE
>>>   IN OPEN V
>>>   libcob: module 'GlobalAlloc' not found
>>>
>>> BTW: Your report "sounds" like a wrong call convention and/or wrong
>>> parameters are used for non-COBOL parts, which may corrupt the stack
>>>
>>> Simon
>>>
>>> Am 04.06.2018 um 19:25 schrieb Bruce Zupek:
>>>> attempt to reference unallocated memory (signal SIGSEGV)
>>>> abnormal termination - file contents may be incorrect
>>>>
>>>> I was in the process of creating the Micro Focus and Fujitsu
>>>> CBL_XXXXX_VFILE subroutines in GNUCobol.
>>>> Issuing a GOBACK in VFILE.COB (after doing the Windows API's
>>>> successfully execute) results in a signal SIGSEGV interrupt.
>>>> I added DISPLAYS to isolate the offending Cobol statement - it is the
>>>> GOBACK.
>>>> The stack must be corrupt. I have no visibility to what component is
>>>> issuing the interrupt.
>>>> I have attached the .DLL and the .EXE as well as the source code.
>>>> Rename VFILE.DLX to VFILE.DLL
>>>> Rename TESTVFX.xex to TESTVFX.EXE
>>>> *TESTVFX* is the command line to invoke the program.
>>>>
>>>> C:\GNUCOBOL\LOADLIB>TESTVFX
>>>> ENTERING VFILE
>>>> RETURN FROM VFILE
>>>> IN OPEN V
>>>> AFTER ALLOC RC =:0013500448
>>>> AFTER ALLOC RC =:+0010000000
>>>> AFTER UNLOCK
>>>> GOBACK FROM CBL_OPEN_VFILE ===> The last statement executed before the
>>>> GOBACK
>>>>
>>>> These are the compile / link parameters.
>>>> For TESTVFX.EXE:
>>>> C:\FUJCBL>\GNUCOBOL\BIN\cobc C:\GEDIT\COBOL\TESTVFX.COB
>>>> -tC:\GEDIT\COBOL\TESTVFX
>>>> .LST -oC:\GNUCOBOL\LOADLIB\TESTVFX  -L\GNUCOBOL\LIB -x
>>>> -fbinary-size=2-4-8  --ts
>>>> ymbols -Xref -fsign=ebcdic -fcomplex-odo -fimplicit-init
>>>> -fsticky-linkage -fperf
>>>> orm-osvs -fmove-ibm -fhostsign -fnotrunc -fno-recursive-check
>>>> -fdefaultbyte=00
>>>>
>>>> For VFILE1.DLL:
>>>> C:\FUJCBL>\GNUCOBOL\BIN\cobc C:\GEDIT\COBOL\VFILE1.COB
>>>> -tC:\GEDIT\COBOL\VFILE1.L
>>>> ST -oC:\GNUCOBOL\LOADLIB\VFILE1 -fbinary-size=2-4-8
>>>> -fbinary-byteorder=native -f
>>>> source-location -Xref --tsymbols  -fsign=ebcdic -fcomplex-odo
>>>> -fimplicit-init -f
>>>> perform-osvs -fmove-ibm -fhostsign -fnotrunc -fno-recursive-check
>>>> -fdefaultbyte=
>>>> 00
>>>>
>>>>
>>>> attempt to reference unallocated memory (signal SIGSEGV)
>>>> abnormal termination - file contents may be incorrect
>>
>