[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-GnuCOBOL] Cobc: Unallocated memory (signal SIGSEGV) - GnuCobol
From: |
Simon Sobisch |
Subject: |
Re: [Bug-GnuCOBOL] Cobc: Unallocated memory (signal SIGSEGV) - GnuCobol Version 3 Release 1 aunder MinGW |
Date: |
Tue, 5 Jun 2018 00:56:30 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
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
>>
>