You are here: Home » Topic » mt-daapd keeps crashing

mt-daapd keeps crashing

This topic contains 6 replies, has 2 voices, and was last updated by  rpedde 10 years, 12 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #796

    nat_6
    Participant

    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

    #7352

    rpedde
    Participant

    @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

    #7353

    nat_6
    Participant

    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.

    #7354

    rpedde
    Participant

    @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

    #7355

    nat_6
    Participant

    I’ve upgraded and it’s running fine as of now. Thanks for your help. It is wonderful software

    #7356

    nat_6
    Participant

    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

    #7357

    rpedde
    Participant

    @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?

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.