PDA

View Full Version : Re: Memory leak in 5.0 CVS s/w?



Victor Brilon
2003-11-24, 22:02
Yes, same prefs file,
No, no recursive links.

See my next email about the misread on the command line difference

dean blackketter wrote:

> Are they both using the same prefs file?
>
> Might you have a music folder that's got a recursive link in it or
something?
>
>
> On Nov 24, 2003, at 8:42 PM, Victor Brilon wrote:
>
>> This got interesting real quick....
>>
>> If I run the server from the command line, i.e.,
>> /usr/local/slimserver/slimserver --d_info
>>
>> then the memory doesn't grow at all. It stays right around 19MB or
so and fluctuates very little while the file scan is going on.
>>
>> If I start the service via the rc script, then immediately I can see
the memory grow to over 26MB within a minute or two and just progress
from there. While this was going on, I went in the web interface and
turned on d_info on the debug screen.
>>
>> Looking at the output log, I can't see anything going wrong. I
uploaded the entire thing for you to look at if you'd like. It's about
13MBs uncompressed, and about 500K compressed. You can find it at
http://victorland.com/slimserver.log.gz
>>
>> Any suggestions on what else to try and why the daemonized version
is different from the command line version? I haven't changed any of the
options in /etc/sysconfig/slimserver, and that seems to be the only
thing that the rc script version looks at, that the command line doesn't.
>>
>> Victor
>>
>> dean blackketter wrote:
>>
>>> Try starting it from the command line and turn on --d_info
>>> Have your SLIMP3 unplugged and don't use the web interface, just to
keep it simple.
>>> It will spew out a lot of debug information, but if it's really
growing infinitely, we'll see what's going on eventually.
>>> -dean
>>> On Nov 24, 2003, at 7:02 PM, Victor Brilon wrote:
>>>
>>>> Sorry...meant to include that in the last email but got too happy
with the send button.
>>>>
>>>> System is a Linux box with RH9.
>>>> /proc/cpuinfo shows this is:
>>>> model name : AMD-K7(tm) Processor
>>>> cpu MHz : 548.952
>>>>
>>>> Running 'free' shows:
>>>> total used free shared buffers
cached
>>>> Mem: 255284 214328 40956 0 13488
107136
>>>> -/+ buffers/cache: 93704 161580
>>>> Swap: 525120 95044 430076
>>>>
>>>>
>>>> I think the above will wrap, so the 'cached' column should show
'107136'
>>>>
>>>> Anyway, looks like plenty of CPU and RAM availability. This system
has been running my old SliMP3 software for the past year or so with no
problem btw.
>>>>
>>>> My library is close to 80 gigs with around 600 albums or so.
>>>>
>>>> /tmp/slimserver.log shows only:
>>>> Out of memory!
>>>>
>>>> Which debugging should I enable to show more relevant info? I can
turn it all on and send you a zip of the log file if you'd think it helpful.
>>>>
>>>> Victor
>>>> dean blackketter wrote:
>>>>
>>>>> victor,
>>>>> how big is your library?
>>>>> how much memory does your system have?
>>>>> can you paste the end of the log into a message?
>>>>> -dena
>>>>> On Nov 24, 2003, at 6:24 PM, Victor Brilon wrote:
>>>>>
>>>>>> Having just installed the nightly build server software, I am
watching it run for about 5-8 minutes and then crashing. Enabling
logging shows a message of "Out of Memory!" being logged.
>>>>>>
>>>>>> If I watch the process as it runs, it's growing by about 300K
every 5 seconds or so. Obviously this is happening as it's scanning
music at startup. What other debugging can I turn on to help figure this
out?
>>>>>>
>>>>>> Thanks,
>>>>>> Victor
>>>>>>

dean
2003-11-25, 08:39
Does the memory keep growing if there is no player connected, no web
connected and the scan has completed?

-dean

On Nov 24, 2003, at 9:02 PM, Victor Brilon wrote:

> Yes, same prefs file,
> No, no recursive links.
>
> See my next email about the misread on the command line difference
>
> dean blackketter wrote:
>
> > Are they both using the same prefs file?
> >
> > Might you have a music folder that's got a recursive link in it or
> something?
> >
> >
> > On Nov 24, 2003, at 8:42 PM, Victor Brilon wrote:
> >
> >> This got interesting real quick....
> >>
> >> If I run the server from the command line, i.e.,
> >> /usr/local/slimserver/slimserver --d_info
> >>
> >> then the memory doesn't grow at all. It stays right around 19MB or
> so and fluctuates very little while the file scan is going on.
> >>
> >> If I start the service via the rc script, then immediately I can
> see the memory grow to over 26MB within a minute or two and just
> progress from there. While this was going on, I went in the web
> interface and turned on d_info on the debug screen.
> >>
> >> Looking at the output log, I can't see anything going wrong. I
> uploaded the entire thing for you to look at if you'd like. It's about
> 13MBs uncompressed, and about 500K compressed. You can find it at
> http://victorland.com/slimserver.log.gz
> >>
> >> Any suggestions on what else to try and why the daemonized version
> is different from the command line version? I haven't changed any of
> the options in /etc/sysconfig/slimserver, and that seems to be the
> only thing that the rc script version looks at, that the command line
> doesn't.
> >>
> >> Victor
> >>
> >> dean blackketter wrote:
> >>
> >>> Try starting it from the command line and turn on --d_info
> >>> Have your SLIMP3 unplugged and don't use the web interface, just
> to keep it simple.
> >>> It will spew out a lot of debug information, but if it's really
> growing infinitely, we'll see what's going on eventually.
> >>> -dean
> >>> On Nov 24, 2003, at 7:02 PM, Victor Brilon wrote:
> >>>
> >>>> Sorry...meant to include that in the last email but got too happy
> with the send button.
> >>>>
> >>>> System is a Linux box with RH9.
> >>>> /proc/cpuinfo shows this is:
> >>>> model name : AMD-K7(tm) Processor
> >>>> cpu MHz : 548.952
> >>>>
> >>>> Running 'free' shows:
> >>>> total used free shared buffers
> cached
> >>>> Mem: 255284 214328 40956 0 13488
> 107136
> >>>> -/+ buffers/cache: 93704 161580
> >>>> Swap: 525120 95044 430076
> >>>>
> >>>>
> >>>> I think the above will wrap, so the 'cached' column should show
> '107136'
> >>>>
> >>>> Anyway, looks like plenty of CPU and RAM availability. This
> system has been running my old SliMP3 software for the past year or so
> with no problem btw.
> >>>>
> >>>> My library is close to 80 gigs with around 600 albums or so.
> >>>>
> >>>> /tmp/slimserver.log shows only:
> >>>> Out of memory!
> >>>>
> >>>> Which debugging should I enable to show more relevant info? I can
> turn it all on and send you a zip of the log file if you'd think it
> helpful.
> >>>>
> >>>> Victor
> >>>> dean blackketter wrote:
> >>>>
> >>>>> victor,
> >>>>> how big is your library?
> >>>>> how much memory does your system have?
> >>>>> can you paste the end of the log into a message?
> >>>>> -dena
> >>>>> On Nov 24, 2003, at 6:24 PM, Victor Brilon wrote:
> >>>>>
> >>>>>> Having just installed the nightly build server software, I am
> watching it run for about 5-8 minutes and then crashing. Enabling
> logging shows a message of "Out of Memory!" being logged.
> >>>>>>
> >>>>>> If I watch the process as it runs, it's growing by about 300K
> every 5 seconds or so. Obviously this is happening as it's scanning
> music at startup. What other debugging can I turn on to help figure
> this out?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Victor
> >>>>>>

