lchnu

另外，请问作者，在调用 mqtt_clean_session 函数的最后一行，将状态设置为CLIENT_STATE_INVALID之后，是否应该将c->mqtt_ack_handler_number = 0; 清零？ 因为此时的 ack链表都已经全部清除了，没有release的情况下，多次连接会导致 mqtt_ack_handler_number越来越大，最终超过最大值。 感谢您的关注和解答，多谢！

> 是的,你说的很对,目前两个bug均已修复,感谢你的issue. 谢谢大神的回复，感谢您的代码！ 1. 我仔细阅读过您的代码，在mqtt_yield_thread函数的exit处，您是destroy thread再清空mqtt_thread，我认为这样不妥当（也在电路上实测过）。destroy之后，任务代码再也无法运行，我认为应该清空再destroy。 您修改的代码： ``` static void mqtt_yield_thread(void *arg) exit: platform_thread_destroy(c->mqtt_thread); c->mqtt_thread = NULL; } ``` 我修改的代码如下： ``` static void mqtt_yield_thread(void *arg) exit: threadToBeDestoried = c->mqtt_thread; c->mqtt_thread...

@jiejieTop 关于mqtt_ack_handler_destroy函数的问题： - 测试过程与现象描述 1. client在socket成功建立连接后，假设Heap区有8000字节空闲。调用mqtt_connect、mqtt_subscribe，并在mqtt_subscribe中注册了一个topic handler； 2. 调试过程中，broker只向client发送CONNACK，而不发送SUBACK； 3. 经过预设timeout，mqtt_yield调用mqtt_ack_list_scan(c, 1)，转到mqtt_ack_handler_destroy(ack_handler) 4. 主动关闭socket，mqtt client进行clean session，删除yield任务，清空mqtt_ack_handler_list和mqtt_msg_handler_list 5. 观察到，heap区的剩余只有7968字节。 6. 反复进行该步骤，Heap区每次剩余字节都逐渐减少32字节。 - 问题分析 client进行sub之后，等待suback超时，在yield任务中destroy了ack_handler。但是，在sub函数调用过程中，msg handler被添加到了ack_handler_list中，msg handler占用的空间并没有被释放，导致了此bug发生 - 问题解决 ``` static void...

经过仔细思考，我最终修改了mqtt_ack_list_scan函数，添加了删除msg handler的代码。 在Suback、unsuback等命令超时的情况下，会删除对应的msg handler，避免heap区的空间越来越少的bug。不知道 @jiejieTop 您如何看？修改的思路可对？ ``` /* if it is not a qos1 or qos2 message, it will be destroyed in every processing */ if( (NULL != ack_handler->handler) &&...

补充说明，在mqtt_clean_session函数处，我在 release all ack部分，也添加了msg handler的部分： 避免了socket连接，收到connack，但socket立即就断开时，heap区不断减小的问题。这种情况在使用流量卡的时候，可能会发生。 ``` /* release all ack_handler_list memory */ if (!(mqtt_list_is_empty(&c->mqtt_ack_handler_list))) { LIST_FOR_EACH_SAFE(curr, next, &c->mqtt_ack_handler_list) { ack_handler = LIST_ENTRY(curr, ack_handlers_t, list); mqtt_list_del(&ack_handler->list); if(NULL != ack_handler->handler) //@lchnu,...

Jie神，你好！ 我在调试过程中，直接将FreeRTOS的xTickCount初始值，在vTaskStartScheduler函数中设置为了0xFFFF0000UL。 salof使用%u，显示不正常。 ``` SALOF_PRINT_LOG("[TS: %u] [TAR: %s] ",salof_get_tick(), salof_get_task_name()) ``` 为了处理这个问题，我修改了_salof_format_int函数中的临时变量n，将其从int变成long long了。 因为你的代码中是判断n的正负，对于unsigned int而言，0xffff0000/10, 一次处理就不满足while循环条件了： ``` static void _salof_format_int( ...... long long n = num; //@lchnu, int to long...

另，为了避免timer在溢出的时候，实际expire时间小于timeout，我用freertos的几个接口函数改写了timer部分。 再次感谢Jie神的工作，太赞了！！！！ ``` //platform_timer.h #include "task.h" typedef struct platform_timer { TickType_t xTicksToWait; TimeOut_t xTimeOut; } platform_timer_t; //platform_timer.c void platform_timer_init(platform_timer_t* timer) { timer->xTicksToWait = 0; timer->xTimeOut.xOverflowCount = 0; timer->xTimeOut.xTimeOnEntering = 0;...