svn-1668 dies mid of song

[mas]

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.

[mas]

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?

[rpedde]

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

[mas]

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?

[rpedde]

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

[mas]

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.

[rpedde]

@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

[mas]

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.

[mas]

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.

[rpedde]

@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

[Author]

Posts