Victor Brilon
2003-11-25, 08:52
No web connection, no player running, and the scan never finishes since
it runs out of memory.

Victor

dean blackketter wrote:
> Does the memory keep growing if there is no player connected, no web
> connected and the scan has completed?
>
> -dean
>
> On Nov 24, 2003, at 9:02 PM, Victor Brilon wrote:
>
>> Yes, same prefs file,
>> No, no recursive links.
>>
>> See my next email about the misread on the command line difference
>>
>> dean blackketter wrote:
>>
>> > Are they both using the same prefs file?
>> >
>> > Might you have a music folder that's got a recursive link in it or
>> something?
>> >
>> >
>> > On Nov 24, 2003, at 8:42 PM, Victor Brilon wrote:
>> >
>> >> This got interesting real quick....
>> >>
>> >> If I run the server from the command line, i.e.,
>> >> /usr/local/slimserver/slimserver --d_info
>> >>
>> >> then the memory doesn't grow at all. It stays right around 19MB or
>> so and fluctuates very little while the file scan is going on.
>> >>
>> >> If I start the service via the rc script, then immediately I can
>> see the memory grow to over 26MB within a minute or two and just
>> progress from there. While this was going on, I went in the web
>> interface and turned on d_info on the debug screen.
>> >>
>> >> Looking at the output log, I can't see anything going wrong. I
>> uploaded the entire thing for you to look at if you'd like. It's about
>> 13MBs uncompressed, and about 500K compressed. You can find it at
>> http://victorland.com/slimserver.log.gz
>> >>
>> >> Any suggestions on what else to try and why the daemonized version
>> is different from the command line version? I haven't changed any of
>> the options in /etc/sysconfig/slimserver, and that seems to be the
>> only thing that the rc script version looks at, that the command line
>> doesn't.
>> >>
>> >> Victor
>> >>
>> >> dean blackketter wrote:
>> >>
>> >>> Try starting it from the command line and turn on --d_info
>> >>> Have your SLIMP3 unplugged and don't use the web interface, just
>> to keep it simple.
>> >>> It will spew out a lot of debug information, but if it's really
>> growing infinitely, we'll see what's going on eventually.
>> >>> -dean
>> >>> On Nov 24, 2003, at 7:02 PM, Victor Brilon wrote:
>> >>>
>> >>>> Sorry...meant to include that in the last email but got too happy
>> with the send button.
>> >>>>
>> >>>> System is a Linux box with RH9.
>> >>>> /proc/cpuinfo shows this is:
>> >>>> model name : AMD-K7(tm) Processor
>> >>>> cpu MHz : 548.952
>> >>>>
>> >>>> Running 'free' shows:
>> >>>> total used free shared buffers
>> cached
>> >>>> Mem: 255284 214328 40956 0 13488
>> 107136
>> >>>> -/+ buffers/cache: 93704 161580
>> >>>> Swap: 525120 95044 430076
>> >>>>
>> >>>>
>> >>>> I think the above will wrap, so the 'cached' column should show
>> '107136'
>> >>>>
>> >>>> Anyway, looks like plenty of CPU and RAM availability. This
>> system has been running my old SliMP3 software for the past year or so
>> with no problem btw.
>> >>>>
>> >>>> My library is close to 80 gigs with around 600 albums or so.
>> >>>>
>> >>>> /tmp/slimserver.log shows only:
>> >>>> Out of memory!
>> >>>>
>> >>>> Which debugging should I enable to show more relevant info? I can
>> turn it all on and send you a zip of the log file if you'd think it
>> helpful.
>> >>>>
>> >>>> Victor
>> >>>> dean blackketter wrote:
>> >>>>
>> >>>>> victor,
>> >>>>> how big is your library?
>> >>>>> how much memory does your system have?
>> >>>>> can you paste the end of the log into a message?
>> >>>>> -dena
>> >>>>> On Nov 24, 2003, at 6:24 PM, Victor Brilon wrote:
>> >>>>>
>> >>>>>> Having just installed the nightly build server software, I am
>> watching it run for about 5-8 minutes and then crashing. Enabling
>> logging shows a message of "Out of Memory!" being logged.
>> >>>>>>
>> >>>>>> If I watch the process as it runs, it's growing by about 300K
>> every 5 seconds or so. Obviously this is happening as it's scanning
>> music at startup. What other debugging can I turn on to help figure
>> this out?
>> >>>>>>
>> >>>>>> Thanks,
>> >>>>>> Victor
>> >>>>>>

dean
2003-11-25, 09:23
Can you make a small library of one album and just scan that and see
what happens?

-dean

On Nov 25, 2003, at 7:52 AM, Victor Brilon wrote:

