An interesting happened when doing the trace with Valgrind, WD never really started but politely told me that the trial period had expired…
so maybe its an increasing integer in a thread?
that could be a possibility, what it does point to is that there is a change in the way that linux works (at some point between kernel 2.6.8 and 2.6.12), having spoken to some friends of mine, there are some large changes going on.
this is the strace output… I have nothing about futex…
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
94.98 37.655674 8972 4197 nanosleep
1.34 0.530045 226 2343 82 select
1.24 0.491657 192 2559 write
1.15 0.454284 54 8388 kill
0.80 0.316423 21 15354 ioctl
0.31 0.123368 15 8329 read
0.08 0.033651 6 5454 gettimeofday
0.05 0.021145 352 60 open
0.04 0.013976 197 71 close
0.00 0.001834 97 19 send
0.00 0.000829 29 29 14 recv
0.00 0.000496 83 6 4 connect
0.00 0.000489 61 8 socket
0.00 0.000435 7 60 time
0.00 0.000302 151 2 getdents64
0.00 0.000174 15 12 fstat64
0.00 0.000154 10 16 setsockopt
0.00 0.000148 30 5 access
0.00 0.000128 7 18 fcntl64
0.00 0.000111 56 2 listen
0.00 0.000096 48 2 accept
0.00 0.000070 18 4 bind
0.00 0.000061 10 6 getsockname
0.00 0.000060 30 2 recvfrom
0.00 0.000056 28 2 lstat64
0.00 0.000053 27 2 old_mmap
0.00 0.000044 22 2 getcwd
0.00 0.000042 21 2 munmap
0.00 0.000010 5 2 poll
------ ----------- ----------- --------- --------- ----------------
100.00 39.645815 46956 100 total
for me memory load is only 9.6% (of 256 mb)
Thanks for looking! This is just soo weird… not sure what to do now…
Apparently ‘futex’ is a pretty new thing (all things relative), read somewhere that first stable Kernel with it in was Red Hat 9 on 2.4.20 with futex support patched in… I will attempt to dig a bit deeper…
rgds
Johan
Not that much closer to a resolution, but I did notice that if I remove the rights to ttyS0, the program becomes stable… (but then I don’t get anything form my weather station either)
I have asked a friend of mine to look through the files I produced.
rgds
Johan
Right, I have now given up,! WD ran in a sort of fashion, I just was not sure about killing and restarting the program every hour. I have now rebuilt the server with a ‘Stable’ distro of Debian Sarge, and it runs well again. My conclusions are not many, but I have pretty much narrowed it down to how WD uses the Com port, it access to com port is removed, application is fine, give it back, and it runs amok! If I run with a kernel that is native (no support for later kernels installed) 2.6.8 or less, I have no problem. If I insstall 2.6.12 and the supporting programmes, it just goes of on a memory eating binge. I guess this will problem will hit the general user domain sooner or later.
Happy it is running OK again, sad that I could not narrow it down any further!
rgds
Johan
hi
i will contact the author about the com port component for the linux version, and see if they have a fix
(can you give me details like what kernal version, etc)
thanks
First off, thanks for writing a version of WD for linux. It is really appreciated. However, I too have the same memory leak problem as the thread author. after a few hours, WD consumes 512megs of memory, and 512 megs of swap to render my system useless. It is so bad I cannot even kill it, and have to reset the system. I will try another install and version today. FYI I am using SUSE 9.3 Linux with the 2.6.1 kernel I believe. I will write more when I go home.
hi
i have made contact with the author of the com port component
and they are going to try and duplicate.
hopefully there will be a fix
specialp
Can you try and remove the rights to the com port before starting WD - does that stop WD from easing your memory?
(chmod 0000 /dev/ttyS0 for Com1) - it might be worth noting the rights before changing so that you can set it back.
Now this will stop WD from getting anything from you weather station, but just as a test.
papile@linux:~/wdisplay> uname -r
2.6.11.4-21.9-default
This is my kernel version. I was incorrect earlier.
When I have the com port closed, it does not leak. When it is open the memory leak increases by 128k or so every few seconds. Over a few hours it will consume all memory.
Yep it eats up all memory within a couple of hours, you just have to check
$ ps -el|grep WeatherD
perodically to see WeatherD growing.
My system: SuSE Linux 9.2, kernel 2.6, 1GB RAM, 1GB swap, running for months without reboot…
Regards,
Sam
I have devised a pretty ghetto solution for now. I have root crontab killing wdisplay once an hour and my crontab starting it right after. This allows me to run and update my web data without collapsing my system
Strange, but works 
Or you could run the following shell script and just kill WeatherD regularely by cron, and let the script re-start it after 5 seconds:
-----------snip--------------
#!/bin/sh
while true
do
echo “#### START ####”
date
./GoWeather.sh
echo “#### STOP #####”
date
sleep 5
done
-----------snip--------------
I was thinking of upgrading my server this weekend but after reading some of the posts re: the memory leak, I think I will hold off. I’m not too keen on using cron to stop and restart WD if I don’t have to. Is there any status on the fix?
Bill
Hi
i do see a memory leak in the history of the component, after the version i have
http://www.deepsoftware.com/nrcomm/nrcommhistory.txt
i will see if i can update it now…
I have emailed the contact again, as I was entitled to some free uprades…so lets wait and see.,…
Is there a chance to get the older (working) version of wdisplay, until the actual one is fixed? At http://www.weather-display.com/files.php I can find only the 5.5 for Linux…
Thanks,
Sam