[ZBX-22110] Memory leak in vmware module Created: 2022 Dec 19 Updated: 2024 Apr 10 Resolved: 2023 Jan 23 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Proxy (P), Server (S) |
Affects Version/s: | 6.2.6, 6.4.0beta5 |
Fix Version/s: | 6.2.7rc1, 6.4.0beta6, 6.4 (plan) |
Type: | Problem report | Priority: | Trivial |
Reporter: | Michael Veksler | Assignee: | Michael Veksler |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
vmware snapshot |
Issue Links: |
|
||||||||||||||||
Team: | |||||||||||||||||
Sprint: | Sprint 95 (Dec 2022), Sprint 96 (Jan 2023) | ||||||||||||||||
Story Points: | 0.2 |
Description |
Following leaks detected by valgrind when monitoring https://192.168.6.244/sdk vmware machine (https://confluence.zabbix.lan/pages/viewpage.action?pageId=24641663) on master: 782694:==00:00:11:41.481 4001066== 133 bytes in 5 blocks are definitely lost in loss record 1,571 of 1,961 782698:==00:00:11:41.481 4001066== at 0x48650D8: malloc (vg_replace_malloc.c:381) 782701:==00:00:11:41.481 4001066== by 0x5C0051F: strdup (strdup.c:42) 782704:==00:00:11:41.481 4001066== by 0x50A313: zbx_strdup2 (misc.c:199) 782707:==00:00:11:41.481 4001066== by 0x21A967: vmware_vm_snapshot_collect (vmware.c:3907) 782709:==00:00:11:41.481 4001066== by 0x21ACCB: vmware_service_get_vm_snapshot (vmware.c:3978) 782712:==00:00:11:41.481 4001066== by 0x2137FB: xml_read_props (vmware.c:1030) 782715:==00:00:11:41.481 4001066== by 0x21BBE3: vmware_service_create_vm (vmware.c:4276) 782718:==00:00:11:41.481 4001066== by 0x220337: vmware_service_init_hv (vmware.c:6109) 782721:==00:00:11:41.481 4001066== by 0x22601F: zbx_vmware_service_update (vmware.c:8644) 782724:==00:00:11:41.481 4001066== by 0x22FF0B: vmware_job_exec (vmware_manager.c:125) 782727:==00:00:11:41.481 4001066== by 0x2302B3: vmware_thread (vmware_manager.c:236) 782730:==00:00:11:41.481 4001066== by 0x3E17AF: zbx_thread_start (threads.c:115) and this 838927:==00:00:11:41.594 4001066== 17,380 bytes in 4 blocks are definitely lost in loss record 1,941 of 1,961 838930:==00:00:11:41.594 4001066== at 0x48650D8: malloc (vg_replace_malloc.c:381) 838933:==00:00:11:41.594 4001066== by 0x50A187: zbx_malloc2 (misc.c:152) 838936:==00:00:11:41.594 4001066== by 0x50BB9B: zbx_dvsprintf (common_str.c:72) 838939:==00:00:11:41.594 4001066== by 0x50BD53: zbx_dsprintf (common_str.c:111) 838942:==00:00:11:41.594 4001066== by 0x21DE47: vmware_service_hv_disks_get_info (vmware.c:5196) 838945:==00:00:11:41.594 4001066== by 0x21FE7F: vmware_service_init_hv (vmware.c:6020) 838948:==00:00:11:41.594 4001066== by 0x22601F: zbx_vmware_service_update (vmware.c:8644) 838951:==00:00:11:41.594 4001066== by 0x22FF0B: vmware_job_exec (vmware_manager.c:125) 838954:==00:00:11:41.594 4001066== by 0x2302B3: vmware_thread (vmware_manager.c:236) 838957:==00:00:11:41.594 4001066== by 0x3E17AF: zbx_thread_start (threads.c:115) 838960:==00:00:11:41.594 4001066== by 0x18E347: server_startup (server.c:1576) 838963:==00:00:11:41.594 4001066== by 0x18F5BB: MAIN_ZABBIX_ENTRY (server.c:2028) One possible thing to could have impacted this - I firstly tried to connect to https://vcenter7.zabbix.sandbox/sdk (but it did not connect for some reason, so I switched to the the firstly mentioned vmware instance, with config_cache_reload on the server) |
Comments |
Comment by Michael Veksler [ 2022 Dec 22 ] |
Available in:
|
Comment by Marina Generalova [ 2023 Jan 04 ] |
Documentation updated: |