前言
在工作中，每周都会遇到一些问题，这些问题在大家工作中可能会有许多共性，于我也是一种经验的积累小结。我觉得花一些时间整理一下，跟粉丝读者们分享一下日常工作遇到的问题，这是一个很好的互动和文章分享的痛点。
当然，不保证每周都有值得分享的问题，当然也可能有多个问题可以分享，那有时候会谈谈自己近期工作生活中遇到的琐事种种，大忙的时候也可能缺更。嗯，从这周开始这一个系列的文章, 看看我能坚持多久，嘿嘿!
一个yang解析错误问题
情况是这样的，项目使用命令行进入，如果在未连接上netconf服务端的时候，马上敲入命令，会导致那个netconf连接不正常。好在这是一个必现的问题，通过定位发现一个日志报错的位于libyang库的代码中，然后打开netopeer2的日志，可以确定到出问题之前的那个rpc的xml内容。通过MG-SOFT netconf browser 软件发送这个rpc的xml， 知道的确是这个rpc导致的错误， 然后连接就断开了。
下一步就看为什么导致错误的了，这个又需要看libyang的代码了，通过设置buildroot工程下的libyang.mk， 增加CMAKE_BUILD_TYP=Debug选项，编译出一个带符号的libyang，然后就是上gdb调试了。
后面定位到是一个xpath解析的问题，由于传入的xpath是没有带模块名的/node0/node1/node2, 在libyang中认为这是一个错误的xpath，然后就罢工抛异常了。紧接着libnetconf在应答接收不完全的情况下，认为连接异常了，然后把连接设置为invalid了，后续的命令就不能正常执行了。
通过分析xpath的格式，搜索了一下，锁定了问题的源头。是在订阅sysrepo事件的时候传入的xpath问题，缺失了模块名。 通过修改对外接口， 增加了对xpath格式的校验， xpath必须格式为 /m0:node0/m1:node1/m2:node2这样，修改验证后，问题解决。然后就是修改整个项目相关的xpath路径，合并提交代码。最后在部门发个通告，增加这个约束说明。 OK， 问题解决。
更多
开源代码也是人写的， 出现问题也是很正常。这个问题的根因是sysrepo的函数入口没有对xpath进行约束，却在libyang中又有对xpath有这种检查，导致了这个问题的出现。
程序员定位bug就像是侦探破案，首先是确认问题，现场勘查，然后找寻各种蛛丝马迹，推演问题的产生原因。程序员更方便的是可以复现问题，各种尝试，修改后还可以进行验证。在这个过程中，逻辑思维很重要。
行动，才不会被动!
欢迎关注个人公众号 微信 -> 搜索 -> fishmwei，沟通交流。