20051117 OSX and Linux running …

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #134

    OK, both servers run 20051117 now, let see what happens …


    OSX and linux both running for more than 5 hours now, played some music, did some admin stufff …

    DOES NOT CRASH (yet) …

    Great work Ron !


    Well, I eventually got it to hang beating on it with 16 wget loops on the status page overnight. Although I’m not sure it’s not gdb that puked. Here’s what I ended up with from running it overnight:

    page: aspl-license.html, uri: /status.html
    Got directive session-count
    Thread 3381875: Entering ws_dispatcher (Connection from
    Thread 3381872: included successfully
    Got directive THREADSTAT
    Got directive SERVICE-STATUS
    Status inquiry
    Received a message from daap server
    Status inquiry — returning 0
    Returning status 0
    Executing: SELECT COUNT(*) FROM songs
    [New Thread 2064079200 (LWP 2978)]
    Couldn’t write floating point status: No such process.

    ^C eventually dropped me back to a gdb prompt, but gdb appears unresponsive

    top shows:

    14854 root 34 19 1307m 447m 600 R 5.7 45.2 164:54.94 gdb

    Yes that’s 1.27GB VIRT :/
    All in all of ~2GB physical mem + swap 8MB is free LOL

    Would that be a leak in mt-daapd or gdb, or not a leak at all?
    I’ll try running outside of gdb and see what pops up.


    Oh, that’s certainly a leak. 🙂

    I was more concerned about the crashing though. I’ll find the leak tonight. Maybe I’ll get playcount done, too.

    — Ron


    I’m not sure that it’s in mt-daapd, though. Had it running for several hours, now, outside of gdb, and VIRT is topping out at 133MB with a low of 79MB. Most of the time it’s at about 90MB. Res is staying steady at about 9MB.
    Except for that, no crashes so far 😉


    I’ve just been valgrinding it for several hours. I see some small leaks — mostly not freeing on exit type of leaks. The only sustained leaks are those from regexec. Looks like it leaks a fair amount. Hitting it with a several hundred http requests eats up 128k or so of memory.

    One solution I saw was to regfree the regexes periodically, to free the retained memory it’s using.

    Might have to implement that. Under normal usage, it probably isn’t an issue, and it might be that you would only see it in heavy use (or maybe only ever see it in stress tests), but it’s worth fixing anyway. Probably won’t get to it tonight, though, I’m about done for the night.

    — Ron


    Running for a couple of days now, no big problems found …

    Ron, I noticed the relative slow loading of the playlist … I have some 5500 songs on my xServe and it takes 12 seconds to load the playlist in my Powerbooks iTunes …
    I remember you where optimizing some code to improve this, did you drop that to get the rage condition fixed ?



    I took out the stuff that tried to put static playlists back in order that they were inserted into the database, as that was hideously expensive.

    I can make it cheaper, but it means I’ll have to special-case how the library is returned versus how the playlists are returned. I really didn’t want to do that. I dunno. I might look at it more.

    More importantly that that, though, is that I need to clean up the database code. Now that I know what I need in the database, it might be the case that I can speed some stuff up there.

    — Ron

Viewing 8 posts - 1 through 8 (of 8 total)
  • The forum ‘Nightlies Feedback’ is closed to new topics and replies.