复盘一个诡异的Bug

该Bug的诡异之处在于这是一个由多种因素综合碰撞之后形成的综合体。纵观整个排查过程，一度被错误的目标误导，花费大量功夫后才找到问题点所在，成熟的组件在没有确凿证据之前不能随意怀疑其稳定性。

前言

此前在接入两台粒径谱仪（TSI3321、TSI3034）数据时，碰到了一个非常诡异的情况，它能导致数据停止解析。

这两台粒径谱仪的数据文件是由两套看似相同的软件实时导出，格式一致，不同在于列的数量和数据频次。

TSI3321数据结构

19426	11/07/23	20:22:50	Raw Counts	5194	173	152	133	100	78	58	40	41	20	30	20	20	21	16	25	17	22	23	15	19	15	16	12	12	6	9	4	3	4	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	3243	7	0	19	1013.9	4.97	3.99	0	0	0	0	0	75	55.7	2.93	2.976	31.1	28.5	204	0000 0000 0000 0000	0.695616	0.994068	0.856124	0.542469	1.64629	18.8966(#/cm3)

TSI3034数据结构

2740	11/07/23	16:59:18		0	0	0	0	0	7.1886	3.5483	19.002	22.113	37.142	57.044	101.7	102.44	97.561	148.99	142.91	147.79	131.06	178.67	150.45	126.46	146.46	139.83	101.2	135.73	133.63	111.5	145	108.56	84.471	106.15	107.23	93.794	71.517	69.307	79.288	92.092	58.615	88.356	75.774	45.489	37.047	35.692	40.959	23.661	31.461	29.858	24.924	21.685	6.1227	16.117	22.555	0	0	10	486.97	1.2		OK	56.8122	81.9485	61.9724	37.8552	2.0539	117.442

接入方案

有如下两个接入数据的方案：

使用传统的数据转发程序解析和上传
采用我方经过多年沉淀和积累的空气数采软件DATS解析存储并上传

传统的数据转发程序功能简单，仅支持解析和上传，自身不存储数据，在某种意义上增加了维护难度。

而DATS不仅具备前者的功能，还有存储数据、云端配置备份等功能，安全性和稳定性都较好。不过也有个缺点，虽然两者共用一个上传模块，但是界面上没开放按照仪器配置上传通道的功能。

从大局出发选择后者，而前者将被逐步淘汰。

本次任务的模板就明确了：

开发两个驱动
开放按仪器配置上传通道的设置界面

由于所有数据都生成在一个文件中，每次读取完整的文件不仅降低了解析效率，还耗费大量内存，当文件超过一定体量时甚至可能引发内存溢出问题。故而选择分段读取方式，在程序首次启动后从文件头开始解析，并缓存文件末尾流的位置，下一次直接从该位置往后读取。此前写过类似代码，可以复制粘贴一下。

鉴于两个驱动的相似性，考虑代码的复用，我先实现了一个通用的解析逻辑TxtReader，在其基础上封装了两个驱动TSI_3321和TSI_3034，再按仪器独立配置MN号上传。

开发、调试顺风顺水，按照这个节奏，不出两天就能交差。

偏偏在最后的节骨眼上爆出了问题！

当我把时间调回去重新解析后，两台相同解析逻辑的仪器驱动，一台正常解析完成，另一台则卡住了，就出现在我的开发环境中。

发现问题

这是个偶然发现但必然出现的问题。

由于开发调试过程中不可避免要经常回退最新解析时间，在调试TSI_3034这台仪器时，一个偶然的机会发现时间回退后启动程序每次只解析到两条就停止了。

举个例子，回调时间到2023-10-12 14:05:00，那么14:05这条数据能成解析并上传，下一个时间点，也就是14:10分的数据在解析完成刷新界面后就死了，并且没有写入发送队列中。

如果把上传模块生成的发送队列里的数据清空就能解析到文件末尾，而另一台3321的驱动则没有这个问题，正常得不能再正常了。

第一次排查

面对这个从没出现过的问题，有如下可能导致问题出现的环节：

驱动解析
存储模块
界面刷新
上传模块

好在可以打断点调试，停掉TSI_3321，只启用TSI_3034一台仪器，在解析到一个时间点的数据并抛给主程序的地方打了断点，单步调试，最终把问题点锁定在上传模块内的一个函数中。

这是另外一个同事开发的模块，先把数据放到队列中，为了保证多线程操作，大量使用了锁。

public void SendHisData(DateTime wdt, FactorTypes wDataType, List<UploadFactorValue> wItemValue, bool wIsReSend, DateTime? beginTime = null, DateTime? endTime = null)
{……lock (m_LockNewSendList){m_NewSendList.Add(new SendList(){Dt = wdt,DataType = (FactorTypes)LocIndex,ServerID = _UploadPara.ServerID,Guid = context.Guid,PNO = context.PNO,Context = context.Context, //预留QN和MN的位置，没有CRC信息NeedResponse = NeedResponse,IsTmp = false,Qn = ""});}……
}

在另一个线程中扫描这个队列

private void ScanSendList(bool isTmp, int readCnt)
{lock (m_LockSendUtil){List<SendList> info = m_SendListUtil.GetUploadSendListByServerID(_UploadPara.ServerID, isTmp, readCnt);if (info.Count > 0){SendList info1 = null;for (int i = 0; i < info.Count; i++){if (isTmp)   //缓存的数据{AddSendList(info[i].Dt, info[i].DataType, info[i].Guid, info[i].Context, false, info[i].NeedResponse, info[i].IsTmp);}else{info1 = m_SendList.Where(a => a.Guid == info[i].Guid).FirstOrDefault();if (info1 == null)    //不在待发送列表里{info1 = m_ReturnList.Where(a => a.Guid == info[i].Guid).FirstOrDefault();if (info1 == null) //不在待应答列表里{if (m_SendListUtil.DelOneSendListByGuid(info[i].Guid))   //删除旧的ID,生成新的ID,顺序往后移{lock (m_LockNewSendList){m_NewSendList.Add(new SendList(){Dt = info[i].Dt,DataType = info[i].DataType,ServerID = _UploadPara.ServerID,Guid = info[i].Guid,PNO = 1,Context = info[i].Context,NeedResponse = info[i].NeedResponse,IsTmp = info[i].IsTmp,Qn = ""});}}}}}}}m_SendListUtil.DelDaysSendList(_UploadPara.ServerID, _UploadPara.ValidDay);   //缓存的不能删除}
}

程序就是在调用SendHisData时发生死锁，既然找到了源头，问题似乎就能解决了吧。

很遗憾，开发上传模块的同事排查逻辑后并未得出死锁的理由，也是，如果代码真存在问题，怎么可能现场那么多点位，尤其是数据量比它多的点位都运行好好的。

于是想到把配置发了他一份，在他电脑上跑一下看看，果不其然，在他电脑上没有死锁，两个文本均能同时正常解析。

这时我怀疑可能是自身电脑问题了，一个多星期没关过机，调试时明显感觉到卡顿。临近下班，一时半会儿找不出问题根源，干脆直接装到现场看看效果。

第二次排查

第二天上班，远程到现场机器一看，TSI_3034数据停了，意料之中的事。就这样观察了近半个月每次都是刚启动软件能正常解析，过了一会儿3034的数据就停了，由于我坚持认为问题出在上传模块，并曾当着他的面复现了，所以第二次排查主要是那个同事经手。

当局者迷，旁观者清，调试别人的代码可能更容易找出问题吧。他一眼就看出TxtReader中用于缓存拼包的变量定义成了临时变量，并没有起到作用。

看来问题还是出在这次新开发的驱动内部。

using (var fs = new FileStream(_file.FullName, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
{if (auto){fs.Seek(_filePoint, SeekOrigin.Current);}string buffer = null;byte[] byteData = new byte[10000];int length;while ((length = fs.Read(byteData, 0, 10000)) > 0){if (auto){_filePoint += length;}string text = Encoding.ASCII.GetString(byteData);byteData = new byte[10000];text = buffer + text;if (string.IsNullOrWhiteSpace(text)){return;}// 找出最后一个\r\n，将剩余的字符串缓存起来int endIndex = text.LastIndexOf("\r\n");if (endIndex > 0){buffer = text.Substring(endIndex, text.Length - endIndex);text = text.Substring(0, endIndex + 1);}else{buffer = null;}……}
}

修改过后，放到现场一跑，问题依然存在。

他电脑上复现不了死锁现象，只能通过记录大量日志分析根源。联想到之前我电脑可以上百分百复现死锁，当即跑了一下，奇怪的是这回死锁问题怎么都不出现。可能当初电脑的确卡，不仅仅解析，入库也慢地难以忍受，甚至引发了.NET运行时的某个Bug，重启电脑后恢复正常。

到了这一步，问题又回到了起点，为什么同一个类的不同实例，一个运行正常，另一个出现了死锁呢，这怎么都解释不通。

这才想起来，有个东西自始至终都被忽略了——数据源。两份文件表面上看似格式相同，有没有可能存在细节上的差别？

同事听后觉得有道理，与其陷在僵局之中，不如换一个方向排查。用十六进制视图分别打开TSI_3321和TSI_3034的数据文件，一眼就看出了猫腻。
TSI3321数据十六进制视图
TSI3034数据十六进制视图

程序中严格按照\r\n分割不同时间点的数据，这在3321的数据文件中是合理的，而到了3034中，每一行结尾却是\t\r\n。没错，多出来一个字符\t，偏偏这个字符又是用于分割列，导致分割后列的数量与预期不一致，跳出了解析逻辑。

string[] rows = text.Split(new string[] { "\r\n" }, StringSplitOptions.RemoveEmptyEntries);
for (int rowIndex = 0; rowIndex < rows.Length; rowIndex++)
{string row = rows[rowIndex].ToLower();string[] dataArr = row.Split(new char[] { '\t' }, StringSplitOptions.RemoveEmptyEntries);// 解析数据时间if (dataArr.Length != _dataRowColumnCount || "Sample #".Equals(dataArr[0], StringComparison.OrdinalIgnoreCase)){continue;}……
}

排查到这里，似乎柳暗花明，调整程序后更新到现场，问题依旧……

第三次排查

究竟哪里还有问题？

同事再一次查看代码，花费一番功夫后，终于找出问题所在。这是第二次排查时，把临时变量改为全局变量后带出来的新Bug。

对于3034来说，每条数据都是以09 0D 0A结尾，以它为例，上面代码中计算的endIndex=1，SubString(0, endIndex+1)=09 0D，跟缓存变量拼接后再分割永远都会多出一列，当然不会解析了。

下面的伪代码能清楚地说明问题

假设本次读取到的字节如下：

byte[] byteData = new byte[xx 0x09 0x0D 0x0A yy 0x09 0x0D 0x0A]

转换为字符串，计算得到endIndex=6

string text = Encoding.ASCII.GetString(byteData);
int endIndex = text.LastIndexOf("\r\n");

去掉尾部的\r\n后本次要解析的目标文本为和缓存文本分别如下

buffer = text.Substring(endIndex, text.Length - endIndex);  // buffer=0D 0A
text = text.Substring(0, endIndex + 1);  // text=xx 09 0D 0A yy 09 0D

按照\r\n分割得到rows

string[] rows = text.Split(new string[] { "\r\n" }, StringSplitOptions.RemoveEmptyEntries);

包含两个元素

[{xx 0x09},{yy 0x09 0x0D}
]

再按照\t分割后取得列

string[] dataArr = row.Split(new char[] { '\t' }, StringSplitOptions.RemoveEmptyEntries);

rows[0]能正常解析，rows[1]由于多出了一个0x0D跳出了解析逻辑

rows[0] = [xx];
rows[1] = [yy 0x0D]

等到下一个扫描周期只读取到一个时间点的数据，跟buffer拼接之后永远多出一个0x0D，所以之后的数据也就再也不会被解析了。

而程序刚启动时每次只读取10000字节，大概率不会碰巧读到行尾，因此能解析到最新数据，而第二个扫描周期每次只能读取一行数据了，因为多出的0x0D而无法解析。

到此为止，这个由驱动引发的Bug才真正地排查完毕。

还有个意外

你以为事情到此就结束了吗？

NO！！！

虽然上传模块实现了按仪器发送数据，可此前类似的需求通常使用另一个轻量级的数据转发软件来实现，空气数采软件并没有支持该功能，并不单单是界面不支持设置。

先前只看到了两个通道都有数据收发，没注意收发记录文件大小一模一样。如果仔细一点的话，兴许就不会耗费这么多功夫了。

尾声

最后的最后，调整数采主程序，兼容按仪器发送数据，这件事情才真正解决完毕。

知道真相后，回过头来想想，其实问题并不复杂，困难之处就在于多种巧合的碰撞，让原本很简单的问题复杂化了。