有趣的bug [英] Interesting bug

问题描述

我刚刚修正了一个错误，这里有一些正确的学生可能会发现有用的弹药。

问题是有些代码很偶然会死带有

分段违规错误。 （并不像过去曾在这里讨论的一些错误那样罕见，但是当它被配置为积极地运用时，可能会在一夜之间运行该程序。

这个bug所在的部分。）很容易捕获错误

（使用超出此新闻组范围的编译器功能）

然后重试，重试总是有效，但是小故障仍然是

我和我合作的另一个正确的学生很讨厌。


事实证明，违规代码看起来像这样：


for（i = 0; i< num; i ++）

if（check（array [i ]））

休息;

if（check（array [i]））

继续;


数组是一个指向malloc''d数组结构的指针; check（）是

一个表达式，它将结构的一个成员与另一个值进行比较。

（如果值匹配，我们不需要再做任何事情了

next-outer循环。）


但是如果for循环未能异常退出，则退出后检查

会尝试读取malloc'空间结束时的值。


我最好的猜测是什么问题通常这不是'

问题，因为虚假价值非常不可能匹配它被检查的对象是什么&b
被允许阅读该内存

（并且没有'不要试着写信给它，但偶尔会有一个mallocd空间只是处于进程内存空间的高端并试图

读取一个通过它的几个字节将访问该进程不拥有的内存，

并且操作系统会捕获它。

这可能对下次有人有用到来并试图

声称它适用于我的系统或类似的东西。

评论？

dave


-

Dave Vandervies dj ****** @ csclub.uwaterloo.ca

欢迎来到comp.lang。 C。这里的人很挑剔。这很好 - 这意味着你可以

（通常）相信你得到的答案 - 或者至少，你可以相信答案

在几个之后出现争吵的日子。 --CLC中的理查德希思菲尔德

I just fixed a bug that some of the correctness pedants around here may
find useful as ammunition.
The problem was that some code would, very occasionally, die with a
segmentation violation error. (Not as infrequent as some bugs that
have been discussed here in the past, but maybe once in an overnight
run of the program when it was configured to aggressively exercise the
section that the bug was in.) It was easy enough to trap the error
(using compiler features that are beyond the scope of this newsgroup)
and retry, and the retry would always work, but the glitch was still
Annoying to me and one other correctness pedant I work with.

Turns out that the offending code looked something like this:

for(i=0;i<num;i++)
if(check(array[i]))
break;
if(check(array[i]))
continue;

array was a pointer to a malloc''d array of num structs; check() was
an expression that compared a member of the struct to another value.
(If the values matched, we didn''t need to do anything more in the
next-outer loop.)

But if the for loop failed to exit abnormally, the check after it exited
would attempt to read the value just past the end of the malloc''d space.

My best guess about what the problem was is that normally this wasn''t a
problem, since the bogus value was Highly Unlikely to match what it was
being checked against and the program was allowed to read that memory
(and didn''t try to write to it), but occasionally the mallocd space would
be just at the high end of the process''s memory space and attempting to
read a few bytes past it would access memory that the process didn''t own,
and the OS would trap it.
This may be useful the next time somebody comes around and tries to
claim that "It works on my system" or something similar.
Comments?
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Welcome to comp.lang.c. People here are picky. That''s good - it means you can
(generally) trust the answers you get - or at least, you can trust the answer
that emerges after a couple of days of bickering. --Richard Heathfield in CLC

推荐答案

Dave Vandervies< dj ****** @ csclub.uwaterloo.ca>潦草地写了下面的内容：

Dave Vandervies <dj******@csclub.uwaterloo.ca> scribbled the following:

我刚刚修正了一个错误，这里的一些正确性可能会发现弹药很有用。


（剪辑）

原来有问题的代码看起来像这样：
for（i = 0; i< num; i ++）
if（check（array [i]））
break;
if（check（array [i]））
继续;


（剪辑）

评论？

I just fixed a bug that some of the correctness pedants around here may
find useful as ammunition.
(snip)
Turns out that the offending code looked something like this: for(i=0;i<num;i++)
if(check(array[i]))
break;
if(check(array[i]))
continue;
(snip)
Comments?

我看到那个代码后（和在我看到你对b
$ b的内容的解释之前，警钟已经消失了。 如果for循环正常退出，

array [i]将超出范围。我很惊讶你的同事们没有一个人能够找到它。这就像一个闪烁的红灯和一个警报器说

（有效）危险，威尔罗宾逊。


-

/ - Joona Palaste（pa*****@cc.helsinki.fi）-------------芬兰-------- \

\ - http://www.helsinki.fi/~palaste ---------------------规则！ -------- /

从互联网上复制音乐的问题就像一把两把剑。

- 芬兰说唱艺术家Ezkimo

As soon as I saw that code (and before I saw your explanation of what it
did) alarm bells went off my head. "If that for loop exits normally,
array[i] will be out of bounds." I''m amazed none of your colleagues
managed to spot it. It''s like a flashing red light and a siren saying
(effectively) "Danger, Will Robinson".

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The question of copying music from the Internet is like a two-barreled sword."
- Finnish rap artist Ezkimo

[很多瑕疵]

[much snippage]

Dave Vandervies< dj ****** @ csclub.uwaterloo.ca>潦草地写下：

