Most Interesting Bug Track Down

[Chris Dollin]

Mark F. Haigh wrote:

... A single additional line of assembly code. Aparrently a
preprocessor macro in a header file far, far away had decided to use
the value of __LINE__ for field debugging of production code. Since
the CPU was an ARM7, and the ARM instruction set can only load a 12 bit
immediate IIRC,

(fx:OT
An eight-bit value on an even bit boundary in the 32-bit word: the
12-bit immediate value is the 8-bit field and a 4-bit /rotate/
count. So not only can the value be at the bottom, middle, or
top of the word, it can be split between the top and the bottom!
)

 

[lawrence.jones]

and another function
whatever( ..., short cmd);
which needed, among other things to send the 2-byte cmd
to the chip. Endianness was not an issue, as my program
was specific to MC680x0.

I tried to send the bytes with
send_to_chip(&cmd, 2);
but it didn't work. Eventually I found that "&cmd" was pointing
2 bytes *before* the 2-byte cmd on the stack.

That was a common behavior in pre-ANSI compilers. Since char and short
arguments are promoted to int (and float arguments are promoted to
double), many compilers just rewrote the argument declarations as the
widened type (much as array arguments declarations are rewritten as
pointer declarations). ANSI outlawed that practice, requiring the
arguments to have their explicitly declared type, not the widened type.

-Larry Jones

What better way to spend one's freedom than eating chocolate
cereal and watching cartoons! -- Calvin

 

[Barry Schwarz]

On Sat, 25 Nov 2006 09:28:21 -0500, Eric Sosman

snip

<off-topic>

Wikipedia's article on IEFBR14 makes amusing reading. The
original one-instruction program had a bug, which must set some
kind of unenviable standard for "fault density:" one bug per
machine instruction! Not only that, but the fix had a bug, and
the fix to the fix had a bug, and it wasn't until the fourth
version of IEFBR14 that the program "did nothing" correctly.

The final version had three times as many lines of source as
the first, executed three times as many instructions, and occupied
eight times as much memory. Code bloat wasn't invented in Redmond.

1 - It's not bloat if the additional code is necessary to make the
program run correctly. A square root function that works only for
perfect squares can be much smaller than one that works in general.
The additional code is not bloat but necessary to correct
deficiencies. A square root function that generates logs or primes
contains bloat.

The minimum size of a program on an IBM mainframe is eight bytes (due
to alignment restrictions). Since that is also the current size of
IEFBR14, it probably didn't grow much. Since the program only
contains two instructions and the mainframe does not have fractional
instructions, it didn't grow by a factor of three. The original
instruction is still in the code so it couldn't have been too
incorrect.

I think the Wikipedia article may suffer from a certain lack of
accuracy.


Remove del for email

 

[Richard Heathfield]

Barry Schwarz said:

I think the Wikipedia article may suffer from a certain lack of
accuracy.

Don't bother fixing it. If you do, it'll probably be broken again by
tonight.

 

[Gordon Burditt]

Code bloat wasn't invented in Redmond.

But I bet they tried to patent it.

The minimum size of a program on an IBM mainframe is eight bytes (due
to alignment restrictions). Since that is also the current size of
IEFBR14, it probably didn't grow much. Since the program only
contains two instructions and the mainframe does not have fractional
instructions, it didn't grow by a factor of three. The original
instruction is still in the code so it couldn't have been too
incorrect.

But under MVS on my college's 360/50, you couldn't run a program
in under 8k without running out of memory. Or perhaps it was IN
8k, and you had to use at least 12k. I tried it (due to the billing
including a function of memory requested) and got a lovely core
dump. I think that had something to do with a 4k page size and two
different subpools and needing space for an initial save area.

 

[Barry Schwarz]

But I bet they tried to patent it.


But under MVS on my college's 360/50, you couldn't run a program
in under 8k without running out of memory. Or perhaps it was IN
8k, and you had to use at least 12k. I tried it (due to the billing
including a function of memory requested) and got a lovely core
dump. I think that had something to do with a 4k page size and two
different subpools and needing space for an initial save area.

The amount of memory a program requires to execute is a different
metric than the size of the program itself. While normally the former
would be larger than the latter, MVS supported programs in overlay
format where it need not be true.

My college used a 360/40 so we are probably in the same generation.
While I can still remember what it looked like, I don't have a clue as
to the minimum region size.


Remove del for email

 

[Spiros Bousbouras]

On Sat, 25 Nov 2006 09:28:21 -0500, Eric Sosman

snip


1 - It's not bloat if the additional code is necessary to make the
program run correctly. A square root function that works only for
perfect squares can be much smaller than one that works in general.
The additional code is not bloat but necessary to correct
deficiencies. A square root function that generates logs or primes
contains bloat.

The minimum size of a program on an IBM mainframe is eight bytes (due
to alignment restrictions). Since that is also the current size of
IEFBR14, it probably didn't grow much. Since the program only
contains two instructions and the mainframe does not have fractional
instructions, it didn't grow by a factor of three. The original
instruction is still in the code so it couldn't have been too
incorrect.

I think the Wikipedia article may suffer from a certain lack of
accuracy.

Most of what you're quoting is Eric Sosman's comments
rather than claims found in the Wikipedia article. The article
does say that the number of executed instructions trippled
in size. Are you sure the final version of the programme
appearing in the article (which by the way is not the final
version of the programme itself) only contains 2 instructions ?

 

[Barry Schwarz]

Most of what you're quoting is Eric Sosman's comments
rather than claims found in the Wikipedia article. The article
does say that the number of executed instructions trippled
in size. Are you sure the final version of the programme
appearing in the article (which by the way is not the final
version of the programme itself) only contains 2 instructions ?

The "final" version at http://en.wikipedia.org/wiki/IEFBR14 shows the
program occupying 16 bytes, 12 of which do not appear in the actual
program. The program on my OS/390 2.10 system occupies 8 bytes, of
which 4 contain the code for the two instructions and the other 4 are
filler to meet the alignment requirements. The same is true for
several previous versions of the operating system.


Remove del for email