【日期】：2004-08-17
【问题】：当解码 Q.931 信令时无限循环
【原因】：当在Q.931信令中发现一个未知的元素id时，我们试图通过读取它的长度来跳过它，并且将位置指针迁移几个字节。但是，在这个例子中的长度是零，导致我们反复跳过相同的元素id。
【怎么发现的】：在解码一个 Ethereal 从 Nortel 追踪到的安装信息时发现了这个问题。他们的信息是 1016 字节长度（包含大量快速启动元素），但我们的 MSG_MAX_LEN 是 1000。通常我们会收到一条来自 common/Communication.cxx 的信息，但现在，当直接输入需要解析的数据时，数组末端内存访问越界，其恰好是 0，暴露了这个问题。 为了找到它，我仅仅在 9931 解码中添加一些打印输出。但很幸运数据恰好是零。
【修复】：如果长度是零，设置为 1。这方式总是行得通。
【在哪些文件修改了】： callh/q931_msg.cxx callh/q931_msg.cxx
【我导致的】：是的
【解决Bug的时间】：1小时
【教训】：信任收到信息中获得的数据。不仅仅是产生大量可能导致问题的数据。显示长度为 0 也同样不好。
【问题】：当解码 Q.931 信令时无限循环
【原因】：当在Q.931信令中发现一个未知的元素id时，我们试图通过读取它的长度来跳过它，并且将位置指针迁移几个字节。但是，在这个例子中的长度是零，导致我们反复跳过相同的元素id。
【怎么发现的】：在解码一个 Ethereal 从 Nortel 追踪到的安装信息时发现了这个问题。他们的信息是 1016 字节长度（包含大量快速启动元素），但我们的 MSG_MAX_LEN 是 1000。通常我们会收到一条来自 common/Communication.cxx 的信息，但现在，当直接输入需要解析的数据时，数组末端内存访问越界，其恰好是 0，暴露了这个问题。 为了找到它，我仅仅在 9931 解码中添加一些打印输出。但很幸运数据恰好是零。
【修复】：如果长度是零，设置为 1。这方式总是行得通。
【在哪些文件修改了】： callh/q931_msg.cxx callh/q931_msg.cxx
【我导致的】：是的
【解决Bug的时间】：1小时
【教训】：信任收到信息中获得的数据。不仅仅是产生大量可能导致问题的数据。显示长度为 0 也同样不好。
