- This topic has 6 replies, 2 voices, and was last updated 17 years, 5 months ago by
.
-
Posts
-
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
@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
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
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. I do have 1GB of memory, but debain fills most of free memory with Disk Cache, so there is usually about 10MB free. I run Azureus almost constantly, but other than that, not much. I’m not sure what svn’s are, sorry. I don’t believe i have any XML’s in the music dir. I’ll try with compression on.
@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
I spoke too soon. It is crashing regularly again; with nothing else running on the machine. Same memory allocation error. It must be something in etch that was changed recently
@nat_6 wrote:
I spoke too soon. It is crashing regularly again; with nothing else running on the machine. Same memory allocation error. It must be something in etch that was changed recently
If you are bored, you could try svn-1359. That one was valgrind’ed pretty hard, and I don’t think there are any obvious memory leaks in it.
Are you sure it’s mt-daapd that’s running out of memory though? Is it possible that something else is running out of memory and mt-daapd is getting hit by the oom killer?
- The forum ‘General Discussion’ is closed to new topics and replies.