R help - Mar 2005 - Encodebuf? yet another memory question

Hi all,
   I was surprised to see this memory error:

Error in scan(Cn.minex13, nlines = 2, quiet = TRUE) : 
        Could not allocate memory for Encodebuf
> memory.size(max=TRUE)
[1] 256843776
> memory.size(FALSE)
[1] 180144528
> memory.limit()
[1] 2147483648


I don't have any objects named 'Encodebuf' and help and the R site
search turn up no matches for this word.  

As memory.size and memory.limit indicate, I'm way below my limit (but,
I grant that maybe windows won't give R any more memory...).   In my
next run, I'll ask to scan fewer lines, but I thought it worth asking
the group if this 'Encodebuf' error meant anything different than the
standard "can't allocate xxxxx bytes" message. (btw, if you are
confused
that scanning only 2 lines would max out my memory... I'm scanning two
long lines from 36 different connections so it does add up).
> version
         _              
platform i386-pc-mingw32
arch     i386           
os       mingw32        
system   i386, mingw32  
status                  
major    2              
minor    0.1            
year     2004           
month    11             
day      15             
language R  

Thanks.

Tim Howard

On Wed, 9 Mar 2005, Tim Howard wrote:
> Hi all,
>   I was surprised to see this memory error:
>
> Error in scan(Cn.minex13, nlines = 2, quiet = TRUE) :
>        Could not allocate memory for Encodebuf
>> memory.size(max=TRUE)
> [1] 256843776
>> memory.size(FALSE)
> [1] 180144528
>> memory.limit()
> [1] 2147483648
>
>
> I don't have any objects named 'Encodebuf' and help and the R
site
> search turn up no matches for this word.
Try the source code, specifically that for R_AllocStringBuffer.
> As memory.size and memory.limit indicate, I'm way below my limit (but,
> I grant that maybe windows won't give R any more memory...).   In my
> next run, I'll ask to scan fewer lines, but I thought it worth asking
> the group if this 'Encodebuf' error meant anything different than
the
> standard "can't allocate xxxxx bytes" message. (btw, if you
are confused
> that scanning only 2 lines would max out my memory... I'm scanning two
> long lines from 36 different connections so it does add up).
Yes, in that it is a direct call to malloc so no gc() takes place.
In any case, you have run out of memory and this is perfectly possible if 
they are long lines since scan reads a line at a time into memory.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595