lchnu
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;...