摆脱跳大神的debug

调试《erlang程序设计》构建基于OTP的系统的示例时,在windows下运行shell_for_testing函数死活不成功。

使用appmon:start()看进程树根本就不是示例的状态,好吧臆测sellaprime_supervisor的start_link函数时unlink那个地方的问题。其实不知道发生了什么事,那就姑且假设是环境不支持好了。


在stackOverFlow上搜到似乎有人问类似的问题,三种解决方案。其中一种是用application,好吧,接下来的内容就是使用application配置打包。

结果使用application还是报错,area_server能启动并响应请求,但崩溃后死活不重启。这不就说明监控树失败了嘛!检查了关键的supervisor一百遍,确定init返回的参数结果没有问题。
鼓捣了半天发现prime_server运转正常。就知道又来了,一行一行对,终于在昨晚到今天中午耗了好几个小时的情况下,发现了那个猪一样的bug……area_server的start_link方法我写的是:gen_server:start。正确的应该是gen_server:start_link({local, ?MODULE}, ?MODULE, [], [])。


我擦。没跟父进程关联,死了谁管你啊!!!
OTL真弱智。


其实如果运用解决bug的推理,这个问题不应该拖这么久才解决。因为指向问题点的证据已经很充分了,子服务启动成功,说明supervisor的init没问题。接下来就应该聚焦在子服务本身上,第一时间就应该看对照组的状态,但我没做。最终墨迹了好久,还是运用了对照组。
代码很简单。但两个server对照了半天,还是没发现错误。(我真是够了)
其实重头想想,就知道问题一定是出在area_server:start_link上。一个进程通过父进程启动了,但没在监控树上显示,但又能响应请求,显然是野进程,没关联注册成功啊!!这不就是start_link和start的区别吗?
修复了之后shell中也能启动成功了。windows没有错,错的是我。想也是。OTL。

希望下次能再理智一点,运用推理早点发现问题点。还有快点去死啦这种不谦虚的态度。

反省最近debug的状态。
其实解决问题更多是用直觉,就是以前遇到过问题的积累等。
但学新东西时没有这种直觉,如果有相似可以类比的对象情况还会好些,但在全新的领域,尤其是多个bug重叠时,面对稀奇古怪的错误信息,一无所知的茫然会让我觉得自己和手无寸铁的小孩没啥区别。

这种心理影响下遇到问题很难保持理智与冷静,而心理状态会直接影响解决问题的速度。

盲目自信,不相信自己真会犯那么弱智的错误;
心浮气躁,轻视系统自带提示,不认真看报错信息,只凭经验瞎猜;
急功近利,希望顺顺利利最好没问题,有问题也只有一个或者一下子解决掉。如果不顺利,又开始迷信,觉得什么破玩意根本调不好,怀疑是环境缺陷(其实心里也出现这种情况微乎其微,仔细想初学都最常规的操作,如果有这么明显的bug早修复了),或者不熟悉新规则;
缺乏计划,没做好应付多个bug的准备,同时也不能专注于单一问题点,所有问题一把抓;
这样的状态再丢掉推理,debug大概就只剩下瞎撞运气的成分了。

其实debug就像对数学题求解。已知现象和一些条件,定位bug点。只要心中有计划,按照步骤测试,根据测试结果不断修正方向,就一定能找到引发现象的原因。
debug步骤主要是,假设、验证、排除。范围从大到小,不断地试验,用系统该数据说话,而不是想象。即使错误猜测在验证时也能带来有价值的信息,即使一个小问题也要善于反问总结。还有一点就是要逼自己熟悉报错,克服对英文的不适应。很多时候对英文的不熟悉也增加了对bug信息抵触情绪。

要早点摆脱要靠跳大神的debug。
 

你可能感兴趣的:(debug)