Ruby Crashing?
-
I've been seeing crashes while using Ruby on the Omega. Since I'm using the "screen" utility from my Mac, I'm not able to capture all of the output. It happens consistently within a couple minutes of starting my Ruby script. What additional information can I provide to help debug this? Is anyone else seeing experiencing this instability?
- Process memory map:
00400000-00401000 r-xp 00000000 1f:03 447 /usr/lib/ruby/ruby2.2-bin
00410000-00411000 rw-p 00000000 1f:03 447 /usr/lib/ruby/ruby2.2-bin
00972000-00ad9000 rwxp 00000000 00:00 0 [heap]
77ae1000-77b62000 rw-p 00000000 00:00 0
77b62000-77bb9000 r-xp 00000000 1f:02 2650 /lib/libuClibc-0.9.33.2.so
77bb9000-77bc8000 ---p 00000000 00:00 0
77bc8000-77bc9000 r--p 00056000 1f:02 2650 /lib/libuClibc-0.9.33.2.so
77bc9000-77bca000 rw-p 00057000 1f:02 2650 /lib/libuClibc-0.9.33.2.so
77bca000-77bcf000 rw-p 00000000 00:00 0
77bcf000-77be3000 r-xp 00000000 1f:02 2665 /lib/libgcc_s.so.1
77be3000-77bf2000 ---p 00000000 00:00 0
77bf2000-77bf3000 rw-p 00013000 1f:02 2665 /lib/libgcc_s.so.1
77bf3000-77c09000 r-xp 00000000 1f:02 2693 /lib/libm-0.9.33.2.so
77c09000-77c18000 ---p 00000000 00:00 0
77c18000-77c19000 rw-p 00015000 1f:02 2693 /lib/libm-0.9.33.2.so
77c19000-77c1c000 r-xp 00000000 1f:02 2668 /lib/libcrypt-0.9.33.2.so
77c1c000-77c2b000 ---p 00000000 00:00 0
77c2b000-77c2c000 rw-p 00002000 1f:02 2668 /lib/libcrypt-0.9.33.2.so
77c2c000-77c3d000 rw-p 00000000 00:00 0
77c3d000-77c40000 r-xp 00000000 1f:02 2664 /lib/libdl-0.9.33.2.so
77c40000-77c4f000 ---p 00000000 00:00 0
77c4f000-77c50000 r--p 00002000 1f:02 2664 /lib/libdl-0.9.33.2.so
77c50000-77c51000 rw-p 00003000 1f:02 2664 /lib/libdl-0.9.33.2.so
77c51000-77cba000 r-xp 00000000 1f:03 439 /usr/lib/libgmp.so.10.2.0
77cba000-77cca000 ---p 00000000 00:00 0
77cca000-77ccb000 rw-p 00069000 1f:03 439 /usr/lib/libgmp.so.10.2.0
77ccb000-77cde000 r-xp 00000000 1f:02 2689 /lib/libpthread-0.9.33.2.so
77cde000-77ced000 ---p 00000000 00:00 0
77ced000-77cee000 r--p 00012000 1f:02 2689 /lib/libpthread-0.9.33.2.so
77cee000-77cef000 rw-p 00013000 1f:02 2689 /lib/libpthread-0.9.33.2.so
77cef000-77cf1000 rw-p 00000000 00:00 0
77cf1000-77e9b000 r-xp 00000000 1f:03 434 /usr/lib/libruby.so.2.2.0
77e9b000-77eab000 ---p 00000000 00:00 0
77eab000-77eb0000 rw-p 001aa000 1f:03 434 /usr/lib/libruby.so.2.2.0
77eb0000-77eb6000 rw-p 00000000 00:00 0
77eb6000-77ebd000 r-xp 00000000 1f:02 2649 /lib/ld-uClibc-0.9.33.2.so
77ec7000-77ec8000 ---p 00000000 00:00 0
77ec8000-77ecc000 rw-p 00000000 00:00 0 [stack:3322]
77ecc000-77ecd000 r--p 00006000 1f:02 2649 /lib/ld-uClibc-0.9.33.2.so
77ecd000-77ece000 rw-p 00007000 1f:02 2649 /lib/ld-uClibc-0.9.33.2.so
77ece000-77ecf000 rw-p 00000000 00:00 0
7f1b8000-7f9b7000 rw-p 00000000 00:00 0
7fff7000-7fff8000 r-xp 00000000 00:00 0 [vdso][NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.htmlAborted
-
I will look into this as I am not sure why you are experiencing this problem.
Have you tried troubleshooting with our Guidelines (at the top of the page)?
-
I have gone through the process. I even tried doing a full factory reset on the Onion Omega and reinstalled everything fresh. Same problem.
The software is a Ruby script calling the command-line to set / read GPIO pins. I'm in the process of re-writing it in Python, since there's better support in Python.
Let me know if you need more specific information or want me to try something.
-
I had a nodejs test app that had a loop to read from the gpio regularly. This app would only run for a few minutes at most before crashing due to lack of memory. Then I got a hold of a gpio class from a user with the last name "bishop", they had a function that was supposed to listen for a change on an input pin. Their code polled the pin regularly also, and also lead to the app crashing. I never found out why it was crashing, but I do remember pretty much any loop polling an input pin on a regular basis was making my app crash.
-
@R-H133 @James-Harding Can you try monitoring the amount of free memory while your programs are running? I have a feeling that there is a memory leak that causes the Omega to eventually run out of memory, crashing the program.
If that is the case, try extending the Omega's available memory with a swap file on a USB drive. Let me know how it goes!
-
@James-Harding Hi, I'm the person with last name 'bishop' that produced the code you refer to.
I would be most interested to see the code you are using to see if I can track down why you are getting the crash.You say you are accessing GPIO pins and getting the crash both when you don't use my code and when you do. Since my code uses similar (but not identical) methods to the standard Omega code to access the GPIO pins, the issue code potentially be in the GPIO access.
Alternatively, code you produce a version of your nodejs code that does everything except access the GPIO pins (e.g. replace the GPIO access code by dummy code that produces a default value). This might help track down if the crash is due to GPIO access or to your code or the nodejs system.
-
@Lazar-Demin - It is definitely running out of memory, but if I remember correctly I boiled my code down to just a loop checking the state of the gpio, after of course initializing it the way I wanted to use it.
Hey @Kit-Bishop, Firstly thanks for the code! Yes the code that I tried after running into issues with my own, was yours. My tests might be out of date because im using a version of code that is still using file writing (/sys/class/gpio/gpioX) to export, read value, and change direction. Where as there is a different gpio class that you have that actually writes directly to the register, like fast-gpio. But i think that class is written in C/C++ and does not have a nodejs addon. Please correct me if I am wrong there. I am new to the Omega and microcontrollers in general, and well I can only tell you what I see and know because I don't know anyone else using this platform.
