标签: bug

A few weeks ago, the cyberworld was embarassed to reveal a major memory-handling bug in the Heartbeat extension of the Transport Layer Security protocol used in the popular OpenSSL cryptographic software library. The Heartbeat extension allows a client to tell a server that it's still connected, even if it's not doing anything at the moment, thereby preventing the server from shutting down the link between them.   The Internet and other news channels are being flooded with stories about how a vast number of users' passwords, credit card numbers, and things like online banking communications are vulnerable to attack. There are also a lot of discussions and explanations about the Heartbleed bug works; most of them make my eyes glaze over in confusion.   But then someone pointed me toward a cartoon explanation of the bug on XKCD.com. I have to say that this is the clearest explanation one could get. Take a look, and see what you think.   (Source: XKCD.com)   I also have to say I am in awe of the comic's creator, Randall Munroe. His subjects range from statements on life and love to mathematical and scientific in-jokes. When it comes to the science and technology side of things, he has a unique gift for presenting complex information in an incredibly understandable way.   One of my personal all-time favorites was the XKCD Radiation Dose Chart . I often use it to locate obscure radiation-related information, such as the dose one might expect from eating a banana. How about you? Do you have a personal XKCD favorite?

Do we now need a solution better than JTAG? Hard real-time control software is increasingly common in terms of the number of different items in everyday life that use it. Many items that offer better safety, with equivalent or better energy efficiency, are now possible. But most of the people I know who have recently purchased a new piece of electronics, or a vehicle, or some other device have found at least one bug! It is becoming increasingly clear that, without help, JTAG-based ICE (in-circuit emulation) is not up to par on many of today's CPUs. Furthermore, JTAG testing and debugging does not allow one to test all the "at speed problems" one encounters in research and development or in production. This is forcing JTAG test escapes to be found by other means. The CAN bus (for controller area network) came out around the same time as JTAG, and both took time to gain momentum. This was when embedded Flash memory sizes were only a few hundred kilobytes in size. By comparison, modern automobiles and control systems use real-time stacks on 100mbp/sec Ethernet, and 1GHz (or higher) processors with many gigabytes of Flash memory, but they often still use only JTAG for debugging, Flash Loading (often only the boot loader), and partial production test. It is left for each chip maker and OS/OEM to come up with a full Flash load/debug solution on its own. Be it an MCU, an FPGA, or some other device, many are limited in one way or another by limitations in JTAG technology. Isn't it time we come up with a readily affordable, industry-wide solution? The thing is that bad debug and test capability can have a very real human cost. Allow me to relate a story that will illustrate my point... Back in the 90s I worked for an aerospace company designing police, fire, medevac, and special mission radios for helicopters and aircraft. We had one Intel ICE for the 8051. The ICE used the old "Bond Out" chip ICE technology. I was not there when the original code was developed and they first attempted to use this ICE. It was bad enough that we were out in a lab in the middle of the desert with a bad ICE. When we were not dealing with scorpions, poisonous centipedes, black widows, or the occasional side-winder that would craw into our lab (or up through the shower drain in the middle of getting ready for work) we had to find other, less venomous, but equally vexing, "bugs" by the time- honoured tradition of "Burn and Learn." What this meant was that we would "burn" a UV erasable version of the processor and then "learn" whether or not it would then burn out the transmitter. Dealing with ever-so-great equipment and angry customers that could fly in at any minute to lodge a complaint was never dull. It was also interesting having to handle walking, crawling poisonous bugs while we were frantically wrestling our own black widow's nest of a C compiler riddled with bugs coupled with a bad ICE. The ICE was so complicated to set up and get working—and the power in the lab went out so often—that it was damn near impossible to get it all running right before we lost power along with the working configuration. It was a race against time reminiscent of a "Dr. Who" episode. This was in the days of DOS, and there was no such thing as an uninterruptable power supply (UPS) for a PC and ICE, let alone a Flash memory in which to save the ICE configuration. This system had actually been designed to use a VT-100 terminal as the interface! Sadly, it had been made for a large corporation that could have easily afforded a plant-wide UPS. Furthermore, the company executives had all been fined for billing all kinds of executive perks to the government, so there was no money for a better ICE when one finally came out. William Murray Electrical Engineer