> No web connection, no player running, and the scan never finishes
> since it runs out of memory.
>
> Victor
>
> dean blackketter wrote:
>> Does the memory keep growing if there is no player connected, no web
>> connected and the scan has completed?
>> -dean
>> On Nov 24, 2003, at 9:02 PM, Victor Brilon wrote:
>>> Yes, same prefs file,
>>> No, no recursive links.
>>>
>>> See my next email about the misread on the command line difference
>>>
>>> dean blackketter wrote:
>>>
>>> > Are they both using the same prefs file?
>>> >
>>> > Might you have a music folder that's got a recursive link in it or
>>> something?
>>> >
>>> >
>>> > On Nov 24, 2003, at 8:42 PM, Victor Brilon wrote:
>>> >
>>> >> This got interesting real quick....
>>> >>
>>> >> If I run the server from the command line, i.e.,
>>> >> /usr/local/slimserver/slimserver --d_info
>>> >>
>>> >> then the memory doesn't grow at all. It stays right around 19MB
>>> or so and fluctuates very little while the file scan is going on.
>>> >>
>>> >> If I start the service via the rc script, then immediately I can
>>> see the memory grow to over 26MB within a minute or two and just
>>> progress from there. While this was going on, I went in the web
>>> interface and turned on d_info on the debug screen.
>>> >>
>>> >> Looking at the output log, I can't see anything going wrong. I
>>> uploaded the entire thing for you to look at if you'd like. It's
>>> about 13MBs uncompressed, and about 500K compressed. You can find it
>>> at http://victorland.com/slimserver.log.gz
>>> >>
>>> >> Any suggestions on what else to try and why the daemonized
>>> version is different from the command line version? I haven't
>>> changed any of the options in /etc/sysconfig/slimserver, and that
>>> seems to be the only thing that the rc script version looks at, that
>>> the command line doesn't.
>>> >>
>>> >> Victor
>>> >>
>>> >> dean blackketter wrote:
>>> >>
>>> >>> Try starting it from the command line and turn on --d_info
>>> >>> Have your SLIMP3 unplugged and don't use the web interface, just
>>> to keep it simple.
>>> >>> It will spew out a lot of debug information, but if it's really
>>> growing infinitely, we'll see what's going on eventually.
>>> >>> -dean
>>> >>> On Nov 24, 2003, at 7:02 PM, Victor Brilon wrote:
>>> >>>
>>> >>>> Sorry...meant to include that in the last email but got too
>>> happy with the send button.
>>> >>>>
>>> >>>> System is a Linux box with RH9.
>>> >>>> /proc/cpuinfo shows this is:
>>> >>>> model name : AMD-K7(tm) Processor
>>> >>>> cpu MHz : 548.952
>>> >>>>
>>> >>>> Running 'free' shows:
>>> >>>> total used free shared buffers
>>> cached
>>> >>>> Mem: 255284 214328 40956 0 13488
>>> 107136
>>> >>>> -/+ buffers/cache: 93704 161580
>>> >>>> Swap: 525120 95044 430076
>>> >>>>
>>> >>>>
>>> >>>> I think the above will wrap, so the 'cached' column should show
>>> '107136'
>>> >>>>
>>> >>>> Anyway, looks like plenty of CPU and RAM availability. This
>>> system has been running my old SliMP3 software for the past year or
>>> so with no problem btw.
>>> >>>>
>>> >>>> My library is close to 80 gigs with around 600 albums or so.
>>> >>>>
>>> >>>> /tmp/slimserver.log shows only:
>>> >>>> Out of memory!
>>> >>>>
>>> >>>> Which debugging should I enable to show more relevant info? I
>>> can turn it all on and send you a zip of the log file if you'd think
>>> it helpful.
>>> >>>>
>>> >>>> Victor
>>> >>>> dean blackketter wrote:
>>> >>>>
>>> >>>>> victor,
>>> >>>>> how big is your library?
>>> >>>>> how much memory does your system have?
>>> >>>>> can you paste the end of the log into a message?
>>> >>>>> -dena
>>> >>>>> On Nov 24, 2003, at 6:24 PM, Victor Brilon wrote:
>>> >>>>>
>>> >>>>>> Having just installed the nightly build server software, I am
>>> watching it run for about 5-8 minutes and then crashing. Enabling
>>> logging shows a message of "Out of Memory!" being logged.
>>> >>>>>>
>>> >>>>>> If I watch the process as it runs, it's growing by about 300K
>>> every 5 seconds or so. Obviously this is happening as it's scanning
>>> music at startup. What other debugging can I turn on to help figure
>>> this out?
>>> >>>>>>
>>> >>>>>> Thanks,
>>> >>>>>> Victor
>>> >>>>>>

Victor Brilon
2003-11-25, 20:31
Then everything works great and the server stabilizes at using just
under 20MB of RAM.

