worst bugs ever (or your most hated)

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

User avatar
markfiend
Posts: 500
Joined: Fri Jul 06, 2007 9:59 am UTC
Location: UK (Leeds)

Re: worst bugs ever (or your most hated)

Postby markfiend » Sat Apr 12, 2008 1:54 pm UTC

biolution wrote:
markfiend wrote:In php4, when you instantiate a new object, it doesn't automatically call the class's constructor method. :evil:


Offtopic:
Spoiler:
Eh? It does. Php4 and php5 have different constructor names, though. In php5, __construct is called, if it doesn't exist, ClassName() is called (if it exists, otherwise it walks up the inheritance hierarchy). In php4, only ClassName() is called. If you're talking about deriving a class, not defining a constructor in the child, and then the parent constructor isn't invoked, ya, I think I read a comment about that happening.

Oh. Thanks. Worth knowing. 8)

OK, revise my complaint, PHP4 doesn't call __construct like PHP5 does. :mrgreen:
advanced, forthright, signifficant
pronouns: he/him

User avatar
Shai
Posts: 86
Joined: Wed Dec 12, 2007 2:59 am UTC
Location: Guelph, Ontario, Canada
Contact:

Re: worst bugs ever (or your most hated)

Postby Shai » Mon Apr 14, 2008 12:38 am UTC

I once spent hours trying to locate a bug in some C code. It kept seg faulting, and I didn't know why. I threw in a printf. It printed what it should have, and didn't seg fault. I took out the printf. It seg faulted.

So I made it print out an empty string and went on my not-so-merry way. I don't know if I have that code anymore, forget what class it was for.
I blame lag.

User avatar
evilbeanfiend
Posts: 2650
Joined: Tue Mar 13, 2007 7:05 am UTC
Location: the old world

Re: worst bugs ever (or your most hated)

Postby evilbeanfiend » Mon Apr 14, 2008 11:08 am UTC

ewwww, worst fix ever.

if you can't find a segfault use valgrind
in ur beanz makin u eveel

User avatar
biolution
Ken
Posts: 560
Joined: Wed Sep 05, 2007 10:05 pm UTC
Location: San Francisco, Ca
Contact:

Re: worst bugs ever (or your most hated)

Postby biolution » Mon Apr 14, 2008 5:56 pm UTC

Shai wrote:I once spent hours trying to locate a bug in some C code. It kept seg faulting, and I didn't know why. I threw in a printf. It printed what it should have, and didn't seg fault. I took out the printf. It seg faulted.

So I made it print out an empty string and went on my not-so-merry way. I don't know if I have that code anymore, forget what class it was for.


I had a similar problem in a swigged python program. If I printed out the query string, it worked. If I didn't, it said the query was malformed. I ended up calling str() on the query string to fix it. Never found out what was going on. I can only guess there was some sort of corruption in the query string the swigged code returned.

Micron
Posts: 319
Joined: Sat Feb 16, 2008 1:03 am UTC

Re: worst bugs ever (or your most hated)

Postby Micron » Mon Apr 14, 2008 10:31 pm UTC

Working with files in Java I hit a case where file names were not portable between different OSs. Windows has a set of reserved device names (things like "COM1") which are treated as valid files in the file system on any path with any extension.

Code: Select all

new File("C:/someFolder/prn.foo").isFile()
returns true.

Code: Select all

new File("C:/someFolder/prn.foo").length()
returns 0.
Attempting to read from such a "file" is not a good idea. Of course such file names are just fine if the code is run on a JVM on a non-Windows system. Fun.

User avatar
'; DROP DATABASE;--
Posts: 3284
Joined: Thu Nov 22, 2007 9:38 am UTC
Location: Midwest Alberta, where it's STILL snowy
Contact:

Re: worst bugs ever (or your most hated)

Postby '; DROP DATABASE;-- » Tue Apr 15, 2008 2:12 am UTC

Definitely one of the "WTF were they thinking?" parts of Windows. There was a related exploit a while back that let you crash the system from IE by accessing such files. And I can only wonder how many cross-platform open-source apps have had complaints of Windows users not being able to compile con.c or similar.

Had a fun one in PHP recently. I had a function parsing a string before doing something like "return urlencode($newfoo)", and changed it to "return base64_encode($foo)", or something like that. Suddenly the string was being returned without being completely parsed, as if that change had broken code earlier in the function. It took a good while before I noticed I'd used $foo instead of $newfoo. >_< ($foo, of course, being the unparsed string, and $newfoo the parsed result.)

Just in case anyone was paying attention in the last 30 seconds or something and saw this post change a couple times, my bad. I hit "edit" instead of "quote". Sorry about that. I'm pretty certain it's back to where it was now. -EvanED
poxic wrote:You suck. And simultaneously rock. I think you've invented a new state of being.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: worst bugs ever (or your most hated)

Postby EvanED » Tue Apr 15, 2008 2:18 am UTC

'; DROP DATABASE;-- wrote:Definitely one of the "WTF were they thinking?" parts of Windows MS-DOS CP/M.