Is a solution better than JTAG now necessary? Hard real-time control software is increasingly common in terms of the number of different items in everyday life that use it. Many items that offer better safety, with equivalent or better energy efficiency, are now possible. But most of the people I know who have recently purchased a new piece of electronics, or a vehicle, or some other device have found at least one bug! It is becoming increasingly clear that, without help, JTAG-based ICE (in-circuit emulation) is not up to par on many of today's CPUs. Furthermore, JTAG testing and debugging does not allow one to test all the "at speed problems" one encounters in research and development or in production. This is forcing JTAG test escapes to be found by other means. The CAN bus (for controller area network) came out around the same time as JTAG, and both took time to gain momentum. This was when embedded Flash memory sizes were only a few hundred kilobytes in size. By comparison, modern automobiles and control systems use real-time stacks on 100mbp/sec Ethernet, and 1GHz (or higher) processors with many gigabytes of Flash memory, but they often still use only JTAG for debugging, Flash Loading (often only the boot loader), and partial production test. It is left for each chip maker and OS/OEM to come up with a full Flash load/debug solution on its own. Be it an MCU, an FPGA, or some other device, many are limited in one way or another by limitations in JTAG technology. Isn't it time we come up with a readily affordable, industry-wide solution? The thing is that bad debug and test capability can have a very real human cost. Allow me to relate a story that will illustrate my point... Back in the 90s I worked for an aerospace company designing police, fire, medevac, and special mission radios for helicopters and aircraft. We had one Intel ICE for the 8051. The ICE used the old "Bond Out" chip ICE technology. I was not there when the original code was developed and they first attempted to use this ICE. It was bad enough that we were out in a lab in the middle of the desert with a bad ICE. When we were not dealing with scorpions, poisonous centipedes, black widows, or the occasional side-winder that would craw into our lab (or up through the shower drain in the middle of getting ready for work) we had to find other, less venomous, but equally vexing, "bugs" by the time- honoured tradition of "Burn and Learn." What this meant was that we would "burn" a UV erasable version of the processor and then "learn" whether or not it would then burn out the transmitter. Dealing with ever-so-great equipment and angry customers that could fly in at any minute to lodge a complaint was never dull. It was also interesting having to handle walking, crawling poisonous bugs while we were frantically wrestling our own black widow's nest of a C compiler riddled with bugs coupled with a bad ICE. The ICE was so complicated to set up and get working—and the power in the lab went out so often—that it was damn near impossible to get it all running right before we lost power along with the working configuration. It was a race against time reminiscent of a "Dr. Who" episode. This was in the days of DOS, and there was no such thing as an uninterruptable power supply (UPS) for a PC and ICE, let alone a Flash memory in which to save the ICE configuration. This system had actually been designed to use a VT-100 terminal as the interface! Sadly, it had been made for a large corporation that could have easily afforded a plant-wide UPS. Furthermore, the company executives had all been fined for billing all kinds of executive perks to the government, so there was no money for a better ICE when one finally came out. William Murray Electrical Engineer  

