[SOLVED] RPi.GPIO and Python segfaults - Printable Version +- Forum (http://forum.xbian.org) +-- Forum: Software (/forum-6.html) +--- Forum: Others (/forum-24.html) +--- Thread: [SOLVED] RPi.GPIO and Python segfaults (/thread-2778.html) |
RPi.GPIO and Python segfaults - skpacman - 24th Feb, 2015 06:43 AM Raspberry Pi 2 B 16GB PNY MicroSD Latest XBian image (as of 2-23-14) I tried running sudo apt-get install python-rpi.gpio but it says it couldn't find the package. Ok... so I go grab the latest package online, run the python setup.py install from the downloaded RPi.GPIO (0.5.11) and it runs fine. I do the same for psutil (2.2.1). I have a python script that uses RPi.GPIO and psutil to display information to a lcd screen I have mounted on the front of the case I have my RPi2 and hardware in. I was previously using a RPiB+ and Raspbian and the script was working just fine. After moving to the RPi2B and XBian (because Raspbmc isn't supported on the RPi2B), the python script segfaults when run. I have the script on PasteBin if anyone wants to take a look... It's not purdy, but it works. EDIT: I ran a gdb backtrace on it and this is what I got: Terminal sudo gdb python GNU gdb (GDB) 7.4.1-debian Copyright © 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabihf". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/python...Reading symbols from /usr/lib/debug/usr/bin/python2.7...done. done. (gdb) run smallfont_test.py Starting program: /usr/bin/python smallfont_test.py [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". Program received signal SIGILL, Illegal instruction. 0x7698c608 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 (gdb) backtrace #0 0x7698c608 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 #1 0x76989004 in OPENSSL_cpuid_setup () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 #2 0x76fe8254 in ?? () from /lib/ld-linux-armhf.so.3 #3 0x0037a848 in ?? () #4 0x0037a848 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) RE: RPi.GPIO and Python segfaults - CurlyMo - 24th Feb, 2015 07:22 AM You should use wiringX and it's python module. It natively supports various devices. Only downfall is you should compile it yourself. RE: RPi.GPIO and Python segfaults - skpacman - 24th Feb, 2015 07:53 AM That doesn't really solve my problem. I will install wiringX and attempt to rewrite my code to use it, but it still doesn't solve my current problem. What is causing the segmentation fault? What steps do I take to figure it out? I'm a noob here. I'm new to python, I'm nowhere near a linux guru, and the RPi2 has done nothing but throw curveballs at me since I plugged it in. RE: RPi.GPIO and Python segfaults - CurlyMo - 24th Feb, 2015 08:01 AM I don't know what is wrong with that python module. We have nothing to do with it. Ask them. But i am the maintainer of wiringX, so i know about that RE: RPi.GPIO and Python segfaults - skpacman - 24th Feb, 2015 08:14 AM I changed my script to use wiringX and (at least from my terminal at work) it seems to be working. I'll make sure it's talking nice with my lcd screen when I get some time tonight at home. Not the solution I was hoping for, but at least it works. RE: RPi.GPIO and Python segfaults - CurlyMo - 24th Feb, 2015 07:19 PM Why? If you got it working with SPI you also got it working on at least the Hummingboard natively. If you used GPIO your code works natively on the Raspberry Pi, Hummingboard, BananaPi, Radxa and more to come. Isn't that an improvement? RE: RPi.GPIO and Python segfaults - skpacman - 25th Feb, 2015 01:03 AM Well, it stopped segfault-ing. Now the LCD isn't displaying as expected. Are the pin designations different between RPi.GPIO and wiringX? I was using BCM designations in RPi.GPIO, does that make a difference? See my new code on PasteBin. I do appreciate that this GPIO code can work on all of those boards using wiringX, but I don't use anything other than RPi right now. EDIT: Ah... answered my own question. Yes, the numbers are different between RPi.GPIO BCM and WiringX. Found it thanks to your site's handy tables. |