id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,blockedby,blocking,platform 14755,Haiku Grinds to a Halt when Dribbling,AGMS,leavengood,"Haiku fails after a few days in radio station use. I was able to recreate a similar problem by dribble reading files (filling the cache) while playing sounds and appending to other files. The cache ate up all memory and then all sorts of things started failing. Would be nice if the cache wasn't so aggressive in using all memory. To recreate it, I was using a 640MB VirtualBox running Haiku R1B1+100, running with virtual memory turned off to save time and keep it simpler. I was playing a sound every 10 seconds (using the ""flite"" voice synthesis to read a fortune cookie), appending to several files every 10 seconds (see attached program), and reading a file every second from a 50GB collection (using find | xargs md5sum ; sleep 1s). It seems that the sound playback leaks memory areas and the cache uses up other memory. The combination leads to fragmented memory, which the cache doesn't recognise as being a shortage condition, so it keeps on allocating. Then all sorts of things fail when they are unable to get a block large enough, from forks to disk writes to GUI. Eventually the OS gets stuck (windows frozen). Ideally, the cache would be using memory areas in an address independent way and you could unmap areas and then remap them in a contiguous address range. Same for the sound buffers. If that's too difficult, the cache low memory detection could also look for fragmentation. Or the media system could stop leaking areas. The quick fix is to restart the media system, so that it frees its areas. But memory will still be kind of fragmented. Would be nice to similarly restart the cache, or get it to drop all its memory areas somehow.",bug,closed,normal,R1/beta2,Servers/media_server,R1/Development,fixed,,agmsmith@… ttcoder,4954,,All