dean blackketter wrote:
> Can you make a small library of one album and just scan that and see
> what happens?
>
> -dean
>
> On Nov 25, 2003, at 7:52 AM, Victor Brilon wrote:
>
>> No web connection, no player running, and the scan never finishes
>> since it runs out of memory.
>>
>> Victor
>>
>> dean blackketter wrote:
>>
>>> Does the memory keep growing if there is no player connected, no web
>>> connected and the scan has completed?
>>> -dean
>>> On Nov 24, 2003, at 9:02 PM, Victor Brilon wrote:
>>>
>>>> Yes, same prefs file,
>>>> No, no recursive links.
>>>>
>>>> See my next email about the misread on the command line difference
>>>>
>>>> dean blackketter wrote:
>>>>
>>>> > Are they both using the same prefs file?
>>>> >
>>>> > Might you have a music folder that's got a recursive link in it or
>>>> something?
>>>> >
>>>> >
>>>> > On Nov 24, 2003, at 8:42 PM, Victor Brilon wrote:
>>>> >
>>>> >> This got interesting real quick....
>>>> >>
>>>> >> If I run the server from the command line, i.e.,
>>>> >> /usr/local/slimserver/slimserver --d_info
>>>> >>
>>>> >> then the memory doesn't grow at all. It stays right around 19MB
>>>> or so and fluctuates very little while the file scan is going on.
>>>> >>
>>>> >> If I start the service via the rc script, then immediately I can
>>>> see the memory grow to over 26MB within a minute or two and just
>>>> progress from there. While this was going on, I went in the web
>>>> interface and turned on d_info on the debug screen.
>>>> >>
>>>> >> Looking at the output log, I can't see anything going wrong. I
>>>> uploaded the entire thing for you to look at if you'd like. It's
>>>> about 13MBs uncompressed, and about 500K compressed. You can find it
>>>> at http://victorland.com/slimserver.log.gz
>>>> >>
>>>> >> Any suggestions on what else to try and why the daemonized
>>>> version is different from the command line version? I haven't
>>>> changed any of the options in /etc/sysconfig/slimserver, and that
>>>> seems to be the only thing that the rc script version looks at, that
>>>> the command line doesn't.
>>>> >>
>>>> >> Victor
>>>> >>
>>>> >> dean blackketter wrote:
>>>> >>
>>>> >>> Try starting it from the command line and turn on --d_info
>>>> >>> Have your SLIMP3 unplugged and don't use the web interface, just
>>>> to keep it simple.
>>>> >>> It will spew out a lot of debug information, but if it's really
>>>> growing infinitely, we'll see what's going on eventually.
>>>> >>> -dean
>>>> >>> On Nov 24, 2003, at 7:02 PM, Victor Brilon wrote:
>>>> >>>
>>>> >>>> Sorry...meant to include that in the last email but got too
>>>> happy with the send button.
>>>> >>>>
>>>> >>>> System is a Linux box with RH9.
>>>> >>>> /proc/cpuinfo shows this is:
>>>> >>>> model name : AMD-K7(tm) Processor
>>>> >>>> cpu MHz : 548.952
>>>> >>>>
>>>> >>>> Running 'free' shows:
>>>> >>>> total used free shared buffers
>>>> cached
>>>> >>>> Mem: 255284 214328 40956 0 13488
>>>> 107136
>>>> >>>> -/+ buffers/cache: 93704 161580
>>>> >>>> Swap: 525120 95044 430076
>>>> >>>>
>>>> >>>>
>>>> >>>> I think the above will wrap, so the 'cached' column should show
>>>> '107136'
>>>> >>>>
>>>> >>>> Anyway, looks like plenty of CPU and RAM availability. This
>>>> system has been running my old SliMP3 software for the past year or
>>>> so with no problem btw.
>>>> >>>>
>>>> >>>> My library is close to 80 gigs with around 600 albums or so.
>>>> >>>>
>>>> >>>> /tmp/slimserver.log shows only:
>>>> >>>> Out of memory!
>>>> >>>>
>>>> >>>> Which debugging should I enable to show more relevant info? I
>>>> can turn it all on and send you a zip of the log file if you'd think
>>>> it helpful.
>>>> >>>>
>>>> >>>> Victor
>>>> >>>> dean blackketter wrote:
>>>> >>>>
>>>> >>>>> victor,
>>>> >>>>> how big is your library?
>>>> >>>>> how much memory does your system have?
>>>> >>>>> can you paste the end of the log into a message?
>>>> >>>>> -dena
>>>> >>>>> On Nov 24, 2003, at 6:24 PM, Victor Brilon wrote:
>>>> >>>>>
>>>> >>>>>> Having just installed the nightly build server software, I am
>>>> watching it run for about 5-8 minutes and then crashing. Enabling
>>>> logging shows a message of "Out of Memory!" being logged.
>>>> >>>>>>
>>>> >>>>>> If I watch the process as it runs, it's growing by about 300K
>>>> every 5 seconds or so. Obviously this is happening as it's scanning
>>>> music at startup. What other debugging can I turn on to help figure
>>>> this out?
>>>> >>>>>>
>>>> >>>>>> Thanks,
>>>> >>>>>> Victor
>>>> >>>>>>

dean
2003-11-25, 23:10
Ok, so add in your music in batches until you find what breaks it.

On Nov 25, 2003, at 7:31 PM, Victor Brilon wrote:

