-
Notifications
You must be signed in to change notification settings - Fork 365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[0.3b2] gen_gdl90 defunct process #48
Comments
Anything interesting in dmesg, /var/log/messages or /var/log/stratux.log ? |
I see a number of references in kern.log like this: kern.log:Sep 17 20:22:01 raspberrypi kernel: [17520.741910] INFO: task gen_gdl90:2377 blocked for more than 120 seconds. In Stratux.log, I see many pages of message queue overflows: I don't know the mechanism for aging out client devices, but I don't think both devices (iphone and ipad) were still connected during this period, which may have resulted in the queue overflow. Those are the only items that look interesting to me. |
It's using ICMP pings to determine if the clients are responding, if not then it should not be queueing messages for them. Sounds like it may have run out of resources. Are you able to replicate this at all? If so, can you check "free -m; df -h", and other messages in dmesg? |
FWIW - I tried this as an experiment yesterday. I left a system running the v0.3b3 image all day and overnight. By mid-afternoon ForeFlight had stopped seeing the "FreeFlight" device but the AHRS continued to work. This morning both the "FreeFlight" and the "Stratux" devices were gone. When I tried to SSH in to take a look I was able to connect but kept getting memory allocation errors whenever the shell tried to fork any other process. Pretty much a sure sign of a memory leak. I'm running the experiment again today and will monitor the memory usage periodically. |
Try with latest code - referenced commit (post-v0.3b3) above improves memory usage and there was a further commit that writes some vital stats (including memory usage) to /var/log/stratux.log. |
I will give it a shot. Thank you. On Wed, Sep 23, 2015 at 7:36 AM, cyoung notifications@github.com wrote:
|
Anyone want to throw memprof on it before trying to reproduce it? |
Having some kind of problem compiling current code. Output of make is:
|
That has to do win the -ldflags arg -- think it might have to do with an On Wednesday, September 23, 2015, Steven Sokol notifications@github.com
|
https://github.com/cyoung/stratux/releases/tag/v0.3b4 memprof if able |
Any further info @ssokol? |
Oops. Created a new issue with logs, screen-shots, etc. On Thu, Sep 24, 2015 at 4:38 PM, cyoung notifications@github.com wrote:
Steven Sokol mobile: +1 816-806-8844 |
Several minor changes implemented in radar display when altitude is based on ADSB estimation per default sound is off (browser requirement to have any interaction before playing sound) limitation of displayed targets down to 20 secs parameter in source code better visible for toggling traces off small error corrections if radar value not yet set
I tend to leave the Stratux running. Consistently I have noticed the web interface hangs and the system stops responding to foreflight if it has been left running long enough. I believe this time the web interface showed about 17hours before it stopped responding.
1898 pts/0 Zl+ 1007:15 [gen_gdl90]
<defunct>
pi@raspberrypi ~ $ free -m
total used free shared buffers cached
Mem: 927 914 13 0 6 22
-/+ buffers/cache: 885 41
Swap: 99 21 78
Granted I will not sit in an airplane for 17 hours with my stratux, but it might indicate a lower level problem.
I have not rebooted the Stratux, if there is any other detail that would be helpful.
The text was updated successfully, but these errors were encountered: