On 04/08/2010 11:03 PM, Chuck Swiger wrote:
Hi--
On Apr 8, 2010, at 12:26 PM, Royce Williams wrote:
Heh - sorry for the extraneous 'T' at the end of your name.
No worries, I've been called worse. :-)
If you're running FreeBSD 7.x, you should already have gcc-4.2.1 or thereabouts
with the base OS. Anyway, even the gcc-3.4.6 version from FreeBSD-6.x seems to
be doing OK with LLVM/JIT bytecode enabled once I removed the two warning
options which were not recognized by gcc-3.
With regard to the failure you've described, what is output of "sysctl
vm.max_proc_mmap"? It could be the cause of ENOMEM from mmap():
[ENOMEM] MAP_FIXED was specified and the addr argument was not
available. MAP_ANON was specified and insufficient
memory was available. The system has reached the per-
process mmap limit specified in the vm.max_proc_mmap
sysctl.
I am not familiar enough with the function of this sysctl to interpret
the results.
# sysctl vm.max_proc_mmap
vm.max_proc_mmap: 78951
It's the number of mmap() entries which the kernel is willing to make available
per process; what you display should be plenty, unless there is some kind of
problem where mmap()ed files never get munmap()ed.
Actually thats a pretty low number if FreeBSD is using mmap() for
malloc() and it is not merging adjacent maps when counting this limit.
78951 (maps) * 4KB (pagesize) = 308 MB
308 MB is a pretty low limit for clamd, especially since the database
alone is ~100MB.
The maximum maps count on Linux is even lower, and yet everything works:
vm.max_map_count = 65530
I guess Linux merges adjacent mmap()s into a single map, and only counts
those.
I don't know what FreeBSD does, but if it doesn't merge the maps then
that max_proc_mmap limit doesn't make sense.
Best regards,
--Edwin
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
