No math for you!



  • A coworker just discovered this bug the other day. It's pretty much random. Sometimes it happens, sometimes it doesn't.

    int1 = 0;
    int2 = 0;
    print(int1); // prints 0
    print(int2); // prints 0
    int1 = int1 + 1;
    int2 = int2 + 1;
    

    So, you'd expect int1 and int2 to both be 1 now, right? Don't be silly. This is Enterprise software we're talking about! You can't spend thousands of F@#KING DOLLARS and expect MATH TO WORK.

    print(int1); // prints 0 again...  WTF!?
    print(int2); // prints 1
    

    I'm going to go slit my wrists.



  • there must be something we're not seeing. Are you sure there isn't some more code ?



  • Obviously this is a custom language/interpreter/compiler then; why not use one of the already well-established languages/interpreters/compilers that are actually used?



  • WTF is print?  what language is this?  what compiler?



  • @Lingerance said:

    Obviously this is a custom language/interpreter/compiler then;

    @tster said:

    WTF is print?  what language is this?  what compiler?

    @pitchingchris said:

    Are you sure there isn't some more code ?

    Yes, it's a proprietary enterprise templating language... and it is anonymized.  No code is missing.  This exact sequence of statements will result in the error.

    @Lingerance said:

    why not use one of the already well-established languages/interpreters/compilers that are actually used?

    You must not work in a corporate environment.  You see, when a well-groomed salesman approaches someone in charge and sells them Enterprisey software, the developer's fate is sealed.  It WILL be used, no matter how bass-ackwards it is.  To do otherwise would be for said executive to admit they were wrong, and as a result to admit to wasting money (on things that aren't sports cars, boats, vacations, etc.).



  • you're SOL :)  useing a proprietary language is the Real WTF.  Especially one that hasn't been out awhile to work out the kinks.



  • Are you sure that the int1 is not actually intl (with a lowercase L) ?  Depending on your IDE and fonts it may be hard to tell the difference. 



  • Yes, it's a proprietary enterprise templating language... and it is anonymized.  No code is missing.  This exact sequence of statements will result in the error.

    If the compiler can't reliably count to one then I'd assess it as overall useless.



  • Better make sure your code is threadsafe and start digging deeper into what print does...



  • @vt_mruhlin said:

    digging deeper into what print does...
     

    Or what the + operator does... is it possible this is [retardedly] overloaded?



  • @djork said:

    You must not work in a corporate environment.  You see, when a well-groomed salesman approaches someone in charge and sells them Enterprisey software, the developer's fate is sealed.  It WILL be used, no matter how bass-ackwards it is.  To do otherwise would be for said executive to admit they were wrong, and as a result to admit to wasting money (on things that aren't sports cars, boats, vacations, etc.).

     

    This must be why Crystal Reports still exists as a thing that anyone uses ever. 



  • @TheDan666 said:

    Are you sure that the int1 is not actually intl (with a lowercase L) ?  Depending on your IDE and fonts it may be hard to tell the difference. 


    yes, considering "It's pretty much random. Sometimes it happens, sometimes it doesn't", your guess is probably correct. given that the code is provided in its entirety.



  • I'd go with --

    1) the variables were originally declared as "short" or "byte" or "char",

    2) somehow the Enterprisy software thinks they're ints or longs in this code segment

    3) the values are stored on the heap, leading to near-random corruption when the store to int2 overwrites the memory used for int1 (although a JIT could also cause this sort of thing with on-stack storage as well if poorly coded).

    So the way to test this is with much larger values for int1 and int2.  Use 0x76767676 for int2 and see whether int1 occasionally ends up with 0x76 or 0x7676 or even 0x767676.

    The second test, assuming you're able to recreate the situation quoted in the article, at least occasionally (1 in 1000 is fine), is to print out the addresses of the variables and see if there is a pattern.  I hope you have an address operator, so you can:

    if (int1==0) print(&int1, &int2) ;

    Of course, there's always the chance that the print function itself is overwriting memory, but that's gotta be a long shot.  

    Seen worse, mind you.


Log in to reply