Re: wip/wsjtx does not decode FT8 radio signals.

[Ramiro Aceves <ea1abz%gmail.com@localhost>]

El 26/12/25 a las 23:57, Ramiro Aceves escribió:
> El 23/12/25 a las 9:02, Ramiro Aceves escribió:
> > El 23/12/25 a las 7:22, Michael van Elst escribió:
> > > ea1abz%gmail.com@localhost (Ramiro Aceves) writes:
> > >
> > > > #0  0x000078935bb7eeea in _lwp_kill () from /usr/lib/libc.so.12
> > > > #1  0x000078935bb846e0 in abort () from /usr/lib/libc.so.12
> > > > #2  0x000078935c022fdc in __enable_execute_stack (addr=<optimized out>)
> > > > at enable-execute-stack.c:77
> > >
> > > This sounds like the program requires an executable stack. You
> > > may need to allow that by patching the binary with something
> > > like:
> > >
> > > paxctl +m /path/to/binary
> > >
> > > This will disable the protection for the process running that
> > > binary.
> >
> > Hello Michael, you were right! It does not crash now with paxctl +m 
> > in / usr/pkg/bin/jt9 binary
> >
> >
> > netbsd-nuc# paxctl  /usr/pkg/bin/jt9
> > PaX flags:
> >    m: mprotect(2) restrictions, explicit disable
> > netbsd-nuc#
> >
> > decoder does not crash now:
> >
> > netbsd-nuc$ jt9 -8 170923_082000.wav
> > <DecodeFinished>   0   0        0
> >
> > But unfortunately WSJTX does not show decodes when feeding the program 
> > with test audio files.
> >
> > I will continue investigating.
> >
> > Regards.
>
> Hi Michael,
>
> Sorry, I think I was using wrong audio files. Text decoder works now 
> after your paxctl +m tweak.
>
>
> netbsd-nuc$ jt9 -8 210703_133430.wav
>
> Program received signal SIGABRT: Process abort signal.
>
> Backtrace for this error:
> #0  0x6f9ed717f61f in ???
> #1  0x6f9ed717eeea in ???
> [1]   Abort trap (core dumped) jt9 -8 210703_133430.wav
>
> netbsd-nuc# paxctl +m /usr/pkg/bin/jt9
>
>
> netbsd-nuc$ jt9 -8 210703_133430.wav
> 133430  15  0.3 2571 ~  W1FC F5BZB -08
> 133430  -2 -0.8 1197 ~  CQ F5RXL IN94
> 133430  13 -0.1 2157 ~  WM3PEN EA6VQ -09
> 133430 -13  0.3  590 ~  K1JT HA0DU KN07
> 133430  -7  0.1  723 ~  A92EE F5PSR -14
> 133430  -3 -0.1 2695 ~  K1BZM EA3GP -09
> 133430 -13  0.3  641 ~  N1JFU EA6EE R-07
> 133430  -3  0.2  466 ~  N1PJT HB9CQK -10
> 133430  -7  0.4 2734 ~  W1DIG SV9CVY -14
> 133430 -16  0.1 1649 ~  K1JT EA3AGB -15
> 133430 -16  0.3  400 ~  W0RSJ EA3BMU RR73
> <DecodeFinished>   0  11        0
>
>
> But sadly live decoding do not work at all. I will continue investigating.
>
>
>
> Thanks.
> Ramiro.


Hello,

I have been investigating this issue for some time but it seems too hard 
and it surpasses me, it requires low level expertise.

The WSJTX program decoding flux may be something like:

WSJT‑X GUI → Shared Memory Segment → JT9 read samples
JT9 decodes → Shared Memory Segment → WSJT‑X GUI read results

WSJT uses that files in /tmp directory:

