Linux Library for low speed IO Communication in C with bindings for C++, Python, Node.js & Java. Supports generic io platforms, as well as Intel Edison, Intel Joule, Raspberry Pi and many more.
I'm running into what I think is a bug in libmraa while working on integrating it into a fairly complex tool that requires SIGINT for proper cleanup (https://github.com/dgatwood/ndi_camera_control). At a high level, the code does this:
Uses a wrapper function for each pin write.
Creates a context for that pin (in a global array) if it does not exist.
Calls the mraa_gpio_write function.
This is all happening on a background thread that is doing software PWM on a pile of pins.
What I'm seeing is that when I send SIGINT, some of my cleanup starts happening, a bunch of threads exit, and then
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xfffff717f040 (LWP 3292)]
0x0000fffff7a81bf4 in mraa_gpio_write () from /usr/local/lib/libmraa.so.2
It looks like that might be the only thread that's running at that point, in which case I can easily work around it by shutting off the lights and stopping talking to GPIO as soon as I get a SIGINT, but I still wouldn't expect a segfault just by continuing to hammer at GPIO pins until the process dies. I'm guessing it is a race condition in the library somewhere.
I've worked around it in my code, but if you want to reproduce it, you can run the tool above (or some scaled-down portion thereof) and change "while (!exit_app)" back to "while(true) in the runPWMThread() function.
I'm running into what I think is a bug in libmraa while working on integrating it into a fairly complex tool that requires SIGINT for proper cleanup (https://github.com/dgatwood/ndi_camera_control). At a high level, the code does this:
This is all happening on a background thread that is doing software PWM on a pile of pins.
What I'm seeing is that when I send SIGINT, some of my cleanup starts happening, a bunch of threads exit, and then
Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xfffff717f040 (LWP 3292)] 0x0000fffff7a81bf4 in mraa_gpio_write () from /usr/local/lib/libmraa.so.2
It looks like that might be the only thread that's running at that point, in which case I can easily work around it by shutting off the lights and stopping talking to GPIO as soon as I get a SIGINT, but I still wouldn't expect a segfault just by continuing to hammer at GPIO pins until the process dies. I'm guessing it is a race condition in the library somewhere.
I've worked around it in my code, but if you want to reproduce it, you can run the tool above (or some scaled-down portion thereof) and change "while (!exit_app)" back to "while(true) in the runPWMThread() function.