　　昨天，反映了网站使用中遇到不适用的问题，管理员回复了，正在分析，着手解决。 　　回复信息中的一个关键词引起了个人对电子业内现况感受之联想。 　　“这是一个bug我们并没有强制这么做”，这言语的理念和表达意义，似乎就是说：bug而已，不是主观行为。 　　bug，与网站研发制造无关？就是说，其客观存在所至，非主观意愿所为。 　　这勾起了个人的感受之感想...... 　　曾几何时，电子产业时兴起了产品技术是吃软不吃硬，到如今软件技术就像人体的皮肉太胖了，脂肪太多了，时时处处都在要减肥。 　　言归正传，这些年来，个人在业内工作的感受就是研发制造重点都放在软件上，个人在日常消费使用的感受就是年年更新换代的产品八成都是软件更新。 　　这几年在电子多媒体产品制造企业工作，软件工程师们的口头禅就是：软件是有bug的啊！ 　　那口气和神态就是表达出一个理念——软件bug是正常的。 　　结果导致的研发制造行为就是10天半个月就有新版本软件，总是不断地频频update、update...... 　　从研发、到生产、到客户、到消费，回过头来，研发说：彻底更新啦，现在是下一代版本啦！ 　　这样的PDCA？产品体质越来越肥、越来越虚，产品寿命越来越短，结果可想而知，电子垃圾泛滥！ 　　哈，又扯远了。 　　还是看看什么是bug？ 　　到google搜索关键词：bug是什么意思。 　　就选看第一条：bug是什么意思_bug的翻译_音标_读音_用法_例句_爱词霸在线词典，解释如下： 　　太有意思啦！记忆中，bug就是臭虫，就是产品里存在质量缺陷。所以才会对软件工程师的理念和行为差异！这怎么是“正常”的呢？ 　　看了网上查询的解释，印证了记忆，更丰富了认识，原来bug也带来了不安全与资源浪费。 　　眼下，物联网、云网络等等，总之通过电子网络可以进入你的家门，看看越演越烈的插件切入吧！什么窃听、打扰、烦恼......，呵呵，小心微妙吧！ 　　变大，凸出，不就是电子产品肥胖、体虚、短命吗？电子垃圾泛滥。 　　bug，真的是太有意思啦！有时间，真要看看技术前辈们当初是怎么用了bug这个单词的？ 　　更值得深思的是电子产品制造何去何从？

       对于每个程序员来说，不犯错误的可能性是没有的，但是通过不断的经验积累，就能有意识主动避免了很多错误，慢慢的错误也就少了，错误一般分为三种： 1.编译出错        这种错误是编译时，编译器报告出来的，刚进入编程是最容易犯。这只是语法错误，等到有了一些经验之后，还是会犯这样的错误，不过会少得多，而且你能更快地发现错误原因。等到经验更丰富之后你就会觉得，语法错误是最简单最低级的错误，编译器的错误提示也就那么几种，即使错误提示是有误导的也能够立刻找出真正的错误原因是什么。相比下面两种错误，语法错误解决起来要容易得多。 2.运行出错         编译器检查不出这类错误，仍然可以生成可执行文件，但在运行时会出错而导致程序崩溃。一般这种错误容易重现，有丰富调试经验的人也容易找出问题所在。所以真正的程序员必须具有丰富的软件调试经验。 3.逻辑出错        这类错误是比较难发现的，编译和运行都会很顺利，看上去也不产生任何错误信息，但是程序没有干它该干的事情，而是干了别的事情。特别是一些边界或者临界错误，他们不会随便发生，想要重现来寻找问题是有一定难度的，为了找这种问题，有时不得不审视一行行源码漏洞可能。        要避免臭虫，这自然就和之初软件设计有莫大的关系，一个简单软件功能，也可以有千奇百怪的不同实现方式，但一种比较简洁的方式去实现，就能避免很多的臭虫。 简洁并不是简单。 例如有一个双向链表 typedef struct node *link; struct node {    // 链表成员结构体         link prev, next;         unsigned char item; }; link head = NULL；    // 链表头 void insert(link p)    // 添加成员 {         p-next = head;         if (head)                 head-prev = p;         head = p;         p-prev = NULL; } link delete(link p)    // 删除成员 {         if (p-prev)                 p-prev-next = p-next;         else                 head = p-next;         if (p-next)                 p-next-prev = p-prev;         return p; } 现加入一个新的功能，要求每个链表成员具有10分钟生存期，每分钟将调用checkOverTime函数将表中超过时间成员剔除。 初眼看到这个问题，可能很多程序员觉得很EASY，没多想就开始直接编写代码。有兴趣的可以自行先做，在看看下面本人的实现，比较一下有何差别。 . . . . . . . . . . . . 首先思考，链表成员现在具有时间属性，故成员结构体需要增加一个时间属性。 struct node {    // 链表成员结构体         link prev, next;         unsigned char item;         unsigned long time; }; 但如何来使用这个变量呢？ 也许有人就开始这么简单折腾了，在insert函数加入p-time = 10;编写下面函数 void checkOverTime(void) {     link p = head;     while(p != NULL) {         p-time--;         if(p-time == 0) {             delete(p);         }         p = p-next;     } } 这么做确实很简单，也很好，看不出有任何错误问题。但是否这就是最好的做法呢？ 其实再深入思考一下，这么遍历整个列表，如果列表成员数少，确实是一种不错做法，但是成员很多的情况下，checkOverTime函数每秒检查调用，是否可取就得很好斟酌了，它也许就成为一条臭虫。         我们仔细考虑到成员的加入，这不就是按照时间先后顺序进行插入吗？如果将time变量用来记录当前加入的时间，其实就只需检查最早插入成员是否超时，一旦没有超时，后面也就没有必要进行检查了。但是time记录什么，又会是一个很考究的问题，如果当前是linux系统，清楚jiffies值的含义，记录当时jiffies值将是一个最佳的选择。对双向链表作了些修改补充，那么最后的源码： typedef struct node *link; struct node {    // 链表成员结构体         link prev, next;         unsigned char item;         unsigned long time;         //... }; typedef struct {     link head, tail; } tag_list; tag_list list = {NULL,NULL};    // 链表 void insert(link p)    // 添加成员 {         p-recv = list.tail;         p-next = NULL;         if (list.tail == NULL) {                 list.head = p;                 list.tail = p;         } else {                 list.tail-next = p;                 list.tail = p;         }         p-time = jiffies; } link delete(link p)    // 删除成员 {         if (p-prev == NULL) {                 list.head = p-next;                 list.head-prev = NULL;         } else {                 p-prev-next = p-next;         }         if (p-next == NULL) {                list.tail = p-prev;                list.tail-next = NULL;         } else {                 p-next-prev = p-prev;         }         return p; } void checkOverTime(void) {     link p;     p = list.head;     while(p != NULL) {         if(jiffies - p-time (10 * 60 * HZ)) {             delete(p);             free(p);         } else break;         p = p-next;     } } 上面只是范例，实际应用还需要考虑很多其它因素，且只能在单线程上调用操作，多线程间使用还需要作重入保护问题的考虑。