Symptom

There are multiple issues discovered below while working on this DDTS. We use this DDTS to focus on the first issue only. The second issue is tracked through another DDTS. The third issue is because the customer runs two different versions of images in the active RP and standby FP which causes standby FMAN-FP repeatedly tries to connect to active FMAN-RP and get rejected due to the port number assignment mismatch between the two image versions. The third issue exacerbates the memory leak in the first two issues, as each time standby FMAN-RP connects, there is memory leak and this piles up when standby FMAN-RP tries to connect a few times a minute. The output of "sh redu" will reveal the two different image versions running in the active RP and the standby RP. #1, the message fman_peer_online is not freed (fman_peer_info is part of this message) after message handling. Since in the normal case, this message is only sent once by each FMAN-FP in the system, the memory leak should be very small, hence we will only fix it in polaris_dev branch, not in any throttle branches. This is a Day-1 issue, and affect all platforms. [fman_mgmt] message fman_peer_online/aa148dd0a63c2005bbc2928e17b35b3a/0 created:207852 destroyed:0 diff:207852 [fman_mgmt] type fman_peer_info/b735676b1276383530c4aca4e6837392/0 created:207852 destroyed:0 diff:207852 #2, the tdlh created by tdlhandle_clone(fman_rp_db) inside fman_peer_handle_connection is not freed. This is tracked and fixed in another DDTS. callsite: 2424522760, thread_id: 21087 allocs: 415, frees: 0, call_diff: 415 % 0x7fc1d2308a1d : __maroon_malloc % 0x7fc22341fd35 : tdlhandle_clone % 0x55751beba0a4 : fman_peer_handle_connection #3, standby FMAN-FP repeatedly tries to connect to active FMAN-RP and get rejected. This is because the customer runs two different versions of images in the active RP and standby FP. The output of "sh redu" will reveal the two different image versions running in the active RP and the standby RP. As the two particular image versions have different the port number assignments, the connection between standby FMAN-RP and active FMAN-FP cannot establish. The third issue exacerbates the memory leak in the first two issues, as each time standby FMAN-RP connects, there is memory leak and this piles up when standby FMAN-RP tries to connect a few times a minute.

Conditions

Workaround

Further Problem Description