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

[Simon Sobisch]

Am 05.06.2018 um 04:21 schrieb Bruce Zupek:
> How did you accomplish this ? Call by variable, Call by literal, and
> Call by constant did not compile (and / or link)

I attached the minimal changed sources.
As I've said currently only static linking seems to work when CALLing
with STDCALL.

> Is it successful because you are using Visual Studio ?

No. It is sucessfull when using the correct types and call-convention ;-)

It is sucessfull directly when using a VS build, likely because cl.exe
always link the needed libraries if not explicit removed and has the
windows function declarations available, even if not including windows.h
(or it somewhow magically adjust "anonymous" stdcalls that GnuCOBOL
currently generate).

It is also successful when using the MinGW 3.0RC1 provided by Arnold
*if* the correct function declarations are available (otherwise you get
the address@hidden linker errors).

For main programs you can use -fwinmain (but this will also remove the
cmd.exe context of the complete application, which often is *not* wanted
[at least if you don't use the pdcurses-win32a library where it is fine]).
The only option to do this *now* is to manually adjust the generated C
sources, either:

a) compile with -C -fno-gen-c-decl-static-call and manually change the
generated .c source to #include <windows.h> (after #include <libcob.h>)

b) compile with -C and adjust the function declarations in generated
.l.h source to use the correct number of parameters.

And then compile the .c source directly with cobc.


Or - brute force by Mario Matos:

Find libcob.h and #include <windows.h> there and add the option
-fno-gen-c-decl-static-call to all cobc uses (that compile static CALLs).


GnuCOBOL will get an option to manually include C headers and (later) a
much better generation of the function declartions, for now - if you
want to do STDCALL - you need to use static linking and one of the
mentioned workarounds.

Simon



> On 6/4/2018 6:56 PM, Simon Sobisch wrote:
>> 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
>

VFILE1.COB
Description: Text document