Segfault only with optimization

[jacob navia]

There is a guy where I work who has 500K lines of code in his head
perfectly (right down to the line number).

There are islam believers that know the koran by heart.
There are christians that know the bible by heart (down to
the line number)

Human memory can be wasted in a thousand ways. Thanks for confirming
it.

Of course, I've never seen anyone else like him.

Obviously. Not everybody wants to waste effort in a stupid
thing like that guy does.

WHAT IS THE USE?

none

 

[santosh]

There are islam believers that know the koran by heart.
There are christians that know the bible by heart (down to
the line number)

Human memory can be wasted in a thousand ways. Thanks for confirming
it.



Obviously. Not everybody wants to waste effort in a stupid
thing like that guy does.

WHAT IS THE USE?

none

Er, guaranteed job? Peer admiration?

 

[Ed Prochak]

How the hell do you know that there is a buffer
overrun if the output is not affected?

This points out that blind testing is never sufficient to prove
correctness of a program. In the data set used in test the program
seems to run fine, but a different data set in production causes it to
crash. The bug (buffer overrun or whatever) was always there. It just
was not manifested in test. Not that using the debugger would not have
helped since the data set used in the debugging session was the test
data.

So how do you know the bug is there BEFORE getting it in production?
Code reviews are one more tool. Note: this requires READING someone
else's code. Amazing how we get back to that. The review might at
least suggest a test case that triggers the bug.

To KNOW that there is a buffer overrun the program MUST
do something it should not do, i.e. produce an output
that is different than the expected output

You can find these bugs by inspection o9f the code (if you know what
to look for, ie experience).

If the output of the program is normal you have NO WAY
to know there is a buffer overrun.

Not from the test. Not even a test with a debugger. You find this the
hard way in production, OR by inspecting the code (There's that Read
the code situation again).

And if you hook a debugger and see some buffer being
overrun that *is* output of course.

IF you see the overrun in the debugger.

What I mean is that such sentences are not helpful to the OP.
And we should try to be less patronizing with newcomers and
people that ask questions. I am sure the OP knows that it is the
programmer that debugs the program. He was asking us to help him
to do that, not to answer him

just do it pal...

You snipped his suggestion to reduce the program to a smaller version
that still shows the bug. So stop harping on people to do what they
already are doing.

Ed

 

[Ed Prochak]

What is the definition of "correct"? A computer program
is simply a machine for computing some function on a set
of strings from some alphabet. If the output is as expected
for all possible inputs, then the program accurately models
the function, and is thus correct. However, if it contains
a programming error, it is very likely that it does not
produce correct output on all possible inputs, but it
is generally not feasible to check all possible inputs.

Not by testing.

So, Jacob is right in the sense that the output is the
only thing that matters in an academic sense of determining
the correctness of the program, and Santosh is right in
the practical sense that a program that contains a buffer
overflow will probably generate incorrect output on some
input string. Can't we all just get along?

Jacob is wrong because he thinks the only way of finding bugs is to
execute the code and trigger the bug. Various code review methods can
find many bugs that testing can easily miss. Unit testing and code
reviews, and static code analyzers and system integration testing and
system design reviews and whatever other tools you want to use are all
helpful for producing code that meets the requirements.

It is not an either or issue, except for a few folks including Jacob.
ED

 

[John Bode]

Interesting interesting...

Can you name any other measure that doesn't rely on
output?

Using a psychic medium is not allowed.

Not to put words in Peter's mouth, but I think he means that just
because it compiles without any warnings or errors is no guarantee
that there isn't a bug in there somewhere.

A buffer overrun won't result in a compiler warning, for example.

Deep thought.

There are whole classes of errors that a compiler is not going to
catch for you. Code can be syntactically and semantically rock-solid,
yet still totally wrong.

 

[santosh]

Not by testing.


Jacob is wrong because he thinks the only way of finding bugs is to
execute the code and trigger the bug. Various code review methods can
find many bugs that testing can easily miss. Unit testing and code
reviews, and static code analyzers and system integration testing and
system design reviews and whatever other tools you want to use are all
helpful for producing code that meets the requirements.

It is not an either or issue, except for a few folks including Jacob.

I guess that Willem was making an epistemological point. On an abstract
Turing machine a buffer overrun would never result in an error. But in
practise of course, a buffer overrun is a bug, whether or not it
manifests in the program's output during a million runs, because there
is always a finite possibility that it might affect the very next run
of the program.

It's interesting that Jacob often accuses the "regulars" of indulging in
too much theory, but in this instance it was he who took refuge behind
empiricism to defend the notion that the output of a program is the
only way to determine it's correctness.

 

[Eric Sosman]

Interesting interesting...

Can you name any other measure that doesn't rely on
output?

I've fixed many bugs that did not affect the program's
output, but were regarded as serious enough to warrant hot
fixes or rapid-response patches.

My favorite involved a piece of code that sorted some
data so it could turn an O(N*N) search task into O(N).
Unfortunately, the sort itself ran in O(N*N*logN) time ...

