Explorerhat Pro CapTouch Segmentation Fault on Exit

Discussion Raspberry Pi
1

Hello,

I have a Raspberry Pi 3 with 2016-03-18-raspbian-jessie and running Python 2.7.9.

The captouch buttons work fine but when the program exits, there is usually a segmentation fault. At startup, the callback function is registered with the pressed() function. The touchpad() function just prints the key presses.

startup

explorerhat.touch.pressed(touchpad)

touchpad

def touchpad(channel, event):
print “Got {} on {}”.format(event, channel)

Output

Explorer HAT Pro detected…
Startup
Got press on 4
Got press on 3
Got press on 2
Got press on 1

Explorer HAT exiting cleanly, please wait…
Stopping flashy things…
Stopping user tasks…
Cleaning up…
Goodbye!
Segmentation fault

This may be a timing problem. It always happens from a GUI terminal but does not always happen from an SSH shell.

Thank you,

Mark

2

More Information

I enabled core dumps and can now see that the error is a SIGSEGV in output_gpio() when called by pwm_thread().

3

Hi Mark,

That’s very odd. On a Raspberry Pi 3 running the latest version of Raspbian Jessie, I can’t replicate your seg. fault. This is the code that I’m using:

import explorerhat as eh

def touchpad(channel, event):
    print "Got {} on {}".format(event, channel)

eh.touch.pressed(touchpad)

Then control-d to exit, and I get the expected:

Explorer HAT exiting cleanly, please wait...
Stopping flashy things...
Stopping user tasks...
Cleaning up...
Goodbye!

without the seg. fault.

Are you running it interactively in a Python prompt in the terminal?

4

Reproduce with

I can reproduce it with this command and it occurs about 50% of the time:

python sandy.py

sandy.py

import explorerhat as eh
from time import sleep

def touchpad(ch, ev):
print “Got {} on {}”.format(ev, ch)

eh.touch.pressed(touchpad)

while True:
sleep(1)

#end

Output

(1st run ok, 2nd run segfault)
pi@raspberrypi:~/logger $ python sandy.py
Explorer HAT Pro detected…
Got press on 1
Got press on 2
Got press on 3
Got press on 4
^CTraceback (most recent call last):
File “sandy.py”, line 10, in
sleep(1)
KeyboardInterrupt

Explorer HAT exiting cleanly, please wait…
Stopping flashy things…
Stopping user tasks…
Cleaning up…
Goodbye!
Segmentation fault (core dumped)
pi@raspberrypi:~/logger $

GDB backtrace

[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib/arm-linux-gnueabihf/libthread_db.so.1”.
Core was generated by `python sandy.py’.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x76a07c9c in output_gpio () from /usr/lib/python2.7/dist-packages/RPi/_GPIO.arm-linux-gnueabihf.so
(gdb) backtrace
#0 0x76a07c9c in output_gpio () from /usr/lib/python2.7/dist-packages/RPi/_GPIO.arm-linux-gnueabihf.so
#1 0x76a0989c in pwm_thread () from /usr/lib/python2.7/dist-packages/RPi/_GPIO.arm-linux-gnueabihf.so
#2 0x7e836908 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

Thoughts?

Since occurance is not 100%, I am thinking it could be a race – possibly with a callback using freed memory.

pi@raspberrypi:~/logger $ python --version
Python 2.7.9

5

The touch detection is handled in the background with a threaded polling loop, right back in the Cap1xxx library. I’d wager that’s where something is going wrong, since exiting before cleanly stopping a thread can cause all sorts of woes.

There should be a Python “atexit” handler function registered to prevent this, but clearly things aren’t being handled in the order they should, or something has been overlooked.

I think the logical next step would be to try and recreate this using just the Cap1xxx library directly, then we can narrow it down to the right thing. I’ll tuck it on the end of my TODO list.