svn-1668 dies mid of song

Viewing 10 posts - 1 through 10 (of 14 total)
  • Author
    Posts
  • #1771
    mas
    Participant

    It just crashed mid of a song. Same thing as the last version. Log files dont say much:

    2007-09-26 22:00:52 (40021600): Scanned 4151 songs (was 4151) in 63 seconds
    2007-09-26 22:00:53 (41eb44e0): Session 0: Streaming file ’03. Thy Serpent – Only Dust Moves… (Bonus Track) – [The Carpenter].mp3′ to 192.168.2.11 (offset 0)
    2007-09-26 22:07:54 (41eb44e0): Session 0: Streaming file ’07. Take It Easy Baby (Ver 1) – [The Yardbirds & Sonny Boy William



    Nothing is syslog and messages. I assume again a memory leak and OOM kicking it.

    #12735
    mas
    Participant

    Twice again. Takes sometimes 5 minutes, sometimes a full hour before it happens. And then bang “Uups no server”.

    Do you have an idea where the memory leak is and if/what I can do it help debugging it?

    #12736
    rpedde
    Participant

    @mas wrote:

    Twice again. Takes sometimes 5 minutes, sometimes a full hour before it happens. And then bang “Uups no server”.

    Do you have an idea where the memory leak is and if/what I can do it help debugging it?

    Are you using sqlite, or sqlite3?

    If 3, try sqlite.

    #12737
    mas
    Participant

    I was of course using sqlite3.

    I just crosschecked svn-1586 with sqlite3. That works, some hours, still no drop.

    So gotta try the new nightly with normal sqlite then. But isnt sqlite slower than sqlite3?

    #12738
    rpedde
    Participant

    @mas wrote:

    I was of course using sqlite3.

    I just crosschecked svn-1586 with sqlite3. That works, some hours, still no drop.

    So gotta try the new nightly with normal sqlite then. But isnt sqlite slower than sqlite3?

    If it has the advantage of working, it doesn’t probably much matter. 🙂

    But yeah.

    #12739
    mas
    Participant

    Hehe yeah. Its not the sqlite3 libs that have the problem though, is something in the code after the rewrite. I have been compiling with sqlite3 since several versions and all are stable before the code rewrite (15xx svn). The svn-16xx all seem to show the memory leak to different degrees.
    Didnt get around trying sqlite with the 16xx yet.

    #12740
    rpedde
    Participant

    @mas wrote:

    Hehe yeah. Its not the sqlite3 libs that have the problem though, is something in the code after the rewrite. I have been compiling with sqlite3 since several versions and all are stable before the code rewrite (15xx svn). The svn-16xx all seem to show the memory leak to different degrees.
    Didnt get around trying sqlite with the 16xx yet.

    Right, and that’s true. I’m getting SQLITE_MISUSE errors in sqlite after the re-write, but I spent *all* *day* sunday looking for it and couldn’t find it.

    So sqlite2 is a decent short-term workaround.

    — Ron

    #12741
    mas
    Participant

    P.S.: The current 1695 still has the same problem.

    Sometimes dies mid of song from likely an out of memory thingy due to memory leaks.

    #12742
    mas
    Participant

    And after some testing over a couple of hours I have some good news:

    The newest svn-1696 seems to have fixed the mem-leak problem. No crash yet. Cool.

    So keep in mind: 1600-1695 all have enough memory leaks to cause a NSLU to bark after a while. svn-1696 seems to be ok again.

    #12743
    rpedde
    Participant

    @mas wrote:

    And after some testing over a couple of hours I have some good news:

    The newest svn-1696 seems to have fixed the mem-leak problem. No crash yet. Cool.

    So keep in mind: 1600-1695 all have enough memory leaks to cause a NSLU to bark after a while. svn-1696 seems to be ok again.

    There are still a couple minor memory leaks, but they aren’t *huge* like the ones fixed in 1696. 🙂

    — Ron

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