> Then everything works great and the server stabilizes at using just
> under 20MB of RAM.
>
> dean blackketter wrote:
>> Can you make a small library of one album and just scan that and see
>> what happens?
>> -dean
>> On Nov 25, 2003, at 7:52 AM, Victor Brilon wrote:
>>> No web connection, no player running, and the scan never finishes
>>> since it runs out of memory.
>>>
>>> Victor
>>>
>>> dean blackketter wrote:
>>>
>>>> Does the memory keep growing if there is no player connected, no
>>>> web connected and the scan has completed?
>>>> -dean
>>>> On Nov 24, 2003, at 9:02 PM, Victor Brilon wrote:
>>>>
>>>>> Yes, same prefs file,
>>>>> No, no recursive links.
>>>>>
>>>>> See my next email about the misread on the command line difference
>>>>>
>>>>> dean blackketter wrote:
>>>>>
>>>>> > Are they both using the same prefs file?
>>>>> >
>>>>> > Might you have a music folder that's got a recursive link in it
>>>>> or something?
>>>>> >
>>>>> >
>>>>> > On Nov 24, 2003, at 8:42 PM, Victor Brilon wrote:
>>>>> >
>>>>> >> This got interesting real quick....
>>>>> >>
>>>>> >> If I run the server from the command line, i.e.,
>>>>> >> /usr/local/slimserver/slimserver --d_info
>>>>> >>
>>>>> >> then the memory doesn't grow at all. It stays right around 19MB
>>>>> or so and fluctuates very little while the file scan is going on.
>>>>> >>
>>>>> >> If I start the service via the rc script, then immediately I
>>>>> can see the memory grow to over 26MB within a minute or two and
>>>>> just progress from there. While this was going on, I went in the
>>>>> web interface and turned on d_info on the debug screen.
>>>>> >>
>>>>> >> Looking at the output log, I can't see anything going wrong. I
>>>>> uploaded the entire thing for you to look at if you'd like. It's
>>>>> about 13MBs uncompressed, and about 500K compressed. You can find
>>>>> it at http://victorland.com/slimserver.log.gz
>>>>> >>
>>>>> >> Any suggestions on what else to try and why the daemonized
>>>>> version is different from the command line version? I haven't
>>>>> changed any of the options in /etc/sysconfig/slimserver, and that
>>>>> seems to be the only thing that the rc script version looks at,
>>>>> that the command line doesn't.
>>>>> >>
>>>>> >> Victor
>>>>> >>
>>>>> >> dean blackketter wrote:
>>>>> >>
>>>>> >>> Try starting it from the command line and turn on --d_info
>>>>> >>> Have your SLIMP3 unplugged and don't use the web interface,
>>>>> just to keep it simple.
>>>>> >>> It will spew out a lot of debug information, but if it's
>>>>> really growing infinitely, we'll see what's going on eventually.
>>>>> >>> -dean
>>>>> >>> On Nov 24, 2003, at 7:02 PM, Victor Brilon wrote:
>>>>> >>>
>>>>> >>>> Sorry...meant to include that in the last email but got too
>>>>> happy with the send button.
>>>>> >>>>
>>>>> >>>> System is a Linux box with RH9.
>>>>> >>>> /proc/cpuinfo shows this is:
>>>>> >>>> model name : AMD-K7(tm) Processor
>>>>> >>>> cpu MHz : 548.952
>>>>> >>>>
>>>>> >>>> Running 'free' shows:
>>>>> >>>> total used free shared
>>>>> buffers cached
>>>>> >>>> Mem: 255284 214328 40956 0
>>>>> 13488 107136
>>>>> >>>> -/+ buffers/cache: 93704 161580
>>>>> >>>> Swap: 525120 95044 430076
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> I think the above will wrap, so the 'cached' column should
>>>>> show '107136'
>>>>> >>>>
>>>>> >>>> Anyway, looks like plenty of CPU and RAM availability. This
>>>>> system has been running my old SliMP3 software for the past year
>>>>> or so with no problem btw.
>>>>> >>>>
>>>>> >>>> My library is close to 80 gigs with around 600 albums or so.
>>>>> >>>>
>>>>> >>>> /tmp/slimserver.log shows only:
>>>>> >>>> Out of memory!
>>>>> >>>>
>>>>> >>>> Which debugging should I enable to show more relevant info? I
>>>>> can turn it all on and send you a zip of the log file if you'd
>>>>> think it helpful.
>>>>> >>>>
>>>>> >>>> Victor
>>>>> >>>> dean blackketter wrote:
>>>>> >>>>
>>>>> >>>>> victor,
>>>>> >>>>> how big is your library?
>>>>> >>>>> how much memory does your system have?
>>>>> >>>>> can you paste the end of the log into a message?
>>>>> >>>>> -dena
>>>>> >>>>> On Nov 24, 2003, at 6:24 PM, Victor Brilon wrote:
>>>>> >>>>>
>>>>> >>>>>> Having just installed the nightly build server software, I
>>>>> am watching it run for about 5-8 minutes and then crashing.
>>>>> Enabling logging shows a message of "Out of Memory!" being logged.
>>>>> >>>>>>
>>>>> >>>>>> If I watch the process as it runs, it's growing by about
>>>>> 300K every 5 seconds or so. Obviously this is happening as it's
>>>>> scanning music at startup. What other debugging can I turn on to
>>>>> help figure this out?
>>>>> >>>>>>
>>>>> >>>>>> Thanks,
>>>>> >>>>>> Victor
>>>>> >>>>>>

Victor Brilon
2003-11-26, 07:58
Dean,

This is a little tough to do since I don't have a whole lot of free disk
space to copy mp3s to for testing unfortunately.

I was able to free up about 13 gigs and point the server at that. It
scanned the entire thing just fine and the memory usage, while
increasing during the scan, never got above 20 MBs or so.

Was there anything in the log I posted that looked unusual to you that
would be a lead for debugging? I am just not familiar enough w/the
changes between v4 and v5 of the server to know what would cause it to
break this way.

Victor

dean blackketter wrote:
> Ok, so add in your music in batches until you find what breaks it.
>
> On Nov 25, 2003, at 7:31 PM, Victor Brilon wrote:
>
>> Then everything works great and the server stabilizes at using just
>> under 20MB of RAM.
>>
>> dean blackketter wrote:
>>
>>> Can you make a small library of one album and just scan that and see
>>> what happens?
>>> -dean
>>> On Nov 25, 2003, at 7:52 AM, Victor Brilon wrote:
>>>
>>>> No web connection, no player running, and the scan never finishes
>>>> since it runs out of memory.
>>>>
>>>> Victor
>>>>
>>>> dean blackketter wrote:
>>>>
>>>>> Does the memory keep growing if there is no player connected, no
>>>>> web connected and the scan has completed?
>>>>> -dean
>>>>> On Nov 24, 2003, at 9:02 PM, Victor Brilon wrote:
>>>>>
>>>>>> Yes, same prefs file,
>>>>>> No, no recursive links.
>>>>>>
>>>>>> See my next email about the misread on the command line difference
>>>>>>
>>>>>> dean blackketter wrote:
>>>>>>
>>>>>> > Are they both using the same prefs file?
>>>>>> >
>>>>>> > Might you have a music folder that's got a recursive link in it
>>>>>> or something?
>>>>>> >
>>>>>> >
>>>>>> > On Nov 24, 2003, at 8:42 PM, Victor Brilon wrote:
>>>>>> >
>>>>>> >> This got interesting real quick....
>>>>>> >>
>>>>>> >> If I run the server from the command line, i.e.,
>>>>>> >> /usr/local/slimserver/slimserver --d_info
>>>>>> >>
>>>>>> >> then the memory doesn't grow at all. It stays right around 19MB
>>>>>> or so and fluctuates very little while the file scan is going on.
>>>>>> >>
>>>>>> >> If I start the service via the rc script, then immediately I
>>>>>> can see the memory grow to over 26MB within a minute or two and
>>>>>> just progress from there. While this was going on, I went in the
>>>>>> web interface and turned on d_info on the debug screen.
>>>>>> >>
>>>>>> >> Looking at the output log, I can't see anything going wrong. I
>>>>>> uploaded the entire thing for you to look at if you'd like. It's
>>>>>> about 13MBs uncompressed, and about 500K compressed. You can find
>>>>>> it at http://victorland.com/slimserver.log.gz
>>>>>> >>
>>>>>> >> Any suggestions on what else to try and why the daemonized
>>>>>> version is different from the command line version? I haven't
>>>>>> changed any of the options in /etc/sysconfig/slimserver, and that
>>>>>> seems to be the only thing that the rc script version looks at,
>>>>>> that the command line doesn't.
>>>>>> >>
>>>>>> >> Victor
>>>>>> >>
>>>>>> >> dean blackketter wrote:
>>>>>> >>
>>>>>> >>> Try starting it from the command line and turn on --d_info
>>>>>> >>> Have your SLIMP3 unplugged and don't use the web interface,
>>>>>> just to keep it simple.
>>>>>> >>> It will spew out a lot of debug information, but if it's
>>>>>> really growing infinitely, we'll see what's going on eventually.
>>>>>> >>> -dean
>>>>>> >>> On Nov 24, 2003, at 7:02 PM, Victor Brilon wrote:
>>>>>> >>>
>>>>>> >>>> Sorry...meant to include that in the last email but got too
>>>>>> happy with the send button.
>>>>>> >>>>
>>>>>> >>>> System is a Linux box with RH9.
>>>>>> >>>> /proc/cpuinfo shows this is:
>>>>>> >>>> model name : AMD-K7(tm) Processor
>>>>>> >>>> cpu MHz : 548.952
>>>>>> >>>>
>>>>>> >>>> Running 'free' shows:
>>>>>> >>>> total used free shared
>>>>>> buffers cached
>>>>>> >>>> Mem: 255284 214328 40956 0
>>>>>> 13488 107136
>>>>>> >>>> -/+ buffers/cache: 93704 161580
>>>>>> >>>> Swap: 525120 95044 430076
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> I think the above will wrap, so the 'cached' column should
>>>>>> show '107136'
>>>>>> >>>>
>>>>>> >>>> Anyway, looks like plenty of CPU and RAM availability. This
>>>>>> system has been running my old SliMP3 software for the past year
>>>>>> or so with no problem btw.
>>>>>> >>>>
>>>>>> >>>> My library is close to 80 gigs with around 600 albums or so.
>>>>>> >>>>
>>>>>> >>>> /tmp/slimserver.log shows only:
>>>>>> >>>> Out of memory!
>>>>>> >>>>
>>>>>> >>>> Which debugging should I enable to show more relevant info? I
>>>>>> can turn it all on and send you a zip of the log file if you'd
>>>>>> think it helpful.
>>>>>> >>>>
>>>>>> >>>> Victor
>>>>>> >>>> dean blackketter wrote:
>>>>>> >>>>
>>>>>> >>>>> victor,
>>>>>> >>>>> how big is your library?
>>>>>> >>>>> how much memory does your system have?
>>>>>> >>>>> can you paste the end of the log into a message?
>>>>>> >>>>> -dena
>>>>>> >>>>> On Nov 24, 2003, at 6:24 PM, Victor Brilon wrote:
>>>>>> >>>>>
>>>>>> >>>>>> Having just installed the nightly build server software, I
>>>>>> am watching it run for about 5-8 minutes and then crashing.
>>>>>> Enabling logging shows a message of "Out of Memory!" being logged.
>>>>>> >>>>>>
>>>>>> >>>>>> If I watch the process as it runs, it's growing by about
>>>>>> 300K every 5 seconds or so. Obviously this is happening as it's
>>>>>> scanning music at startup. What other debugging can I turn on to
>>>>>> help figure this out?
>>>>>> >>>>>>
>>>>>> >>>>>> Thanks,
>>>>>> >>>>>> Victor
>>>>>> >>>>>>

