In message <Pine.GSO.4.10.10203191303250.3121-100000@orbit>, Kip Macy writes: >Looking at the source for efence this happens when mmap fails (in this case wi >th >ENOMEM). Looking at the man page the two possibilities are: the system has >reached the per-process mmap limit specified in the vm.max_proc_mmap sysctl or > >insufficient memory was available. *BSD limits the maximum amount of memory th >at >a process can mmap to swap+physical.
I've also found it useful to increase the value of MEMORY_CREATION_SIZE in the ElectricFence source. Setting this to larger than the amount of address space ever used by the program seems to avoid the vm.max_proc_mmap limit; maybe when ElectricFence calls mprotect() to divide up its allocated address space, each part of the split region is counted as a separate mmap. I came across this before while debugging perl-Tk, and one other issue was that the program ran fantastically slowly; a trivial script that normally starts in a fraction of a second was taking close to an hour to get there on quite fast hardware. You expect ElectricFence to make things slow, but not quite that slow :-) Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
