§ ¶An amusing benefit of staying in 32-bit land
Quick entry today.
A limitation of 32-bit code is that it lives in a 32-bit address space, which limits directly addressable memory to 2-4GB and typically usable memory to as low as 1.5GB. Well, I've found that this is sometimes a benefit. You see, a Core i7 CPU can run code really fast, and if you've got a piece of code stuck in a loop allocating memory, that means it can allocate memory really fast too -- so fast that it sends the system into swap death within seconds. Sometimes with a lightweight debugger like WinDbg/CDB or with command-line utilities like taskkill.exe you can nuke the process quickly, but with a heavyweight IDE like Visual Studio it can take minutes for the debugger for respond and for the system to recover. If you have enough system memory, however, the 32-bit process will run out of address space and crash out before it can do damage. It's funny to see a process instantly hit the 1.5GB brick wall in Task Manager and then break in the debugger.
(You might ask why I have a paging file at all. Well, certain features of Windows require a paging file because it's a convenient way to do critically low level I/O, such as writing a kernel dump file. It also increases the chances of you being able to catch the offender before the system really absolutely runs out of memory, at which time Bad Things Happen(tm).)
Comments
Comments posted:
The Ctrl + Alt + Delete screen needs to have priority above all other processes in the system, specifically for killing processes.
Tom - 05 08 11 - 09:41
I once tried running my 16 gig dev box without swap. It wasn't pretty.
Trimbo - 06 08 11 - 05:41
Makes you wonder if the VS debugger should have an option to jail your process into a restricted job object. Would be a nice feature.
tobi - 06 08 11 - 20:55
Interesting, didn't know you could do that with job objects. That looks cleaner than the idea I had of doing a bunch of VirtualAlloc(MEM_RESERVE) calls.
The docs mention that there can be a conflict from the Program Compatibility Assistant (PCA) using them, though, which is another reason to hate the PCA.
Phaeron - 06 08 11 - 21:59
Also, if your windows is in trial mode, user processes get moved into a non-removable job object that limits you to max 3 processes. Jobs are a quite underused feature for sandboxing in my opinion. That is what they are made for. You can set all kinds of limits, child processes get added automatically and can optionally be prevented from leaving the job.
tobi - 06 08 11 - 22:31
And filling up the address space with MEM_RESERVE is hilarious ;-)
tobi - 06 08 11 - 22:32
Nothing has higher priority then the CD tray. This has been my joke and pet peeve since day one with windows. If I ever became CEO of microsoft, I would fire the person who did this.
This memory discussion brings up a good point, even though people have these nice systems with tons of memory, most 32 bit applications dont use it lol.
evropej - 08 08 11 - 03:59
I must say I haven't tried yet, but, if I would run into such problem on 64bits, I'd try calling SetProcessWorkingSetSize in debug builds...
Goran Mitrovic - 08 08 11 - 08:05
Goran: SetProcessWorkingSetSize won't help, because it only sets the amount of memory that Windows tries to keep resident in physical memory. It doesn't enforce any kind of quota.
KeyJ (link) - 17 08 11 - 19:43
KeyJ: I know, but, the rest of the system might remain responsive. My experience says that if you're not quick enough to terminate immediately, you might need minutes (even 10 or more) to quit application that allocates in a loop. It simply take ages for Windows to respond on mouse clicks and to launch TaskManager...
Goran Mitrovic - 22 08 11 - 05:03
Which brings us to a question -- why allocate memory in a (runaway) loop?
Igor Levicki (link) - 07 01 12 - 14:13
It was copying a singly linked list which had been corrupted and looped.
Phaeron - 07 01 12 - 19:03
Comment form
Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
