Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Andi B.

Pages: [1] 2 3 ... 42
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
Code: [Select]
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.

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 -

Code: [Select]
cc = gcc
link = wlink
$(cc) $(objs) ....
$(link) .....

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, 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.

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)
  PCOMPORT cp = (PCOMPORT)param;
  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 }

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....

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

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 bytes (17GB) free

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
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've only this debug kernel - '@#IBM:14.104a#@_SMP  IBM OS/2 Kernel'

Can someone share b or c? Thanks.

Programming / Re: on Github
« on: January 16, 2022, 10:55:45 am »
I also tried Sourceforge again with a test repository. They insisted on 2 factor login, ...

My old souceforge login works as it did years before. Only email/password from the browser. No app, no sms, no verification code...., as simple as it could be.

Just found in my user preferences 'Multifactor authentication is currently disabled. How to use Multifactor authentication'.

But of course you're right. You can't trust any cloud provider. That's also one of the main reasons why I switched to git (from svn).

Programming / Re: on Github
« on: January 15, 2022, 07:06:53 pm »
In the past I've created some projects at cause I wanted GIT instead SVN. As you said Adrian made clear years ago that he don't want to add git repositories at his server. My choice for bitbucket was made cause -

- at that time bitbucket was fully functional with our browsers in contrary to github
- I try to avoid MS were I can
- I knew Atlassian before

Maybe today I would take a closer look at sourceforge or gitlab.

Anyway personally I need full control over software repository I participate. We know Adrian has done a tremendous good job with netlabs in the past. But the last years I got the impression he could not spend the time necessary to run netlabs the way it would deserve. Sometimes he answers to emails immediately but sometimes he don't answer at all. So if we start projects at I think we need more than one admin.

Other thoughts?

Applications / Re: ArcaOS 5.0.7
« on: January 13, 2022, 08:58:35 am »
I switched from current pmmerge to the lastest build 4os2.

What do you mean by that?

Can't get ICAT over UDP to work. Maybe this is not possible with MultiMac network drivers?

Storage / Re: JFS - Trap 0003 - anyone?
« on: January 06, 2022, 03:13:47 pm »
Recently I also had a JFS 0003 trap while I prepared a bootable ArcaOS USB stick.

I also read a while ago an explanation for one sort of JFS 0003 trap. What I remember is it had to do with removable devices where sometimes JFS find things on a volume which clearly do not match what it expects. Caused by the drive letter is now used by another volume. Hence JFS gives up for safety reasons. At least this is what I remember.

Did you search in the bugtracker for this? trap 003 or CS:IP or the location value?

Andy, are you now running successfully with the latest IJFW build I gave to you on 30.12.2021 ?
Yes. But as mentioned per email it needs long time tests to be really sure.

Long story -
if you remember I had occasional hangs with my PCM9310. PCM9310 is my current firewall. I only tested the same installation on the NUC and saw similar/same problems. With PCM9310 I see the problem only once a week or a few times a day (dependent on usage pattern?). So to be really sure I need weeks.

With the NUC I could reproduce a problem (the same problem?) within minutes. But I tested the NUC with a 50-70Mbit/s LTE connection while the PCM9310 handles the 8Mbit/s DSL connection. And we know the problem is load/speed/??? dependent. So not 100% comparable. If this is/was all the same problem than it is definitely solved. If there is still another problem then it may show up in a few days/weeks.

Pages: [1] 2 3 ... 42