Linrad raspberypiZero segfaults in NetBSD

[Ramiro Aceves]

Hi,

As an experiment I compiled Linrad in Raspberry Pi Zero W (32 bit arm) under NetBSD operating system. I was expecting some kind of failure at compiling but surprisingly it ended just fine. :-)

I configured Linrad to get input from Afedri-Net receiver using 192.168.1.210 usual address and 50000 port, sample rate 48000 Hz. No sound output device. I think that raspberypizerow does not have audio phisical outputs, but it could stream data on the network, it might be one useful thing for experiments.

Graphical output using CTWM window manager and VNC session in another computer.

Linrad started fine in SSB mode and run for several seconds , I could see it working until it segfaulted.

netbsd-raspaZeroW$ ./xlinrad
[1] Bus error (core dumped) ./xlinrad


I started a gdb debugger session:

netbsd-raspaZeroW$ gdb xlinrad xlinrad.core

GNU gdb (GDB) 11.0.50.20200914-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm--netbsdelf-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

--Type <RET> for more, q to quit, c to continue without paging--
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from xlinrad...
(No debugging symbols found in xlinrad)
[New process 3906]
[New process 2525]
[New process 3924]
[New process 28464]
[New process 313]
[New process 1231]
[New process 7848]
[New process 28732]
[New process 290]
[New process 4669]
[New process 2853]
[New process 3878]
[New process 1604]
[New process 6857]
[New process 1059]
[New process 7831]

Core was generated by `xlinrad'.
--Type <RET> for more, q to quit, c to continue without paging--
Program terminated with signal SIGBUS, Bus error.
#0 0x000e4c38 in ?? ()
[Current thread is 1 (process 3906)]
(gdb) bt
#0 0x000e4c38 in ?? ()
#1 0x000e6d5c in ?? ()
#2 0x7575c568 in pthread.create_tramp ()
from /usr/lib/libpthread.so.1
#3 0x75693324 in __mknod50 ()
from /usr/lib/libc.so.12
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

Is there an easy way to compile Linrad executable with debugging symbols to investigate the crash?

I did once tweaking the makefile but it is tedious and gets erased with ./configure.

Thanks.
Ramiro.

[Leif Asbrink]

Hello Ramiro,

In options.h there is a sctiond "---- Debug tool ----"

You can set #define SYMBOL_TABLES TRUE

Note that you must run ./configure again after changing the
symbol table option

73

Leif

> --
> There is an excellent Linrad User Guide by Gaetan, ON4KHG, at:
> http://w3sz.com/Linrad%20Installation%20&%20Configuration%20User%20Guide%20-%20V1-0.pdf
> ---
> You received this message because you are subscribed to the Google Groups "Linrad" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linrad+un...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/linrad/067AEE4B-DE1D-4BDA-820C-797B63F2FE56%40gmail.com.

[Ramiro Aceves]

Thanks so much Leif, I will try.

Regards.

Ramiro.

El 15/4/25 a las 8:13, Leif Asbrink escribió:

[Ramiro Aceves]

Hi Leif,

I changed #define SYMBOL_TABLES TRUE but that was not enough, that
prevented stripping the symbols (-s )but I needed to manually add this
to CFL Makefile variable to generate them and remove optimization. With
optimization -O2 some information get lost for the debugging GDB session:

CFL="-g -O0 ....."

I get a good xlinrad and xlinrad.core to analyze with GDB.


I do not know anything about debugging with GDB and how Linrad works, it
surpasses me, I give you this information that will perhaps give clues
about the possible bug that is causing the crash under a 32 bit
RaspberyPiZero NetBSD system.

netbsd-raspaZeroW$ gdb xlinrad xlinrad.core

GNU gdb (GDB) 11.0.50.20200914-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm--netbsdelf-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from xlinrad...

[New process 14638]
[New process 18909]
[New process 7459]
[New process 3892]
[New process 26577]
[New process 26663]
[New process 4912]
[New process 20632]
[New process 14118]
[New process 1466]
[New process 25678]
[New process 8434]
[New process 24399]
[New process 28177]
[New process 29474]
[New process 11439]

Core was generated by `xlinrad'.
--Type <RET> for more, q to quit, c to continue without paging--
Program terminated with signal SIGBUS, Bus error.

#0 0x001823bc in wg_waterf_line () at screen.c:3203
3203 wg_waterf_times[i]=wg_waterf_times[i-1];
[Current thread is 1 (process 14638)]
(gdb)

(gdb) bt
#0 0x001823bc in wg_waterf_line () at screen.c:3203
#1 0x00184e18 in screen_routine () at screen.c:3830
#2 0x000d5e70 in thread_screen () at lxsys.c:1554
#3 0x735cc568 in pthread.create_tramp () from /usr/lib/libpthread.so.1
#4 0x73503324 in __mknod50 () from /usr/lib/libc.so.12

Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

(gdb) frame 0
#0 0x001823bc in wg_waterf_line () at screen.c:3203
3203 wg_waterf_times[i]=wg_waterf_times[i-1];

(gdb) list
3198 if(wg_timestamp_counter>2*text_height)
3199 {
3200 i=max_wg_waterf_times-1;
3201 while(i>0)
3202 {
3203 wg_waterf_times[i]=wg_waterf_times[i-1];
3204 i--;
3205 }
3206 hide_mouse(wg.xleft, wg.xleft+10*text_width,
3207 wg_waterf_y,
wg_waterf_y+text_height );
(gdb)

(gdb) info locals
i = 7
j = 8224
ix = 872
color = 0
(gdb)

(gdb) print i
$5 = 7
(gdb) print max_wg_waterf_times
$6 = 8
(gdb) print wg_waterf_times
$7 = (WATERF_TIMES *) 0x72bb4473
(gdb) print wg_waterf_times[i-1]
$8 = {line = 10020, text = '\000' <repeats 11 times>}
(gdb)

CHATGPT suggest this (I do not trust much on him but I am a novice in
all of this C programming ;-) ):


"""The address of wg_waterf_times ending in 0x...73 is once again
suspicious — memory allocations for structs are usually aligned (e.g.,
end in 0, 4, or 8). So either:

This pointer is somehow being corrupted,

Or you're getting a field pointer, not the base of an allocation."""

Anyway, I can send you xlinrad an xlinrad.core for you if it helps to
debug this.

Regards.
Ramiro.





El 15/4/25 a las 8:13, Leif Asbrink escribió:

[Ramiro Aceves]

Hello,

Just for information, I have tested Linrad in an old Pentium 3.5 GHz 32
bit laptop under NetBSD operating system and it just works fine.

Regards.