site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com --- --- -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Apr 11, 2007, at 12:06 PM, Travis Rose wrote: The initialization and compression were meant to indicate two different code blocks (sorry!). So it's not a misnamed variable problem. Eventually, my colleague who was working on this problem learned about some limitations with VM management inherent in running 32-bit code (32-bit pointers) ... namely, he observes the VM is actually flushed at 4GB, although the program would crash after 3.4GB use (because of the overhead of the OS is ~0.6GB, in practice, a total 4GB allocation isn't ever achieved for 32-bit); you might think that the system would detect this problem and flush VM sooner; no such luck. As a result, when re-compiling for 64-bit, the program works (i.e., VM gets flushed before running out of memory, etc.) If this is indeed generally the case, we think this may be a problem for developers who use the 32-bit default and get surprised later by the "behavior" of VM management. This is not generally the case; your crash is undobtedly either a stack/heap collision because of a failed termination condition on your recursion, or you are missing a corresponding "free" for one or more of your "malloc" calls. I suggest using MallocDebug, the standard malloc's environment variables, or the "leaks" tool to find out what the problem is. I think you are lucking out (or using a 64 bit application) on Linux, given that the limit on a 32 bit Linux program is generall 3G, unless you specifically compile your 32 bit Linux kernel with a 4G/4G instead of the standard 1G/3G KVA/UVA split. The crash you are getting on a 32 bit MacOS X application is likely indicative of a real coding problem. (and this discussion really belongs on the porting list, rather than being posted in both places). This email sent to site_archiver@lists.apple.com