Just to emphasize how far back that lineage goes. ;-)

User avatar
TomBot
Posts: 228
Joined: Sun Jul 29, 2007 1:17 am UTC
Location: Illinois (UIUC)
Contact:

Re: worst bugs ever (or your most hated)

Postby TomBot » Tue Apr 15, 2008 2:59 am UTC

Gatesunder wrote:My current most hated bug is one in which the compiler keeps telling me a variable isn't declared in the scope it's in when it's declared right about where it's first used. The annoying part is that it doesn't complain at all about me using the variable the line below the line it's complaining about. Here's an example

Code: Select all

Node< T > * x = new Node< T >( data );
blargh[ i ] = x;


I forget what the other line is that it's not complaining about, but the thing it is complaining about is x, saying it's not declared in this scope on the second line, but doesn't say anything about the line it's declared on. I honestly cannot wrap my head around it no matter how many times I go over the code trying to see if it's coming from somewhere else. *shrug*


I'm not sure if this is your problem, but you reminded me of a strange thing I just saw today:

Code: Select all

class Foo {
    class Inner { int bar; };

    void foobar()
    {
        // This does not work!  Expects semicolon before i, then i is undeclared later.
        // (Tested on GCC 4.2 and 3.something, but presumably it works on something, as this was given code.)
        vector<Inner>::iterator i;
    }
};

Spoiler:
Turns out you need:

Code: Select all

typename vector<Inner>::iterator i;
I'm not sure what the compiler thinks you're doing otherwise, though. Maybe declaring a variable ::iterator at global scope? Hmm...

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: worst bugs ever (or your most hated)

Postby EvanED » Tue Apr 15, 2008 3:02 am UTC

TomBot wrote:Turns out you need:

Code: Select all

typename vector<Inner>::iterator i;
I'm not sure what the compiler thinks you're doing otherwise, though. Maybe declaring a variable ::iterator at global scope? Hmm...

[shameless self-promotion]
This page I wrote gives a description of the issues. I guess it is one of the better pages on the web because I'm getting in the top couple hits for "c++ typename" on the search engines, which blows my mind... but whatever
[/shameless self-promotion]

User avatar
TomBot
Posts: 228
Joined: Sun Jul 29, 2007 1:17 am UTC
Location: Illinois (UIUC)
Contact:

Re: worst bugs ever (or your most hated)

Postby TomBot » Tue Apr 15, 2008 3:20 am UTC

That's pretty helpful, thanks.

Man, it's too bad compilers don't give better, more heuristic errors, though. For example, if the compiler sees you using a qualified dependent name without typename, it sets a flag so that if you get a syntax error nearby, it could say, "Maybe you need typename."

(Reminds me of something I just read around here where somebody made a parser generator that would show you the shortest expression that would create a shift-reduce conflict. That would have been useful for ocamlyacc to have when I was taking the compilers class.)

The sad thing is, I'm perfectly capable of trying to make GCC give me better error messages - yay open source - I just don't, because I'm lazy.

Rysto
Posts: 1459
Joined: Wed Mar 21, 2007 4:07 am UTC

Re: worst bugs ever (or your most hated)

Postby Rysto » Tue Apr 15, 2008 3:23 am UTC

Well, in GCC's partial defence, it's the parser that has to detect the error, and C++ is hideously difficult to parse, let alone give good error messages for.

maafy6
Posts: 102
Joined: Wed Aug 22, 2007 10:43 pm UTC

Re: worst bugs ever (or your most hated)

Postby maafy6 » Tue Apr 15, 2008 3:45 am UTC

Seg fault:

Code: Select all

for(std::vector<SomeClass>::iterator i = foo->getVectorOfStuff().begin();
    i != foo->getVectorOfStuff().end();
    i++)
{
   doStuff();
}


Non-seg fault

Code: Select all

std::vector<SomeClass> bar = foo->getVectorOfStuff();
std::vector<SomeClass>::iterator i;
for(i = bar.begin(); i != bar.end(); i++)
{
   doStuff();
}


Do not know why the original was broken, unless g++ has decided to demand cleaner looking code in general.

User avatar
Gatesunder
Posts: 120
Joined: Sat Feb 09, 2008 11:24 pm UTC
Location: KSU

Re: worst bugs ever (or your most hated)

Postby Gatesunder » Tue Apr 15, 2008 4:05 am UTC

Gatesunder wrote:

Code: Select all

    Node< T > * x = new Node< T >( data );
    blargh[ i ] = x;



heh, I decided to try programming this in Java and things are coming along rather nicely, but for the heck of it I went back to the C++ code and decided to fiddle and then decided to turn on all the warnings and got a nifty little warning that just adds to the confusion.

" Warning: unused variable 'x' "

and it's pointing at the line I declared it on of course. I'm gonna check out that writeup EvanED linked and see if my problem lies in that area . . . *shrug* . . .
I'm wrong 99% of the time, but some day that 1% will be better than the rest ...

coppro
Posts: 117
Joined: Mon Feb 04, 2008 6:04 am UTC