(Didn't use a debugger, either. A profiler told me
where the time was going, and code-reading did the rest.)

 

[CBFalconer]

.... snip ...

The operating system kernel in question is over 13,000 lines of C
code. Students in the course add about 5,000 lines of their own
code to it. Not what I'd consider a large program, or even
medium size, but well above the 2,000 lines that Jacob says a
person can debug without a debugger. I developed the kernel, and
the reference solutions, without using a debugger.

I just did a rough line count on two of my packages, hashlib and
nmalloc. I found both added up to about 2500 lines. Now I avoid
extra lines, and like to put multiple statements in a single line,
etc., so I suspect most writers would find those code modules to
add up to about 5000 lines each. I also think there is little
redundancy in my code. I counted the main module, the header
files, the testing files, and the accessory files (added optional
abilities).

My point is that those units have never seen a debugger. They have
seen the equivalent of printfs, and they have been debugged.

 

[CBFalconer]

There are islam believers that know the koran by heart. There
are christians that know the bible by heart (down to the line
number). Human memory can be wasted in a thousand ways. Thanks
for confirming it.


Obviously. Not everybody wants to waste effort in a stupid
thing like that guy does.

WHAT IS THE USE?

none

Well, for one thing, he probably doesn't need a printed listing.
At 50 lines per page, that adds up to 10K pages for a single
listing. It would appear fair economies are possible.

 

[jacob navia]

Well, for one thing, he probably doesn't need a printed listing.
At 50 lines per page, that adds up to 10K pages for a single
listing. It would appear fair economies are possible.

FANTASTIC FALCONER!

At this price, your whole brain is worth only a few bucks!

 

[Peter Nilsson]

What is the definition of "correct"?

There are many, but here's a topical one...

A strictly conforming program shall use only those
features of the language and library specified in
this International Standard. It shall not produce
output dependent on any unspecified, undefined, or
implementation-defined behavior, and shall not
exceed any minimum implementation limit.

You'll note that it includes one non-output criteria
that Jacob was asking for.

In 2005 I posted 21 lines of code that (at the time)
crashed gcc and lcc-win32. It had no output statements,
so was highly deterministic! It was quite simply a
declaration of an array. It was syntactically and
semantically valid, but it violated minimum limits.

but it is generally not feasible to check all possible
inputs.

Precisely. However... it _is_ generally possible to prove
program correctness without having to trial all inputs.
[Or at least write code where this is generally possible.]

So, Jacob is right in the sense that the output is the
only thing that matters in an academic sense of determining
the correctness of the program,

Ever heard of denotational semantics?

Of course, you don't have to go to that extreme, but the
fact is, there are plenty of ways to determine correctness
that don't require running the program and checking the
output.

[And yes, I've heard of the Knuth quote: "I have only
proved it correct, not tried it." ;-]

and Santosh is right in
the practical sense that a program that contains a buffer
overflow will probably generate incorrect output on some
input string.

I agree that Santosh was right, but would point out that
what he said is not the same as what you've said he
said.

 

[user923005]

There are islam believers that know the koran by heart.
There are christians that know the bible by heart (down to
the line number)

Human memory can be wasted in a thousand ways. Thanks for confirming
it.

Have you ever seen someone solve a bug in ten seconds without even
looking at the code? Larry does it all the time.

Obviously. Not everybody wants to waste effort in a stupid
thing like that guy does.

What makes you think he put effort into it? It just comes naturally
to him.

WHAT IS THE USE?

none

He's the best programmer I have ever met, and nobody else is even
close.

 

[Flash Gordon]

jacob navia wrote, On 17/03/08 23:17:

Static analysis never goes beyond the most trivial
bugs.

So you are saying that the requirements imposed on companies developing
safety critical software are a waist of time? Have you ever worked on
safety critical software, as in software which if it goes wrong can
directly lead to the loss of life?

The problem is that in medium to big sized
programs, the number of possible paths grows
exponentially. That is why static analyzers limit
themselves and prune the tree of possibilities
and because of that they can't see most of the difficult
bugs.

The professionals (and there are professional at static analysis) have a
number of methods at there disposal and various tools to automate some
of the static analysis (lint like tools being a start). I'm not saying
that static analysis is cheap (the companies we were checking out
certainly were not) but when done properly by professional (and I am not
a professional in this field) it can and does catch a lot.

If you start reading here you might learn something about what not only
can be done but is actually done in the real world
http://www.google.co.uk/search?hl=e...result&cd=1&q=software+static+testing&spell=1

 

[Kelsey Bjarnason]

FANTASTIC FALCONER!

At this price, your whole brain is worth only a few bucks!

Assuming this is the only thing his brain can store, which seems a
dubious assumption to make. Consider that just through the period of
one's typical schooling, one likely learns and retains somewhat more than
this, yet one continues to learn for the rest of one's life. Whatever
other limits the brain may have, limited storage capacity seems not to be
a significant issue.