Victor Brilon
2003-11-26, 08:27
Dean,
More analysis on this, and I *think* I have the problem solved.

Obviously what's happening is that perl itself is running out of memory
for some reason, not the system itself. I am guessing this is caused by
reading in some weird data structure that unexpectedly takes up too much
memory.

I wrote some code to go through all my mp3s looking for any tags that
didn't look right since I suspected they're the culprit. Sure enough, I
have one album where it looks like the ID3 tags got written as UTF-8
encoded. Interestingly enough, MP3::Info could not read them properly,
but in Windows they're seen ok.

I moved that one album out of my hierarchy and the server completed its
scan just fine. Memory still grew (as to be expected) but it stabilized
at ~30 MBs and seems to be running just fine.

Any idea why this is so with v5 and not with v4?

Victor

Victor Brilon wrote:
> Dean,
>
> This is a little tough to do since I don't have a whole lot of free disk
> space to copy mp3s to for testing unfortunately.
>
> I was able to free up about 13 gigs and point the server at that. It
> scanned the entire thing just fine and the memory usage, while
> increasing during the scan, never got above 20 MBs or so.
>
> Was there anything in the log I posted that looked unusual to you that
> would be a lead for debugging? I am just not familiar enough w/the
> changes between v4 and v5 of the server to know what would cause it to
> break this way.
>
> Victor
>
> dean blackketter wrote:
>
>> Ok, so add in your music in batches until you find what breaks it.
>>
>> On Nov 25, 2003, at 7:31 PM, Victor Brilon wrote:
>>
>>> Then everything works great and the server stabilizes at using just
>>> under 20MB of RAM.
>>>
>>> dean blackketter wrote:
>>>
>>>> Can you make a small library of one album and just scan that and see
>>>> what happens?
>>>> -dean
>>>> On Nov 25, 2003, at 7:52 AM, Victor Brilon wrote:
>>>>
>>>>> No web connection, no player running, and the scan never finishes
>>>>> since it runs out of memory.
>>>>>
>>>>> Victor
>>>>>
>>>>> dean blackketter wrote:
>>>>>
>>>>>> Does the memory keep growing if there is no player connected, no
>>>>>> web connected and the scan has completed?
>>>>>> -dean
>>>>>> On Nov 24, 2003, at 9:02 PM, Victor Brilon wrote:
>>>>>>
>>>>>>> Yes, same prefs file,
>>>>>>> No, no recursive links.
>>>>>>>
>>>>>>> See my next email about the misread on the command line difference
>>>>>>>
>>>>>>> dean blackketter wrote:
>>>>>>>
>>>>>>> > Are they both using the same prefs file?
>>>>>>> >
>>>>>>> > Might you have a music folder that's got a recursive link in it
>>>>>>> or something?
>>>>>>> >
>>>>>>> >
>>>>>>> > On Nov 24, 2003, at 8:42 PM, Victor Brilon wrote:
>>>>>>> >
>>>>>>> >> This got interesting real quick....
>>>>>>> >>
>>>>>>> >> If I run the server from the command line, i.e.,
>>>>>>> >> /usr/local/slimserver/slimserver --d_info
>>>>>>> >>
>>>>>>> >> then the memory doesn't grow at all. It stays right around
>>>>>>> 19MB or so and fluctuates very little while the file scan is
>>>>>>> going on.
>>>>>>> >>
>>>>>>> >> If I start the service via the rc script, then immediately I
>>>>>>> can see the memory grow to over 26MB within a minute or two and
>>>>>>> just progress from there. While this was going on, I went in the
>>>>>>> web interface and turned on d_info on the debug screen.
>>>>>>> >>
>>>>>>> >> Looking at the output log, I can't see anything going wrong. I
>>>>>>> uploaded the entire thing for you to look at if you'd like. It's
>>>>>>> about 13MBs uncompressed, and about 500K compressed. You can find
>>>>>>> it at http://victorland.com/slimserver.log.gz
>>>>>>> >>
>>>>>>> >> Any suggestions on what else to try and why the daemonized
>>>>>>> version is different from the command line version? I haven't
>>>>>>> changed any of the options in /etc/sysconfig/slimserver, and that
>>>>>>> seems to be the only thing that the rc script version looks at,
>>>>>>> that the command line doesn't.
>>>>>>> >>
>>>>>>> >> Victor
>>>>>>> >>
>>>>>>> >> dean blackketter wrote:
>>>>>>> >>
>>>>>>> >>> Try starting it from the command line and turn on --d_info
>>>>>>> >>> Have your SLIMP3 unplugged and don't use the web interface,
>>>>>>> just to keep it simple.
>>>>>>> >>> It will spew out a lot of debug information, but if it's
>>>>>>> really growing infinitely, we'll see what's going on eventually.
>>>>>>> >>> -dean
>>>>>>> >>> On Nov 24, 2003, at 7:02 PM, Victor Brilon wrote:
>>>>>>> >>>
>>>>>>> >>>> Sorry...meant to include that in the last email but got too
>>>>>>> happy with the send button.
>>>>>>> >>>>
>>>>>>> >>>> System is a Linux box with RH9.
>>>>>>> >>>> /proc/cpuinfo shows this is:
>>>>>>> >>>> model name : AMD-K7(tm) Processor
>>>>>>> >>>> cpu MHz : 548.952
>>>>>>> >>>>
>>>>>>> >>>> Running 'free' shows:
>>>>>>> >>>> total used free shared
>>>>>>> buffers cached
>>>>>>> >>>> Mem: 255284 214328 40956 0
>>>>>>> 13488 107136
>>>>>>> >>>> -/+ buffers/cache: 93704 161580
>>>>>>> >>>> Swap: 525120 95044 430076
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> I think the above will wrap, so the 'cached' column should
>>>>>>> show '107136'
>>>>>>> >>>>
>>>>>>> >>>> Anyway, looks like plenty of CPU and RAM availability. This
>>>>>>> system has been running my old SliMP3 software for the past year
>>>>>>> or so with no problem btw.
>>>>>>> >>>>
>>>>>>> >>>> My library is close to 80 gigs with around 600 albums or so.
>>>>>>> >>>>
>>>>>>> >>>> /tmp/slimserver.log shows only:
>>>>>>> >>>> Out of memory!
>>>>>>> >>>>
>>>>>>> >>>> Which debugging should I enable to show more relevant info?
>>>>>>> I can turn it all on and send you a zip of the log file if you'd
>>>>>>> think it helpful.
>>>>>>> >>>>
>>>>>>> >>>> Victor
>>>>>>> >>>> dean blackketter wrote:
>>>>>>> >>>>
>>>>>>> >>>>> victor,
>>>>>>> >>>>> how big is your library?
>>>>>>> >>>>> how much memory does your system have?
>>>>>>> >>>>> can you paste the end of the log into a message?
>>>>>>> >>>>> -dena
>>>>>>> >>>>> On Nov 24, 2003, at 6:24 PM, Victor Brilon wrote:
>>>>>>> >>>>>
>>>>>>> >>>>>> Having just installed the nightly build server software, I
>>>>>>> am watching it run for about 5-8 minutes and then crashing.
>>>>>>> Enabling logging shows a message of "Out of Memory!" being logged.
>>>>>>> >>>>>>
>>>>>>> >>>>>> If I watch the process as it runs, it's growing by about
>>>>>>> 300K every 5 seconds or so. Obviously this is happening as it's
>>>>>>> scanning music at startup. What other debugging can I turn on to
>>>>>>> help figure this out?
>>>>>>> >>>>>>
>>>>>>> >>>>>> Thanks,
>>>>>>> >>>>>> Victor
>>>>>>> >>>>>>

