SIGSEGV: memory access violation (Running test app: caribou_dump1090)

[ki6uve]

Getting this error with running the CaribouLite test app: ./caribou_dump1090

soapy_sighandler caught SIGSEGV [INFO] soapy_sighandler killing soapy_cariboulite (cariboulite_release_driver) CaribouLite: Signal [11] received from pid=[-1695350262] Signal [11] caught, with the following information: signal errno = 0 signal process pid = -1695350262 signal process uid = 65535 signal status = 0 signal errno / SIGSEGV / the process access a valid region of memory in an invalid way - violated memory access permissions SIGSEGV: memory access violation

Anyone have any solutions?

[mjmckenna]

Hi.... are you running with PiOS or DragonOS? I downloaded the latest DragonOS with the 6.5 kernel (https://www.youtube.com/watch?v=oa9ZlwYyCxA&t=310s) and was able to get the cariboulite to transmit CW with the test app from both the 1HGz narrowband and wideband channels.

[ki6uve]

Yes, I'm using the latest DragonOS. SDR++ works but cannot get Dump1090 to work with the CaribouLite.

[ki6uve]

Does anyone know if the CaribouLite SDR project is abandoned? Are there any other places to reach people who have one and can help with getting it working?

[alphafox02]

I’m trying to get back to checking this as well, can someone confirm the main branch compiled on DragonOS. I only tested the fork someone had created to address the 6.5 kernel. I’ll rebuild and try the dump1090 app, but out of curiosity - does it need to be that specific app vs using another that’s capable of using soapy input for 1090 info? I mean for a temporary workaround.

[ki6uve]

I don't know if I specifically need dump1090...I'm just trying to get the RPi with CaribouLite to feed ADSB data into my Virtual Radar app for displaying air traffic. When I run the dump1090 test app, I get the error above. When I run the full version of Dump1090, it fails to launch stating that it couldn't find a compatible RTLSDR.

[mjmckenna]

Just an FYI that the gnu-radio cariboulite source block shows the same Malloc overrun as the caribou_dump1090.

Best Regards, Mark

On Tue, Mar 12, 2024 at 6:14 PM ki6uve @.***> wrote:

I don't know if I specifically need dump1090...I'm just trying to get the RPi with CaribouLite to feed ADSB data into my Virtual Radar app for displaying air traffic. When I run the dump1090 test app, I get the error above. When I run the full version of Dump1090, it fails to launch stating that it couldn't find a compatible RTLSDR.

— Reply to this email directly, view it on GitHub https://github.com/cariboulabs/cariboulite/issues/196#issuecomment-1992670882, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABXEELHON775B66PLTH7TTLYX542ZAVCNFSM6AAAAABEQSEG6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJSGY3TAOBYGI . You are receiving this because you commented.Message ID: @.***>

[alphafox02]

I just attempted to build from main on this repo on latest DragonOS Pi64, but making the changes as shown roughly in the video from the forked repo, checking user groups, and applying the chmod g+rw /dev/gpiomem

and even CubicSDR I’m getting a SIGSEGV memory access violation. I swear every time I get exited to see new updates to the repo I run into an issue with running it each time. I’ll have to drop back to the forked repo where I last new things would run and try the 1090 app with that.

[alphafox02]

Nevermind I made a mistake and left dtparam=i2c_arm=on in place without commenting it out.

Fixed that, rebooted, built the dump1090 app and it’s now running. Waiting to see if it shows any aircraft.

[ki6uve]

Are you using the CaribouLite on an RPi4? Please post a link to which Dump1090 branch you used. Thanks!!

[alphafox02]

I may have been confused as to what you meant by dump 1090. I thought you were trying to use the dump 1090 app that is in this repository for the hat. Seems to be a very basic one. I’ll try something else.

[ki6uve]

Redid every again to test it and I still cannot get it working. These are the exact steps I used:

1. Flashed card with DragonOS Pi64 Beta 35.1
2. mkdir projects
3. git clone https://github.com/unixpunk/cariboulite.git
4. cd cariboulite
5. git checkout patch-1
6. ./install.sh
7. edit /boot/firmware/config.txt with the following:
8. Comment out 'dtparam=i2c_arm=on' and ' dtparam=spi=on
9. Added: 'dtparam=i2c_vc=on' and 'dtoverlay=spi1-3cs'
10. sudo usermod -aG dialout,root ubuntu
11. sudo nano /etc/rc.local
12. Added: 'chmod g+rw /dev/gpiomem'
13. Rebooted
14. Navigate to ~/projects/cariboulite/examples/cpp
15. mkdir build
16. cd build/
17. cmake ../
18. make
19. ./caribou_dump1090

Then I get the error listed above regarding memory violation

[ki6uve]

Well, I tried again with 32bit bullseye version of the OS, but same error. So frustrating.

[alphafox02]

Can you show your config.txt ?

[ki6uve]

[all] kernel=vmlinuz cmdline=cmdline.txt initramfs initrd.img followkernel

[pi4] max_framebuffers=2 arm_boost=1

[all]

Enable the audio output, I2C and SPI interfaces on the GPIO header. As these

parameters related to the base device-tree they must appear before any

other dtoverlay= specification

dtparam=audio=on

dtparam=i2c_arm=on

dtparam=spi=on

dtparam=i2c_vc=on dtoverlay=spi1-3cs dtoverlay=smi-dev

Comment out the following line if the edges of the desktop appear outside

the edges of your display

disable_overscan=1

uncomment this if your display has a black border of unused pixels visible

and your display can output without overscan

disable_overscan=1

If you have issues with audio, you may try uncommenting the following line

which forces the HDMI output into HDMI mode instead of DVI (which doesn't

support audio output)

hdmi_drive=2

hdmi_force_hotplug=1

Next is for headless usage only (no HDMI connected) and 1080P resolution

hdmi_force_mode=1

hdmi_group=2

hdmi_mode=82

[cm4]

Enable the USB2 outputs on the IO board (assuming your CM4 is plugged into

such a board)

dtoverlay=dwc2,dr_mode=host

[all]

Enable the KMS ("full" KMS) graphics overlay, leaving GPU memory as the

default (the kernel is in control of graphics memory with full KMS)

Comment the below line for headless usage

dtoverlay=vc4-kms-v3d

Autoload overlays for any recognized cameras or displays that are attached

[ki6uve]

Maybe my headers are not correct. I do get this error too: sudo apt-get -y install raspberrypi-kernel-headers module-assistant Reading package lists... Done Building dependency tree... Done Reading state information... Done E: Unable to locate package raspberrypi-kernel-headers

[mjmckenna]

If you are using DragonOS, it’s an Ubuntu/Lubuntu release so you have to comment out the raspberry pi headers. The previous 2 you-tube videos from cemaxecuter cover the changes to the install.sh

https://youtu.be/CO4Sg5iWb3k?si=D3Ig4sT2ZCTVsCA7 https://youtu.be/CO4Sg5iWb3k?si=D3Ig4sT2ZCTVsCA7

Best Regards, Mark

On Thu, Mar 14, 2024 at 4:15 PM ki6uve @.***> wrote:

Maybe my headers are not correct. I do get this error too: sudo apt-get -y install raspberrypi-kernel-headers module-assistant Reading package lists... Done Building dependency tree... Done Reading state information... Done E: Unable to locate package raspberrypi-kernel-headers

— Reply to this email directly, view it on GitHub https://github.com/cariboulabs/cariboulite/issues/196#issuecomment-1998351521, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABXEELGBK22E4MKKA3MZKQLYYIAPHAVCNFSM6AAAAABEQSEG6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJYGM2TCNJSGE . You are receiving this because you commented.Message ID: @.***>

[ki6uve]

Mark: The video for R34 didn't show commenting out the RPi headers in the install.sh. Does that still need to be done if I am trying this with Dragon R35.1?

[mjmckenna]

Hi. He didn’t mention commenting out the headers line on the last video, but I recall a longer discussion in the Beta R32 video @ 2min mark.

I went back this am and checked the images with the recent DragonOS 64 with a kernel of 6.5, Dragon Os 64 with kernel of 5.15, RPi OS 64 with 6.1.21.

For all, I had the same issue with caribou-dump1090 crashing. On the DragonOS 6.5 and RPi OS 6.1.21, SoapySDRutil —find will find the 2 channels of the cariboulite without issue. On DragonOS 5.15., it finds the cariboulite with a similar error as dump1090. For all, running grc with the cariboulite source block I get a malloc error

Best Regards, Mark

On Fri, Mar 15, 2024 at 11:03 AM ki6uve @.***> wrote:

Mark: The video for R34 didn't show commenting out the RPi headers in the install.sh. Does that still need to be done if I am trying this with Dragon R35.1?

— Reply to this email directly, view it on GitHub https://github.com/cariboulabs/cariboulite/issues/196#issuecomment-1999856875, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABXEELASNKBEO52KLBF2UL3YYMETHAVCNFSM6AAAAABEQSEG6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJZHA2TMOBXGU . You are receiving this because you commented.Message ID: @.***>

[ki6uve]

Mark: Were you ever able to get cariboulite working with dump1090? If so, what DragonOS version? Also, what cariboulite branch? UnixPunk patch-1 or something else.

[unixpunk]

@ki6uve @mjmckenna i don't believe anyone has gotten much to work beyond software that supports SoapySDR. the different dump1090's don't seem to work yet (unless you find one supporting soapysdr), gnuradio, gqrx and other software trying to use the driver directly might still be a problem. SoapySDRServer / SoapyRemote, CubicSDR work fine as examples of some using SoapySDR.

You also need to make sure your user/group has rw access to /dev/gpiomem so that you don't need to use sudo as using sudo will cause other issues with CubicSDR, for example, because pulseaudio may not be running at the system level/under root.

hth. we're all mostly waiting and trying to contribute where we can but appears most of us end-users aren't software developers by day, though I'm seeing some new hero's contributing!

[mjmckenna]

Sorry, my text that the caribou_dump1090 failed in all cases. Is it something about going in under cpp and creating a build dir and building just the dump1090?

somehow got deleted. I have a feeling the two cases on youtube were on RPOS32-bit armhf OS

https://www.youtube.com/watch?v=YVl0995zDS4 alsotalks about the changes in DragonOS for the install.sh @2min

On Fri, Mar 15, 2024 at 1:49 PM ki6uve @.***> wrote:

Mark: Were you ever able to get cariboulite working with dump1090? If so, what DragonOS version? Also, what cariboulite branch? UnixPunk patch-1 or something else.

— Reply to this email directly, view it on GitHub https://github.com/cariboulabs/cariboulite/issues/196#issuecomment-2000154916, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABXEELDRUH7O2AOFL2BIJYLYYMYAZAVCNFSM6AAAAABEQSEG6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBQGE2TIOJRGY . You are receiving this because you commented.Message ID: @.***>

-- Best Regards, Mark

[mjmckenna]

Thank you for your contributions unixpunk. Cariboulite labs has videos of the side transmitting but I haven’t been able to get mine transmitting other than CW thru the cariboulite_util_tool. I was hoping to use a SoapySDR sink in grc to transmit.

Have you been able to transmit and if so, which program?

Best Regards, Mark

On Fri, Mar 15, 2024 at 2:27 PM unixpunk @.***> wrote:

@ki6uve https://github.com/ki6uve @mjmckenna https://github.com/mjmckenna i don't believe anyone has gotten much to work beyond software that supports SoapySDR. the different dump1090's don't seem to work yet (unless you find one supporting soapysdr), gnuradio, gqrx and other software trying to use the driver directly might still be a problem. SoapySDRServer / SoapyRemote, CubicSDR work fine as examples of some using SoapySDR.

You also need to make sure your user/group has rw access to /dev/gpiomem so that you don't need to use sudo as using sudo will cause other issues with CubicSDR, for example, because pulseaudio may not be running at the system level/under root.

hth. we're all mostly waiting and trying to contribute where we can but appears most of us end-users aren't software developers by day, though I'm seeing some new hero's contributing!

— Reply to this email directly, view it on GitHub https://github.com/cariboulabs/cariboulite/issues/196#issuecomment-2000225467, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABXEELGNJTSS3V24FOD6LADYYM4S3AVCNFSM6AAAAABEQSEG6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBQGIZDKNBWG4 . You are receiving this because you were mentioned.Message ID: @.***>

[unixpunk]

i've not tried tx yet, last i saw it was cw-only until this pr is complete: https://github.com/cariboulabs/cariboulite/pull/197

[alphafox02]

Okay I'm back! in the copy/paste above of the config.txt on DragonOS I notice you have this line, dtoverlay=smi-dev

Did you add that? In my configuration I've got the two dtparam lines commented out, then added the i2c_vc and spi1-3cs and right after that it does into the comment out the following line if the edges blah blah.

Remove that dtoverlay=smi-dev and reboot. See if your issue goes away.

Also to catch everyone up on the latest DragonOS Pi64 image I shoved in the 6.5 kernel to provide 22.04 the ability to run on the Pi5. I have also put the kernel headers for that specific kernel. There's no need to add anything else nor change the kernel. In fact the kernel won't ever update unless you pull down and manually do so.

[alphafox02]

Aslo @unixpunk I did try the from main code here and manually had to edit the cpp file that you did, the line number has changed where the extra parameter needs removed. If the developer made that one change, the install goes basically perfectly to include the groups being added to the user.

[ki6uve]

Just to be clear...Does someone have the native dump1090 app working?  If so, what version of DragonOS and what branch of the cariboulite software.  I've tried removing the smi dev line from my config.txt but it still fails.  On Mar 17, 2024, at 4:17 PM, alphafox02 @.***> wrote: Aslo @unixpunk I did try the from main code here and manually had to edit the cpp file that you did, the line number has changed where the extra parameter needs removed. If the developer made that one change, the install goes basically perfectly to include the groups being added to the user.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[alphafox02]

I made a new ticket with the exact steps I took. I’ll go update it thought to mention building the dump1090 app.

[ki6uve]

You're a gentleman and a scholar!!!On Mar 17, 2024, at 5:01 PM, alphafox02 @.***> wrote: I made a new ticket with the exact steps I took. I’ll go update it thought to mention building the dump1090 app.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[alphafox02]

I'm getting now a memmor access violation with gqrx, but nothing else (yet).

[unixpunk]

Aslo @unixpunk I did try the from main code here and manually had to edit the cpp file that you did, the line number has changed where the extra parameter needs removed. If the developer made that one change, the install goes basically perfectly to include the groups being added to the user.

@alphafox02 I found my change solves the issue for DragonOS's version of Ubuntu but it breaks it for other OS versions, don't recall specifically if it was Raspbian or what I saw it with and had to undo my change to build... I have no idea why the difference; this is why they haven't merged it yet I assume.

[DanaGoyette]

I get a similar SIGV violation in gqrx.

After hacking at all the CMakeLists.txt files to force a Debug build (the files all force a Release build instead of respecting CMAKE_BUILD_TYPE), Valgrind points out where the bad write is:

Valgrind points me to here:

gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.5.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp xtrx
Resampling audio 96000 -> 48000
BandPlanFile is /home/dana/.config/gqrx/bandplan.csv
BookmarksFile is /home/dana/.config/gqrx/bookmarks.csv
[INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_107400; UHD_4.3.0.0+ds1-5
libusb: warning [libusb_exit] device 2.1 still referenced
libusb: warning [libusb_exit] device 1.3 still referenced
libusb: warning [libusb_exit] device 1.2 still referenced
libusb: warning [libusb_exit] device 1.1 still referenced
[INFO] SoapyCaribouliteSession, sessionCount: 0
==57875== Invalid write of size 8
==57875==    at 0x7EAE998: spi_init (in /usr/lib/aarch64-linux-gnu/libbladeRF.so.2)
==57875==    by 0x1D4746B7: io_utils_spi_add_chip (io_utils_spi.c:427)
==57875==    by 0x1D4646FB: caribou_fpga_init (caribou_fpga.c:130)
==57875==    by 0x1D4602AF: cariboulite_init_driver_minimal (cariboulite_setup.c:624)
==57875==    by 0x1D4605AB: cariboulite_init_driver (cariboulite_setup.c:691)
==57875==    by 0x1D45D64B: SoapyCaribouliteSession::SoapyCaribouliteSession() (CaribouliteSession.cpp:49)
==57875==    by 0x1D4577A3: __static_initialization_and_destruction_0(int, int) (Cariboulite.cpp:5)
==57875==    by 0x1D4577DF: _GLOBAL__sub_I_Cariboulite.cpp (Cariboulite.cpp:545)
==57875==    by 0x40044C7: call_init (dl-init.c:74)
==57875==    by 0x40044C7: call_init (dl-init.c:26)
==57875==    by 0x40045D3: _dl_init (dl-init.c:121)
==57875==    by 0x6EBEDD3: _dl_catch_exception (dl-error-skeleton.c:182)
==57875==    by 0x400A437: dl_open_worker (dl-open.c:808)
==57875==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
==57875==
CaribouLite: Signal [11] received from pid=[16]
Signal [11] caught, with the following information:
   signal errno = 0
   signal process pid = 16
   signal process uid = 0
   signal status = 0
   signal errno / SIGSEGV / the process access invalid region of memory
SIGSEGV: memory access violation

gdb shows this:

#0  0x0000007ff499e998 in spi_init (phy=<optimized out>, userdata=0x7fffffb060) at ./thirdparty/analogdevicesinc/no-OS_local/platform_bladerf2/platform.c:16
No locals.
#1  0x0000007fdca646b8 in io_utils_spi_add_chip (dev=0x7fdca99230 <SoapyCaribouliteSession::sys+400>, cs_pin=18, speed=1000000, swap_mi_mo=0, mode=0, chip_type=io_utils_spi_chip_type_fpga_comm, hard_dev=0x7fffffb0f8)
    at /home/dana/Downloads/cariboulite/software/libcariboulite/src/io_utils/io_utils_spi.c:427
        spi_device_file = "/dev/spidev1.0\000\000\000\000\000\000`\237\202\300\000\000\000\000\000\000\000"
        res = -1
        __func__ = "io_utils_spi_add_chip"
        i = 0
        new_chip_index = 0
#2  0x0000007fdca546fc in caribou_fpga_init (dev=0x7fdca994c8 <SoapyCaribouliteSession::sys+1064>, io_spi=0x7fdca99230 <SoapyCaribouliteSession::sys+400>)
    at /home/dana/Downloads/cariboulite/software/libcariboulite/src/caribou_fpga/caribou_fpga.c:130
        __func__ = "caribou_fpga_init"
        hard_dev_fpga = {spi_dev_id = 1, spi_dev_channel = 0, spidev = {fd = 0, speed = 0, mode = 0 '\000', lsb = 0 '\000', bits = 0 '\000'}}
#3  0x0000007fdca502b0 in cariboulite_init_driver_minimal (sys=0x7fdca990a0 <SoapyCaribouliteSession::sys>, info=0x0, production=false) at /home/dana/Downloads/cariboulite/software/libcariboulite/src/cariboulite_setup.c:624
        __func__ = "cariboulite_init_driver_minimal"
        led0 = 127
        led1 = -593164884
        btn = 127
        cfg = -592904024
#4  0x0000007fdca505ac in cariboulite_init_driver (sys=0x7fdca990a0 <SoapyCaribouliteSession::sys>, info=0x0) at /home/dana/Downloads/cariboulite/software/libcariboulite/src/cariboulite_setup.c:691
        ret = 127
        __func__ = "cariboulite_init_driver"
        self_tes_res = {fpga_fail = 0, modem_fail = 0, mixer_fail = -592902432, smi_fail = 127}

It sure would be helpful to have those logs from the ZF_LOGD statements go to stderr.

EDIT: This might be a different bug, actually...