Re: worst bugs ever (or your most hated)

Postby coppro » Tue Apr 15, 2008 4:11 am UTC

maafy6 wrote:Seg fault:

Code: Select all

for(std::vector<SomeClass>::iterator i = foo->getVectorOfStuff().begin();
    i != foo->getVectorOfStuff().end();
    i++)
{
   doStuff();
}


Non-seg fault

Code: Select all

std::vector<SomeClass> bar = foo->getVectorOfStuff();
std::vector<SomeClass>::iterator i;
for(i = bar.begin(); i != bar.end(); i++)
{
   doStuff();
}


Do not know why the original was broken, unless g++ has decided to demand cleaner looking code in general.
Could be that getVectorOfStuff returns a vector that is regenerated every time you call. If so, then the iterators aren't members of the same vector, so boom!

User avatar
Yakk
Poster with most posts but no title.
Posts: 11083
Joined: Sat Jan 27, 2007 7:27 pm UTC
Location: E pur si muove

Re: worst bugs ever (or your most hated)

Postby Yakk » Tue Apr 15, 2008 5:46 am UTC

Gatesunder wrote:My current most hated bug is one in which the compiler keeps telling me a variable isn't declared in the scope it's in when it's declared right about where it's first used. The annoying part is that it doesn't complain at all about me using the variable the line below the line it's complaining about. Here's an example

Code: Select all

Node< T > * x = new Node< T >( data );
blargh[ i ] = x;


I forget what the other line is that it's not complaining about, but the thing it is complaining about is x, saying it's not declared in this scope on the second line, but doesn't say anything about the line it's declared on. I honestly cannot wrap my head around it no matter how many times I go over the code trying to see if it's coming from somewhere else. *shrug*


#define problems as a guess.

Try

Code: Select all

#ifdef Node
  int err[0];
#endif
#ifdef T
  int err[0];
#endif
#ifdef data
  int err[0];
#endif
One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision - BR

Last edited by JHVH on Fri Oct 23, 4004 BCE 6:17 pm, edited 6 times in total.

coppro
Posts: 117
Joined: Mon Feb 04, 2008 6:04 am UTC

Re: worst bugs ever (or your most hated)

Postby coppro » Wed Apr 16, 2008 3:26 am UTC

Yakk wrote:
Gatesunder wrote:My current most hated bug is one in which the compiler keeps telling me a variable isn't declared in the scope it's in when it's declared right about where it's first used. The annoying part is that it doesn't complain at all about me using the variable the line below the line it's complaining about. Here's an example

Code: Select all

Node< T > * x = new Node< T >( data );
blargh[ i ] = x;


I forget what the other line is that it's not complaining about, but the thing it is complaining about is x, saying it's not declared in this scope on the second line, but doesn't say anything about the line it's declared on. I honestly cannot wrap my head around it no matter how many times I go over the code trying to see if it's coming from somewhere else. *shrug*


#define problems as a guess.

Try

Code: Select all

#ifdef Node
  int err[0];
#endif
#ifdef T
  int err[0];
#endif
#ifdef data
  int err[0];
#endif
Or, for brevity:

Code: Select all

#if defined(Node) or defined(T) or defined(data)
# error "code"
#endif

maafy6
Posts: 102
Joined: Wed Aug 22, 2007 10:43 pm UTC

Re: worst bugs ever (or your most hated)

Postby maafy6 » Thu Apr 17, 2008 1:18 am UTC

So, our system has several XML files scattered about, used to generate schemas or just to sit there and be meta-data, whatever. Since I've come on, I've had issues putting in different comments in certain places in these files. And it's just like "Oh, oh well. No comments in this spot." After having this annoy us one final time, another guy sat down to figure out why Qt couldn't parse comments correctly. He tests, but cannot get it to choke. He looks at my comments, and then again in a different IDE. Tries using my comment and then yells at me.

I had several comments of the form:

Code: Select all

<!-- This seemed to be a nicely formatted
  -- easy to read comment that looks perfectly
  -- natural to the naked eye.
  -->


He then goes to W3C. Sure enough, and unbeknownst to all of us at the time "--" cannot be used in comments at any point unless you are opening or closing the comment.

#%@$!?

Who knew, eh?

User avatar
phlip
Restorer of Worlds
Posts: 7554
Joined: Sat Sep 23, 2006 3:56 am UTC
Location: Australia
Contact:

Re: worst bugs ever (or your most hated)

Postby phlip » Thu Apr 17, 2008 1:32 am UTC

An SGML comment is just text delimited by --, within a <! ... > tag. You should, for example, technically be able to do stuff like <!DOCTYPE html etc etc -- yay HTML is fun -->. DTDs, for instance, use this comment style all the time. So your comment should, strictly-speaking, be equivalent to the meaningless <!easy to read comment that looks perfectly>.

However, most people who make web pages treat it as if it's just text delimited by <!-- and -->, regardless of what's between them... and almost every browser will parse them like that too (so things like the comment in the doctype don't work).

Making your comments always <!-- stuff -->, and never using two hyphens within the comment, is the only way to ensure it will be read correctly regardless of whether it's parsed the common way or the "correct" way. In fact, I think comments in XML have to be <!-- stuff -->, sans intervening double hyphens... but I may be wrong about that (I'm sure I'll be corrected soon if I am).

Code: Select all

enum ಠ_ಠ {°□°╰=1, °Д°╰, ಠ益ಠ╰};
void ┻━┻︵​╰(ಠ_ಠ ⚠) {exit((int)⚠);}
[he/him/his]

User avatar
TomBot
Posts: 228
Joined: Sun Jul 29, 2007 1:17 am UTC
Location: Illinois (UIUC)
Contact:

Re: worst bugs ever (or your most hated)

Postby TomBot » Thu Apr 17, 2008 1:38 am UTC

maafy6 wrote:Seg fault:

Code: Select all

for(std::vector<SomeClass>::iterator i = foo->getVectorOfStuff().begin();
    i != foo->getVectorOfStuff().end();
    i++)
{
   doStuff();
}


Non-seg fault

Code: Select all

std::vector<SomeClass> bar = foo->getVectorOfStuff();
std::vector<SomeClass>::iterator i;
for(i = bar.begin(); i != bar.end(); i++)
{
   doStuff();
}


Do not know why the original was broken, unless g++ has decided to demand cleaner looking code in general.


Really, both should work, assuming: doStuff does not modify the structure of foo->getVectorOfStuff(), and (as mentioned) foo->getVectorOfStuff() is returning a reference to the same vector each time.

BTW, God kills fewer kittens if you use ++i instead of i++.

User avatar
phlip
Restorer of Worlds
Posts: 7554
Joined: Sat Sep 23, 2006 3:56 am UTC
Location: Australia
Contact:

Re: worst bugs ever (or your most hated)

Postby phlip » Thu Apr 17, 2008 1:55 am UTC

Does foo->getVectorOfStuff() return a vector, or a reference to a vector?

If the former, then it'd be returning a new temporary object every time it's called... which means that each time you say foo->getVectorOfStuff.end() you'll get a different answer... since you're referring to a different vector, whose data will be in a different place.

If you make it return a reference to a vector, and always a reference to the same vector, then the first version shouldn't segfault.

TomBot wrote:BTW, God kills fewer kittens if you use ++i instead of i++.

Why? Given a non-awful compiler, they'll both compile to the same thing, so the only difference is style... and (in my opinion) i++ is more readable... it has the bits in the same order as "i = i + 1" - thing you're changing first, what you're doing to it afterwards. If C used something like "i + 1 -> i", then "++i" would be a better match.

Code: Select all

enum ಠ_ಠ {°□°╰=1, °Д°╰, ಠ益ಠ╰};
void ┻━┻︵​╰(ಠ_ಠ ⚠) {exit((int)⚠);}
[he/him/his]

Rysto
Posts: 1459
Joined: Wed Mar 21, 2007 4:07 am UTC

Re: worst bugs ever (or your most hated)

Postby Rysto » Thu Apr 17, 2008 2:06 am UTC

phlip wrote:Why? Given a non-awful compiler, they'll both compile to the same thing, so the only difference is style... and (in my opinion) i++ is more readable... it has the bits in the same order as "i = i + 1" - thing you're changing first, what you're doing to it afterwards. If C used something like "i + 1 -> i", then "++i" would be a better match.

Because in C++, when ++ is an overloaded operator, they don't compile to the same thing.

User avatar
Xanthir
My HERO!!!
Posts: 5321
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: worst bugs ever (or your most hated)

Postby Xanthir » Thu Apr 17, 2008 2:22 am UTC

maafy6 wrote:So, our system has several XML files scattered about, used to generate schemas or just to sit there and be meta-data, whatever. Since I've come on, I've had issues putting in different comments in certain places in these files. And it's just like "Oh, oh well. No comments in this spot." After having this annoy us one final time, another guy sat down to figure out why Qt couldn't parse comments correctly. He tests, but cannot get it to choke. He looks at my comments, and then again in a different IDE. Tries using my comment and then yells at me.

I had several comments of the form:

Code: Select all

<!-- This seemed to be a nicely formatted
  -- easy to read comment that looks perfectly
  -- natural to the naked eye.
  -->


He then goes to W3C. Sure enough, and unbeknownst to all of us at the time "--" cannot be used in comments at any point unless you are opening or closing the comment.

#%@$!?

Who knew, eh?

Not quite true. This is something HTML (and XML as well) inherited from SGML.

In SGML, "--" encountered within an element marks the beginning or end of a comment. It's how you, say, comment out a single attribute from an element without having to comment the entire element out and put a copy of it (with the removed attribute) outside of the comment block. (Frex, <a --href="..."-- id="..."> should be parsed as <a id="...">.) <!-- and --> count as comment start and end tags, and respond to the --s appropriately. The first time you encounter a -- after a <!--, you are no longer commenting out text. Whatever comes after that is parsed as a part of the document, at least until you encounter another --.

This is explained well in a blog post by Hixie (the sort-of ruler of html5) where he explains his (successful) quest to get browsers to implement sgml comments properly, followed by his eventual realization that this is stupid and the spec shouldn't work like that.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
biolution
Ken
Posts: 560
Joined: Wed Sep 05, 2007 10:05 pm UTC
Location: San Francisco, Ca
Contact:

Re: worst bugs ever (or your most hated)

Postby biolution » Thu Apr 17, 2008 3:22 am UTC

Fun one I finally figured out today.

Code: Select all

$file_data = base64_encode(file_get_contents($file));
...much later...
$url_data = rawurlencode($data)
...much later...
$data = wddx_serialize_value($url_data);
...save to db...


While not technically incorrect (shouldn't need to urlencode it in this instance), it can turn a 3 megabyte binary file into about 30 megabytes of memory usage. This poses a rather large problem when people are uploading 10 megabyte files and PHP is only allowed 64 megabytes of memory, usually running out when wddx_serialize_value needs to copy the whole chunk.

The reason is base64_encode uses + and / for some bytes, and then rawurlencode converts those to %xx. So you gain about 30% from base64, then another 10-20% from urlencode. Meanwhile, since $data is being passed by value everywhere, memory slowly accumulates and runs out.

User avatar
markfiend
Posts: 500
Joined: Fri Jul 06, 2007 9:59 am UTC
Location: UK (Leeds)

Re: worst bugs ever (or your most hated)

Postby markfiend » Thu Apr 17, 2008 2:23 pm UTC

Another one: My genius forebear (see above in this thread) has inconsistently called values retrieved from database calls $retrieved_foo or $retreived_bar

Edit: It's not in this thread :roll:

Edit again: found it
advanced, forthright, signifficant
pronouns: he/him

User avatar
Shai
Posts: 86
Joined: Wed Dec 12, 2007 2:59 am UTC
Location: Guelph, Ontario, Canada
Contact:

Re: worst bugs ever (or your most hated)

Postby Shai » Tue Apr 22, 2008 1:04 am UTC

Rysto wrote:
phlip wrote:Why? Given a non-awful compiler, they'll both compile to the same thing, so the only difference is style... and (in my opinion) i++ is more readable... it has the bits in the same order as "i = i + 1" - thing you're changing first, what you're doing to it afterwards. If C used something like "i + 1 -> i", then "++i" would be a better match.

Because in C++, when ++ is an overloaded operator, they don't compile to the same thing.


Depends on how it's used.

Code: Select all

int x1 = 3, x2 = 3;
int y1 = ++x1;
int y2 = x2++;


y1 should be 4, and y2 should be 3. At least, to the best of my memory.
I blame lag.

User avatar
TomBot
Posts: 228
Joined: Sun Jul 29, 2007 1:17 am UTC
Location: Illinois (UIUC)
Contact:

Re: worst bugs ever (or your most hated)

Postby TomBot » Tue Apr 22, 2008 9:32 am UTC

No, that's not overloaded. Overloaded would be:

Code: Select all

#include <iostream>
using namespace std;

class Foo {
public:
   Foo(int _i) : i(_i) {}
   
   Foo operator ++ (int)
   {
      cerr << "Foo++" << endl;
      Foo temp(*this);
      i = i + 1;
      return temp;
   }
   
   Foo & operator ++ ()
   {
      cerr << "++Foo" << endl;
      i = i + 1;
      return *this;
   }
   
private:
   int i;
};

int main()
{
   Foo f(1);
   f++;
   ++f;
   return 0;
}

This outputs:

Code: Select all

Foo++
++Foo

As you can see, the postincrement version involves calling the the copy ctor and the dtor. You can argue that if you are ignoring the return value, the compiler might notice that none of those functions have side effects and elide them. But that's asking quite a lot of the compiler, and it can only work if the compiler has the source to all those functions.

Back on topic: I was just using a lab full of computers with really old and buggy ALSA drivers (snd_azx). When playing audio data with snd_pcm_writei(), if I did everything exactly the same but changed the size of the chunks of data I call that with, it goes from working perfectly (<128 bytes) to being high pitched (>128 bytes) to being normal-pitched but with clicks in it (>> 128 bytes).

User avatar
hotaru
Posts: 1041
Joined: Fri Apr 13, 2007 6:54 pm UTC

Re: worst bugs ever (or your most hated)

Postby hotaru » Wed Apr 23, 2008 7:36 am UTC

TomBot wrote:You can argue that if you are ignoring the return value, the compiler might notice that none of those functions have side effects and elide them. But that's asking quite a lot of the compiler, and it can only work if the compiler has the source to all those functions,

doesn't gcc have some way to specify in the function definition that a function doesn't have side effects?
ah, here it is... but apparently it only works in c, not in c++ :lol:

Code: Select all

factorial product enumFromTo 1
isPrime n 
factorial (1) `mod== 1

User avatar
Yakk
Poster with most posts but no title.
Posts: 11083
Joined: Sat Jan 27, 2007 7:27 pm UTC
Location: E pur si muove

Re: worst bugs ever (or your most hated)

Postby Yakk » Wed Apr 23, 2008 4:55 pm UTC

hotaru wrote:
TomBot wrote:You can argue that if you are ignoring the return value, the compiler might notice that none of those functions have side effects and elide them. But that's asking quite a lot of the compiler, and it can only work if the compiler has the source to all those functions,

doesn't gcc have some way to specify in the function definition that a function doesn't have side effects?
ah, here it is... but apparently it only works in c, not in c++ :lol:


C++0x will have constexpr functions. These functions are highly restricted, but can be evaluated at compile-time without any real effort by a compiler, if all of their parameters are constexpr.

Such a function cannot modify any of it's parameters, it can only reference constexpr global values, and it can only call constexpr functions.

So if it is "known" that the parameters to a constexpr function haven't been modified, then I think a C++0x compiler could eliminate redundant calls to the constexpr function...

(ie, this is similar to the gcc 'const' function, but more restricted, checked by the compiler, and more general in that it can be applied to C++ functions and to C++ methods).
One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision - BR

Last edited by JHVH on Fri Oct 23, 4004 BCE 6:17 pm, edited 6 times in total.

User avatar
hotaru
Posts: 1041
Joined: Fri Apr 13, 2007 6:54 pm UTC

Re: worst bugs ever (or your most hated)

Postby hotaru » Thu Apr 24, 2008 3:13 pm UTC

Yakk wrote:C++0x will have constexpr functions. These functions are highly restricted, but can be evaluated at compile-time without any real effort by a compiler, if all of their parameters are constexpr.

Such a function cannot modify any of it's parameters, it can only reference constexpr global values, and it can only call constexpr functions.

So if it is "known" that the parameters to a constexpr function haven't been modified, then I think a C++0x compiler could eliminate redundant calls to the constexpr function...

(ie, this is similar to the gcc 'const' function, but more restricted, checked by the compiler, and more general in that it can be applied to C++ functions and to C++ methods).

actually that sounds almost exactly the same as gcc's 'pure' functions. 'const' is even more restricted, it's basically the same as 'pure', except that a 'const' function shouldn't read global variables. neither one should have side effects.

Code: Select all

factorial product enumFromTo 1
isPrime n 
factorial (1) `mod== 1

User avatar
Yakk
Poster with most posts but no title.
Posts: 11083
Joined: Sat Jan 27, 2007 7:27 pm UTC
Location: E pur si muove

Re: worst bugs ever (or your most hated)

Postby Yakk » Thu Apr 24, 2008 3:47 pm UTC

gcc pure/const vs c++0x constexpr side-discussion:
Spoiler:
hotaru wrote:
Yakk wrote:C++0x will have constexpr functions. These functions are highly restricted, but can be evaluated at compile-time without any real effort by a compiler, if all of their parameters are constexpr.

Such a function cannot modify any of it's parameters, it can only reference constexpr global values, and it can only call constexpr functions.

So if it is "known" that the parameters to a constexpr function haven't been modified, then I think a C++0x compiler could eliminate redundant calls to the constexpr function...

(ie, this is similar to the gcc 'const' function, but more restricted, checked by the compiler, and more general in that it can be applied to C++ functions and to C++ methods).

actually that sounds almost exactly the same as gcc's 'pure' functions. 'const' is even more restricted, it's basically the same as 'pure', except that a 'const' function shouldn't read global variables. neither one should have side effects.


The global variables in question have to be constexpr -- and constexpr global "variables" are constants determined at compile time.

gcc doesn't have "really constant global variables", so pure is weaker than const. :) But because C++0x has the new level of constness called constexpr, it can produce gcc "const" levels of purity while letting constexpr functions to read'm!

Pure fails because two calls to a pure function with the same parameters can result in different results, as the context of the pure function is the arguments and every global variable, which could be changed between calls to a pure function. Const in gcc land fixes this by eliminating that implicit dependency on every global variable. Constexpr in C++0x land extends fixes this by marking which global variables are "really" const and cannot be changed by anything, to the level that you can (and should!) precompute them at compile time and replace their use with the constants in question...
One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision - BR

Last edited by JHVH on Fri Oct 23, 4004 BCE 6:17 pm, edited 6 times in total.

Ray
Posts: 2
Joined: Wed Mar 12, 2008 7:45 am UTC

Re: worst bugs ever (or your most hated)

Postby Ray » Fri May 02, 2008 4:33 am UTC

Shai wrote:I once spent hours trying to locate a bug in some C code. It kept seg faulting, and I didn't know why. I threw in a printf. It printed what it should have, and didn't seg fault. I took out the printf. It seg faulted.

So I made it print out an empty string and went on my not-so-merry way. I don't know if I have that code anymore, forget what class it was for.


I had a very similar bug back when I was first learning C. The program would segfault consistently on one specific test case. I suspected that one particular pointer might be pointing at something other than what it should be, so I added a printf("%p", foo) to check. In my case though, it didn't print what it should have. Rather, it confirmed that the pointer was pointing nowhere near where it should...and then the program worked perfectly. And just like in your case, removing the printf made it segfault again. I never did figure out why.

User avatar
TomBot
Posts: 228
Joined: Sun Jul 29, 2007 1:17 am UTC
Location: Illinois (UIUC)
Contact:

Re: worst bugs ever (or your most hated)

Postby TomBot » Fri May 02, 2008 5:54 am UTC

Pointers can be like a loaded gun, in that if you aren't careful, you'll cause a lot of damage, and that damage will potentially be far away.

User avatar
hotaru
Posts: 1041
Joined: Fri Apr 13, 2007 6:54 pm UTC

Re: worst bugs ever (or your most hated)

Postby hotaru » Fri May 02, 2008 6:00 am UTC

more gcc pure/const vs c++0x constexpr side-discussion:
Spoiler:
Yakk wrote:The global variables in question have to be constexpr -- and constexpr global "variables" are constants determined at compile time.

gcc doesn't have "really constant global variables", so pure is weaker than const. :) But because C++0x has the new level of constness called constexpr, it can produce gcc "const" levels of purity while letting constexpr functions to read'm!

Pure fails because two calls to a pure function with the same parameters can result in different results, as the context of the pure function is the arguments and every global variable, which could be changed between calls to a pure function. Const in gcc land fixes this by eliminating that implicit dependency on every global variable. Constexpr in C++0x land extends fixes this by marking which global variables are "really" const and cannot be changed by anything, to the level that you can (and should!) precompute them at compile time and replace their use with the constants in question...

so c++0x constexpr global variables are basically the same as constants defined with #define, which you can use in const functions in gcc... so i guess c++0x constexpr functions are basically the same as gcc const functions.
i usually use #define for things that are supposed to be really constant in c, since c doesn't have "really constant variables" at all.
it looks like c++ is finally starting to catch up to gnu c, feature-wise :P

Code: Select all

factorial product enumFromTo 1
isPrime n 
factorial (1) `mod== 1

User avatar
hotaru
Posts: 1041
Joined: Fri Apr 13, 2007 6:54 pm UTC

Re: worst bugs ever (or your most hated)

Postby hotaru » Fri May 02, 2008 7:14 am UTC

here's a really annoying one i just figured out...

Code: Select all

#include <stdio.h>
int main(){
  const char saltc[]="./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
  char salt[2]={0};
  printf("%02hhx\n",saltc[0]);
  salt[2]=0;
  printf("%02hhx\n",saltc[0]);
  return 0;
}


the output of that program is this on my system:

Code: Select all

2e
00


the program i encountered this in was a lot more complicated, and didn't actually do anything nearly as obvious as salt[2] = 0, so it took me a while to figure out how saltc[0] was getting changed...

Code: Select all

factorial product enumFromTo 1
isPrime n 
factorial (1) `mod== 1

User avatar
Strilanc
Posts: 646
Joined: Fri Dec 08, 2006 7:18 am UTC

Re: worst bugs ever (or your most hated)

Postby Strilanc » Fri May 02, 2008 4:32 pm UTC

hotaru wrote:here's a really annoying one i just figured out...

Code: Select all

#include <stdio.h>
int main(){
  const char saltc[]="./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
  char salt[2]={0};
  printf("%02hhx\n",saltc[0]);
  salt[2]=0;
  printf("%02hhx\n",saltc[0]);
  return 0;
}


the output of that program is this on my system:

Code: Select all

2e
00


the program i encountered this in was a lot more complicated, and didn't actually do anything nearly as obvious as salt[2] = 0, so it took me a while to figure out how saltc[0] was getting changed...


Classic off-by-one error.
Don't pay attention to this signature, it's contradictory.

User avatar
Dusty Chalk
Posts: 142
Joined: Thu May 01, 2008 9:00 pm UTC

Re: worst bugs ever (or your most hated)

Postby Dusty Chalk » Tue May 06, 2008 2:03 am UTC

My favourite bugs are also my most frustrating until I find them. That elation one feels when one finds a particularly frustrating bug is directly proportional to the frustration, and I live for that (the elation part, not the frustration part). Of course, if I never figure it out, then it stays on my frustrating list...
I remain,
:-Peter, aka :-Dusty :-Chalk

User avatar
Strilanc
Posts: 646
Joined: Fri Dec 08, 2006 7:18 am UTC

Re: worst bugs ever (or your most hated)

Postby Strilanc » Tue May 06, 2008 2:40 am UTC

Dusty Chalk wrote:My favourite bugs are also my most frustrating until I find them. That elation one feels when one finds a particularly frustrating bug is directly proportional to the frustration, and I live for that (the elation part, not the frustration part). Of course, if I never figure it out, then it stays on my frustrating list...


Depends on what was causing it. You haven't known pain until you've done anything complicated in VBA.

"Oh, of course, I just had to cut and paste the code so it would interpret it correctly. That was so obvious. Good thing I only wasted hours trying to figure out what the hell was going on. Thanks a lot, VBA."

That is not an exaggeration. I had another one where changing line A then line B to line B then line A stopped a crash (note: the lines did not depend on each other).

It got to the point where one of the first things I checked was whether or not VBA was screwing with me.
Don't pay attention to this signature, it's contradictory.

btilly
Posts: 1877
Joined: Tue Nov 06, 2007 7:08 pm UTC

Re: worst bugs ever (or your most hated)

Postby btilly » Tue May 06, 2008 3:04 am UTC

Strilanc wrote:
Dusty Chalk wrote:My favourite bugs are also my most frustrating until I find them. That elation one feels when one finds a particularly frustrating bug is directly proportional to the frustration, and I live for that (the elation part, not the frustration part). Of course, if I never figure it out, then it stays on my frustrating list...


Depends on what was causing it. You haven't known pain until you've done anything complicated in VBA.

"Oh, of course, I just had to cut and paste the code so it would interpret it correctly. That was so obvious. Good thing I only wasted hours trying to figure out what the hell was going on. Thanks a lot, VBA."

That is not an exaggeration. I had another one where changing line A then line B to line B then line A stopped a crash (note: the lines did not depend on each other).

It got to the point where one of the first things I checked was whether or not VBA was screwing with me.

That's what I've come to expect from virtually all Microsoft products.

Case in point. A co-worker is working on a web-based zoom tool. The idea is that you take a picture, click on it, and you have a magnifier glass that you can scroll around the picture with to see things close up. But on IE 6 if you scroll the window with a mouse wheel, the zoom tool stops working. Kaput. Dead. Works fine on Firefox, but IE is hosed by a mouse wheel.

So we experiment. The page layout is that we have the image, an invisible div layer placed over the image, and the magnifying glass in the div layer. The div layer captures events that we use to move the magnifying glass to the right spot. (And when we move the magnifying glass we also scroll the image it is using for its display so that you are magnifying the spot right below your mouse.) Works fine until you use a mouse wheel.

After experimenting we find that if we give the invisible div layer a background color, then it works fine. WTF? Add a background color to a div layer and you remember it is there??? What kind of crap is this? My guess (unverified, but still seems reasonable) is that it is the act of redrawing the div layer that reminds IE 6 what area the div layer covers so it can remember to capture events.

You might think we're done, but we can't let it <b>have</b> a background color. I float the idea of having a transparent gif as a background image, but IE has problems with transparencies. Much musing follows.

The solution? We add the events needed for the zoom tool to the image that is supposed to be underneath the magnifying glass. Now when you scroll with the scroll wheel, the image captures a mouse event, and the JavaScript from that event reminds IE 6 that the div layer is supposed to be there, and things start working again.

OK, so 2 developers just wasted an hour working around a Microsoft bug. (Well technically I'm not a developer. I just get called in because I've got a knack for debugging this crap.) What's next? Oh right, <b>another</b> Microsoft bug. This one affects both IE 6 and IE 7... (That one was faster to resolve. When you have a JavaScript object referring to an image and you change the URL of the image, IE doesn't realize that it should fetch a new image from the server. Solution: Have multiple JavaScript objects and swap objects rather than updating the properties of the object you have.)

Hey Redmond. It is software. It is supposed to work. You're supposed to be able to trust that it will work and layer ideas on top of your existing layers. Without having to constantly go back and find all of the places where things randomly don't work, even though they do in every other major browser.
Some of us exist to find out what can and can't be done.

Others exist to hold the beer.

sox
Posts: 2
Joined: Wed May 07, 2008 7:43 pm UTC

Re: worst bugs ever (or your most hated)

Postby sox » Wed May 07, 2008 8:09 pm UTC

I recently had a bug where adding a module named bar.cpp somehow caused foo.cpp to not compile. Line by line, i removed code from bar.cpp in a trial-and-error attempt to figure out what was causing the problem... until i had removed ALL code from bar.cpp. Even the comments.

"Strange," i thought to myself. "Maybe i'm going crazy, and adding this file to the project isn't actually what caused the problem."

So, i deleted the empty bar.cpp. The project compiled with no warnings.

I re-added bar.cpp. Foo.cpp wont' build due to a zillion errors.

Eventually, after pinching myself and looking around for evidence of a glitch in the matrix, I renamed bar.cpp to jar.cpp. No warnings or errors!

Spoiler:
It turns out that our project was doing unity builds. All cpp files were automagically #included together into a series of "master" cpp files in alphabetical order. So, adding bar.cpp had slightly re-ordered the master files for everything following alphabetically... and foo.cpp was silently depending on a preceeding module to #incude some needed headers.

I spent the better part of a day laughing at this one. The name of your source file should NEVER EVER break the build.
:roll:

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: worst bugs ever (or your most hated)

Postby EvanED » Wed May 07, 2008 9:11 pm UTC

sox wrote:The name of your source file should NEVER EVER break the build.

At the risk of getting off topic, this is one of many complaints I have about Java.


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 11 guests