What's the worst example of undefined behaviour actually possible?

Question

In questions about things not to do in C++ such as dereferencing a dangling pointer or calling delete twice for the same address I often see the statement that it's undefined behaviour and anything can happen - the program can overwrite the system disk or offend my parents.

What is the worst real example of undefined behaviour consequences beyond crashing the program? I don't mean cases when first data in memory is corrupted and then this data is fed somewhere and that somewhere behaves wrong, I mean cases when undefined behaviour on its own directly causes bad consequences.

Answer 1

I once accidentally delete'd a pointer twice and my computer collapsed into a singularity while flying monkeys extruded themselves from my nether regions.

Not really, but the whole point of undefined behavior is that it's, well, undefined.

This is not to be confused with defined behavior (which the standard mandates) or implementation-defined behavior (which the standard doesn't mandate but the implementation must).

The worst I've ever seen was wrong data being put into a variable which was later used (one of those "i = i++ + ++i;" moments). Nothing more serious than that unfortunately.

But bad data is serious enough, believe me.

Answer 2

"The disk can be overwritten" is kind of a joke (not a very great one but still), anyway, it is meant to emphasize the nature of the behaviour allowed for undefined operations, not necessarily the magnitude. Probably the worst result that you are ever going to see in the case of undefined behaviour is the kind of things that you would expect such as memory corruptions, hangs and so on. Although, this can lead to any kind of result in the end anyway, including maybe your harddrive being formatted, so maybe that is not such a low probability after all.

char *commandString="do something innocuous";
aFunctionWhichOverwritesTheAddressOfCommandStringToSomethingWhichFormatsTheHardDrive();
system(commandString);

Answer 3

Well, I'd say it depends on the circumstances.

If undefined behaviour causes a missile to do unexpected things, offending your parents might be the least of your problems.

Answer 4

What are the limits of your imagination?

Here's a few little disaster scenarios:

• Overwriting a critical header in your binary file format just before you save to disk?

• Rewriting part of another processes code in an unprotected environment?

• Scribbling on memory mapped IO controller registers?

Answer 5

Broadly speaking...

In a modern PC, memory protection limits the direct damage to memory within the program's memory space. The damage could be proportionate to the privileges that process has while executing on a particular system (so don't run it with root privileges if you don't have to).

On the other hand, in embedded systems using a CPU without a memory management unit, a program could overwrite the entire processor memory space, which could easily corrupt a filesystem in use, mess up CPU or peripheral registers. Pretty much anything could go wrong.

The worst I've seen is a embedded device that had a fan speed controller. If code crashed, sometimes the fans would crank up to full-speed. Such things are mitigated with careful code review and testing, as well as defensive coding for things that really matter (e.g. the fan control software doing extra integrity checks of its variables and resetting if it finds an anomaly). Using "watchdog" circuit and/or software is also a standard practice.

Answer 6

What is the worst real example of undefined behaviour consequences beyond crashing the program?

Crash (or lock up) the machine. Lose some data. Even, depending on the software, maybe toast some hardware.

FWIW as I developed a device driver for Windows 3.1 I used a diskless (i.e. without a hard drive) PC: instead it booted from floppy, loaded Netware client network drivers from the floppy, and then loaded Windows from a Netware file server. In those days (FAT, pre-NTFS) it was easy for a system crash to corrupt a local hard drive.

Answer 7

In embedded code, without a "true" operating system to protect you from your mistakes, reading or writing from randomly-set pointers could realistically cause ANY behavior the device is physically capable of -- including launching nuclear missiles and causing Armageddon, I suppose, considering the quality standard of Pentagon procurement;-).

Answer 8

The horror of undefined behavior isn't so much that the program will eat your homework, fire the nukes, or castrate you (though those are all certainly possible depending on the hardware your software is driving...) but that it is often very difficult to debug, and you will waste hours upon hours trying to figure out what went wrong after your program crashes or after you find it behaves differently on a new platform. Expressions with undefined behavior according to the language in question's standard will usually do one of the following annoying things:

• Destroy the stack, meaning you can't get a backtrace.
• Do something you don't want silently, so you don't know that something is wrong until much later; the further apart the moment when the problem is triggered from the moment when you can see its effects the more difficult it is to debug.
• Behave differently under different compilers, so your program will seem to work fine on one platform but then break in unexpected ways when you try to port.

In an ideal language, anything that would have undefined behavior is a compiler error.

Answer 9

I once had the dereference of a null pointer (which was being used to set a value) cause a vision system to whip its stepper motor around really fast, throwing parts inside the cabinet. It turned out that the stepper motor's control registers were mapped to the lowest memory addresses. That wasn't a smart choice.

-John

Answer 10

#pragma directives are implementation defined. On old versions of GCC, unrecognized pragmas would launch Emacs running a towers of hanoi simulation, or a game of NetHack.

Answer 11

Since nobody's pointed out yet, the worst that can happen is probably that nothing goes wrong and you don't notice it. Then a hacker notices it and figures out how to inject arbitrary data into your system over the network, giving them full control at the privilege level of the process that is running. They wait until your system is holding some sufficiently important information (like credit card info) or controls some sufficiently important mechanism (eg a missile, or a power grid or an mri or 10 million desktops) and then come up with some lucrative way to screw over the people running those systems.

Accidents aren't malicious, so you have luck on your side and nothing too bad is likely to happen. Security is a different matter.

Answer 12

It could open a security whole, see: Buffer overrun exploitation

Answer 13

You don't want to risk it.

Answer 14

I once accessed a double via a pointer to long long int, and right after that, the lotto ticket I bought didn't win.

What are the chances?

Answer 15

I once installed a kernel driver of the wrong version, and it forced my PC into psychedelic agony. It was more fun than harm though.

Answer 16

Okay, long after asking the question we encountered a nice example. The program would read outside the allocated buffer while preparing a packet for sending over the network.

If some memory it tried to read was not mapped into the program address space it would crash with access violation. Otherwise it would effectively send some unrelated data over the network, that data would be ignored by the recipient and both the program and the recipient would continue normally. Ironically the bug has been there for years and was not noticed until recently when the program changed from sending unrelated data to crashing.

That's so in the spirit of what user Jeremy Huiskamp answers in the accepted answer to this question. It's plain luck there was not a password or something really interesting in the memory region the program sent over the network.