[BUG] RadarBox Crashing - uncaught target signal 11 (Segmentation fault) - core dumped

[bslatyer]

Hey Dirk,

I've uncovered that RadarBox will continully crash and do a core dump while on x86_64 machines

[rbfeeder] qemu: uncaught target signal 11 (Segmentation fault) - core dumped
[rbfeeder] /usr/bin/rbfeeder: line 17:   129 Segmentation fault      qemu-arm-static /usr/bin/rbfeeder_armhf "$@"

However, I've used these fixes in the past and was wondering if this can be included into the x86_64 images?

https://github.com/sdr-enthusiasts/docker-radarbox/blob/main/version_0.4.3_workarounds.md#version-043-workarounds

Related to this issue over at SDR Enthusiasts - sdr-enthusiasts/docker-radarbox#166

Let me know what you think.

Thanks,

Braeden

[dirkhh]

fantastic... I wasn't aware of this, thanks for pointing it out.
I'll work this into the next release!

[dirkhh]

please take a look at beta.7 - I tested this here in a VM (and on a bunch of SBCs) and it seems to fix this problem.

[bslatyer]

No worries Dirk. I'll try running it later today when I have some time.

[dirkhh]

did you have a chance to test this? On one host the fix in beta.7 wasn't sufficient for me after a reboot. beta.9 seems to fix this. What was your experience?

[dirkhh]

... and I found yet another possible error scenario - when requesting a RadarBox key in a VM. So beta.10 fixes that one as well.

[bslatyer]

Hey Dirk,

I tested Beta 8 yesterday and it all worked fine on my end.

I didn't see the RadarBox request issue as I already had a key.

I just tested Beta 10 and that looks good to me.

[dirkhh]

thank you for that confirmation. I was waiting to hear back... everything else has been tested for a while now, so I'll make this the next release.
Again, thanks for bringing this to my attention, even complete with a solution!

[ginlik1996]

Hello,
I just moved from a standalone RPi 4 to a OrangePi Zero 3 as a Micro feeder with a Ubuntu VM as Stage 2 and i'm seeing this problem. Is it possible that the issue is still present on the OrangePi?

Thank for the amazing work!

[dirkhh]

So rbfeeder should be running on the stage 2, so this is not the orange pi. I'm confused.

[ginlik1996]

So rbfeeder should be running on the stage 2, so this is not the orange pi. I'm confused.

Sorry, i didn't know how it worked, i tought it was running on the microfeeder.
So yes, this is on the stage 2 instance, which is an Ubuntu 22.04.4 LTS installed using the curl command.

[dirkhh]

I'd love to see the logs from that Ubuntu machine. Can you run this as root and send me the URL it produces? Whiles the script tries to remove personal information, it's not perfect, so feel free to email this link to me instead of posting it here.

sudo bash /opt/adsb/log-sanitizer.sh | curl -F'expires=24' -F'file=@-' https://0x0.st

I of course have the latest version of the adsb.im stack running on my own stage2 server - which is a Ubuntu 22 LTS VM. I get none of these crashes (but - no joke - thousand of errors with rb infrastructure broken, not responding, or otherwise failing while the stage2 system tries to talk to it).

So I'd love to understand why this would crash for you and not for me.

Depending exactly on how long this Ubuntu system has been up, the logs may not include a couple of other things that I'd love to know. can you also post the the support info here (you get that from the web interface under System in the top right corner). And can you add to that which CPU is in your system? Intel, AMD, ARM...?

[ginlik1996]

