mt-daapd keeps crashing

@nat_6 wrote:

After running flawlessly for about 2 months, mt-daapd has been crashing more and more frequently. As of now, it is crashing approx 15 mins after I start it. I’m running it on debian etch.

Log file:

2006-11-16 21:44:28: 130.253.146.120 logging in as session 182
2006-11-16 21:44:28: Session 182: Streaming file ‘Since U Been Gone.mp3’ to 130.253.146.120 (offset 0)
2006-11-16 21:44:30: 130.253.146.120 logging in as session 183
2006-11-16 21:44:30: Session 183: Streaming file ’16 Love Calls.m4a’ to 130.253.146.120 (offset 0)
2006-11-16 21:44:33: 130.253.146.120 logging in as session 184
2006-11-16 21:44:33: Could not spawn thread: Cannot allocate memory
2006-11-16 21:44:33: Aborting
2006-11-16 21:44:33: Rendezvous socket closed (daap server crashed?) Aborting.
2006-11-16 21:44:33: Aborting
delldeathbox:~#

The cannot allocate memory line seems to be present every time it crashes. Does anyone know why this is happening? Thanks

Not to be glib, but running out of memory would be my guess. 🙂 Can’t help myself, sorry. 🙂

What version is this? If it’s svns in the 1300 or so range, it could be memory leak if you are scanning iTunes xml files. After you’ve spooled some music, what does memory utilization look like? Are you sure it’s mt-daapd running our of memory, or is it something else, and it’s just mt-daapd getting hit with the oom killer?

Is this 0.2.4 on a resnet or something with high utilization? And how many songs do you have? If it’s 0.2.4, is compression turned on?

All these might help figure it out.

– Ron

@nat_6 wrote:

Sorry, it is version 0.2.4. About 7,500 songs in a college dorm, so high usage, as many as 10 songs streaming at once.

Ya, that’s probably it. The 0.2.4 series builds the whole dmap tree in memory, and then streams it out. With 7500 songs, that’s probably 2 or 3 mb of memory, or maybe more if the heap is badly fragmented.

I’ll try with compression on.

Actually, that would make it worse, as the compression in 0.2.4 does compression in-memory, so it would actually cause more memory problems.

If you are running etch, there is a newer version in testing — you can apt-get it.

If you are running sarge (on x86, ppc or mipsel), I have sarge packages of nightlies at http://nightlies.mt-daapd.org.

Might be worth upgrading to a newer version. The new versions use significantly less memory. Although a couple warnings — you’ll probably want to just move your old config file out of the way and let it install a new one… config file format has changed, and lots of new options.

Also, make sure your whole cache directory is writable by the runas user (chown nobody /var/cache/mt-daapd; chmod 700 /var/cache/mt-daapd). Previously, it didn’t have to be, but with a sqlite backend, it has to make temp files in the cache directory.

— Ron