Author Topic: Only short exceptq report although .xqs file was there, why?  (Read 1882 times)

Andi B.

  • Hero Member
  • *****
  • Posts: 641
  • Karma: +8/-1
    • View Profile
Only short exceptq report although .xqs file was there, why?
« on: January 21, 2022, 04:13:03 pm »
I see an application crash but only this short exceptq report
Code: [Select]
______________________________________________________________________

 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 -
Code: [Select]
{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 -
Code: [Select]
------------------------------------------------------------

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?

Lars

  • Hero Member
  • *****
  • Posts: 954
  • Karma: +45/-0
    • View Profile
Re: Only short exceptq report although .xqs file was there, why?
« Reply #1 on: January 22, 2022, 11:54:12 am »
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 ?

Lars

  • Hero Member
  • *****
  • Posts: 954
  • Karma: +45/-0
    • View Profile
Re: Only short exceptq report although .xqs file was there, why?
« Reply #2 on: January 22, 2022, 12:39:59 pm »
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)

Andi B.

  • Hero Member
  • *****
  • Posts: 641
  • Karma: +8/-1
    • View Profile
Re: Only short exceptq report although .xqs file was there, why?
« Reply #3 on: January 22, 2022, 12:44:00 pm »
Edit: thanks for your info which answers my question below.

How do I make a .dbg file with watcom?

Exceptq accepts the following -
Code: [Select]
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'
Code: [Select]
{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

Andi B.

  • Hero Member
  • *****
  • Posts: 641
  • Karma: +8/-1
    • View Profile
Re: Only short exceptq report although .xqs file was there, why?
« Reply #4 on: January 22, 2022, 01:57:41 pm »
Looking at the map file I see at the failing address watcoms MemAllocator -
Code: [Select]
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....

Lars

  • Hero Member
  • *****
  • Posts: 954
  • Karma: +45/-0
    • View Profile
Re: Only short exceptq report although .xqs file was there, why?
« Reply #5 on: January 22, 2022, 03:55:22 pm »
For Watcom I find this:

Code: [Select]
[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.

Lars

  • Hero Member
  • *****
  • Posts: 954
  • Karma: +45/-0
    • View Profile
Re: Only short exceptq report although .xqs file was there, why?
« Reply #6 on: January 22, 2022, 03:57:18 pm »
Looking at the map file I see at the failing address watcoms MemAllocator -
Code: [Select]
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 ...).
« Last Edit: January 22, 2022, 04:07:20 pm by Lars »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 3628
  • Karma: +77/-0
    • View Profile
Re: Only short exceptq report although .xqs file was there, why?
« Reply #7 on: January 22, 2022, 06:16:42 pm »
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.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 3628
  • Karma: +77/-0
    • View Profile
Re: Only short exceptq report although .xqs file was there, why?
« Reply #8 on: January 22, 2022, 06:48:52 pm »
OK, use something like 'LDFLAGS=-Zlinker option symfile=xxx.dbg' and -g in both CFLAGS (CXXFLAGS) and LDFLAGS to get the dbg file.

Andi B.

  • Hero Member
  • *****
  • Posts: 641
  • Karma: +8/-1
    • View Profile
Re: Only short exceptq report although .xqs file was there, why?
« Reply #9 on: January 23, 2022, 09:53:28 am »
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 -
Code: [Select]
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 -
Code: [Select]
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 }

Dave Yeo

  • Hero Member
  • *****
  • Posts: 3628
  • Karma: +77/-0
    • View Profile
Re: Only short exceptq report although .xqs file was there, why?
« Reply #10 on: January 23, 2022, 10:41:21 am »
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.

Andi B.

  • Hero Member
  • *****
  • Posts: 641
  • Karma: +8/-1
    • View Profile
Re: Only short exceptq report although .xqs file was there, why?
« Reply #11 on: January 23, 2022, 10:48:39 am »
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.


Dave Yeo

  • Hero Member
  • *****
  • Posts: 3628
  • Karma: +77/-0
    • View Profile
Re: Only short exceptq report although .xqs file was there, why?
« Reply #12 on: January 23, 2022, 06:55:45 pm »
Sorry, I was thinking GCC, for OW, I think you'd want something like this,
Code: [Select]
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

Andi B.

  • Hero Member
  • *****
  • Posts: 641
  • Karma: +8/-1
    • View Profile
Re: Only short exceptq report although .xqs file was there, why?
« Reply #13 on: January 23, 2022, 07:14:21 pm »
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.....

Dave Yeo

  • Hero Member
  • *****
  • Posts: 3628
  • Karma: +77/-0
    • View Profile
Re: Only short exceptq report although .xqs file was there, why?
« Reply #14 on: January 23, 2022, 08:38:01 pm »
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.
Code: [Select]
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)
Code: [Select]
gcc -g -Zomf test.c test.exeWill 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,
Code: [Select]
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)
Code: [Select]
gcc -g test.c -o test.o
gcc -g -Zomf test.o -o test.exe
Code: [Select]
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