dean
2003-11-26, 12:33
Good find, Victor.

The MP3::Info had been updated to handle some obscure ID3 options that
some folks had found.

Can you pick one MP3 file that exhibits this problem and send it to me?

-dean

On Nov 26, 2003, at 7:27 AM, Victor Brilon wrote:

> Dean,
> More analysis on this, and I *think* I have the problem solved.
>
> Obviously what's happening is that perl itself is running out of
> memory for some reason, not the system itself. I am guessing this is
> caused by reading in some weird data structure that unexpectedly takes
> up too much memory.
>
> I wrote some code to go through all my mp3s looking for any tags that
> didn't look right since I suspected they're the culprit. Sure enough,
> I have one album where it looks like the ID3 tags got written as UTF-8
> encoded. Interestingly enough, MP3::Info could not read them properly,
> but in Windows they're seen ok.
>
> I moved that one album out of my hierarchy and the server completed
> its scan just fine. Memory still grew (as to be expected) but it
> stabilized at ~30 MBs and seems to be running just fine.
>
> Any idea why this is so with v5 and not with v4?
>
> Victor
>
> Victor Brilon wrote:
>> Dean,
>> This is a little tough to do since I don't have a whole lot of free
>> disk space to copy mp3s to for testing unfortunately.
>> I was able to free up about 13 gigs and point the server at that. It
>> scanned the entire thing just fine and the memory usage, while
>> increasing during the scan, never got above 20 MBs or so.
>> Was there anything in the log I posted that looked unusual to you
>> that would be a lead for debugging? I am just not familiar enough
>> w/the changes between v4 and v5 of the server to know what would
>> cause it to break this way.
>> Victor
>> dean blackketter wrote:
>>> Ok, so add in your music in batches until you find what breaks it.
>>>
>>> On Nov 25, 2003, at 7:31 PM, Victor Brilon wrote:
>>>
>>>> Then everything works great and the server stabilizes at using just
>>>> under 20MB of RAM.
>>>>
>>>> dean blackketter wrote:
>>>>
>>>>> Can you make a small library of one album and just scan that and
>>>>> see what happens?
>>>>> -dean
>>>>> On Nov 25, 2003, at 7:52 AM, Victor Brilon wrote:
>>>>>
>>>>>> No web connection, no player running, and the scan never finishes
>>>>>> since it runs out of memory.
>>>>>>
>>>>>> Victor
>>>>>>
>>>>>> dean blackketter wrote:
>>>>>>
>>>>>>> Does the memory keep growing if there is no player connected, no
>>>>>>> web connected and the scan has completed?
>>>>>>> -dean
>>>>>>> On Nov 24, 2003, at 9:02 PM, Victor Brilon wrote:
>>>>>>>
>>>>>>>> Yes, same prefs file,
>>>>>>>> No, no recursive links.
>>>>>>>>
>>>>>>>> See my next email about the misread on the command line
>>>>>>>> difference
>>>>>>>>
>>>>>>>> dean blackketter wrote:
>>>>>>>>
>>>>>>>> > Are they both using the same prefs file?
>>>>>>>> >
>>>>>>>> > Might you have a music folder that's got a recursive link in
>>>>>>>> it or something?
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On Nov 24, 2003, at 8:42 PM, Victor Brilon wrote:
>>>>>>>> >
>>>>>>>> >> This got interesting real quick....
>>>>>>>> >>
>>>>>>>> >> If I run the server from the command line, i.e.,
>>>>>>>> >> /usr/local/slimserver/slimserver --d_info
>>>>>>>> >>
>>>>>>>> >> then the memory doesn't grow at all. It stays right around
>>>>>>>> 19MB or so and fluctuates very little while the file scan is
>>>>>>>> going on.
>>>>>>>> >>
>>>>>>>> >> If I start the service via the rc script, then immediately I
>>>>>>>> can see the memory grow to over 26MB within a minute or two and
>>>>>>>> just progress from there. While this was going on, I went in
>>>>>>>> the web interface and turned on d_info on the debug screen.
>>>>>>>> >>
>>>>>>>> >> Looking at the output log, I can't see anything going wrong.
>>>>>>>> I uploaded the entire thing for you to look at if you'd like.
>>>>>>>> It's about 13MBs uncompressed, and about 500K compressed. You
>>>>>>>> can find it at http://victorland.com/slimserver.log.gz
>>>>>>>> >>
>>>>>>>> >> Any suggestions on what else to try and why the daemonized
>>>>>>>> version is different from the command line version? I haven't
>>>>>>>> changed any of the options in /etc/sysconfig/slimserver, and
>>>>>>>> that seems to be the only thing that the rc script version
>>>>>>>> looks at, that the command line doesn't.
>>>>>>>> >>
>>>>>>>> >> Victor
>>>>>>>> >>
>>>>>>>> >> dean blackketter wrote:
>>>>>>>> >>
>>>>>>>> >>> Try starting it from the command line and turn on --d_info
>>>>>>>> >>> Have your SLIMP3 unplugged and don't use the web interface,
>>>>>>>> just to keep it simple.
>>>>>>>> >>> It will spew out a lot of debug information, but if it's
>>>>>>>> really growing infinitely, we'll see what's going on
>>>>>>>> eventually.
>>>>>>>> >>> -dean
>>>>>>>> >>> On Nov 24, 2003, at 7:02 PM, Victor Brilon wrote:
>>>>>>>> >>>
>>>>>>>> >>>> Sorry...meant to include that in the last email but got
>>>>>>>> too happy with the send button.
>>>>>>>> >>>>
>>>>>>>> >>>> System is a Linux box with RH9.
>>>>>>>> >>>> /proc/cpuinfo shows this is:
>>>>>>>> >>>> model name : AMD-K7(tm) Processor
>>>>>>>> >>>> cpu MHz : 548.952
>>>>>>>> >>>>
>>>>>>>> >>>> Running 'free' shows:
>>>>>>>> >>>> total used free shared
>>>>>>>> buffers cached
>>>>>>>> >>>> Mem: 255284 214328 40956 0
>>>>>>>> 13488 107136
>>>>>>>> >>>> -/+ buffers/cache: 93704 161580
>>>>>>>> >>>> Swap: 525120 95044 430076
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> I think the above will wrap, so the 'cached' column should
>>>>>>>> show '107136'
>>>>>>>> >>>>
>>>>>>>> >>>> Anyway, looks like plenty of CPU and RAM availability.
>>>>>>>> This system has been running my old SliMP3 software for the
>>>>>>>> past year or so with no problem btw.
>>>>>>>> >>>>
>>>>>>>> >>>> My library is close to 80 gigs with around 600 albums or
>>>>>>>> so.
>>>>>>>> >>>>
>>>>>>>> >>>> /tmp/slimserver.log shows only:
>>>>>>>> >>>> Out of memory!
>>>>>>>> >>>>
>>>>>>>> >>>> Which debugging should I enable to show more relevant
>>>>>>>> info? I can turn it all on and send you a zip of the log file
>>>>>>>> if you'd think it helpful.
>>>>>>>> >>>>
>>>>>>>> >>>> Victor
>>>>>>>> >>>> dean blackketter wrote:
>>>>>>>> >>>>
>>>>>>>> >>>>> victor,
>>>>>>>> >>>>> how big is your library?
>>>>>>>> >>>>> how much memory does your system have?
>>>>>>>> >>>>> can you paste the end of the log into a message?
>>>>>>>> >>>>> -dena
>>>>>>>> >>>>> On Nov 24, 2003, at 6:24 PM, Victor Brilon wrote:
>>>>>>>> >>>>>
>>>>>>>> >>>>>> Having just installed the nightly build server software,
>>>>>>>> I am watching it run for about 5-8 minutes and then crashing.
>>>>>>>> Enabling logging shows a message of "Out of Memory!" being
>>>>>>>> logged.
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> If I watch the process as it runs, it's growing by about
>>>>>>>> 300K every 5 seconds or so. Obviously this is happening as it's
>>>>>>>> scanning music at startup. What other debugging can I turn on
>>>>>>>> to help figure this out?
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> Thanks,
>>>>>>>> >>>>>> Victor
>>>>>>>> >>>>>>