xfrp项目内存泄漏

[workmengxue]

运行xfrp项目在小内存设备上，观测available内存，每次tcp连接后会泄漏408字节。

[liudf0716]

@workmengxue 谢谢反馈。请问是什么版本测试发现的呢？

[workmengxue]

最新的

staylightblow8 @.***> 于2024年11月1日周五 14:16写道：

@workmengxue https://github.com/workmengxue 谢谢反馈。请问是什么版本测试发现的呢？

— Reply to this email directly, view it on GitHub https://github.com/liudf0716/xfrpc/issues/66#issuecomment-2451360511, or unsubscribe https://github.com/notifications/unsubscribe-auth/BEYS6CDOH2J2QL6LWREYS5DZ6MMC3AVCNFSM6AAAAABQ7RFJW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJRGM3DANJRGE . You are receiving this because you were mentioned.Message ID: @.***>

[liudf0716]

@workmengxue 好的，我自己验证一下，再次感谢反馈！

[lawishere]

config.c 里面涉及的 strdup 要回收 clear_main_control() 里面有个 tcp_mux 这里似乎作者想把状态机恢复到一个初始状态，没实现完，这里有泄漏，我认为做一个 delstream 行为会合理一点。 handle_control_work() 里面 case TypeNewProxyResp 对 npr 操作不能使用 FREE，不像 JAVA 的对象聚合性，要把 proxy 里面的内容都 FREE，类似的还有 handle_login_response() 里面的 lres case TypeStartWorkConn 漏了 sr 释放，有一个泄漏

下面有些泄漏，但是没有太大所谓。 init_login() 考虑完整性也要回收，不过如果是单例使用也没所谓。 msg.c 里面的 login_resp_unmarshal() 涉及的内存分配要回收 msg.c 里面的 new_proxy_resp_unmarshal() 涉及的内存分配要回收

开源不易，难得作者那么好的开源，略尽绵力。

[liudf0716]

@lawishere 能具体说什么地方有内存泄露吗？

config.c 里面涉及的 strdup 要回收

config.c里面strdup的内容生命周期跟进程是一样的，这部分进程推出后自然就会释放，所以这部分就没有特意对其进行释放

clear_main_control() 里面有个 tcp_mux 这里似乎作者想把状态机恢复到一个初始状态，没实现完，这里有泄漏，我认为做一个 delstream 行为会合理一点。

stream 不是指针，这部分没有泄露点

handle_control_work() 里面 case TypeNewProxyResp 对 npr 操作不能使用 FREE，不像 JAVA 的对象聚合性，要把 proxy 里面的内容都 FREE，类似的还有 handle_login_response() 里面的 lres case TypeStartWorkConn 漏了 sr 释放，有一个泄漏

npr如果不释放就内存泄露了， new_proxy_resp_unmarshal函数里面calloc了这个对象

下面有些泄漏，但是没有太大所谓。 init_login() 考虑完整性也要回收，不过如果是单例使用也没所谓。 msg.c 里面的 login_resp_unmarshal() 涉及的内存分配要回收 msg.c 里面的 new_proxy_resp_unmarshal() 涉及的内存分配要回收

需要具体分析一下问题，这个描述有点太笼统了

开源不易，难得作者那么好的开源，略尽绵力。

谢谢支持！