Segmentation fault without sudo
michela opened this issue · 18 comments
nxppy segfaults without sudo.
Would be useful if sudo wasn't required at run-time after installation with sudo (for the NXP library).
The EXPLORE-NFC examples don't require root to run.
Hi @michela, I'm not able to reproduce this condition with a fresh install of Raspbian and nxppy. I'm able to read cards as the pi user without issue.
Is the explore-nfc daemon running in the background? If you stop/kill it, are you able to read cards with nxppy as the pi user?
No, I get the same result whether or not explorenfcd is running or not.
Thanks @michela, let's try and narrow it down a little since I can't make it happen on my setup. What version of Raspbian are you running? Can you run your script under strace so we can see where it's faulting?
A GDB backtrace is also sometimes helpful: https://wiki.archlinux.org/index.php/Step-by-step_debugging_guide#Gdb
Pls find strace output attached.
I get the same error regardless of whether running in virtualenv or not.
Thank you. Can you also send over polling.py in its entirety? I'm seeing some imports that I wouldn't expect from the example code.
Okay, I think I may have an idea what's going on. With the latest version of Raspbian, the pi user is automatically included in the gpio group, which gives the user account access to the GPIO pins. In your strace output, any access to the GPIO pins fails with "Permission denied".
Can you try adding your pi user to the gpio group like this:
sudo usermod -a -G gpio pi
output.txt
Added pi to the gpio group but no change. strace attached
Noting I don't have a /sys/class/gpio/gpio2 folder on my device.
(nfc) pi@obe-dev-1 ~/src $ tree /sys/class/gpio
/sys/class/gpio
├── export
├── gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
└── unexport
Hi guys,
I am experiencing the same problem. If I elevate via sudo, working fine, but without, getting permission denied
) = 0
fstat64(0, {st_mode=S_IFREG|0600, st_size=79833, ...}) = 0
fstat64(1, {st_mode=S_IFREG|0600, st_size=79892, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f8b000
fstat64(0, {st_mode=S_IFREG|0600, st_size=80038, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f8a000
open("/sys/class/gpio/gpio2/direction", O_WRONLY) = -1 EACCES (Permission denied)
open("/sys/class/gpio/export", O_WRONLY) = -1 EACCES (Permission denied)
open("/sys/class/gpio/unexport", O_WRONLY) = -1 EACCES (Permission denied)
open("/sys/class/gpio/unexport", O_WRONLY) = -1 EACCES (Permission denied)
open("/sys/class/gpio/unexport", O_WRONLY) = -1 EACCES (Permission denied)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x58} ---
+++ killed by SIGSEGV +++
ive also tried your fix above ie adding pi to gpio but still the same problem.
Hi @michela, @rosshwalker,
Which OS and version are you guys running? My testing is on the latest Raspbian.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 8.0 (jessie)
Release: 8.0
Codename: jessie
I am running my script via cups-pdf environment so realise my problem is related to this. I dont know enough about cups environment to know how to fix this one.
Ross.
Can you both verify that this udev rule is present? http://stackoverflow.com/a/30940526/1697679
Confirming this line in 99-com.rules. Not sure if it was there prior to updating raspi-config and following the advice in stackoverflow
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio'"
No change after reboot
Noted gpiochip0 still had root:root ownership so manually changed - no luck
pi@obe-dev-1 /sys/class/gpio/gpiochip0 $ sudo chmod -R 770 *
pi@obe-dev-1 /sys/class/gpio/gpiochip0 $ sudo chown -R root:gpio *
Like another poster to stackoverflow who didn't get this working - this directory not present
/sys/devices/virtual/gpio
PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
NAME="Raspbian GNU/Linux"
VERSION_ID="7"
VERSION="7 (wheezy)"
ID=raspbian
ID_LIKE=debian
ANSI_COLOR="1;31"
How about creating the missing symlinks and assigning the permissions to match this screenshot?
Unfortunately since I don't see this issue on either my old or new Raspbian installations, I'm just shooting in the dark a bit. Not sure where these symlinks came from or why they seem to be missing on your installation. Also worth noting that /sys/class/gpio is the correct location - /sys/devices/virtual/gpio is no longer used in modern kernels.
I am seeing the same issue on Arch Linux. I have created an udev rule
SUBSYSTEM=="spidev", GROUP="tty", MODE="0660"
SUBSYSTEM=="bcm2835-gpiomem", GROUP="tty", MODE="0660"
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:tty /sys/class/gpio && chmod -R 770 /sys/class/gpio"
and all permissions seem to be correctly set:
$ ls -alh /sys/class/gpio/
-rwxrwx--- 1 root tty 4.0K Jan 11 19:52 export
-rwxrwx--- 1 root tty 4.0K Jan 11 19:52 unexport
lrwxrwxrwx 1 root tty 0 Jan 11 19:52 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
...
$ ls -alh /dev/gpiomem
crw-rw---- 1 root tty 244, 0 Jan 11 19:52 /dev/gpiomem
ls -alh /dev/spidev0.*
crw-rw---- 1 root tty 153, 0 Jan 11 19:52 /dev/spidev0.0
crw-rw---- 1 root tty 153, 1 Jan 11 19:52 /dev/spidev0.1
Interestingly, after running sudo python polling.py, the devices change (with the correct permissions)
$ sudo python polling.py
$ ls -alh /sys/class/gpio/
-rwxrwx--- 1 root tty 4.0K Jan 11 19:52 export
-rwxrwx--- 1 root tty 4.0K Jan 11 19:52 unexport
lrwxrwxrwx 1 root tty 0 Jan 29 10:13 gpio2 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpio2
lrwxrwxrwx 1 root tty 0 Jan 29 10:13 gpio23 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpio23
lrwxrwxrwx 1 root tty 0 Jan 29 10:13 gpio7 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpio7
lrwxrwxrwx 1 root tty 0 Jan 11 19:52 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
...
I figured it out. I can export pins just fine as a regular user
$ echo "2" > /sys/class/gpio/export
$ ls -alh /sys/class/gpio/
-rwxrwx--- 1 root tty 4.0K Jan 29 10:28 export
-rwxrwx--- 1 root tty 4.0K Jan 11 19:52 unexport
lrwxrwxrwx 1 root tty 0 Jan 29 10:25 gpio2 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpio2
...
however, inside /sys/class/gpio/gpio2, the permissions were still wrong:
$ ls -alh /sys/class/gpio/gpio2/
-rw-r--r-- 1 root root 4.0K Jan 29 10:25 direction
-rw-r--r-- 1 root root 4.0K Jan 29 10:25 value
...
because the files were linked from /sys/devices/platform/soc/
$ ls -alh /sys/devices/platform/soc/
drwxr-xr-x 4 root root 0 Jan 11 19:52 3f200000.gpio
...
If I added this directories to my udev rule
KERNEL=="spidev*", GROUP="tty", MODE="0660"
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:tty /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:tty /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:tty /sys/devices/platform/soc/*.gpio/gpio && chmod -R 770 /sys/devices/platform/soc/*.gpio/gpio'"
everything works as expected now.
@michela @rosshwalker can you try out @nils-werner's solution and see if it resolves your issue as well?
Please let me know if @nils-werner's solution doesn't work for you, and I'll be happy to try and troubleshoot further.