7-Zip komprese - málo paměti (fragmentace, /3GB)

[zarevak]

Snažil jsem se pomocí 7-Zip pluginu zkomprimovat malý (13kb) soubor pomocí PPMd komprese v úrovni Ultra a obdržel jsem tuto hlášku:

The archive was not created due to fatal error. (14) Not enough storage is available to complete this operation.

Copak to znamená?

Na (NTFS) disku je dostatek místa (~11GB) a Task Manager hlásí dostatek volné paměti (~900MB). Systém Windows XP SP3, Salamander 2.52 beta 1.

[Jan Patera]

Snažil jsem se pomocí 7-Zip pluginu zkomprimovat malý (13kb) soubor pomocí PPMd komprese v úrovni Ultra a obdržel jsem tuto hlášku:
The archive was not created due to fatal error. (14) Not enough storage is available to complete this operation.

Deje se cosi podivneho v systemove funkci FormatMessage. Spravne se ma zobrazit "Ran out of memory".
Tady hlavne zalezi na "Dictionary size". U me se ta chyba projevuje od 512MB. Muzete mi mailem poslat vas bug report? Predevsim sekci Modules. Diky

[zarevak]

Out of memory je rozhodně lepší hlášení, ale stále mi přijde divné - Directory size 192MB nenaznačuje, že by 1GB volné paměti nemělo stačit

Snažil jsem se repredukovat problém a vygenerovat bug report těsně před vzniknutím problému a po vzniknutí problému. Nakonec jsem dočel k následujícímu:
1) Spustím Salamandera - 7Zip funguje
2) Otevřu velmi jednoduchou stránku s pár odkazy v IEVieweru - 7Zip funguje
3) Z této stránky odkazem otevřu web Altapu - 7Zip funguje
4) Z původní stránky otevřu web Microsoftu - 7Zip nefunguje

Mailem zašlu seznam modulů po bodu 3) a po bodu 4). V bodu 4) přibyly tyto moduly:

Code: Select all

0x1B000000 (size: 0xC000) (ver: 7.0.5730.13): ImgUtil.dll (C:\WINDOWS\system32\ImgUtil.dll)
0x41E30000 (size: 0xE000) (ver: 7.0.6000.16791): pngfilt.dll (C:\WINDOWS\system32\pngfilt.dll)
0x420C0000 (size: 0x39000) (ver: 7.0.6000.16791): Dxtrans.dll (C:\WINDOWS\system32\Dxtrans.dll)
0x76B20000 (size: 0x11000) (ver: 3.5.2284.1): ATL.DLL (C:\WINDOWS\system32\ATL.DLL)
0x6D430000 (size: 0xA000) (ver: 5.3.2600.5512): ddrawex.dll (C:\WINDOWS\system32\ddrawex.dll)
0x73760000 (size: 0x4B000) (ver: 5.3.2600.5512): DDRAW.dll (C:\WINDOWS\system32\DDRAW.dll)
0x73BC0000 (size: 0x6000) (ver: 5.1.2600.5512): DCIMAN32.dll (C:\WINDOWS\system32\DCIMAN32.dll)
0x42010000 (size: 0x57000) (ver: 7.0.6000.16791): Dxtmsft.dll (C:\WINDOWS\system32\Dxtmsft.dll)
0x6CD00000 (size: 0xC0000) (ver: 2.0.31005.0): npctrl.dll (c:\Program Files\Microsoft Silverlight\2.0.31005.0\npctrl.dll)
0x6C900000 (size: 0x2FE000) (ver: 2.0.31005.0): agcore.dll (c:\Program Files\Microsoft Silverlight\2.0.31005.0\agcore.dll)
0x76380000 (size: 0x5000) (ver: 5.1.2600.5512): MSIMG32.dll (C:\WINDOWS\system32\MSIMG32.dll)
0x74C80000 (size: 0x2C000) (ver: 4.2.5406.0): OLEACC.dll (C:\WINDOWS\system32\OLEACC.dll)
0x76080000 (size: 0x65000) (ver: 6.2.3104.0): MSVCP60.dll (C:\WINDOWS\system32\MSVCP60.dll)
0x4EC50000 (size: 0x1A6000) (ver: 5.1.3102.5581): gdiplus.dll (C:\WINDOWS\WinSxS\x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.2600.5581_x-ww_dfbc4fc4\gdiplus.dll)
0x73940000 (size: 0xD0000) (ver: 5.3.2600.5512): D3DIM700.DLL (C:\WINDOWS\system32\D3DIM700.DLL)

[Jan Patera]

Out of memory je rozhodně lepší hlášení, ale stále mi přijde divné - Directory size 192MB nenaznačuje, že by 1GB volné paměti nemělo stačit

Diky za vypisy. Neni dulezite, kolik pameti je fyzicky volne, nebo je volno ve swap souboru. Dulezite je, jak velky souvisly blok pameti lze jeste nacpat do adresniho prostoru aplikace a tudiz alokovat.
Za normalnich okolnosti nedostane normalni 32bit aplikace vice nez 2 GB. V techto 2 GB je nacteno spousta knihoven a naalokovano spousta
(relativne malych) kousku pameti. Salamander nacita do pameti spousta shell extensions, ktere pamet rozdrobuji. Nactenim dalsiho pluginu (zde IEViewer, resp. nactenim dalsich knihoven timto pluginem) doslo k dalsimu rozdrobeni. Takze uz nebylo mozne naalokovat souvislych 192 MB.
Nicmene, existuji zpusoby, jak:
1) dat 32bit aplikaci 3GB na 32bit OS
2) dat 32bit aplikaci 4GB na 64bit OS
3) zlepsit fragmentaci pameti

