Ben Wing wrote:
OK, it looks like your whole problem is due to low-memory warnings. i see why
you're
getting an infinite loop, and i can fix that; but i still don't know why you're
getting low-memory warnings at all. could you set a breakpoint at
check_memory_limits and step through it and see what values you're getting for
data_start, lim_data, cp, and warnlevel?
In check_memory_limits
+ cp 0x09250000 ""
data_size 135245148
+ data_space_start 0x011552a4 "End of Emacs initialized data"
warn_function 0x0101e4fc malloc_warning(const char *)
warnlevel 0
lim_data 116391936
The value of lim_data is bogus, and I spent some time looking why:
Looks like those variables that should have UNINIT_PTR values
unsigned char *data_region_base = UNINIT_PTR;
unsigned char *data_region_end = UNINIT_PTR;
unsigned char *real_data_region_end = UNINIT_PTR;
from ntheap.c have instead values like
+ data_region_base 0x09100000 ""
+ data_region_end 0x0910c000 ""
+ real_data_region_end 0x0910c000 ""
when entering main(). Thus in ntheap.c, sbrk()
if (data_region_base == UNINIT_PTR)
condition is never true, and data_region_size is never initialized.
This looks like a compiler/linker bug to me, but almost too elementary
to be believable. Unfortunately I don't quickly see how to go around
that. I quickly tried initializing those in the beginning of main, but
it crashed elsewhere.
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for
80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
Maybe you have a suggestion? In the meanwhile I'll try to get the
latest Visual C++ service pack, just in case that it has a cure for
this.
Harri