# how to enlarge memory allocation limit ?

## doublehp

Running Avidemux on large file (2800MB), I get this error message:

 *Quote:*   

> Images stat:
> 
> ___________
> 
> Max memory consumed (MB)     : 7290
> ...

 

I am pretty sure this is a kernel or libc limitation.

I have 1GB Ram, and 4GB swap. Of course I run out of ram  :Smile:  but just before app crash, I use only 800MB swap, what means: I do not run out of memory.

Thus, I think the app crashes due to software limit. Any one could think how to increase it ? kernel recomp ? init argument to pass to libc ? avidemux limit (what would be pretty stupid, since video applications are known to consume RAM).

I dont have problem on smaller files (below 1500MB). Problem occur whatever the file system is (NTFS, Ext3 over RAID). And NO I dont run out of disk space  :Smile:  I do have gigas available  :Smile: 

I may also get this message:

 *Quote:*   

> Set pos failed : asked rel:2228223 max: 0, absPos:844424930138911 absPosafterRefill:844424962899972
> 
> avidemux2: dmx_demuxerMSDVR.cpp:225: virtual uint8_t dmx_demuxerMSDVR::setPos(uint64_t, uint64_t): Assertion `0' failed.
> 
> Aborted
> ...

 

At crash time, ps reports about 1132384kB virtual memory allocated by process ( 668072kB resident, 1095180kB swapped).

----------

## doublehp

A new test confirms that the problem is around virtual memory; using different parameters, avidemux crashed at the time using:

1150388 kB virtual

576272 kB resident

1113184 kB aproximative swap

(measurement has ~ 300 kB precision)

A second measuerment indicates 1132232 580036 1095028, with 9000 precision.

----------

## HeissFuss

Not sure if this'd have anything to do with it, but did you enable High memory support in your kernel?

----------

## eccerr0r

HeissFuss is right, high memory support will probably solve the issue and at the cost of some TLB flushes, give you full 4G for the process (process size limit due to a 32-bit architecture).  Without the high memory support processes are limited to 3G or 2G each (depending on the 3G/1G or 2G/2G split chosen on your kernel compile) but you don't suffer the TLB flush/bounce buffer penalties.

Technically speaking I would claim that avidemux is a lazy programmer's solution to the big file problem, simply mmapping it all...  Maybe it's fine, maybe not, but I don't think you have to have the whole AVI file in RAM or mapped in RAM to do your work...  Having small chunks at a time should be sufficient.

----------

## doublehp

I desagree: High mem (4G) help states: "Select this if you have a 32-bit processor and between 1 and 4 gigabytes of physical RAM." . Are you sure virtual memory can be linked to physical ?

Of course avidemux coding is poor, thats why it has been removed from portage ^^

But, as I was saying, working on smaller file is not a problem; "Indexing" works very fine on 2800MB files, as well as on 1700MB. When I tried indexing 8GB files, mem allocation went up to 2960204 657392 2923192 before crashing (lucky me I put 4G swap  :Smile:  ) While idnexing 1700MB file, allocation comes up to 1661400 619724 1624196 without any problem. So, tes thats close to the file size, but thats above 1G ... highmem is actually disabled on my system (I will recompile during the day to compare).

While "copying" a 1700MB file (ask avidemux to only copy streams, not use codecs, but not either use the system file copy command), process goes up to 96%, and avidemux could allocate: 3145724 684440 3108520.

This rings me a bell: virtual allocation is 3G without highmem, but, physical always turns around 650M, what are 2/3 of my 1GB stick. This rings me a bell because I remember some tests about /dev/shm: until last Christmass I could use it up to 50%, and this limit is now lower (between 25% and 40%). I wonder if this could be linked; and I still wonder how allowing highmem could help.

----------

## mudrii

check the ulimit options

ulimit -a

----------

## doublehp

```
dhp@moon_gen_2:~$ ulimit -a

core file size          (blocks, -c) 0

data seg size           (kbytes, -d) unlimited

scheduling priority             (-e) 0

file size               (blocks, -f) unlimited

pending signals                 (-i) 7168

max locked memory       (kbytes, -l) 32

max memory size         (kbytes, -m) unlimited

open files                      (-n) 1024

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

real-time priority              (-r) 0

stack size              (kbytes, -s) 8192

cpu time               (seconds, -t) unlimited

max user processes              (-u) 7168

virtual memory          (kbytes, -v) unlimited

file locks                      (-x) unlimited

dhp@moon_gen_2:~$

```

... seems reasonable to me  :Smile: 

(Gentoo default)

Edit: (before reboot, with highmem OFF)

----------

## doublehp

Recompiled Linux, rebooted.

First very funny thing I notice: I have more ram \o/

Yes, switching option on gave me more free RAM !!! 

On my hybrid old mother board, 3 months ago, I switched my 512M SDRAM stick for a 1G DDR, and I was very surprised to see both #lshw and #free indicate me (from human memory) around 940000kB physical. Calculation was for me: 10242=1048576 ... so, I thought I was missing about 60 to 80MB (less than 9%, I gave up  :Very Happy:  ). Fact is, after reboot, I get 1031996 physical RAM (after kernel take it's part, less than 2M), what looks closer to me to 1048576 than before  :Smile: 

So, why whould Highmem be required to use 1G RAM ?

Let's come back to topic: things are better: still copying my 1700MB file, avidemux2 consumes up to 3145724 718732 3108520 what is obviously far more than before. So, yes this options has an influence on my problem.

Working on a 2800M file, avidemux allocated up to 1150124 684300 1112920 (before crash). I will try adding more swap

Copying 2800M, it can allocate 1131940 707260 1094736 .

----------

## eccerr0r

It's not that highmem would help the problem, it has a side effect of using different address spaces (at a performance cost!) for kernel and system memory.  There's a lot of websites posting about why highmem is needed, but it boils down to requiring addressing space for PCI, video buffers, etc., in the 1G of address space for the kernel.

You will still run out of memory when this 4G mark is reached (minus some overhead), instead of the "1G" method which is probably 2 or 3GB.

Looks like you may need to use a 64 bit system to use that buggy software (if it even will work properly with 64-bit pointers) so you can have an even larger address space, or look for/write a solution that can do the work on a 32 bit system...

Bad software.  Source of all evil.

----------

## mean

What version are you using and what kind of files ?

I would guess they are ms dvr files ?

If so upgrading to a more recent version will fix the problem, and it was a bug that was specific to ms dvr.

(And for your information it is developped on amd64, so i'm pretty sure it handles 64 bits ptr fine)

----------

## doublehp

 *mean wrote:*   

> What version are you using and what kind of files ?
> 
> I would guess they are ms dvr files ?
> 
> If so upgrading to a more recent version will fix the problem, and it was a bug that was specific to ms dvr.
> ...

 

TV recorded films, using Windows Media Center. Yes they are dvr-ms things.

There is no possible upgrades: I am using ~x86 for most possible things (all Gentoo, mplayer, E17, sys-libs ...), except for avidemux that is masked, and that I installed by unmasking ebuild (manual install failed). So, avidemux can not be upgraded; mencoder is already latest available in the distro ( weekly updates).

I dont know if the bug is specific to ms-dvr, but it happens on all my recorded files.

And of course ... Media Center works on my weak machine that had Windows sold with, but is not available for install on my home customised machine (Media Center is only available as pre-installed with new machines), and owner of machine that have TV receiver do not allow me to install Linux on it. So, cant export, cant recode, cant record under Linux ... pretty much stuck.

I will through those files, and buy a new TV receiver for me.

----------

