Segmentation Fault when following Bluetooth-KISS-TNC.pdf on Pi 0w

[n0mo]

Running a Pi 0w, I get a Segmentation fault shortly after starting direwolf:

pi@n0mo_tnc_01:~ $ direwolf
Dire Wolf version 1.5 (Feb 24 2018) Beta Test 2
Includes optional support for: gpsd

Reading config file direwolf.conf
Audio device for both receive and transmit: plughw:1,0 (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Will be checking periodically for /dev/rfcomm0
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept AGW client application 0 on port 8000 ...
Segmentation fault

I have tried commenting out SERIALKISSPOLL /dev/rfcomm0, but the issue remains.

[n0mo]

direwolf.conf.txt
Added txt extension for upload only.

[dranch]

Please enable core dumps on your Rpi ZeroW and send a backtrace to us:

https://blog.xojo.com/2015/08/17/take-a-core-dump-what-to-do-when-your-app-crashes-on-linux/

--David
KI6ZHD

[n0mo]

Attached.
core.gz

[dranch]

Please just provide the text from the gdb backtrace.. not the core itself

[n0mo]

(gdb) bt
#0 0x00024458 in hdlc_rec_bit ()
#1 0x00014820 in demod_afsk_process_sample ()
#2 0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[na7q]

Getting the same issue here on my pi zero with the dev 1.5 version.

[dranch]

I had forgot to ask before but can you recompile direwolf with debugging objects (add the use -g at the make line) and when cordumps, again do the backtrace and we should see more information than just "??".

[cniesen]

I have the same/similar issue with 1.5b2. 1.4 (release) is working fine. Here are the outputs:

(dev branch at commit 182713f :)

pi@aprs-igate:~ $ rtl_fm -f 144.39M - | direwolf -c sdr.conf -r 24000 -D 1 -t 0 -
Dire Wolf version 1.5 (Mar 31 2018) Beta Test 2

Reading config file sdr.conf
Audio input device for receive: stdin  (channel 0)
Audio out device for transmit: null  (channel 0)
Found 1 device(s):
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 24000 sample rate.
Note: PTT not configured for channel 0. (Ignore this if using VOX.)
Ready to accept AGW client application 0 on port 8000 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Tuner gain set to automatic.
Tuned to 144642000 Hz.
Oversampling input by: 42x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Exact sample rate is: 1008000.009613 Hz
Sampling at 1008000 S/s.
Output at 24000 Hz.
Signal caught, exiting!

User cancel, exiting...
Segmentation fault
pi@aprs-igate:~ $

(master branch at commit 23ea246 :)

pi@aprs-igate:~/direwolf $ rtl_fm -f 144.39M - | direwolf -c sdr.conf -r 24000 -D 1 -t 0 -
Dire Wolf version 1.4

Reading config file sdr.conf
Audio input device for receive: stdin  (channel 0)
Audio out device for transmit: null  (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 24000 sample rate.
Note: PTT not configured for channel 0. (Ignore this if using VOX.)
Found 1 device(s):
Use -p command line option to enable KISS pseudo terminal.
Ready to accept AGW client application 0 on port 8000 ...
Ready to accept KISS client application on port 8001 ...
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Tuner gain set to automatic.
Tuned to 144642000 Hz.
Oversampling input by: 42x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Exact sample rate is: 1008000.009613 Hz
Sampling at 1008000 S/s.
Output at 24000 Hz.
Connect to IGate server noam.aprs2.net (2607:7c80:54:1::21) failed.

Connect to IGate server noam.aprs2.net (199.167.130.10) failed.

Connect to IGate server noam.aprs2.net (205.206.140.4) failed.

Connect to IGate server noam.aprs2.net (165.138.206.199) failed.

Connect to IGate server noam.aprs2.net (45.79.213.91) failed.

Connect to IGate server noam.aprs2.net (2001:56a:f326:af00:97f3:6b71:732:9e3c) failed.

Connect to IGate server noam.aprs2.net (100.16.163.97) failed.

Connect to IGate server noam.aprs2.net (44.24.241.98) failed.

Connect to IGate server noam.aprs2.net (208.94.241.11) failed.

Connect to IGate server noam.aprs2.net (74.208.165.54) failed.


Now connected to IGate server noam.aprs2.net (205.206.140.4)
Check server status here http://205.206.140.4:14501

[ig] # aprsc 2.1.2-gc90ee9c
[ig] # logresp xxx unverified, server T2EDM

Sorry, I would need some "hand holding" to compile it with the debugging objects and gdb (-g isn't an option on make).

[dranch]

I assume you built your own version of Direwolf before. If that's not true, let me know and I can add more details. Anyway, I would first recommend to uninstall your previous version of Direwolf to remove any stray binaries (don't forget to make a backup of your direwolf.conf). Next, when you untar and prepare to build direwolf 1.5B2, edit the Makefile.linux file. In that file, find the line:

CFLAGS += -O3 -pthread -Igeotranz -D_XOPEN_SOURCE=600 -D_DEFAULT_SOURCE=1 -Wall

and change it to read

CFLAGS += -O0 -g -pthread -Igeotranz -D_XOPEN_SOURCE=600 -D_DEFAULT_SOURCE=1 -Wall

(Changing the -O optimization to be zero and enable debugging objects with -g).

Now build Direwolf with:

make -f Makefile.linux

The resulting Direwolf should have debugging objects in it now. Next, you can turn on core dumps in your Raspberry Pi with running the following at the command line:

ulimit -c 0

Finally, go ahead and running your original command line. When Direwolf crashes, find the core file (if should be in the current directory):

ls -la core.*

Let's assume it's named "core.1234". We also need to to know where the direwolf binary is. Run the next command to see where your direwolf binary is:

whereis direwolf
direwolf: /usr/local/bin/direwolf

Now run the gdb debugger to see what's having an issue:

gdb -c core.1234 /usr/local/bin/direwolf

Once the program logs up, run the command "bt" (for backtrace) and send the results back to this Github issue.

--David
KI6ZHD

[nojronatron]

I'm running DW 1.4 on Stretch on an RPi 2 B+. I'm returning to Direwolf after a vacation, but last time it was on Jessie and DW 1.3 (before I had any sort of handle on what I was doing).

I've run into "Segmentation Fault" and unexpected exit when monitoring a frequency with APRS traffic, and I have CDIGIPEAT 0 0 set in the config.

Testing with CDIGIPEAT 0 0 on a frequency with APRS traffic, with or without DIGIPEAT configured, consistently causes Direwolf exit with Segmentation Fault, almost always after the 1st APRS packet is heard.

Testing with CDIGIPEAT 0 0 on a frequency without APRS traffic, with or without DIGIPEAT configured, does NOT cause Segmentation Fault nor an abrupt exit (after an hour or so of observation).

Testing with CDIGIPEAT commented-out, with or without DIGIPEAT enabled on any frequency, does NOT cause Segmentation Fault nor an abrupt exit (after some time of observation).

I've noticed the same behavior with the 1.4 beta & 1.5-beta and beta2 after clean-up and rebuild.

Just out of curiosity if it matters: Where should CDIGIPEAT be put in the .config? I've added it a few lines below a valid DIGIPEAT entry (with arguments as listed in the instruction manual).

[dranch]

There was a reported issue with CDIGIPEAT that should have been fixed in Direwolf v1.5Beta2:

On CDIGIPEAT according to the doc, MYCALL is implied so that CDIGIPEAT 0 0 should just work however it causes a SEGFAULT (prevously discussed). I needed to use , and CDIGIPEAT needs something in the 3rd parameter to filter on:

CDIGIPEAT 0 0 ^VK1RGI-1$

Please give that a try and let us know if it fixes your issue.

--David
KI6ZHD

[nojronatron]

Seems to be working, thanks David!

[wb2osz]

This is from 7 years ago.
A lot has changed since then.
Please open a new case if still a problem.