Books for advanced C++ debugging

[Barry Schwarz]

[ ... ]

i not speak about standards, i speak about a real cpu
if one 386 cpu of state X(eax=1, ebx=19, ecx=20 ...)
read the binary of "add eax, ebx"
the result will be always the state of cpu
X'(eax=20, ebx=19, ecx=20 ...)

Yes, but what if what's executed is 'add eax, [ebx]' instead? If ebx
happens to point to uninitialized memory,

i see the hardware 386cpu, the memory that can read, like a system
if this system has one state

State(0)={X(eax=20, ebx=19, ecx=20 ...)
Memory={1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,1 ...}
}
if the cpu read the instruction
'add eax, [ebx]'

State(1)={X(eax=21, ebx=19, ecx=20 ...)
Memory={1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,1,...}
}
there is not UB

it is like a phisical system
if i know the position in the time 0 i know the position in the next time 1

UB in that system could be only for the fail of cpu

Except you will never know all the states. Every time you run the
program, the clock will be different. If you are running on a typical
system, you share the CPU, memory, and OS with numerous other tasks
running "simultaneously" and their states will not be the same from
one execution to the next.

If you run the program in the morning and it produces a result of 42
and in the afternoon and it produces 24 or you recompile it on an odd
numbered Thursday during a full moon and it now produces 69 or you
change compilers and it now produces 7734, there is no way for you to
define the behavior of the program. Hence, its behavior is undefined.

 

[James Kanze]

"Nick Keighley" <[email protected]> ha scritto nel messaggiothis was originally on comp.lang.c++
but discussions about Undefined Behaviour seem on-topic to
comp.lang.c as well

in a cpu can not be undefinited behaviour because if the cpu
is in the state X and it read the instruction "a" the result
will be always the state X'

Obviously, you've never worked on real hardware. CPU's have
certain rules which must be obeyed, and can have undefined
behavior if you violated them.

the same for the couple cpu-os of the cpu-os is in the state
XX and it read the instruction "a" the result will be always
the state XX'
Ditto.

UB exist only in the standards

Not really. What you can say is that most of the cases which
result in undefined behavior in the standard will still be
compiled to deterministic code on most most machines. What that
code does, however, is not defined, and can be pretty much
anything. Including behavior not recognized by the standard
(like generating a core dump, crashing the system or the
processor, formatting the hard disk, sending spam emails to half
the world...).

 

[James Kanze]

[ ... ]

it is like a phisical system if i know the position in the
time 0 i know the position in the next time 1
UB in that system could be only for the fail of cpu

Except you will never know all the states. Every time you run the
program, the clock will be different. If you are running on a typical
system, you share the CPU, memory, and OS with numerous other tasks
running "simultaneously" and their states will not be the same from
one execution to the next.

If you run the program in the morning and it produces a result
of 42 and in the afternoon and it produces 24 or you recompile
it on an odd numbered Thursday during a full moon and it now
produces 69 or you change compilers and it now produces 7734,
there is no way for you to define the behavior of the program.
Hence, its behavior is undefined.

The actual speed of the gates on the chip will depend on the
temperature. Depending on this speed, the results of accessing
"inexistant" memory may vary. (Just to cite one case I've
actually encountered. The program caused the machine to hang or
not, depending on how long the machine had been turned on.)

 

[James Kanze]

details asynchronous exceptions.

OK. It's true that things like internal errors in the virtual
machine would be asynchronously. (The C++ standard says nothing
about what happens when there is a problem in the execution
platform, so it's undefined behavior. In practice, of course,
regardless of what the language specification says, if the
execution platform doesn't work correctly, you can forget the
language standard.) The case of Thread.stop() is a special
case; they've explicitly provided a means of creating an
asynchronous exception in another thread. Current C++ doesn't
recognize threads, but I don't think that the next version
(which does support threading) will have anything similar. (The
current Java specification deprecates Thread.stop().)

I haven't thought it through thoroughly enough, but at the
very least it would be in practice impossible to write correct
code in the face of asynchronous exceptions, and may be
in-fact impossible to write it. Depends on exactly what they
call "a transfer of control" and "statements" in regards to
when an asynchronous exception can be raised. However, this is
getting a little off topic, so I guess I'll leave it at that.

Writing exception safe code is on topic, and the nothrow
guarantee for a few, primitive functions is necessary in order
to do so.

 

[Joshua Maurice]

OK.  It's true that things like internal errors in the virtual
machine would be asynchronously.  (The C++ standard says nothing
about what happens when there is a problem in the execution
platform, so it's undefined behavior.  In practice, of course,
regardless of what the language specification says, if the
execution platform doesn't work correctly, you can forget the
language standard.)  The case of Thread.stop() is a special
case; they've explicitly provided a means of creating an
asynchronous exception in another thread.  Current C++ doesn't
recognize threads, but I don't think that the next version
(which does support threading) will have anything similar.  (The
current Java specification deprecates Thread.stop().)


Writing exception safe code is on topic, and the nothrow
guarantee for a few, primitive functions is necessary in order
to do so.

From that little except, I'm not clear on exactly when a Java
asynchronous exception can be thrown. I'm not sure what my no-throwing
primitives are, if any. Then again, it's sort of an anal point. As you
noted, if the platform encounters a problem it can't handle, your
program is FUBAR anyway. I do strongly dislike how the stack will be
unwound if the JVM hits some kinds of internal errors (see finally
blocks).

 

[Martin Eisenberg]

And last but not least: Is there a good book in C++ debugging?

I don't know if it's good but I just came across this reference:

Zeller - Why Programs Fail
http://www.whyprogramsfail.com/


Martin