Sure can do!
Here is the link (I checked it and I didn't see anything compromising):
https://0x0.st/XTgu.txt

Also i just checked the logs again and something has changed, as you can see I'm not getting the same error as before, but I'm getting this:

[2024-06-20 18:12:18.699][rbfeeder] [2024-06-20 18:12:18]  Starting RBFeeder Version 1.0.10 (build 20231120150000)
[2024-06-20 18:12:18.701][rbfeeder] [2024-06-20 18:12:18]  Using configuration file: /etc/rbfeeder.ini
[2024-06-20 18:12:18.701][rbfeeder] [2024-06-20 18:12:18]  Network-mode enabled.
[2024-06-20 18:12:18.701][rbfeeder] [2024-06-20 18:12:18]  		Remote host to fetch data: 172.18.0.3
[2024-06-20 18:12:18.744][rbfeeder] [2024-06-20 18:12:18]  		Remote port: 30005
[2024-06-20 18:12:18.744][rbfeeder] [2024-06-20 18:12:18]  		Remote protocol: BEAST
[2024-06-20 18:12:18.902][rbfeeder] [2024-06-20 18:12:18]  Using GNSS (when available)
[2024-06-20 18:12:19.094][rbfeeder] Error opening the listening port 32458 (Raw TCP output): bind: Address already in use

The system has an uptime of more or less 1 day and it was installed almost 2 weeks ago.

The adsb.im version is 2.1.2, I updated it yesterday morning from 2.1.0 but i had a strange issue, the web gui wasn't working at all after the update. So, since I didn't have any config yet, I uninstalled and reinstalled using these command. Maybe this caused the issue?

sudo bash /opt/adsb/app-uninstall 
curl https://raw.githubusercontent.com/dirkhh/adsb-feeder-image/main/src/tools/app-install.sh | sudo bash

Here's the support info:

Please cut and paste (or provide a screenshot of) this data when asking for help.

    Current:v2.1.2(stable)
    Board:Virtualized x86_64 environment under kvm
    Base:ADS-B Feeder app running on Ubuntu 22.04.4 LTS
    Kernel:Linux adsb-feeder 5.15.0-112-generic #122-Ubuntu SMP Thu May 23 07:48:21 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
    Containers:
        ghcr.io/sdr-enthusiasts/docker-adsb-ultrafeeder:latest-build-410
    SDR(s):

        none

    Ultrafeeder args:

    Env variables:

    Memory:

                   total        used        free      shared  buff/cache   available
    Mem:           3.8Gi       961Mi       493Mi        75Mi       2.4Gi       2.5Gi
    Swap:          3.8Gi          0B       3.8Gi

    Storage:

    Filesystem                         Size  Used Avail Use% Mounted on
    tmpfs                              391M   71M  320M  19% /run
    /dev/mapper/ubuntu--vg-ubuntu--lv   95G  9.5G   81G  11% /
    tmpfs                              2.0G     0  2.0G   0% /dev/shm
    tmpfs                              5.0M     0  5.0M   0% /run/lock
    /dev/vda2                          2.0G  132M  1.7G   8% /boot
    /dev/vda1                          1.1G  6.1M  1.1G   1% /boot/efi
    tmpfs                              391M  4.0K  391M   1% /run/user/1000

The system is an unRAID 6.12.10 box with a Intel i7 13700k and an Asus Prime Z790-P WIFI D4.

Let me know if you need anything else!

[wiedehopf]

That looks like the requesting of a feed key isn't working.

[wiedehopf]

docker run --rm -i --network config_default -e BEASTHOST=ultrafeeder -e LAT=MY_REAL_FEEDER_LAT -e LONG=MY_REAL_FEEDER_LONG -e ALT=267 -v /opt/adsb/rb/cpuinfo:/proc/cpuinfo  ghcr.io/sdr-enthusiasts/docker-radarbox:latest-build-654

i've tested this command on x86_64 (not vm, not ubuntu though) and can't reproduce the issue.

[2024-06-20 18:36:39.937][rbfeeder] [2024-06-20 18:36:39]  Starting RBFeeder Version 1.0.10 (build 20231120150000)
[2024-06-20 18:36:39.938][rbfeeder] [2024-06-20 18:36:39]  Using configuration file: /etc/rbfeeder.ini
[2024-06-20 18:36:39.938][rbfeeder] [2024-06-20 18:36:39]  Network-mode enabled.
[2024-06-20 18:36:39.938][rbfeeder] [2024-06-20 18:36:39]               Remote host to fetch data: 172.20.0.4
[2024-06-20 18:36:39.938][rbfeeder] [2024-06-20 18:36:39]               Remote port: 30005
[2024-06-20 18:36:39.938][rbfeeder] [2024-06-20 18:36:39]               Remote protocol: BEAST
[2024-06-20 18:36:39.956][rbfeeder] [2024-06-20 18:36:39]  Using GNSS (when available)
[2024-06-20 18:36:39.966][rbfeeder] [2024-06-20 18:36:39]  Start date/time: 2024-06-20 18:36:39
[2024-06-20 18:36:40.007][rbfeeder] [2024-06-20 18:36:39]  Socket for ANRB created. Waiting for connections on port 32088
[2024-06-20 18:36:41.194][rbfeeder] [2024-06-20 18:36:41]  Connection established.
[2024-06-20 18:36:41.195][rbfeeder] [2024-06-20 18:36:41]  Empty sharing key. We will try to create a new one for you!
[2024-06-20 18:36:41.197][rbfeeder] [2024-06-20 18:36:41]  CPU Serial empty. Use MAC address instead.
[2024-06-20 18:36:41.703][rbfeeder] [2024-06-20 18:36:41]  Your new key is ..................

Interestingly the network is named docker_default not config_default (not an adsb_im system).
That's just a note unrelated to the issue.

@ginlik1996 just because i don't have a better idea, let's have a look at:

cat /opt/adsb/rb/cpuinfo

[wiedehopf]

[2024-06-20 18:12:19.094][rbfeeder] Error opening the listening port 32458 (Raw TCP output): bind: Address already in use

This is from a log after you uploaded the log, so it's difficult to see the issue.
Also the log is too incomplete to really understand it, so you'd have to upload the log again and it should include the change.

[ginlik1996]

Well i fixed the issue by reinstalling Ubuntu and restoring the configuration from backup.

But I think i have an insight on what happened.

I started my configuration on a RPi 4 as a standalone feeder.
I bought a couple of weeks later an OrangePi zero 3 to use as a micro feeder.
I then installed a Ubuntu 22.04 LTS VM and i restored on it the full config backup from my RPi 4, then i changed the config to turn it into a stage 2.
After doing this I connected the OPi micro feeder and I noticed the issue.
Is it possible that by restoring the backup from an arm RPi to a Ubuntu x86 VM it was still looking for something about the RPi?

Anyway thanks everyone for the help!

[dirkhh]

I think one thing I need to make more strongly worded in the documentation.
A stage2 should best be started from scratch, not from an existing feeder.
We try hard to make it behave the same either way, but we have had a couple of instances with strange bugs where simply starting from scratch made everything work...