A few minutes with valgrind showed that output_pos was never
initialized, so the output array was not getting filled correctly.
The following fixes that problem
diff -ru tuneR/src/readmp3.c /homes/bill/packages/tuneR/src/readmp3.c
--- tuneR/src/readmp3.c 2014-04-07 04:38:21.000000000 -0700
+++ /homes/bill/packages/tuneR/src/readmp3.c 2014-10-21
09:54:19.351867000 -0700
@@ -96,6 +96,7 @@
state.input = blob;
state.input_size = n_blob;
state.output_size = 0;
+ state.output_pos = 0;
mad_decoder_init(&decoder, &state,
mad_input_cb, mad_header_cb, NULL,
NULL, NULL, NULL);
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Tue, Oct 21, 2014 at 7:51 AM, Prof Brian Ripley
<rip...@stats.ox.ac.uk> wrote:
> On 21/10/2014 15:47, Dimitri Liakhovitski wrote:
>>
>> I will try with .wav files and report back.
>> So far, I am not sure I understood what could be done (if anything) to fix
>> it...
>
>
> This is nothing to do with my reply!
>
> The posting guide asked you to contact the tuneR maintainer *before
> posting*. What did he say?
>
> Bill Dunlap's reply pointed to a bug in tuneR (or a library it uses).
>
>
>>
>> On Tue, Oct 21, 2014 at 2:26 AM, Prof Brian Ripley
>> <rip...@stats.ox.ac.uk> wrote:
>>>
>>> On 20/10/2014 17:53, John McKown wrote:
>>>>
>>>>
>>>> On Mon, Oct 20, 2014 at 10:30 AM, Dimitri Liakhovitski <
>>>> dimitri.liakhovit...@gmail.com> wrote:
>>>>
>>>>> Dear Rers,
>>>>>
>>>>> I am trying to run a for-loop in R.
>>>>> During each iteration I read in an mp3 file and do some basic
>>>>> processing.
>>>>> If I do what I need to do for each file one by one - it works fine.
>>>>> But once I start running a loop, it soon runs out of memory and says:
>>>>> can't
>>>>> allocate a vector of size...
>>>>> In each iteration of my loop I always overwrite the previously created
>>>>> object and do gc().
>>>>>
>>>>> Any hints on how to fight this?
>>>>>
>>>>> Thanks a lot!
>>>>>
>>>>>
>>>>>
>>>> Please don't use HTML for messages.
>>>>
>>>> What occurs to me, from reading the other replies, is that perhaps
>>>> within
>>>> the loop you are causing other objects to be allocated. And that can be
>>>> done just by doing a simple assignment, so it may not be obvious. What
>>>> this
>>>> can do is cause what we called a "sand bar" in the old days. That's
>>>> where
>>>> you allocate a big chunk of memory for an object. Say this take up 1/2
>>>> of
>>>> your available space. You now create a small object. This object is
>>>> _probably_ right next to the large object. You now release the large
>>>> object. Your apparent free space is now almost what it was at the
>>>> beginning. But when you try to allocate another large object which is,
>>>> say,
>>>> 2/3 of the maximum space, you can't because that small object is sitting
>>>> right in the middle of our memory space. So you _can_ allocate 2 large
>>>> objects which are 1/3 your free space size, but not 1 object which is
>>>> 2/3
>>>> of the free space size. Which can lead to your type of situation.
>>>>
>>>> This is just a SWAG based on some experience in other systems. Most
>>>> "garbage collection" do _not_ do memory consolidation. I don't know
>>>> about
>>>> R.
>>>>
>>>>
>>> That is true of R (except for the early days which did have a moving
>>> garbage
>>> collector).
>>>
>>> However 'your available space' is not the amount of RAM you have but the
>>> process address space. The latter is enormous on any 64-bit OS, so
>>> 'memory
>>> fragmentation' (as this is termed) is a thing of the past except for
>>> those
>>> limited to many-years-old OSes.
>>>
>>>
>>> --
>>> Brian D. Ripley, rip...@stats.ox.ac.uk
>>> Emeritus Professor of Applied Statistics, University of Oxford
>>> 1 South Parks Road, Oxford OX1 3TG, UK
>
>
>
>
> --
> Brian D. Ripley, rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
> 1 South Parks Road, Oxford OX1 3TG, UK
>
> ______________________________________________
> R-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
