http://www.perlmonks.org?node_id=432851

I was rereading some threads I started (always good to look for new replies), and found this in this thread:
Calling all coders: Please regale us with your darkest compiler error conundrums, stricture miseries, and "WTF?" moments!
So, anyone want to go 0 for 2?

-QM
--
Quantum Mechanics: The dreams stuff is made of

Replies are listed 'Best First'.
Re: Call for Compiler Error Conundrums
by hardburn (Abbot) on Feb 21, 2005 at 14:46 UTC

    This one isn't mine, but I saw it on LtU a while back. This isn't the exact error message (which I don't remember), but I believe it's from O'Caml:

    Type a' is not type a'

    O'Caml is strongly typed. The a' type can stand in for any type, as long as it's the same type everywhere a' appears. However, these types don't cross lexical scopes, so the above indicates two different a' types in two lexical scopes.

    In my High School C++ class, one of my classmates found this jem out of VC++:

    Ambigious error

    At which he replied "Oh, I'm ambigious?!!"

    This one isn't out of a compiler, but caused me much grief. Last week, I was setting up a new Apache VirtualHost to run an SSL site. This would be the second SSL site we had (both within the same Apache config), but whenever I used the new domain, I kept getting the old site. After an hour of playing, I saw this line, right near the top of the Named-based Virtual Hosts docs:

    Name-based virtual hosting cannot be used with SSL secure servers because of the nature of the SSL protocol.

    At which point I went to find a hammer for use in bashing my skull in for improper RTM.

    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Re: Call for Compiler Error Conundrums
by heptadecagram (Novice) on Feb 21, 2005 at 17:37 UTC

    When using mod_perl2 and CGI.pm (I'd rather not, but I'm working with code that is unfortunately dependent upon both), it is often the case that any fatal error (die or croak) will just stop. No warning, no error, just a blank page. I spent an hour tracing this down to a mysterious Fh line in CGI.pm that seems to cause the problem.

    I'm now working on migrating the very large system in question away from CGI.pm, but it's not easy. mod_perl2 is frustratingly unsupported by the many modules that would make such a migration much easier.

Re: Call for Compiler Error Conundrums
by holli (Abbot) on Feb 22, 2005 at 04:05 UTC
    Also, not perl related, but the king of error messages i ever got is
    File xy.z cannot be deleted. Not enough space on the volume.
    This is of course caused by the the attempt of Windows to copy the file to the recycle bin before deleting it, but still it reads strange.


    holli, /regexed monk/

      There are oodles of illogical error messages like that. The logical conclusion is the minimal example, and thus my favourite, which I saw on a site collecting of such messages. It appears in some version of Visual Studio IIRC:

      
      ┌────────────────────────┬───┐
      │ Error                  │ x │
      ├────────────────────────┴───┤
      │                            │
      │      No errors found       │
      │                            │
      │         ┌──────┐           │
      │         │  Ok  │           │
      │         └──────┘           │
      └────────────────────────────┘
      

      Makeshifts last the longest.

      This is of course caused by the the attempt of Windows to copy the file to the recycle bin before deleting it...
      Which begs the question "Why would Windows copy it instead of renaming it?" (But then, what is Windows if not rational?)

      -QM
      --
      Quantum Mechanics: The dreams stuff is made of

Re: Call for Compiler Error Conundrums
by Anonymous Monk on Feb 22, 2005 at 13:29 UTC
    About 15 years ago I helped someone debug a small program that remained silent while it should produce output. So we added a few debugging print statements. The program ran correctly (printing beside the debugging messages, also the messages it should). Removed the debugging, no messages at all. So we did a binary search to find out what the minimum amount of debugging messages printed was necessary.

    A bare minimum. Printing an additional empty string made the program work correctly. No additional printing, and the program would not print at all.

    Fast forward to a few months ago. I was trying to get an open source program working on an embedded system. It kept crashing with segmentation faults. Added debugging print statements - and it ran fine. Remove them, crash. Put them elsewhere, crash. Moved to a different place, and it ran fine. Eventually, I ended up with putting the following code in the program:

    if(i == 0) abort();
    This is after a for loop that left i to be equal to 256.
Re: Call for Compiler Error Conundrums
by iblech (Friar) on Feb 21, 2005 at 06:44 UTC

    Some time ago, we tried to install Gentoo, a source-based Linux distribution. We used as optimization flag for gcc -fomit-frame-pointer (sic, not the correct -fomit-framepointer!). So, we were'nt able to compile anything, all configure scripts died with gcc not being able to compile anything. It took us some time to find that mistake...

    --Ingo

      I suppose I was originally asking for Perl compiler issues, but due to the underwhelming response, I'll take what I can get :)
      ...all configure scripts died with gcc not being able to compile anything.
      I hope gcc now gives appropriate error messages when bad flags come down the pipe.

      -QM
      --
      Quantum Mechanics: The dreams stuff is made of

Re: Call for Compiler Error Conundrums
by benizi (Hermit) on Mar 05, 2005 at 19:15 UTC

    Definitely in the "WTF?" category. While building a Visual Studio .NET project:

    Error: No such interface supported

    The project built fine two days prior, but now this error was the only output from the build process. No line numbers, no pointers to anything. Even the great error message index didn't shed much light. It seems to be a pretty generic Windows message.