40
\$\begingroup\$

Write programs that produce crazy, obscure, ridiculous, or just plain nutty runtime errors. Obfuscation and golfitude (shortness) not required.

  • solutions that look like they should work fine are better.
  • solutions that look like they should break one way but break another are better.
  • solutions that are nondeterministic are better as long as they are reproducible sometimes.
  • solutions with long distance between error cause and manifestation are better.
  • bonus points for producing errors that should be impossible.
  • bonus points for errors that crash the runtime (like making python segment fault) or operating system.

The unit of score shall be upvotes.

Addendum 1

Compiler misbehaviors are fine too.

\$\endgroup\$

closed as too broad by Doorknob Nov 24 '15 at 14:59

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    \$\begingroup\$ Making Python segfault is easy: import sys; sys.setrecursionlimit(~-2**31); x=lambda x:x(x); x(x); \$\endgroup\$ – marinus Aug 4 '12 at 1:53
  • \$\begingroup\$ Peter: whoops. I repurposed the question half way through writing it :S \$\endgroup\$ – Wug Aug 5 '12 at 23:48
  • \$\begingroup\$ ...what about malbolge or INTERCAL? i'm pretty sure they'd have some pretty insane errors, probably can do it with a single char as well. \$\endgroup\$ – acolyte Aug 6 '12 at 21:26
  • 1
    \$\begingroup\$ This is definitely the best link to go for the solution: destroyallsoftware.com/talks/wat :-) \$\endgroup\$ – seri Aug 13 '12 at 17:50
  • 1
    \$\begingroup\$ Possible duplicate of stackoverflow.com/q/1146014/736054. \$\endgroup\$ – Konrad Borowski Jan 6 '14 at 12:29

32 Answers 32

69
\$\begingroup\$

