内存溢出性bug记录，不好找原因，出差，复现概率极低挂机几个月都有没浮现的

厦门出现设备问题说明以及解决方案
1：群内提供问题是app无法控制设备的继电器开关,同时切换为本地模式后依旧无法控制继电器开关，2个小区 一个小区一直没有出现问题，另一个要交付的小区出现9-11户设备都无法控制继电器

2：通过现场来看得到如下数据，出现问题后，
①通过本地按键触发然后前往涂鸦后台，发现数据上报了，但是设备继电器没有动作
②控制app下发配置数据，日志是下发了，但是app切换后，设备状态回到上一次，也就是说没有控制成功，简单的说，设备可以上传数据无法接收下发的数据
③为了能够看下是否是程序没有下发，采取电烙铁融化出现问题的设备，然后将jlink插入到设备上面，让电脑给设备供电从而从220V的电源上拿下来，设备依旧不断电重启，从而漏出后面控制信号接口，通过示波器查看是否有波形发送到继电器-------结论没有波形输出（虽然是本地模式）
④通过将jlink插入到出现问题设备的调试扣发现，按键有log，但是出现了一个特殊的log,如下：
00> 851353880ms:queue full
00> 851367460ms:queue full
00> 851369171ms:[KEY] key handle,value: 0,mode:0
00> 851369446ms:[KEY] key handle,value: 1,mode:0
00> 851369446ms:led:0, continue_times:912, set_time:54, onoff_flag:1,mode:2
00> 851369446ms:dpID=1 type:4 dplen:1: 00
00> 851369519ms:queue full

就是上面标红的，也就是说消息队列存储的数据满了
这个时候分析指向了数据为何没有处理，使其充满整个内存池。
然后通过代码发现之前工程师将空间开到了120条数据，所以和硬件梅工+周工一起通过3个手机快速控制目的是将内存池填满复现消息，最后失败了，一旦重启上电根本无法无线

然后我企图通过修改内存池大小将120条–>10条，同样无法复现而再修改小会出现消息根本无法处理的问题

然后开始寻找为何数据满了，程序不去处理的问题，然后通过各种模拟将数据弄满来复现问题，最后发现有一个结构体有一些问题，重点来了如下：

这个标记中只有为2的时候才会将内存池中的数据处理掉，全局搜索后发现这个标记一定是1或者2，不会有任何其他的赋值，如果为2就一定不会数据一直满，但是如果是1，在1中还会将此标记赋值为2，非常奇妙，那么真相只有一种情况，不是1也不是2.此时我通过调试人为干预，将这个参数设置为3，结果不出所料，数据确实无法处理，同时多次发送数据后log出现了，空间满了，继电器无法控制，通过按键后上报信息可以的现象，也就是说通过干预完美复现用户家里现象。

所以现在就要开始解决，这个结构体变量为何无缘无故自动修改了数值。如上述所说，全局没有修改的地方，那么就会有2种情况，
一是外接环境干扰，使其数据发生位反转了。
二是程序中存在结构体数据对齐问题或者是数据溢出干扰到了这个 结构体

第一种情况环境不好搞，那就先尝试第二种，一旦溢出，肯定是这个变量附近的结构体或者数据溢出 ，
通过分析发现如下

应答数据的结构体给了15个字节的空间，通过代码发现应答数据一般13个字节就够了
所以上个工程师给了15个字节，但是万万没想到，竟然读取产品信息的应答中会有字符串连接函数，而这个空间大道了20多个字节如下：

高达28个字节 越界了13个字节，上个工程师空间给小了。所以这就是上述所说的，不是1就是2，为什么会出现所谓的3，

完美解释了，为何有数据不去处理，至此厦门项目bug从根本上找到了原因
在这里插入图片描述