Find another way for event detection ? This lib can crash the OS.
Closed this issue · 3 comments
New issue to not pollute the previous issue.
You should warn people that using this lib can crash the system, using a simple php class with sysfs is more realiable if you don't need advanced functionalities.
As I dont need SPI, I2C, PWM, I build another simple class with sysfs and event dection (3Hz is really enought for my needs, I just compare the lastest state to detect an event, and high event stay a lot of seconds (about 30s), so I dont need to detect a 100ms lvl high).
I dont I time to find the line, because it crash the RPI OS on every event low -> up without any low, only reboot is possible, it's very long, that's why I prefer to use sysfs, it's safe enought faster and light.
To reproduce : install raspbian lastest, add buster repo, update/upgrade, install php-7.2.4?, php-curl, php-event.
Note : I have a websocket server in the event loop too and php-redis as cache, I use laravel command to run the program (in root).
I have build my own library with sysfs/file_get_content file_put_content and custom Hz, without extension, it's safe and dont crash the rpi, you cant do 60kHz but about 30kHz so it's enought.
I think that accessing gpio registers is not realiable to use in production (because of system crash).
Remember : the crash is on raspbian buster (not "stable"), with php 7.1 / 7.2 Maybe no crash with raspbian stretch (but outdated php7.0 not compatible with my app).
Maybe you should find another (safe) way to do it (like pure C ext with real event, but it's very diffucult to code !).
You can do real edge detection with sysfs (gpioX/edge) but it is blocking, so you need other php extension, like swoole with true multithread/event, but I didn't played with it yet, react loop is non blocking only. Try to look at this : https://www.swoole.co.uk
It's faster than node, and can be compatible with react plugin, you can sleep(X) in event or do blocking tasks like gpioX/edge) without blocking the program.
There are other PHP libraries that use sysfs directly, like php-gpio and PiGPIO. Did you have a look at them before making your own? There's a fair amount of community support in both of them.
I can't help but notice here that you're using Raspbian Buster. Are you sure that this isn't the cause of the issue? Have you tried another library that uses the event registers, like wiringPi? For simple edge detection, you should be able to run this as an unprivileged user (ie not root). If the system is freezing and you're not running this at root, that suggests to me that it's less likely to be a library issue.
I think it's fair to assume that a "stable" release should be stable, but I can't help but think that you'd use a "testing" release at your own risk. Buster isn't due for release for another 6 months, there could well still be issues there. Can you replicate this issue using any standard Raspbian images?
Do you have any information on why using dev/mem is not safe? It might help to identify what's going wrong. If you have a look through the SoC doc, that outlines all the peripheral address as used in this library.
Everyone has their own use-cases for projects like this, and fundamentally changing how this library works would lose the advantages that have been gained by this implementation.
Although I've spend many hours on this project, it's still really just a hobby - I don't have time to explore the likes of swoole (as an aside, that would involve installing a PHP extension, I understood that the point of using sysfs was to avoid this). If you'd like to make a PR to allow a pluggable driver, by all means do!
I prefer my own library, it's very small and fit my needs (only 165 lines ...), can be used on another board (not only rpi), I just need set high/low, in/out pull up/down, and slooow input event detection. We need
reliable boards (escape room), so we can change for other boards later.
I don't really know why /dev/mem is unsafe (maybe low level access is more powerfull but dangerous), but on many forums , many developpers says "don't use /dev/mem, it's bad it can crash the system or destroy the board!", yes sometime people say "it's bad" but it is no really bad.
I use buster only because I need php 7.2 (laravel 5.6, and performance ++), stable raspbian have an outdated php version (7.0), and generally a lots of outdated packages (I dont use a lot debian, but gentoo on servers). OK I should try to stay in stretch and install php 7.2. I have tried wiringPi, no freeze. msantiago (previous issue), had a freeze in raspbian stretch, so I think that it is not only buster stability problem in some lib.
@neoteknic Glad you've found a solution. Have you considered making your library available to the community?
Have you tested a slightly older version of PHP? I understand that Laravel 5.6 will run on 7.1
It'd be really helpful if you could link in some of the discussion around the use of /dev/mem, it might provide a way to work around this issue.