Haakon Meland Eriksen reports that sweep exits with memory allocation errors in what
seem to me to be unusual circumstances. excerpts from his bug reports follow:
<bug report>
I'm using SUSE LINUX 10.0, with Sweep 0.8.4 packages by Packman, on an IBM
Thinkpad T42P with 2 Gb of RAM and 60 Gb of disk space, where 47 Gb is
available.
The problem seems related to file size, because saving as Speex anything
larger than five minuttes is sure to break things. All is not lost, however,
the Speex file I made last night was found in the folder I had chosen to save
it in. This file was seven minuttes long. At other times I haven't been so
lucky.
The way I use Sweep is
* to start it
* hit the Create new file button
* change the name to filename.spx
* set the duration - how large can I safely set this to given my hardware? I
usually go for five minuttes, but really need to at least an hour or more for
longer folk tales. 10 minutes equals about 201 Mb of Data Memory.
* leave the sampling rate at CD quality
* leave the channels at stereo
* hit the create button
* select all
* hit the record dialog button
* hit the record into selection button
* hit the stop button, unless I run out of time
* cut out long pauses with select and CTRL+x
* choose Save as, then choosing the file format, saving with default settings
* wait for Sweep to finish compression and saving. This is when I get into
trouble.
I have tried to save an empty 10 minute file as SPX today, and that worked
without any crashes, so I'm unsure how to reliably reproduce the bug, but it
has happened many times.
<followup bug report>
I tried sweep from the command line, and I got the following error
mmap failed in sweep_large_alloc_data: cannot allocate memory
I looked around a bit, and found that by increasing /proc/sys/vm/max_map_count
from the default 65536, I can make the error go away. Doubling the value
equals double the amount of memory, thus
65536 = 256 Mb
131072 = 512 Mb
262144 = 1024 Mb
393216 = 1536 Mb
I used 393216 on my 2 Gb RAM system, which enabled me to start recording into
a 30 minute sound file without generating the above error. Increasing to 35
minutes at first seemed to work, but upon stopping recording the error
returned, so 30 minutes is my limit.
<bug report/>
given the amount of ram apparently available and given that this is a failing system call
to allocate memory, i suspect that this is a system configuration issue.
(i'm not ruling anything out though)
i can't reproduce this problem here so i'm going to install openSUSE 10 to see if i can
on that. if this is a problem with a legal system configuration then we need to be able to
identify and at least warn the user and mitigate the damage if not work around the probem.
i thought at first it might be a problem with ulimits but i've tried to match mine to Haakon's
but still couldn't reproduce it.