netbsd-nuc$ ls -lh /tmp/ |grep WSJ
drwxr-xr-x  2 ramiro  wheel   48B Jan  6 11:43 WSJT-X
-rw-r--r--  1 ramiro  wheel   61B Jan  6 11:43 WSJT-X.lock
-rw-r-----  1 ramiro  wheel    0B Jan  6 11:43 
qipc_sharedmemory_WSJTXcb30261685f45c5a8508adfc3b022ef81b80a216
-rw-r-----  1 ramiro  wheel    0B Jan  6 11:44 
qipc_systemsem_WSJTXad2fdb40ccc8f1b0e1e4539c6e1592c39b2fe13b
-rw-r-----  1 ramiro  wheel    0B Jan  6 11:43 
qipc_systemsem_WSJTXcb30261685f45c5a8508adfc3b022ef81b80a216
netbsd-nuc$

If we attach the decoder manually while WSJTX is running it does not 
decode anything:

netbsd-nuc$ jt9 -s WSJT-X -8
0014 WSJT-X


In Linux we get good decoding messages if we issue the same command:


ramiro@debian-nuc8i7:~$ jt9 -s WSJT-X -8
103630   9  0.1  616 ~  HA8VZ II3WWA -05
103630  10  0.1  676 ~  CQ II3WWA JN65
103630  10  0.1 1714 ~  CQ F5PIO JN19
103630   4  0.1  732 ~  DL9YNG GJ0KYZ +08
103630  -6  0.1 2137 ~  E75W LB9TH JO29
103630   1  0.3  172 ~  CQ IW2NEF JN46
103630 -11  0.1 2181 ~  SQ8AA M7REV IO82
103630   4 -0.5  383 ~  DH6MBR II6WWA RR73
103630  -5  0.1 2002 ~  SP6TP PH7KLM JO32
103630   5 -0.3 1145 ~  EA6BH F1PSX JN08
103630   4  0.3 1614 ~  OT9A M0BSI R+13
103630  -6  0.1 1316 ~  CQ HA1BF JN86
103630  -4 -0.2  967 ~  M0KTB TF2AC RR73
103630  -9  0.5 1935 ~  F1SER 2E0KJF RR73
103630 -11  0.1 1091 ~  SQ8V II9WWA -02
103630  -1 -0.2 1578 ~  SQ8AA M8VCP IO93
103630  -3  0.1 1384 ~  SQ8AA II0WWA R-13
103630   8  0.1 2312 ~  JA4DND EB3DIM -16
103630  -3  0.1  930 ~  CQ 4U1A JN88
103630   7  0.0 1207 ~  CQ II1WWA JN35
103630  -9  1.0 2239 ~  F4DNU CR2WWA -05
103630 -19  0.2 1042 ~  CQ OL6WWA JN89
103630  -6  0.1  207 ~  PA0LDE IU1QXQ 73
103630 -16  0.1 1266 ~  SV2AJX SQ7JZO RR73
103630   2  0.1 2341 ~  CQ EA8UP IL18
103630   5 -0.2 1207 ~  3Z6V II5WWA -09
103630   0  0.1 1692 ~  PA3BMB IZ2KPE RR73
103630  -4  0.1  383 ~  F5OYA/P EA5HRE RR73
103630  -9  0.1 1364 ~  SP5KG DA0WWA +08
103630  -9  0.1 1325 ~  G0VXM DL3RDO R-17
103630 -10 -0.2  722 ~  F5IXN DK6DM +04
103630 -13  0.1 1094 ~  CQ LZ1ZF KN22
103630 -17  0.1  840 ~  OM3JW F4LER JN18
<DecodeFinished>   0  33        0


This is what the AI says about the possible cause of the problem (who 
knows...):

    This is not due to WAV/audio, flags, or the JT9 decoder itself:
    The decoder works fully in offline mode (WAVs)
    The problem is with the “shared memory decoder” functionality in NetBSD

    Cause (likely):
    JT9 uses SysV IPC (shmget, semget) for live decoding with WSJT-X.
    While NetBSD supports these calls, the behavior is slightly 
different from Linux (permissions, initialization, and semaphore 
handling), so the decoder cannot deliver messages to the WSJT-X GUI.

    On Linux/Windows, the same mode works perfectly.

Conclusion:

    NetBSD builds of JT9 cannot be used as a live external decoder with 
WSJT-X today.Only WAV decoding is currently functional.


All of this surpasses me. Keep in touch if you find something.

Thanks so much.

Regards.
Ramiro.



>