Body 1) a 2) spolu souviseji.
Uvidime, zda se podari do AS2.52b2 zminene zpusoby dostat, ted uz je to mimo moznosti me osoby (jakozto plugin developera/maintainera)

[zarevak]

Na fragmentaci jsem úplně zapomněl Díky za vysvětlení.

V mém bugreportu chybí pouhých 536KB pro alokaci 192MB velkého bloku (Mezi GDI+ a UxTheme - obě knihovny načteny na svém Image base).

Mám pocit, že 3GB pro 32bit aplikaci vyžaduje jak podporu ze strany aplikace (informace v EXE souboru o podpoře 3GB - v linkeru přepínač /LARGEADDRESSAWARE), tak podporu ze strany systému (přepínač /3GB v boot.ini). Nevím, zda je kvůli 7-Zip pluginu vhodné jít do takových šíleností. Na druhou stranu pokud Salamander nepoužívá nějakou podezřelenou ukazatelovou aritmetiku, tak by to nemělo ublížit - navíc na 64-bit systému přepínač /LARGEADDRESSAWARE automaticky dodá 32-bit aplikaci 4GB virtuálního prostoru

Nějaké informace o limitech paměťového subsystému:
Mark's Blog : Pushing the Limits of Windows: Virtual Memory
EDIT: The Old New Thing : Summary of the recent spate of /3GB articles

[Jan Patera]

(přepínač /3GB v boot.ini). Nevím, zda je kvůli 7-Zip pluginu vhodné jít do takových šíleností.

Samozrejme nebudeme chtit po uzivatelich, aby to delali

[Jan Rysavy]

navíc na 64-bit systému přepínač /LARGEADDRESSAWARE automaticky dodá 32-bit aplikaci 4GB virtuálního prostoru

AHA, o tom jsem si soukromě snil, ale zatím nehledal podrobnosti.

[Jan Rysavy]

Rozhodli jsme se problematiku zatím neřešit (z časových důvodů), je to jeden až dva dny naší práce (najít vhodné místo, přealokovat všechny pluginy, otestovat to na všech Windows, podpořit automatickou detekci realokace se zobrazením varování do trace). Pokud na problém budou uživatelé narážet (dosud je toto asi první hlášení), budeme ho řešit.

[zarevak]

OK. Mně osobně by stejně /LARGEADDRESSAWARE nepomohlo, protože mám 32-bit systém bez /3GB. Je ale dobré vědět kde je příčina původně hlášené chyby

Přejmenoval jsem vlákno, aby více odpovídalo současnému stavu diskuze.

[Jan Rysavy]

Zběžně jsem koukal, že option LARGEADDRESSAWARE zřejmě neexistoval ve Visual Studiu 6, takže bychom museli v rámci post-build modifikovat přímo PE header. Plánujeme přechod na VS 2008, kde už bude možné option nastavit v prostředí.

Base adressy pluginů a jejich LANG modulů bychom skutečně výhledově měli sešlápnout, momentálně zabírají 0.5GB adresního prostoru díky nehospodárné alokaci.

[zarevak]

Nehospodárná alokace pluginů? Podle přiložených obrázků jsou pěkně pohromadě "Výhledově" si myslím, že je v tomto případě vhodný návrh termínu...

Po načtení všech dostupných pluginů a následném používání Salamandera jsem si nechal vygenerovat bugreport a na jeho základě vytvořil níže uvedenou mapu alokace modulů. Většina pluginů je pěkne pohromadě narozdíl od některých zbloudilých modulů Microsoftu (ImgUtil, GdiPlus). Je však pravda, že právě v místě, kde jsou načteny pluginy a jejich jazyky žádná cizí zbloudilá knihovna není (alespoň na mém systému - WinXP SP3 + IE7 + Silverlight + Flash 10 + TortoiseSVN).

Těch pár pluginů na začátku bylo relokováno Windowsy (moje a stepand76 pluginy).

[Jan Rysavy]

Viz příloha. Vzhledem k velikosti většiny pluginů v řádu stovek KB je alokovaný prostor přehnaný.

[manison]

OT: Hezkou mapu virtuálního adresového prostoru procesu lze zobrazit v nové Russinovichově utilitě VMMap

[zarevak]

Jen tři dny stará utilitka. Díky za tip

To mne však přívádí na myšlenku: Jak VirtualPC tak VMWare alokují pamět po 1MB velkých blocích. Nemohl by 7-Zip plugin alokovat pamět také tak?

Mám pocit, že 7-Zip plugin je zatím jedinným, který se snaží alokovat tak velké kusy paměti, takže by se měl o dobré chování starat on. Salamander by pak neměl práci s řešením těchto zvláštních situací.

[Jan Rysavy]

To je spíš otázka pro 7-Zip aplikaci, na které plugin stojí. U command line verze to problém nebude vůbec, v případě GUI verze se již do procesu nějaké shell extensions načítat budou, ale pravděpodobně nedojde k fragmentaci, jakou vidíme u Salamandera. Takže nečekám, že to autor 7-Zipu bude považovat za problém.