Can't allocate memory required for (de)compression..help!

[Duarte]

Hi everyone!
Sorry if i shouldn't post this here.
I realy don't know if i should be asking for help here, sorry to be bothering..but i'm a little desperate.
I tried to install a game that after installation some files start to extract, to complete the installation, but i get this error :




i've a core 2 Duo @ 3.00GHz with 2 GB ram. i installed the game on other machine i have and everything went well..the other machine is pentium 4 3.2GHz with 1 GB ram! i don't understand this .. can anyone help please?

[encode]

Seems to be you have not enough memory available to decompress. Extract int on other machine and repack it with WinRAR, 7-Zip or PIM archiver.

[Shelwien]

Somehow that looks like Vista+2GB vs XP+1GB

[encode]

That means FreeArc is buggy...

[IsName]

Duarte, try unarc. It should work.

[nimdamsk]

There are bunch of problems with memory management in Windows systems. Total amount of memory may not help here because program needs _continuous_ memory block. Memory is fragmented somehow so may be there is no such block there. You can try close all other programs or boot and decompress in safe mode.

[Duarte]

Thanks to everyone for the replies!
I've tried to decompress in safe mode but i get the same error..always rep:661mb
I will try to find some way to defrag RAM, i really think that's the problem!
if nothing else works i will try to repack everything!
Thanks!

[Duarte]

Well..after some more tries the error doesn't go away..
I tried with a few programs to defrag RAM, but nothing seems to work..RAM defrag, FreeRAM XP Pro and SpeedUpMyPC 3..

[nimdamsk]

You can try also latest FreeArc, usually it's located here: http://www.haskell.org/bz/arc1.arc It's dated as 30-june. If this won't help, than there would be Bulat's turn

[Duarte]

nimdamsk it gives me the same error!
The difference is that it doesn't stop..total time just keeps going up and nothing is extracted..jebus

[IsName]

nimdamsk it gives me the same error!
The difference is that it doesn't stop..total time just keeps going up and nothing is extracted..jebus

Duarte, did you test unarc? It's included in all FreeArc packages.
Problem you described shows with 32-bit systems... do you have such?
Ram defrag could not help - it does completely different thing.

[Duarte]

Sorry IsName, i didn't pay the attention i should to your preveious post!
The decompression with unarc went smooth as silk!
I still don't understand this error, but it's working with unarc so i'm happy!
Thanks IsName, and thanks everyone!
You guys rock!

[IsName]

The decompression with unarc went smooth as silk!
I still don't understand this error

I try to explain this. Every program must be given some memory to work, thus physical memory has to be divided among programs(in fact, among processes). Every process receive 4 GB of memory space (on 32-bit windows, upper half is reserved for OS). Memory is broken into small pieces (afaik, 4 KB), called pages. Then some of these 4 KB pieces in process address space are mapped to physical memory(by OS). There's some extra pieces of code, usually doing some often required work(like working with files, with internet etc.) called DLLs. But DLLs are loaded into process space and therefore split it into parts. So, in your case, probably several DLLs are loaded(some shit like Kaspersky antivirus , leaving no 661 MB continous block. unarc has less features, and it uses only system DLLs which are really necessary. Such are usually loaded to the upper 1/8 of available 2 Gb. On 64-bit system, upper 2 GB (of 4) are not reserved,leaving solid 2 GB block for FreeArc... and this problem disappear.
Please excuse me for any mistakes I made here... I'm not a programmer.

@Bulat: do you plan to remove wininet.dll ?
You really should put an advice to use unarc if decompression fails with this error. It shouldn't be hard.

[encode]

I think, users should not care about all that stuff... Any program should work correctly!

[pat357]

The memory requirements for packing/unpacking can be specified by the -lc/ld switches.
If you pack a game or something else for somebody else, one should know this, it's clearly written in the manual.
Moreover, the amount of memory for unpacking "REP" is 2x dict. size, 2 x 661 MB in this case. (also written in the manual).

Can one not complain about not being able to unpack a game if I packed it on my "8 GB Core2 dual Quad/Vista64" system using the maximum memory requirements ?
Algorithms like PPMD and most CM'ers are symmetric, so if I use these with max. memory settings on *my* system, I should know it might not unpack on someone else's system !!

RTFM and use -ldxxx MB switches or don't use the -m8/-m9 setting when packing for someone else if you have a system with "much more than average" available memory.
Freearc has also "special" switches for high mem. packing/low mem. unpacking (-m7x, -m8x and -m9x).

[Duarte]

Thanks for your explanation IsName!

[Bulat Ziganshin]

one note: REP unpacking memreqs should be 1x, but due to bug archives created with 0.40 and all alphas of 0.50 except for last one (June 23) are need up to 2x for decompression. so, repacking archives with last alpha would be useful

[SvenBent]

So "rep -b1024" requires 2gb of memory for decompression?

[Bulat Ziganshin]

yes, it was a bug in compression algo so it makes archives which may need up to 2x for decompression (to be exact, this situation arrives when data are not comressible and no repeats was found for entrire 1x-sized chunk)

i've fixed this in fa, but not yet released fixed version of standalone REP

[pat357]

So "rep -b1024" requires 2gb of memory for decompression?

I still wonder why you use the "stand-alone" REP ?
REP is integrated in ARC.EXE/FREEARC.EXE and you can configure all the "one file" compressors to work with FreeArc :

arc a -mrep:100mb+lzma:max:64mb .....
arc a -mexe+rep:200mb+delta+rzm ........

It just seems a lot easier to me to use arc/freearc for this !
The "stand-alone" REP is still interesting for some quick&dirty testing though..