Dave Vandervies <dj******@csclub.uwaterloo.ca> scribbled the following:

for（i = 0; i< num; i ++）
if（check（array [i]））
break;
if（ check（array [i]））
continue;

for(i=0;i<num;i++)
if(check(array[i]))
break;
if(check(array[i]))
continue;

文章< news：c6 ********** @ oravannahka.helsinki.fi>

Joona I Palaste< pa ***** @ cc.helsinki.fi>写道：一看到那段代码（在我看到你对它做了什么的解释之前），警报就响了起来。 如果for循环正常退出，则
array [i]将超出范围。我很惊讶你的同事没有设法发现它。它就像一个闪烁的红灯和一个警报器说
（有效）危险，威尔罗宾逊。

In article <news:c6**********@oravannahka.helsinki.fi>
Joona I Palaste <pa*****@cc.helsinki.fi> writes:As soon as I saw that code (and before I saw your explanation of what it
did) alarm bells went off my head. "If that for loop exits normally,
array[i] will be out of bounds." I''m amazed none of your colleagues
managed to spot it. It''s like a flashing red light and a siren saying
(effectively) "Danger, Will Robinson".

错误通常很多在所有不相关的

干扰被删除之后更容易发现。 :-)


还可以很容易地阅读*应该*写的内容，而不是实际写的内容。如果由原始程序员完成

调试，则尤其如此。

-

In-Real-Life：Chris Torek，风河系统

盐湖城，美国犹他州（40°39.22''N，111°50.29''W）[phone]

电子邮件：忘了它 http://web.torek.net/torek/index.html

由于垃圾邮件发送者，阅读电子邮件就像在垃圾中搜索食物一样。

Errors are often a great deal easier to spot after all the irrelevant
distractions have been removed. :-)

It is also easy to read what *should* have been written, rather
than what was actually written. This is particular true if the
debugging is being done by the original programmer.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22''N, 111°50.29''W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

文章< c6 ***** *****@oravannahka.helsinki.fi>，

Joona I Palaste< pa ***** @ cc.helsinki.fi>写道：

In article <c6**********@oravannahka.helsinki.fi>,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Dave Vandervies< dj ****** @ csclub.uwaterloo.ca>潦草地写了下面的内容：

Dave Vandervies <dj******@csclub.uwaterloo.ca> scribbled the following:

我刚刚修正了一个错误，这里的一些正确的学生可能会发现这些弹药很有用。

I just fixed a bug that some of the correctness pedants around here may
find useful as ammunition.

（剪辑）

(snip)

结果证明有问题的代码看起来像这样：

Turns out that the offending code looked something like this:

for（i = 0; i< num; i ++ ）
if（check（array [i]））
break;
if（check（array [i]））
continue;

for(i=0;i<num;i++)
if(check(array[i]))
break;
if(check(array[i]))
continue;

< br（>）（snip）

(snip)

评论？

我一看到那段代码（在我看到你的解释之前）警报响起了我的脑袋。 如果for循环正常退出，则
array [i]将超出范围。我很惊讶你的同事没有设法发现它。这就像一个闪烁的红灯和一个警笛说
（有效）危险，威尔罗宾逊。

As soon as I saw that code (and before I saw your explanation of what it
did) alarm bells went off my head. "If that for loop exits normally,
array[i] will be out of bounds." I''m amazed none of your colleagues
managed to spot it. It''s like a flashing red light and a siren saying
(effectively) "Danger, Will Robinson".

我也是，我曾经找到了。 （令人难以置信的是，当你将它们缩小到几行代码时，这些问题会变得多么简单。）问题在于我们在那个

模块中有另外2500行代码用指针做了各种有趣的事情，

所以我们一直在寻找失去跟踪指针的问题，

不寻找像这样的东西。 （但我认为，如果我在问题描述中发布

2500行代码而不仅仅是
，新闻组或我的雇主都不会给我留下深刻的印象。 />
释放错误的片段。）


一旦我们有时间（因为我们正在寻找其他的东西）

部分代码反正）每隔几行添加一个检查点，我看到

哪个检查点之间发生了问题，需要大约五分钟才能确定并修复问题。

dave


-

Dave Vandervies dj ****** @ csclub.uwaterloo.ca

[S]我们有点说服我们的bug实际上是bug ，

是为什么我们偶尔会进行如此愉快的精力充沛的讨论。

- 在comp.lang.c中的理查德希思菲尔德

So was I, once I found it. (It''s incredible how much easier these
problems are to find when you''ve narrowed them down to a few lines of
code.) The problem was that we had another 2500 lines of code in that
module that were doing all sorts of interesting things with pointers,
so we were looking for problems with losing track of the pointers there,
not looking for things like this one. (But I figured that neither
the newsgroup nor my employer would be terribly impressed if I posted
2500 lines of code in my description of the problem instead of just a
paraphrase of the snippet where the bug actually was.)

Once we had the time (because we were looking for something else in that
part of the code anyways) to add checkpoints every few lines and I saw
which checkpoints the problem was happening between, it took about five
minutes to identify and fix the problem.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
[S]ome of us take a little convincing that our bugs are in fact bugs, which
is why we have such delightfully energetic discussions on occasion.
--Richard Heathfield in comp.lang.c

这篇关于有趣的bug的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！