The issue description does not say what the problem is, but you probably mean that according to "proc.mem[,zabbix]", the agent uses a little memory on FreeBSD and a lot of memory on Linux. By itself, this is no indication of a bug: different methods are used on these operating systems for determining process memory usage and "proc.mem[,zabbix]" is generally not the best way of measuring memory usage for multi-process processes with shared memory, because a lot of common memory will be counted multiple times (at least on Linux).
If you wish this issue to be considered for investigation, you should provide a description of the problem and what the expected output should be.
Sorry for short description.
Example:
On FreeBSD agent consume 25.5 MB of RAM, BUT the command "'proc.mem" report that agent use only 2.5 MB .
$ zabbix_get -s 192.168.77.105 -k 'proc.mem[,zabbix]' 2506752
Another example:
On FreeBSD my mysql use 600/700 MB of RAM, BUT the command "proc.mem" report only 13.6MB
$ zabbix_get -s 192.168.77.105 -k 'proc.mem[,mysql]' 13647872
So proc.mem on a FreeBSD system report an errata value of consumed RAM for
every process.
On Oracle Linux (RHEL7) all values reported by proc.mem are correct.
ON FREEBSD 10.1
#top | grep zabbix 1280 zabbix 1 4 0 25512K 3104K select 1 0:07 0.00% zabbix_agentd 1281 zabbix 1 4 0 25512K 3096K select 1 0:07 0.00% zabbix_agentd 1279 zabbix 1 23 0 25512K 3096K select 1 0:07 0.00% zabbix_agentd 1278 zabbix 1 20 0 25512K 2944K nanslp 0 0:03 0.00% zabbix_agentd 1282 zabbix 1 20 0 25460K 2840K nanslp 0 0:02 0.00% zabbix_agentd #ps aux | grep zabbix zabbix 1277 0.0 0.0 25460 2716 - I 11:11PM 0:00.00 /usr/local/sbin/zabbix_agentd zabbix 1278 0.0 0.0 25512 2944 - S 11:11PM 0:02.73 zabbix_agentd: collector [idle 1 sec] (zabbix_agentd) zabbix 1279 0.0 0.0 25512 3096 - S 11:11PM 0:07.21 zabbix_agentd: listener #1 [waiting for connection] (zabbix_agentd) zabbix 1280 0.0 0.0 25512 3104 - S 11:11PM 0:07.31 zabbix_agentd: listener #2 [waiting for connection] (zabbix_agentd) zabbix 1281 0.0 0.0 25512 3096 - S 11:11PM 0:07.24 zabbix_agentd: listener #3 [waiting for connection] (zabbix_agentd) zabbix 1282 0.0 0.0 25460 2840 - S 11:11PM 0:01.56 zabbix_agentd: active checks #1 [idle 1 sec] (zabbix_agentd) #top | grep mysql 35461 mysql 55 20 0 711M 610M uwait 0 0:54 0.00% mysqld #ps aux | grep mysql USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND mysql 35461 0.0 7.5 727564 624552 - I 7:40AM 0:55.70 /usr/local/libexec/mysqld mysql 35269 0.0 0.0 17064 2640 - Is 7:40AM 0:00.01 /bin/sh /usr/local/bin/mysqld_safe
Thank you for an elaborate explanation! 
Time has come for elaborate explanation from our side!
The problem is more likely to be in the lack of documentation but not in the proc.mem[] item itself. The reason for such huge difference in proc.mem[] output on Linux and FreeBSD is that on the former zabbix agent returns virtual memory size but on the latter it outputs size taken by process code, data and stack. (Call
#ps -o tsiz -o dsiz -o ssiz
and add up columns to get the same result as zabbix agent.)
I don't think it would be a good idea to change behaviour of proc.mem[] on FreeBSD to make it return virtual memory size because it would affect existing installations. Current trunk already has proc.mem[] with broadened functionality (https://support.zabbix.com/browse/ZBXNEXT-1078). There is one more parameter and one can use proc.mem[,,,,vsize] and proc.mem[,,,,rss] to see virtual memory size and resident set size. More information on this can be found here:
- https://www.zabbix.com/documentation/3.0/manual/config/items/itemtypes/zabbix_agent
- https://www.zabbix.com/documentation/3.0/manual/appendix/items/proc_mem_notes (you can see that default memtype differs for FreeBSD)