The obligatory PHP one (which still hasn't been fixed as of 5.4):

<?::

Outputs:

Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM on line 1

Whaa?

\$\endgroup\$
  • 11
    \$\begingroup\$ I do like this one. It might be my favorite error message. Apart from the one time my friend tried to boot his windows laptop to the recovery partition, and it turned the entire screen into a white box with giant red letters spelling "ERROR". \$\endgroup\$ – Wug Aug 4 '12 at 6:50
  • 4
    \$\begingroup\$ Deliberate, but weird nevertheless: "Paamayim Nekudotayim would, at first, seem like a strange choice for naming a double-colon. However, while writing the Zend Engine 0.5 (which powers PHP 3), that's what the Zend team decided to call it. It actually does mean double-colon - in Hebrew!" php.net/manual/en/language.oop5.paamayim-nekudotayim.php \$\endgroup\$ – Jon Gauthier Aug 6 '12 at 1:50
  • 12
    \$\begingroup\$ @HansEngel: Yes, it means double-colon in Hebrew. Using English for every token except this one makes sense because...? I guess I'd just have to ask the PHP team. \$\endgroup\$ – Ry- Aug 6 '12 at 2:18
  • \$\begingroup\$ Sorry dude, but you are simply calling the static method/variable '' (empty string) from the class '' (empty string) \$\endgroup\$ – Ismael Miguel Mar 6 '14 at 23:00
  • 1
    \$\begingroup\$ @IsmaelMiguel: It’s confusing because of the Hebrew, not because it’s wrong. \$\endgroup\$ – Ry- Mar 6 '14 at 23:01
61
\$\begingroup\$

Gcc compile error:

int main()
{
        long long long a;
}

error: long long long is too long for GCC

\$\endgroup\$
  • 6
    \$\begingroup\$ They just knew that somebody will try long long long, if long and long long are both valid. \$\endgroup\$ – Konrad Borowski Jan 6 '14 at 12:18
  • 3
    \$\begingroup\$ I think "a is too long!" would have been a better error message, but this is still a great answer. \$\endgroup\$ – Wug Jan 13 '14 at 11:17
52
\$\begingroup\$

Windows Command Prompt

If you're happy and you know it clap your hands!

Output:

happy was unexpected at this time.

\$\endgroup\$
  • 1
    \$\begingroup\$ I tried that command to check the result, but it displayed ^V :( hard days these \$\endgroup\$ – Fabricio Jun 6 '14 at 10:40
  • 7
    \$\begingroup\$ @Fabricio, was that just from pressing CTRL+V to paste the line? In Command Prompt, the keyboard "shortcut" for paste is ALT+SPACE, E, P. \$\endgroup\$ – Hand-E-Food Jun 9 '14 at 23:20
42
\$\begingroup\$

PHP

$ cat error.php 
<?php
function echo_string(string $string) {
    echo $string;
}
echo_string("Hello, world!");
$ php error.php 
PHP Catchable fatal error:  Argument 1 passed to echo_string() must be an instance of string, string given, called in error.php on line 5 and defined in error.php on line 2

You cannot pass a string to a function, you have to pass a string instead!

Update: This code is NOT an error in PHP 7. Hover on/click/touch a spoiler to check why (contains spoilers about how the code works).

A new feature known as scalar type declarations was added in PHP 7. This feature allows using scalar types in function declarations.

\$\endgroup\$
  • 6
    \$\begingroup\$ What the f*** php. \$\endgroup\$ – Wug Jan 13 '14 at 11:18
  • 7
    \$\begingroup\$ PHP is trying to get the class string (which is valid). Type-hinting (that thing that you are doing) only works for classes. Since the class string doesn't exist, it throws an error. \$\endgroup\$ – Ismael Miguel Mar 6 '14 at 22:52
  • \$\begingroup\$ You can check here yours code working properly: sandbox.onlinephpfunctions.com/code/… \$\endgroup\$ – Ismael Miguel Mar 6 '14 at 22:58
  • 2
    \$\begingroup\$ @IsmaelMiguel: Yeah, I understand why it happens, but the error is still ridiculous in my opinion. \$\endgroup\$ – Konrad Borowski Mar 7 '14 at 15:48
  • 1
    \$\begingroup\$ Then try array(''=>array()''). \$\endgroup\$ – Ismael Miguel Mar 7 '14 at 18:13
32
\$\begingroup\$

bash

$ echo "Hello, world!"
bash: !": event not found

And you would think that bash would accept a simple "Hello, world!" program.

\$\endgroup\$
  • \$\begingroup\$ Explanation of this: strings passed in double quotes as arguments to programs in bash are expanded, meaning `echo hi` turns into hi inside of the double-quoted string. ! is used as a prefix to event designators. So, bash tries to evaluate !", but can't find the referenced event. \$\endgroup\$ – Mego Nov 24 '15 at 13:01
31
\$\begingroup\$

Python 2.7

# Look I'm actually coding: see my happy face?
print ':)'

Generates the rather unhelpful:

SyntaxError: encoding problem: with BOM

How can a simple comment generate an error?

\$\endgroup\$
  • 12
    \$\begingroup\$ In latest Python interpreters: if first 2 lines starts with # and contain string coding: next word used as encoding description \$\endgroup\$ – AMK Jan 6 '14 at 20:06
31
\$\begingroup\$

Mathematica

When using Mathematica to create graphical output, one sometimes triggers error messages formatted according to specifications being used in the program itself. Here is a trivial example.

Rotate[f/0, .6]

enter image description here

\$\endgroup\$
26
\$\begingroup\$

TI-89 Graphing Calculator

I discovered this when learning about implicit differentiation in high school calculus. If you input:

d(xy+x=0,x)

You get the following:

1 = 0

With this caveat, printed in tiny letters at the bottom of the screen:

Warning: May produce false equation

This happens because xy is not interpreted as x * y, but rather as its own symbol, xy.

Oddly, if you do d(xy=0,x), you get 0 = 0 with the same warning.

\$\endgroup\$
22
\$\begingroup\$

You can make the Haskell compiler's brain explode:

C:\Windows\system32>ghci
...
Prelude> :set -XExistentialQuantification
Prelude> data Foo = forall a. Foo a
Prelude> let foo f = 1 where Foo a = f

<interactive>:4:21:
    My brain just exploded
    I can't handle pattern bindings for existential or GADT data constructors.
    Instead, use a case-expression, or do-notation, to unpack the constructor.
    In the pattern: Foo a
    In a pattern binding: Foo a = f
    In an equation for `foo':
        foo f
          = 1
          where
              Foo a = f
Prelude>
\$\endgroup\$
21
\$\begingroup\$

Ruby

Rules abuse.

class StandardError

  def to_s
    words = File.open('/usr/share/dict/words'){|f|f.readlines.map &:chop}.sample(100)
    words.last.capitalize!
    super.gsub(/\w+/){words.pop}
  end

  to_s(3)

end

If run on OSX, produces, e.g.

$ ruby weird_runtime_error.rb 
weird_runtime_error.rb:9:in `to_s': Sculpturation contingence explicate tappet(phonendoscope ethopoeia nannandrous) (ArgumentError)
    from weird_runtime_error.rb:9:in `<class:StandardError>'
    from weird_runtime_error.rb:1:in `<main>'
\$\endgroup\$
  • 6
    \$\begingroup\$ What on earth does that mean? \$\endgroup\$ – TRiG Mar 15 '14 at 4:22
  • 8
    \$\begingroup\$ It means wrong number of arguments(1 for 0). It is expressing that through a language that is generated lazily and stochastically using English vocabulary with little regard for linguistic plausibility. \$\endgroup\$ – histocrat Mar 17 '14 at 20:50
20
\$\begingroup\$

DOS Prompt

c:\>make love

gives you

Fatal Error: 'love' does not exist. Don't know how to make it.

Stumbled upon this while I was trying to insult my computer for being uncooperative. Made me kinda sad for a while until I found out, that this only happens if love does not exist. If it exists he will gladly make it.

\$\endgroup\$
  • 5
    \$\begingroup\$ This is actually dedicated to make utility, not DOS itself. \$\endgroup\$ – Vovanium Jun 6 '14 at 15:46
  • 1
    \$\begingroup\$ I get: make: *** No rule to make target 'love'. Stop. \$\endgroup\$ – agtoever Oct 23 '15 at 20:22
  • \$\begingroup\$ @agtoever You are running the wrong make. \$\endgroup\$ – Navin Nov 11 '15 at 5:54
  • \$\begingroup\$ I get: make: Fatal error: Don't know how to make target 'love' but that's on Unix. On DOS, I get make is not recognized as an internal or external command, operable program or batch file. \$\endgroup\$ – lebatsnok Nov 23 '15 at 13:42
16
\$\begingroup\$

Bash (Quine error)

This error is a Quine in Bash!

$ bash: bash:: command not found...
bash: bash:: command not found...

Of course you must have the relevant locale (english here).

\$\endgroup\$
  • 1
    \$\begingroup\$ Mine did not print the ... at the end, so I had to omit it in the original input as well. \$\endgroup\$ – Zev Eisenberg Jun 8 '14 at 17:57
16
\$\begingroup\$

CSH

A really classical csh joke:

% make fire?
make: No match.
\$\endgroup\$
15
\$\begingroup\$

Bash - accurate recreation of a rare historical error message

echo -ne $(tail -n +257 /usr/src/linux*/drivers/char/lp.c | head -1 | cut -d '"' -f 2 | sed 's/%d/0/')

Output:

lp0 on fire

Requires the linux kernel source to be unpacked in the usual place.

Fun fact: i once received this message in earnest, when running an old ribbon printer.

\$\endgroup\$
  • \$\begingroup\$ Is it an error message, or just an output of a program? \$\endgroup\$ – yo' Oct 23 '15 at 18:51
  • 1
    \$\begingroup\$ @yo' the bash one-liner itself returns successfully, but the output it produces is a genuine error message; the script simply pulls the error from the printer driver source. \$\endgroup\$ – Riot Oct 23 '15 at 20:12
  • \$\begingroup\$ ah ok, that's a tricky thing to do :-) \$\endgroup\$ – yo' Oct 23 '15 at 20:12
  • 1
    \$\begingroup\$ Incidentally, the error means it's continuing to print to a paper jam, which is a fire hazard. \$\endgroup\$ – Joshua Nov 20 '15 at 4:26
13
\$\begingroup\$

C(++)

If compile-time errors count here's one (assuming a file named "crash.c").

#include "crash.c"

int main(){ return 0; }

It fills the screen with this upon compilation (have Ctrl-C ready)

                 from crash.c:1,
                 from crash.c:1:
crash.c:3:1: error: redefinition of ‘main’
crash.c:3:1: note: previous definition of ‘main’ was here
In file included from crash.c:1:0,
                 from crash.c:1,
                 from crash.c:1,

Another snippet which compiles perfectly well (no warnings under -Wall and illustrates the beautiful type safety of C </s>

#include <stdio.h>
int i;

int main(){
  sprintf(NULL, "%s", (char *) (void *) (1/i));
  return 0;
}

Running it gives:

Floating point exception (core dumped)
\$\endgroup\$
13
\$\begingroup\$

Ruby

Feel like it's weird that this can happen in a high-level language.

$*<<$*<<$**$/

produces

ArgumentError: recursive array join
\$\endgroup\$
10
\$\begingroup\$

This is very old, but for those who remember BCPL,

GET "LIBHDR"

LET START() = VALOF 
$8
        RESULTIS 0
$)

would complain

$8
 ^
"( ) or 8 expected"
\$\endgroup\$
10
\$\begingroup\$

R

This is technically not an error but a warning but nevertheless it's ridiculous, and occurs for completely esoteric reasons.

[[EDIT]] It seems that the cause of some parts of the funny warnings resides in RStudio rather than R per se, so it's less interesting than I first thought. The first example i.e plot(1:2, NotAGraphicalParameter = "ignore.me") is, however, still reproducible in "naked" R and is funny enough on its own right.[[/EDIT]]

> plot(1:2, NotAGraphicalParameter = "ignore.me")
# produces a nice scatterplot with two points, [1,1] and [2,2]
Warning messages:
1: In plot.window(...) :
  "NotAGraphicalParameter" is not a graphical parameter
2: In plot.xy(xy, type, ...) :
  "NotAGraphicalParameter" is not a graphical parameter
3: In axis(side = side, at = at, labels = labels, ...) :
  "NotAGraphicalParameter" is not a graphical parameter
4: In axis(side = side, at = at, labels = labels, ...) :
  "NotAGraphicalParameter" is not a graphical parameter
5: In box(...) : "NotAGraphicalParameter" is not a graphical parameter
6: In title(...) : "NotAGraphicalParameter" is not a graphical parameter
> plot(2:3)
# another nice scatterplot: [2,2] and [3,3] 
# but there should be nothing wrong this time!
# however ...
There were 12 warnings (use warnings() to see them)
> warnings()
Warning messages:
1: "NotAGraphicalParameter" is not a graphical parameter
2: "NotAGraphicalParameter" is not a graphical parameter
3: "NotAGraphicalParameter" is not a graphical parameter
4: "NotAGraphicalParameter" is not a graphical parameter
5: "NotAGraphicalParameter" is not a graphical parameter
6: "NotAGraphicalParameter" is not a graphical parameter
7: "NotAGraphicalParameter" is not a graphical parameter
8: "NotAGraphicalParameter" is not a graphical parameter
9: "NotAGraphicalParameter" is not a graphical parameter
10: "NotAGraphicalParameter" is not a graphical parameter
11: "NotAGraphicalParameter" is not a graphical parameter
12: "NotAGraphicalParameter" is not a graphical parameter
# but let's try once more:
> plot(2:3)
# yup. no warnings this time. we had to do it twice

It's like R remembers our insults. But not for long.

I can't really explain why this happens - but it is reproducible. Actually it occurs every time when you supply some "not a graphical parameter" to plot 1, and then do a plot 2 in a completely impeccable way. It is especially funny that we get 12 "not a graphical parameter" warnings for the second plot but only 6 for the first one. Another funny thing is that if you supply "not a graphical parameter" with a value NULL then no condition is thrown:

plot(1:2, Nonsense=NULL)
# no warnings
# however
plot(1:2, Nonsense="gibberish")
# gives the usual 6-pack of warnings

And to get even more ridiculous, let's draw some lines on top of the previously drawn plot:

plot(1:2)
# you will see the number of warnings growing with each line:
lines(1:2, 1:2, mumbo = 1)
lines(1:2, 1:2, jumbo = 2)
lines(1:2, 1:2, bimbo = 3)
lines(1:2, 1:2, cucaracha = 4)
lines(1:2, 1:2, karaoke = 5)
lines(1:2, 1:2, radiogaga = 6)
lines(1:2, 1:2, reptiles = 7)
lines(1:2, 1:2, cowsonmoon = 8)
lines(1:2, 1:2, stainlessSteelLadderToTheMoon = 9)
lines(1:2, 1:2, frambuesa = 10)
lines(1:2, 1:2, fresa = 11)
lines(1:2, 1:2, limonYNada = 12)
lines(1:2, 1:2, slingsAndArrows = 13)
# ... and now you have 25 warnings:
warnings()

Warning messages:
1: "mumbo" is not a graphical parameter
2: "jumbo" is not a graphical parameter
3: "bimbo" is not a graphical parameter
4: "cucaracha" is not a graphical parameter
5: "karaoke" is not a graphical parameter
6: "radiogaga" is not a graphical parameter
7: "reptiles" is not a graphical parameter
8: "cowsonmoon" is not a graphical parameter
9: "stainlessSteelLadderToTheMoon" is not a graphical parameter
10: "frambuesa" is not a graphical parameter
11: "fresa" is not a graphical parameter
12: "limonYNada" is not a graphical parameter
13: "mumbo" is not a graphical parameter
14: "jumbo" is not a graphical parameter
15: "bimbo" is not a graphical parameter
16: "cucaracha" is not a graphical parameter
17: "karaoke" is not a graphical parameter
18: "radiogaga" is not a graphical parameter
19: "reptiles" is not a graphical parameter
20: "cowsonmoon" is not a graphical parameter
21: "stainlessSteelLadderToTheMoon" is not a graphical parameter
22: "frambuesa" is not a graphical parameter
23: "fresa" is not a graphical parameter
24: "limonYNada" is not a graphical parameter
25: In plot.xy(xy.coords(x, y), type = type, ...) :
  "slingsAndArrows" is not a graphical parameter

This should not win big time unless there is no justice.

\$\endgroup\$
  • 1
    \$\begingroup\$ What version of R are you using? Because i can't reproduce the pack of warnings you're getting with plot(2:3) right after using plot(1:2, NotAGraphicalParameter = "ignore.me"). DId you redefine something in your .Rprofile? \$\endgroup\$ – plannapus Jan 9 '14 at 8:27
  • 1
    \$\begingroup\$ looks like this is specific to running R in Rstudio (both on Windows and Ubuntu) but doesn't occur when you run R in linux terminal or windows Rgui. \$\endgroup\$ – lebatsnok Jan 9 '14 at 8:35
  • \$\begingroup\$ I think I have seen something similar with modelling functions (lm or glm) without Rstudio but can't reproduce it now. (That is, earlier warnings were coming up when not relevant any more.) \$\endgroup\$ – lebatsnok Jan 9 '14 at 8:40
9
\$\begingroup\$

Windows Command Script

WARNING, this is a fork bomb!

This will output garbage questions about quitting if you try to quit the console in any way.

%0|%0|%0

Bonuses:

  • Will make the system pretty much unusable until restart
  • Prevents quitting the script, which should be impossible
\$\endgroup\$
  • 2
    \$\begingroup\$ Danger Will Robinson? \$\endgroup\$ – Jacob Mar 11 '14 at 21:54
7
\$\begingroup\$

q insults you

q)`u#1 1
'u-fail
q)

```u#`` tells q that every element in a list is unique (so it can build some sort of hash-based index, presumably). this is what happens when it's not actually true.

\$\endgroup\$
  • 1
    \$\begingroup\$ What is the language? I tried searching for "q insults you" language, but I couldn't have found anything. \$\endgroup\$ – Konrad Borowski Mar 15 '14 at 13:28
  • \$\begingroup\$ Sorry for being unintentionally cryptic, the language is [q](en.m.wikipedia.org/wiki/…. It also works in k4, BTW. \$\endgroup\$ – Aaron Davies Mar 20 '14 at 5:04
6
\$\begingroup\$

How about compiler optimisation errors:

#include <stdio.h>

#define N 4

int main(void)
{
    int sum;
    int i;
    int arr[N];

    for (i = 0, sum = 0; i < N; i++, arr[i] = sum) {
        sum += arr[i];
    }
    printf("%d\n", sum);
    return 0;
}

This is specific to gcc >= 4.7. Compiles and runs fine with gcc -O0 -Wall. Compiles with gcc -O2 -Wall but results in an inf-loop.

Also note, how gcc does see the problem for smaller N, e.g. N = 3:

test.c:11:38: warning: array subscript is above array bounds [-Warray-bounds]
  for (i = 0, sum = 0; i < N; i++, arr[i] = sum) {
                                       ^
test.c:12:13: warning: 'arr[0]' is used uninitialized in this function [-Wuninitialized]
  sum += arr[i];
         ^

Btw, this has been taken from a bug report, I can't recall the bug number though.

\$\endgroup\$
  • 3
    \$\begingroup\$ Well, this is undefined behavior, so the compiler is allowed to do anything. But it still feels strange that the compiler decided to change an assignment outside of the local array that is never used, and use of undeclared value to an infinite loop, even if the C standard allows this (after all, it depends on undefined behavior - accessing arr[N] (outside of array), and accessing arr[0] (which is uninitialized)). As anything is allowed for undefined behavior, this is not optimization error, but very unlikely to be what user wanted. \$\endgroup\$ – Konrad Borowski Jan 9 '14 at 12:37
  • 4
    \$\begingroup\$ This is explicitly not a compiler optimization error. UB is UB, and the compiler would be right even if it decided to eradicate all your data from your hard drive. \$\endgroup\$ – H2CO3 Mar 7 '14 at 6:06
5
\$\begingroup\$

I've always liked this weirdness in APL:

      ⍝ obviously a syntax error
      { (] } 3  
SYNTAX ERROR
      {(]}3

      ⍝ but:
      { (] } 1÷0
DOMAIN ERROR
      {(]}1÷0 

      ⍝ it even works with statically defined functions
      ∇z←f x
[1]  z←[{]}x
[2]  ∇
      f 1÷0
DOMAIN ERROR
      f 1÷0
     ∧
      f 3
SYNTAX ERROR
f[1] z←[{]}x     

It parses the inside of functions lazily!

\$\endgroup\$
4
\$\begingroup\$

PHP

<?php
[][] = 42;

[] is used in order to push elements. However, if you use it for array literal, the PHP makes crazy error message, even if you assign to it in order to push. Requires PHP >= 5.4, as before that you couldn't have indexed array literals.

Output:

Fatal error: Cannot use [] for reading in [...][...] on line 2

\$\endgroup\$
4
\$\begingroup\$

Python

Nested blocks

for a in range(26):
 for b in range(26):
  for c in range(26):
   for d in range(26):
    for e in range(26):
     for f in range(26):
      for g in range(26):
       for h in range(26):
        for i in range(26):
         for j in range(26):
          for k in range(26):
           for l in range(26):
            for m in range(26):
             for n in range(26):
              for o in range(26):
               for p in range(26):
                for q in range(26):
                 for r in range(26):
                  for s in range(26):
                   for t in range(26):
                    for u in range(26):
                     for v in range(26):
                      for w in range(26):
                       for x in range(26):
                        for y in range(26):
                         for z in range(26):
                          print a

Python 2.7: SystemError: too many statically nested blocks

Self-referencing lists

def printList(myList):
    for element in myList:
        if isinstance(element, list):
            printList(myList)
        else:
            print(element)

a = []
a.append(a)
printList(a)

Python 2.7

True is not a constant

The problem in the following example is that in Python 2.7, True and False are not constants. And True and False can automatically get casted to 1 and 0:

True=False
a=10/True

Traceback (most recent call last):
  File "/home/moose/.config/pluma/tools/new-tool-2", line 11, in <module>
    exec(sys.stdin.read())
  File "<string>", line 2, in <module>
ZeroDivisionError: integer division or modulo by zero

Python 2.7:

Intendation

def f(n):
    if n <= 1:
        return n
    else:
        return f(n-1)+f(n-2)

Do you get the error?

Traceback (most recent call last):
  File "/home/moose/.config/pluma/tools/new-tool-2", line 11, in <module>
    exec(sys.stdin.read())
  File "<string>", line 4
    else:
       ^
SyntaxError: invalid syntax

Mixing tabs and spaces was ok in Python 2.7 ... but mind the indentation level!

\$\endgroup\$
  • 1
    \$\begingroup\$ The mixing spaces and tabulators example doesn't work correctly, as Stack Exchange platform doesn't allow tabulators in code. \$\endgroup\$ – Konrad Borowski Jan 6 '14 at 15:35
  • \$\begingroup\$ @xfix: Ok, but I think people who read this get the point. Most editors don't show space / tabs either (except for trailing whitespace) and if they show it, it's most of the time gray. And in every other language (except for whitespace) whitespaces don't matter, as long as at least one is there. \$\endgroup\$ – Martin Thoma Jan 6 '14 at 15:41
  • \$\begingroup\$ You should write your programs in the Whitespace programming language. \$\endgroup\$ – Alexander Jan 9 '14 at 15:41
  • \$\begingroup\$ Is the Python 3 one a joke? \$\endgroup\$ – Ry- Mar 7 '14 at 15:57
  • \$\begingroup\$ @minitech I have no idea. That's what it's supposed to do with print a. \$\endgroup\$ – Justin Mar 11 '14 at 19:43
3
\$\begingroup\$

I'll start:

#include <iostream>

using namespace std;

class A
{
public:
    A()
    {
    }

    void doSomethingDiabolical()
    {
        delete this;
    }

    virtual void breakHorribly()
    {
        cout << "still alive" << endl;
        doSomethingDiabolical();
        cout << "still alive" << endl;
    }
};

class B : public A
{
public:
    B() : A()
    {
    }

    void breakHorribly()
    {
        cout << "still alive" << endl;
        ((A *) this)->breakHorribly();
        cout << "still alive" << endl;
        doSomethingDiabolical();
        cout << "still alive" << endl;
        breakHorribly();
        cout << "dead" << endl;
    }
};

int main()
{
    jane();
}

void jane()
{
    cout << "still alive" << endl;
    A * o = new B;
    cout << "still alive" << endl;
    o->breakHorribly();
}

Any guesses why this program crashes? :D

See jane run: http://ideone.com/gtaZ3

\$\endgroup\$
  • 1
    \$\begingroup\$ Isn't this a rather straightforward infinite recursion? B::BreakHorribly calls itself before doSomethingDiabolical is called, so delete this is never reached. \$\endgroup\$ – marinus Aug 4 '12 at 1:43
  • \$\begingroup\$ This program explodes for a large number of reasons. Its behavior changes if you remove different print statements. However, you're right. I didn't have the time to reproduce the undefined behavior I had once, but I ended up getting a pure virtual function call at runtime. \$\endgroup\$ – Wug Aug 4 '12 at 6:48
  • 2
    \$\begingroup\$ You're not saying you once accidentally typed something like delete this, are you? \$\endgroup\$ – ceased to turn counterclockwis Aug 5 '12 at 11:11
  • \$\begingroup\$ No, it was much more subtle than that, but the end result was the same: a destructor was called for a class during execution of a member function \$\endgroup\$ – Wug Aug 5 '12 at 23:45
3
\$\begingroup\$

Bash

I got this today when I tried to find out whether it is possible to protect the system from rm -rf /.

mkdir /tmp/a
mkdir /tmp/a/b
sudo mount --bind /tmp/a /tmp/a/b
rm -rf /tmp/a

The error message with LANG=C:

rm: WARNING: Circular directory structure.
This almost certainly means that you have a corrupted file system.
NOTIFY YOUR SYSTEM MANAGER.
The following directory is part of the cycle:
  '/tmp/a/b'
\$\endgroup\$
  • \$\begingroup\$ This warning is coming from rm, not bash. Not sure what language you should declare in the title, given that you used bash to set it up. \$\endgroup\$ – user62131 Mar 30 '17 at 2:45
2
\$\begingroup\$

R

Another one which is not ridiculous and, again, a warning rather than an error, but still nice:

> sapply(as.list(-1:-51), log)
 [1] NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN
[20] NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN
[39] NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN
There were 50 or more warnings (use warnings() to see the first 50)

I like the last bit: 50 or more :)

And the actual warnings:

1: In lapply(X = X, FUN = FUN, ...) : NaNs produced
2: In lapply(X = X, FUN = FUN, ...) : NaNs produced
....
50: In lapply(X = X, FUN = FUN, ...) : NaNs produced

FUN = FUN!

\$\endgroup\$
  • 1
    \$\begingroup\$ Nyan Code?! Well, that is weird indeed! \$\endgroup\$ – Kroltan Mar 20 '14 at 8:20
  • \$\begingroup\$ I don't see what's unexpected or surprising. log of a negative produce Not A Number (NaN) as it should. \$\endgroup\$ – plannapus Jun 6 '14 at 8:33
2
\$\begingroup\$

CPython

import ctypes
import sys
(ctypes.c_char * sys.getsizeof(None)).from_address(id(None))[:4] = '\x00' * 4

The result:

Fatal Python error: deallocating None

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
\$\endgroup\$
  • \$\begingroup\$ Even better in Python 3: ctypes.pythonapi._Py_Dealloc(ctypes.py_object(None)). \$\endgroup\$ – kirbyfan64sos Oct 22 '15 at 16:55
2
\$\begingroup\$

Bash - counterintuitive escape failure

echo "this should definitely work!!!11!"

returns

-bash: !11: event not found

(history expansion on the commandline is not prevented by double quotes)

Bonus:

echo "I don't know what's gone wrong!! !echo is usually pretty foolproof!-1"

The output is unlikely to be what's expected. Press up to get the command again, and notice it's changed from what you typed. If you press up and enter a couple of times, it's likely your output will begin to look somewhat horrific. Try it for yourself.

\$\endgroup\$
2
\$\begingroup\$

C# - Recursive, lazy Fibonacci generator

static void Main()
{
    Console.WriteLine(string.Join(",", fib().Take(141)));
    Console.ReadLine();
}

static IEnumerable<decimal> fib(decimal n = 0, decimal m = 1)
{
    if (n == 0)
    {
        yield return 0;
        yield return 1;
    }
    while (true)
    {
        yield return n + m;
        foreach(var x in fib(m, n+m))
        {
            yield return x;
        }
    }
}

This code looks fine, right? A fairly simple Fibonacci generator, spiced up with some recursion and lazy enumeration. Should work.

Nope! Running this will cause an OverflowException. This is because we are using decimal, and the 141st Fibonacci number (~8.1E28) exceeds the maximum value of decimal (~7.9E28).

The int, however does not throw an OverflowException when you exceed its maximum value. Instead it, as expected, overflows to a negative value. So if we replace int instead with decimal, like in the following code, it should work, right?

static void Main()
{
    Console.WriteLine(string.Join(",", fib().Take(141)));
    Console.ReadLine();
}

static IEnumerable<int> fib(int n = 0, int m = 1)
{
    if (n == 0)
    {
        yield return 0;
        yield return 1;
    }
    while (true)
    {
        yield return n + m;
        foreach(var x in fib(m, n+m).ToList())
        {
            yield return x;
        }
    }
}

If you read the code it should be obvious why this won't work. If you didn't... I didn't just change the type from decimal to int; I also snuck in a call to ToList() in the foreach statement. This will force the enumerator returned to be eagerly evaluated. This will cause not 141 recursions, but instead an infinite number of recursions. Actually, long before it hits infinity it will of course overflow the stack, causing the runtime to throw a StackOverflowException. (bonus: this exception cannot be caught, so it will crash the runtime)

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.