OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Andi B. on January 21, 2022, 04:13:03 pm
-
I see an application crash but only this short exceptq report
______________________________________________________________________
Exception Report - created 2022/01/21 14:28:40
______________________________________________________________________
Hostname: NUC-J3160
OS2/eCS Version: 2.45
# of Processors: 4
Physical Memory: 2994 mb
Virt Addr Limit: 2048 mb
Exceptq Version: 7.11.5-shl BETA8 (Jun 1 2020 18:37:02)
______________________________________________________________________
Exception C0000005 - Access Violation
______________________________________________________________________
Process: P:\UTIL\PCM9362_ANETCOM.EXE (07/17/2020 16:00:11 121,227)
PID: 78 (120)
TID: 02 (2)
Priority: 200
Filename: P:\UTIL\PCM9362_ANETCOM.EXE (07/17/2020 16:00:11 121,227)
Address: 005B:0002ADA6 (0002:0000ADA6)
Cause: Attempted to read from 00000000
(not a valid address)
No more data.
As stated in the docs there is the matching xqs file in the same directory -
{0}[p:\util] dir pcm*
Volume in drive P is Apps Serial number is 92FC:A5C3
Directory of P:\util\pcm*
17.07.20 16.00 121.227 0 ___A_ PCM9362_AnetCom.exe
17.07.20 15.59 11.662 0 ___A_ PCM9362_AnetCom.xqs
132.889 bytes in 2 files and 0 dirs
135.168 bytes allocated
18.281.160.704 bytes (17GB) free
{0}[p:\util]
At the same time there was a popuplog.os2 entry written -
------------------------------------------------------------
01-21-2022 14:28:40 SYS3171 PID 0078 TID 0002 Slot 00a8
P:\UTIL\PCM9362_ANETCOM.EXE
c0000005
0002ada6
P1=00000001 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX
EAX=01000e48 EBX=01000b20 ECX=0000000a EDX=00000014
ESI=01000b20 EDI=00ffffec
DS=0053 DSACC=d0f3 DSLIM=7fffffff
ES=0053 ESACC=d0f3 ESLIM=7fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:1dc6058c CSACC=d0df CSLIM=7fffffff
SS:ESP=0053:00ffffec SSACC=d0f3 SSLIM=7fffffff
EBP=01000b90 FLG=00010206
PCM9362_ANETCOM.EXE 0002:0000ada6
I didn't see traps in this application since a long time and considered it quite stable. At the same time it wrote the usual message in it's log file so I guess it's some problem in the serial communication library I use. But the question here is not why my program crashes, I'm wondering why the exceptq report is not that helpful as usual. Any hints?
-
I don't know what the .XQS files are for or what they do but nowadays I find .DBG files. Looking into them, they obviously contain the stripped debug info. I would expect that you need these files if you want to have source file and linenumber information printed out in your EXCEPTQ report.
Can you build your app, strip the debug info and have that placed into a .DBG file with the same filestem as your executable binary ?
-
It's something like this:
emxomfstrip -D PCM9362_AnetCom.dbg PCM9362_AnetCom.exe
or, if you want to remove the debug info from the exe and only have it in the .DBG file:
emxomfstrip -D PCM9362_AnetCom.dbg -o PCM9362_AnetCom.exe PCM9362_AnetCom.exe (I believe)
-
Edit: thanks for your info which answers my question below.
How do I make a .dbg file with watcom?
Exceptq accepts the following -
Exceptq searches for debug data in the following order:
embedded debug data
.dbg file
.xqs file
.sym file
I create the .xqs file from the mapfile with 'mapxqs $*.map'
{0}[p:\usr\share\doc\exceptq-7.11.5] mapxqs
mapxqs v1.04a - (C)2010-2011 R L Walsh
Creates .xqs symbol files from IBM, Watcom, and Borland .map files.
Usage: mapxqs [-options] [optional_files] mapfile[.map]
General options:
-o specify output file (default: *.xqs)
-l create a listing of symbols (default: *.xql)
-m omit module file names (default: include module info)
Demangler options:
-g use builtin GCC demangler (default)
-v use VAC demangler (requires demangl.dll)
-n don't demangle symbols
Other options:
-d dump symbols in *.xqs to *.xql (example: mapxqs -d file.xqs)
note: -o is the only option that can be used with -d
-
Looking at the map file I see at the failing address watcoms MemAllocator -
Module: P:\watcom/lib386/os2\clib3r.lib(nmemneed.c)
0002:0000ad60 __nmemneed_
Module: P:\watcom/lib386/os2\clib3r.lib(mem.c)
0002:0000ad70 __MemAllocator
0002:0000ae20 __MemFree
Module: P:\watcom/lib386/os2\clib3r.lib(grownear.c)
Seems a bit strange to me. Puzzling....
-
For Watcom I find this:
[c:\watcom\binp]wstrip
Open Watcom Executable Strip Utility Version 2.0beta1 Limited Availability
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Usage: wstrip [options] input_file [output_file] [info_file]
options: (/option is also accepted)
-q don't print informational messages
-n don't print warning messages
-r process resource information rather than debugging information
-a add information rather than delete information
input_file: executable file
output_file: optional output executable or '.'
info_file: optional output debugging or resource information file
or input debugging or resource information file
Something like:
wstrip PCM9362_AnetCom.exe PCM9362_AnetCom.exe PCM9362_AnetCom.dbg
Looks like "info_file" would then contain that debugging data. However, I am not sure if Watcom will do at all because it does not produce either the (proper) Codeview or HLL debug format that exceptq would understand. Unless excdeptq was written to also support the Watcom debugging format but I doubt that. You will have to try out.
-
Looking at the map file I see at the failing address watcoms MemAllocator -
Module: P:\watcom/lib386/os2\clib3r.lib(nmemneed.c)
0002:0000ad60 __nmemneed_
Module: P:\watcom/lib386/os2\clib3r.lib(mem.c)
0002:0000ad70 __MemAllocator
0002:0000ae20 __MemFree
Module: P:\watcom/lib386/os2\clib3r.lib(grownear.c)
Seems a bit strange to me. Puzzling....
That does not mean much. You might have a bunch of functions marked as "static" which never show up in the map file and consequently, they don't show up in the .XQS file. On the other hand, "__MemAllocator" and "__MemFree" are close enough to each other to not fit in yet an additional "static" function.
The full exceptq will give you the source file and line which is very convenient and even works if the trap location is in a function marked as "static".
What I think is a possible problem is if you use "malloc" from a DLL/EXE using its version of the RTL and therefore heap management and then use "free" from a DLL/EXE using a different version of the RTL and therefore heap management.
That can be a problem if for example you allocate a block of memory from an executable written with Watcom and then pass on that pointer to a DLL written with GCC to have it freed. That can blow your app. Know your enemies.
And then, for Watcom, it's about using the register based RTL vs. the stack based RTL. You are using the register based RTL and hopefully you have been compiling your code to use register based argument passing (but I would think so, otherwise you'd have a whole bunch of problems and not only one ...).
-
Hi, the xqs files should be enough to create a trp report and it looks like you are correctly creating them. And of course wl.exe is a patched version of wlink.exe to handle dwarf debugging code. IIRC, (have to look at the mozilla source), the symfile directive creates the dbg file. You do have to build with -g to get the debug info to begin with.
To double check the debug status, try running the binary under an OS/2 (not Watcom) debugger.
Perhaps simply exceptq's exception handler isn't handling the exception correctly and it is falling through to the default exception handler, which creates the entry in popuplog.
-
OK, use something like 'LDFLAGS=-Zlinker option symfile=xxx.dbg' and -g in both CFLAGS (CXXFLAGS) and LDFLAGS to get the dbg file.
-
I played a bit and think I did set up all right the first time. I had tested exceptq reports with watcom previously. What I now think may be the problem is this peace of code I copied from the bloatcom library I found ages ago on hobbes I think. This is the start of new thread which I have added exceptq handling in this way -
static void _System receive_thread(ULONG param)
{
EXCEPTIONREGISTRATIONRECORD exRegRec;
PCOMPORT cp = (PCOMPORT)param;
APIRET rc = NO_ERROR;
const ULONG cbTempMax = 65536;
ULONG cbTemp = 0;
void *pTemp = malloc(cbTempMax);
LoadExceptq(&exRegRec, NULL, NULL);
I now see malloc is called in this thread before LoadExceptq. If malloc fails when this thread is created then exceptq probably can't do it's job. No clue why malloc should fail but the trap report indicates this. Of course I've changed this code now.
Thanks for the infos. One question - what's the advantage from creating a .dbg file instead .xqs? I got the impression most newer software use .xqs, right?
Moreover as we are here - what I still didn't get to work is building with watcom and source level debugging with idebug. wl creates hll debugging info (tested with compiling with gcc and linking with wl). But wcc386 don't create proper debug info here no matter which switches I use.
Currently I usually use this settings -
wcc386 -zq -wx -ef -of -Ip:\watcom1.9\h\os2;e:\c\include -d2 -d__DEBUG__ -d__DEBUG_PMPRINTF__ main.c
wl NAME main SYSTEM os2v2 OPTION MAP=main.watmap debug all lib pmprintf.lib file { main.obj }
-
Hi Andy, sorry, I didn't realize that you were compiling with OW when I posted.
DBG vs XQS: DBG has more info to find where the error occurred. XQS are small and give enough info much of the time. I feel that it is best to add the XQS files to your package and have the DBG files available if needed. I don't know how well exceptq handles the OpenWatcom debug format.
You should be able to add the symfile directive to your wlink options
I see your linking with wl, wl is for GCC, handles dwarf style debug info. Using wc386, you should probably link with wlink. Perhaps this is your problem producing debug info, '-d2 -dDEBUG_BUILD' is what the screensaver uses.
wc386 only produces HLL debugging info and that's currently it. You have to use the OW debugger.
Might of got confused about debugging styles, GCC -Zomf -g produces files that can be debugged in idebug, OW doesn't so your left with its debugger.
-
OK, use something like 'LDFLAGS=-Zlinker option symfile=xxx.dbg' ...
Doing this leads to missing debug info (c source code) for wdw :-(
This would be no problem when I got idebug debug info instead. But unfortunately no.
-
Sorry, I was thinking GCC, for OW, I think you'd want something like this,
wlink NAME main SYSTEM os2v2 OPTION symfile=PCM9362_ANETCOM.dbg OPTION MAP=main.watmap debug all lib pmprintf.lib file { main.obj }
Hmm, testing it doesn't seem to work here. Anyways see the SYMFILE option in the OW Linker Guide
-
Ok, now a bit offtopic but as you're here ...
I want to use different scenarios -
- compile with OW (wcc382), link with wl or wlink, debug works but only with wdw (idebug would be better so ...)
- compile with gcc, link with wl or wlink, debug with idebug (or wdw)
- compile with gcc, link with gcc, debug with idebug (think this works cause I did that in the past with wpa_supplicant, have to check again)
I'm currently struggling with 2. as I don't find the right libraries which I need to link with. I now realize that if my memory serves me well and 3. really works then it would be better to skip 2. and use 3. only. But wait, there is a ticket about debug problems and Lars comment that this does not work correct....
For new projects I want to circumvent ICC cause it's missing language extension, its slow compile time, not so good error checking.....
-
OK, as you know, #1 only works with OW tools.
I think perhaps your understanding of how GCC works is incomplete. GCC itself will call the linker.
gcc -g test.c -o test.exe
will compile test to an aout object file and link with ld.exe, it won't produce a debuggable binary (it did way back)
gcc -g -Zomf test.c test.exe
Will convert the aout object file to omf and link with emxomfld.exe, which depending on environment settings will massage the command line for a native linker,
Environment variables:
EMXOMFLD_TYPE:
The type of linker we're using. Values: WLINK, VAC365, VAC308, LINK386.
WLINK wlink.exe from Open Watcom v1.5 or later.
VAC365 ilink.exe from IBM C and C++ Compilers for OS/2 v3.6 or later.
VAC308 ilink.exe from Visual Age for C++ v3.08.
LINK386 link386 form OS/2 install or DDK.
EMXOMFLD_LINKER:
Name of the linker to use and optionally extra parameters. Spaces in the
linker name or path is not supported. Quotes are not supported either.
The default values for these two variables are VAC365 and ilink.exe.
There's also environment variables for rc, run emxomfld without arguments to see all options.
So while it is possible to link directly with wlink, it is tricky and really you should use GCC to link.
Both of these work, (going from memory)
gcc -g test.c -o test.o
gcc -g -Zomf test.o -o test.exe
gcc -g -Zomf test.c -o test.o
gcc -g -Zomf test.o -o test.exe
With CFLAGS=-Zomf, things can get more complex, static libs use emxomfar instead of ar, ranlib will fail on a omf static lib, do SET AR=emxomfar, SET RANLIB=ECHO for that scenario.
Usually omf libs end in .lib and aout ones in .a
-
Thanks for explanation. Have to test.
Usually I use makefiles and gcc -c (compile only) and link with whatever I choose in the makefile. Something like -
cc = gcc
link = wlink
.
.
$(cc) $(objs) ....
$(link) .....
-
... and in that case you will need to specify -Zomf as a compiler switch because there is nothing massaging this switch into the linker ...
-
Thanks for explanation. Have to test.
Usually I use makefiles and gcc -c (compile only) and link with whatever I choose in the makefile. Something like -
cc = gcc
link = wlink
.
.
$(cc) $(objs) ....
$(link) .....
Interesting, guess you'd use the OW crt files then, creating an OW binary. As Lars mentioned, did you use -Zomf as a CFLAG? Or .obj as a suffix and GCC was smart enough to create an OMF object file. Also be hard to do things like the equivalent of -Zhigh-mem. I guess for a simple C program it would work. Perhaps part of the reason for your short exceptq report.
It'll fall down with CPLUS source where you use g++ instead of gcc (same rules for linking). When I moved to GCC 9.2.0 for building Mozilla, it was trying to call a response file from another response file, which doesn't work. Went through similar back around FF4 when the linker cmd line grew to over 64KB (32KB?) and piping the cmd line failed. Then we ended up linking directly with wl.exe, it was hard. This time I linked directly with emxomfld, 873 object files (most consisting of 15 source files) plus libraries created a long cmd line (900 odd words) and was tricky to get working. Here's the sh script I ended up with, renamed to .txt to post. Note the needed libraries.
-
Interesting, guess you'd use the OW crt files then, creating an OW binary. .......Perhaps part of the reason for your short exceptq report.
That's what I tried the last days. Not the problem with exceptq. The failing program (why I started this thread) was made with wcc/wlink.
Then we ended up linking directly with wl.exe, it was hard.
This is what I remember. I thought it would be a good choice cause it worked with Mozilla. But now it seems it's not. Beside the topic of this thread - which compiler/linker combination allows debugging with idebug?
Now I think I've to try again gcc for compiling and linking.
Edit: Okay, this works. At least with a short test
gcc -lcx -O0 -Wall -Wextra -c -Ie:\c\include -Zomf -g -D__DEBUG__ -D__DEBUG_PMPRINTF__ main.c -o main.obj
gcc -lcx -Zexe -Zomf -Zmap -g -g main.obj -Lpmprintf.lib
Source level debugging with idebug works. exceptq report is generated and seems fine. Guess -lcx is only needed during linking and I can remove it from CFLAGS.
-
This is what I remember. I thought it would be a good choice cause it worked with Mozilla. But now it seems it's not. Beside the topic of this thread - which compiler/linker combination allows debugging with idebug?
Basically LDFLAGS=-g -Zomf. All the OS/2 linkers should work, the usual is wl.exe as we have the source. We stopped using ilink for Mozilla as it couldn't handle the code size, IIRC the limit was 32 MB
Now I think I've to try again gcc for compiling and linking.
Should be fine. Linking against libcx will give exceptq support, LDFLAGS+=-lcx, -Zmap for map files.