[philhu]

I reported this before as some kind of memory leak.

I am still seeing, with 12.1, some kind of memory leak.

Things that work right after reboot, like opening a 90 movie list (showcase mode) as i scroll left or right works.

2 days later, try this, and within 2 pages, the system freezes. SSH still works, and everything is still running, but XBMC is dead, requiring an xbmc reboot

Is there still a stability problem on raspbmc?

[popcornmix]

I would expect a memory leak to result in xbmc being killed (with an OOM message in dmesg log).
I think raspbmc will then relaunch xbmc.

From ssh, what happens if you "sudo killall xbmc.bin". Does it relaunch happily?

256M or 512M Pi? What's the gpu_mem split? Have you enabled the 1080p GUI? Any changed advancedsettings?
What skin and what view do you have in library mode?

I'm currently using rbej's Gotham openelec build which is very stable.

[philhu]

If I do a kill -9 (killall doesnt seem to be installed), it does restart

The specs are Model b, 512m, 128m for video, 720P, not 1080p
AEON NOX, No advancedsettings, library mode is showcase (I think)

I also added a swapfile along the way, leaving an ssh session open, entering command 'free'. Sure enough over time, memory goes down, after 1.5-2 days, the swap starts filling up.

kill -9 kills xbmc, it does restart and the memory seems to clear out over time.

I HAVE seen the oom message in dmesg. Something about needing to kill a child process or the process xbmc.bin due to memory constraints. So, I have seen it. I think though, I see the crash with OOM while using it before the system crash actually happens on its own

[nickr]

You perhaps misunderstand linux memory management.

[philhu]

You perhaps misunderstand linux memory management.

Could your answer possibly be MORE CRYPTIC? I love a good word game

[popcornmix]

You perhaps misunderstand linux memory management.

Could your answer possibly be MORE CRYPTIC? I love a good word game

I assume nickr is alluding to the free memory reported by free or top going down is normal, and not necessarily a sign of a leak:
http://www.linuxhowtos.org/System/Linux%...gement.htm

[philhu]

You perhaps misunderstand linux memory management.

Could your answer possibly be MORE CRYPTIC? I love a good word game

I assume nickr is alluding to the free memory reported by free or top going down is normal, and not necessarily a sign of a leak:
http://www.linuxhowtos.org/System/Linux%...gement.htm

No, I've been running linux flavors since 0.99p14 in 1996.

What I am seeing is definitely a memory leak. With swapable set to 10 (out of 100), Linux should never swap to a swapfile unless it absolutely has to.

As I said, without the swapfile, it dies alot quicker. With it, it takes longer to die, but slows down, since, I assume, it reads more from the swapfile.

I've also determined it is somewhere in the CIFS/network-access code. I switched my main share to NFS, since I didnt like all the permission problems cifs has. I synched my gid/uid with my QNAP nas, and changed the library volume to NFS. Besides running about 30% faster, I am not seeing the memory problems, or at least nothing that seems to stand out. I've turned off my swapfile to see if I can see a problem quicker.

[nickr]

That is interesting. The only real way to find memory leaks though is to use valgrind.

[philhu]

That is interesting. The only real way to find memory leaks though is to use valgrind.

Well, this issue seems gone now that I switched to NFS file mounts to the QNAP.

I mapped across the uid/gid from the rasp device to the QNAP, so now permissions work, I can change file ownerships and see them in both places and best, NO MORE MEMORY LEAKS. The test unit has been up 6 days (with doing nothing). For my testing, without swapfile, a doing nothing scenario ran 3 days before tasks started getting killed, with a 256M swapfile, it went up to 5 days.