• (cs) in reply to The Anonymous Coward
    Anonymous:
    Anonymous:

    I had something very similar happen recently.  Turns out the compiler (gcc) was bungling an optimization.  The fix was to compile with "-fno-strict-aliasing".

    Well, many optimizations make assumptions about your program's behavior, and if your program breaks those assumptions, then you have to turn off the optimization.

    Now I don't know what your code does -- nor do I know much about the "strict aliasing" optimization -- but unless you've read up on the optimization options enough to know that you "shouldn't" have to turn this one off, I wouldn't rush to saying the compiler "bungled" it or was wrong in any way.

    Most don't make any assumptions (if designed correctly), but unfortunately, this one does make some assumptions. It assumes you won't do certain things involving pointers and typecasting - basically (as I understand it), that you won't have two pointers of completely different types pointing to the same bit of memory (with certain execeptions - see the gcc manpage). If you've enabled -Wstrict-aliasing or -Wall, it should warn you about the most obvious cases, though it can't catch them all. The warning usually seems to be "type-punned pointer breaks strict aliasing rules".

  • Franko (unregistered) in reply to Sweets

    9600 was available on dedicated lines, not general lines, way back when.


  • Reinder (unregistered) in reply to RogerC

    Couldn't you have done either of the following:

    • replace the interrupt handler by one that knew about this behaviour (this will only work if the processor does not push data on the stack before the interrupt handler runs)? (writing BELOW the stack pointer is valid in the Macintosh PowerPC ABI; its interrupt handler does just this)
    • get you linker to find your version of the functions?
  • Theo (unregistered) in reply to MattJ

    8192 is 2^13. Unlucky for some, lucky for workarounds I guess

  • clvrmnky (unregistered)

    There is a small bug in Java TCP/IP on Windows, where you will get connection reset errors on a perfect and by-the-book teardown of the connection.  This can cause all sorts of problems when you have a server on big iron (some Unix, all OS/390) that expects the connection to close gracefully and w/o error.

    I found an obscure reference to this in the JVM "features" documentation that recommends sleeping the thread for a bit before sending back the final close.  I wen whole-hog and made the sleep value a hidden property we could turn on or off as necessary.

  • Anonymous (unregistered) in reply to Mike Stewart
    Anonymous:
    In a developer product I was working on, customers would get random and unreproducible crashes in the apps they wrote.  This went on for months.  To make a very long tale of woe short, it was finally narrowed down to some printing scenarios.  After finding a short, reliable repro (division by zero in a printing scenario), the cause was found:  print drivers from some companies were resetting the hardware error handling in the FPU for some unexplained reason.  If a developer generates a div/0 error in their app (or usually something more complex than that), the FPU thinks the software will handle it, and when it doesn't:  crash.

    Workaround:  sprinkle calls to _fpreset anywhere one might think the print driver has fiddled with the FPU.


    One version of Photoshop (5.0 IIRC) had the same problem. Adobes workaround: Tell the user to select Help->About Photoshop after any operation involving the printer driver. Fortunately it was fixed in a patch some time later.

  • JY (unregistered) in reply to bit
    Anonymous:

    HitScan:
    Anonymous:
    Wow. Why 8192?


    Workarounds2 is most likely a DWORD in the registry, and almost certainly used as a bitflag in the program. 8192 is the 14th bit in a DWORD.

    Of course, if you've got other things turned on in Workaruonds2 and you replace the old number with 8192, you just broke something else!

    It should instruct you to add 8192 to the value of that variable.

    Not that the whole thing is not crazy enough, you know.



    Um, no this action calls out the quoted poster's concern -- if the bit's already set, it can become unset by adding some values...  + ain't ||

  • (cs) in reply to JY

    Anonymous:

    Um, no this action calls out the quoted poster's concern -- if the bit's already set, it can become unset by adding some values...  + ain't ||

    If the bit's already set there's no need to set it again, is there? *roll eyes*

  • JY (unregistered) in reply to iwpg
    iwpg:

    Anonymous:

    Um, no this action calls out the quoted poster's concern -- if the bit's already set, it can become unset by adding some values...  + ain't ||

    If the bit's already set there's no need to set it again, is there? *roll eyes*



    My comment was about the "add" being a bad instruction to give a user because telling someone to blindly "add x to y"  as the poster suggested, does not consider the current value of the magic bit, so it is no safer than telling them to just stuff 8192 into the box, wiping out any other bits that had been set (as suggested in the first post that the "add 8192" poster was commenting on)

    The instructions seem to assume that the user either has no way of figuring out if the magic bit is set, or wouldn't be told that the purpose of "8192" is to turn on one bit...

    (I'm presuming, based on considerable experience, that many people with problems will be told to "try this fix" or might be told to do it more than once

  • monster (unregistered) in reply to That Guy

    Anonymous:
    You've done this lots of times?  I wouldn't.  IMHO, if you need the current time to generate unique ID's, as Notes seems to do for "Replica ID's and document UNID's", you are doing it wrong.  Generate your unique ID's some other more reliable way, and attach the appropriate timestamps (say, for transactions, using your example) to the appropriate ID.

    Well... the immediate WTF IMHO is that Notes used a ridiculously low ticks/second value of 100. Make that 2^64 and that problem is gone for good. Of course using time for a unique ID is still a problem, since even the server time can (and will) jump forward and backward (!) - e.g. when you synchronize with a time server. Jumping forward usually isn't a problem, and for small deltas jumping backward can be bypassed by slowing down the clock for a short time - but that still leaves us with jumping backward by a huge amount of time. In that case your unique IDs are gone, and so is the "sequence number" attribute of the timestamp.

    That's a nasty problem in IT systems - and using pure sequence numbers doesn't solve everything. E.g. a transaction B that happened after some other transaction A can have the proper sequence number (B > A), but those transactions can still have timestamps A > B which is confusing at least. Users don't like such things, and programmers must be very aware of this when extending/maintaining the system.

  • rp (unregistered) in reply to Ross Patterson

    My first programming courses were on a VM/CMS system (actually built by Siemens I believe), so we would spend a lot of time compiling and running our exercise programs. We were told to keep hitting the ENTER key while this was in progress; this would cause the scheduler to notice that the job, being "interactive", needed higher priority.

    I never took the trouble to verify this. It does make sense; the population of the system was very diverse, mixing highly interactive use with very long term batch processing.

  • (cs) in reply to rp
    rp:
    My first programming courses were on a VM/CMS system (actually built by Siemens I believe), so we would spend a lot of time compiling and running our exercise programs. We were told to keep hitting the ENTER key while this was in progress; this would cause the scheduler to notice that the job, being "interactive", needed higher priority.

    I never took the trouble to verify this. It does make sense; the population of the system was very diverse, mixing highly interactive use with very long term batch processing.



    This sounds like you made your course at the "Spengergasse"?

  • rp (unregistered) in reply to Fred

    This reminds me of the CGI script I wrote two weeks ago. It calls a commandline application for which I do not have the source code. The application works fine when called on the command line, but invariably crashed when called through the CGI script.

    The fix: prior to invoking the application, set some arbitrary environment variable to a large enough value (the script uses "aaaaa(...)rgh" with a thousand "a"s).

    I think we can all guess which language this application was written in. The WTF, as far as I'm concerned, is that people who should know better keep defending this language. Some even propagate it for entry-level programming courses.

  • Metaspace (unregistered)

    Anyone read the entry in the Lotus Bug DB?

    This coupled with the dramatic advances in >processor speed at a rate much higher than >anyone predicted, have exposed this as a major >limitation.

    LOL! And this after Moore'sLaw and all :-)

  • (cs) in reply to Metaspace

    I was making a file system for flash chip on an embedded system. After some changes the chip would start to lose all the data written to the file system after reprogramming the system. The problem was fixed by adding sleep(500) to the beginning of the file system initialization routine.

  • Chris (unregistered) in reply to JoeBloggs
    Anonymous:
    Well, I managed to narrow it down to one function, but when I put dialog-box calls in the function to try to find which line was causing the problem, the program worked perfectly. I found that simply setting up for displaying a dialog box without actually displaying it would solve the problem, so now the code has a line in it with the comment: /* Fixes a bug with the program segfaulting while reading from a file. It works. Trust me. */


    We've had a similar one, in PHP. A certain script would cause PHP to segfault every now and then, until we put in a line to send us an e-mail when it started up. Works fine now!
  • Kyuz (unregistered)

    The .NET framework 1.x had/has some pretty hellacious bugs that could really sneak up on you.  Take for example http://thedotnet.com/nntp/127816/showpost.aspx.  Copying to the clipboard would throw an exception for no reason, and this behavior was completely random; would only happen on some machines some of the time with no apparent pattern.  QA went nuts trying to reproduce, luckily google saved the day.  The best workaround I could come up with was just to retry the copy operation N times and then fail gracefully, however it always ended up working on the 2nd or 3rd try....

    Another horrible one was http://www.thescripts.com/forum/thread102504.html.  Our testing servers in certain configurations were dying rather quickly due to being unable to open files/sockets/etc.  Perfmon told me it was because there were too many OS handles open.  Looking at the process with Sysinternals handle viewer showed 10,000 or so open registry handles...oops! The problem was, after a thorough audit of the code, there was no possible way that I wasn't Close()ing every registry key I was opening.  Besides, even with previously experienced handle leaks, I had never seen anything happening this fast.  However I resisted what now seems obvious because I couldn't believe that MS would ship a somewhat important class like RegistryKey that didnt implement Close() properly.  Blech.  When I finally decompiled the framework libraries I found this:


    private void Dispose(bool disposing) {
        if (hkey != RegistryKey.INVALID_HANDLE_VALUE && !(this.GetSystemKey())) {
            Win32Native.RegCloseKey(this.hkey);
            this.hkey = RegistryKey.INVALID_HANDLE_VALUE;
        }
    }

    The problem was that when calling RegistryKey.OpenRemoteBaseKey, the key being returned was set such that GetSystemKey() returned true.  Makes sense right, I mean HKEY_LOCAL_MACHINE is a *system* key.  Why should it matter that this system key happens to reside on a remote machine?

    My fix in this case was to implement my own RegistryKey class using the Win32 Reg* API.

    Problems like this ended up being so common that I now ask any interviewee who claims to have worked with .NET to give me an example of a bug they've experienced in the framework/class libs.  If they can't think of one then I become suspicious that they've lied about how much experience they have :p.

  • (cs) in reply to GoatCheez
    <font color="#000000"> Really unrelated, but king of related. There's a game I play that fails to run on my Athlon64 X2 4200. It gets disconnected/crashes when I try to log on. I went to the forum, and the workaround is: Switch to an Intel processor. Apparently, the bug has something to do with the fact I have two processors. I wonder if the bug is exposed on the recent Intel dual core processors as well? Either way, WHAT A CRAPPY WORKAROUND!
    </font>
    I ran into this with, I think it was, Thief on my "hyperthreaded" Intel CPU.  The symptom was that the program would just freeze after playing it for a while. The "solution" was to modify the executable so it would run only on the first virtual CPU (or to turn off hyperthreading.)  I assume the same workaround would work (and be necessary) on the dual-core CPU in my laptop.

    There were two levels to the workaround.  Level 1 is this: every time you run the program, you go into Task Manager and set it  to run only on one CPU.  Level 2 involved downloading a program that would change something in the .exe file to bind the program to a single CPU.  I don't remember the name of the program, though.


  • Tox (unregistered) in reply to JoeBloggs

    Anonymous:
    I've got an odd workaround of my own for what I suspect is a compiler bug. A program I wrote one time had a habit of crashing while reading a data file. This only happened with one compiler, and only in the release compile, not the debug compile, so I couldn't simply attach a debugger and see where the crash was occurring. Instead, I would narrow it down by having the program display a series of dialog boxes, and see which ones got displayed before the crash. Well, I managed to narrow it down to one function, but when I put dialog-box calls in the function to try to find which line was causing the problem, the program worked perfectly. I found that simply setting up for displaying a dialog box without actually displaying it would solve the problem, so now the code has a line in it with the comment: /* Fixes a bug with the program segfaulting while reading from a file. It works. Trust me. */

    No that doesn't fix the bug. You must be having a memory leak somewhere, and the additional function calls to displaying the dialogbox has "stretched" the range of "valid memory".

    Similiarly I notice sometimes an array declaration alleviates segfaults, e.g. int segfaultbuster[1024]; or int * segfaultbuster = (int*)malloc(1024); note that the previous one 'works' better if the segfaults are caused at load time.

    Again, that's NOT a fix.

  • (cs)
    Alex Papadimoulis:

    I've had to use some rather strange workarounds to get things working, but none like these two. Today's post is an "interactive" one, so go ahead and post your own workaround stories in the comments.

    Rusty B was having trouble connecting to a Sybase database through Access. He just kept receiving the following error message:

    reserved error (-7748): there is no message for this error

    Thankfully, Google led him to the solution in Sybase's Knowledge Base: 

    To resolve this error, set WorkArounds2=8192 for your data source.

    This can be done by using the registry editor (REGEDIT).

    Damn!  I finally get a WTF posted and I was on vacation that week ....

    I was waiting for someone to say 'The real WTFis that he was using Access' but no one bit.

  • rp (unregistered) in reply to ammoQ

    (It was the university of Nijmegen, actually.)

  • (cs)

    There is a good Microsoft Workaround for old Foxpro apps.  Simply set the maximum memory to 128 MB in  your boot.ini.  Of course windows runs like a sloth on methadone, but the foxpro app will start!

     

     

  • robbak (unregistered) in reply to Rank Amateur
    Rank Amateur:

    There was a time when a rank amateur like myself could read one book by Peter Norton and know just about all there is to know about PCs. That era had clearly ended when I migrated from Windows 95 to XP.

    After installing my perfectly legal copy of Access 97, it wouldn’t execute, displaying an error message saying there was no license for it. Fortunately the workaround was documented in Knowledge Base Article #141373:

    Step 1: Go to your font folder.

    Font?

    Step 2: Find the file for the Haettenschweiler font.

    Haettenschweiler??

    Step 3: Change the extension of this file.

    How can this possibly be related to registering a license???

    Step 4: Reinstall Access. You can revert the extension after installation is complete.

    WTF????

    It worked perfectly. But it was then that I realized that I had no hope of really understanding computers anymore.

    --RA



    Oh, yes, I've _done_ that workaround. I think that the apparently missing file fools the install into adding the required licence keys to the registry.

    That said, Before I read the kb, I found where the keys were in the registry, using the old binary division  method - Yes, export the entire registry on a working machine, and import bits of it untill it starts/stops working (Licence was misspelt license, for obscurity!) - , and did a small registry export and imported it whenever the problem occoured. Made me look real good when I emailed a .reg file to someone and had them working in 5 minutes!

    CAPTCHA:awesomeness
  • (cs)
    Alex Papadimoulis:
    I've had to use some rather strange workarounds to get things working, but none like these two. Today's post is an "interactive" one, so go ahead and post your own workaround stories in the comments.


    This week's issue of "InfoWorld" has a cover story "Heroic Hacks and Inspired Work-arounds".  They seem to think that they are good things.  I think that they fail to separate making it go right and technical ugliness.  The former is important; the latter is very unfortunate.

    Sincerely,

    Gene Wirchenko

  • Jesper Stocholm (unregistered)

    I worked on a project that uses MSSql 2k and it's BULK-INSERT statement. The system initially deletes data from a bunch of tables and afterwards inserts data into these tables again. The statement spawns a lot of threads when executing - all of which are out of control of the caller.

    We started experiencing deadlocks when runing jobs that deleted only a small amount of data. We consulted Microsoft PS but they could not identify the source of the lock. Our own analysis indicated, that some of the threads deleting data were not finished before BULK-INSERT started inserting data into the tables again. We tried to insert some delays in the code to "let the threads finish", but we could not determine exactly how long we should let it wait.

    Due to some other errors we discovered that we had to let BULK-INSERT check for constraints when loading data - something it does not do per default. Since the system is performance-critical, we hesitated to deploy this feature since it greatly diminishes performance. However, we realized that when we had it check for constraints - and thereby slowed down the system considerably - the problem with dead-locks dissapeared.

    We still don't know what caused the dead-locks ... but it has not shown it's ugly face since.

    :o)

  • (cs)

    I haven't seen alot of javascript around here. So here is my hack/workaround for reading binary files in IE using the "Scripting.FileSystemObject".

    For security reasons you are only able to open a file as a textStream. This ofcourse works perfectly except on images and the sorts. So i have written this function to work around the limitations the scriptingFileObject has. When you encouter a illegal ASCII value with your text stream it always returns some strange 2 byte value. It's not a unicode charcter it seems pretty random. But it is the same for the value you realy need. 

    function getByte(inByte){ 
  switch(inByte){ 
    case 0x0152: return 0x8C; 
    case 0x0153: return 0x9C; 
    case 0x0160: return 0x8A; 
    case 0x0161: return 0x9A;  
    case 0x0178: return 0x9F;  
    case 0x017D: return 0x8E;  
    case 0x017E: return 0x9E;  
    case 0x0192: return 0x83;  
    case 0x02C6: return 0x88;  
    case 0x02DC: return 0x98;  
    case 0x2013: return 0x96;  
    case 0x2014: return 0x97;  
    case 0x2018: return 0x91;  
    case 0x2019: return 0x92;  
    case 0x201C: return 0x93;  
    case 0x201D: return 0x94;  
    case 0x2020: return 0x86;  
    case 0x2021: return 0x87;  
    case 0x2022: return 0x95;  
    case 0x2026: return 0x85;  
    case 0x2030: return 0x89;  
    case 0x2039: return 0x8B;  
    case 0x203A: return 0x9B;  
    case 0x201A: return 0x82;  
    case 0x201E: return 0x84;  
    case 0x20AC: return 0x80;  
    case 0x2122: return 0x99;  
    default: return inByte; 
  } 
}

    And using this hackish function it seems you can actually read binary files. Have fun bashin it =P

  • Syrion (unregistered) in reply to Coughptcha
    Coughptcha:
    Gene Wirchenko:
    There were some run-times that measured the speed of the system when starting up.  When systems got too fast, the counts would overflow.

    Sincerely,

    Gene Wirchenko

    CPUs aren't the only things that can go faster than exptected.  As I understand it (and I'm sure someone will correct me), when the European Space Agency launched the first Ariane 5 rocket, it used the Ariane 4 guidance algorithms.  Unfortunately, the Ariane 5 ran faster, and, well, ESA had disastrous results.  Something about an overflow on a conversion ...


    It was not exactly that.
    In fact, Ariane 5 had a larger drift range than Ariane 4. When the max drift angle is exceed, it means the rocket is starting to fall back to Earth.... To avoid any civil disaster, the Ariane rocket auto-desctruct itself in case of drift overflow.
    The WTF was : Ariane 5 had phycically a larger drift range, but had programatically the Ariane 4 drift range (due to some WTF programmer). So when Ariane 5 started to drift and exceed Ariane 4 max drift angle, the software told the rocket to explode.
    I think this WTF is a record since it is the most expensive WTF in the story of I.T. Billions of Euros returned to ashes juste because the wrong soft version has been deployed....
  • damon (unregistered) in reply to Dre

    hihi,

    can you please explain to me how this works?

    lets say i am going to open a .jpg file, and i create a textstream object outta it by

    var xxx = fso.openTextFile("C:\blah.jpg");

    and then i parse xxx byte by byte to convert these numbers to a hexademical representation?

    regards

    damon

     

     

    Dre:

    I haven't seen alot of javascript around here. So here is my hack/workaround for reading binary files in IE using the "Scripting.FileSystemObject".

    For security reasons you are only able to open a file as a textStream. This ofcourse works perfectly except on images and the sorts. So i have written this function to work around the limitations the scriptingFileObject has. When you encouter a illegal ASCII value with your text stream it always returns some strange 2 byte value. It's not a unicode charcter it seems pretty random. But it is the same for the value you realy need. 

    function getByte(inByte){ 
  switch(inByte){ 
    case 0x0152: return 0x8C; 
    case 0x0153: return 0x9C; 
    case 0x0160: return 0x8A; 
    case 0x0161: return 0x9A;  
    case 0x0178: return 0x9F;  
    case 0x017D: return 0x8E;  
    case 0x017E: return 0x9E;  
    case 0x0192: return 0x83;  
    case 0x02C6: return 0x88;  
    case 0x02DC: return 0x98;  
    case 0x2013: return 0x96;  
    case 0x2014: return 0x97;  
    case 0x2018: return 0x91;  
    case 0x2019: return 0x92;  
    case 0x201C: return 0x93;  
    case 0x201D: return 0x94;  
    case 0x2020: return 0x86;  
    case 0x2021: return 0x87;  
    case 0x2022: return 0x95;  
    case 0x2026: return 0x85;  
    case 0x2030: return 0x89;  
    case 0x2039: return 0x8B;  
    case 0x203A: return 0x9B;  
    case 0x201A: return 0x82;  
    case 0x201E: return 0x84;  
    case 0x20AC: return 0x80;  
    case 0x2122: return 0x99;  
    default: return inByte; 
  } 
}

    And using this hackish function it seems you can actually read binary files. Have fun bashin it =P

  • RaviS (unregistered) in reply to Bus Raker

    Hi,

    I tried the given solution. but didn't solve the issue. I am using Access 2003. Can u suggest any othe solution?

    Thanks,

     

    Bus Raker:
    Alex Papadimoulis:

    I've had to use some rather strange workarounds to get things working, but none like these two. Today's post is an "interactive" one, so go ahead and post your own workaround stories in the comments.

    Rusty B was having trouble connecting to a Sybase database through Access. He just kept receiving the following error message:

    reserved error (-7748): there is no message for this error

    Thankfully, Google led him to the solution in Sybase's Knowledge Base: 

    To resolve this error, set WorkArounds2=8192 for your data source.

    This can be done by using the registry editor (REGEDIT).

    Damn!  I finally get a WTF posted and I was on vacation that week ....

    I was waiting for someone to say 'The real WTFis that he was using Access' but no one bit.

  • (cs)

    Not exactly a "programming" workaround, but here goes..
    There was this DOS-based game called Cyberia which didnt have an explicit save feature. The game however had checkpoints, and it auto-saved your progress at those checkpoints.
    However, there were certain series of checkpoints which would always "dissapear" upon exiting the game.
    This essential meant there was no way for me to complete the game unless I played it all at a stretch, without even exiting the game.
    I knew the game had to be saving the progress in some sort of "savefile", so I noted down all files in the game directory before starting the game, and after exiting the game.

    The solution?
    >copy savefile1 savefile2

    Oh, and I was only 12 years old then :P

    PS: Thank you MS-DOS. Those years of tweaking config.sys/autoexec.bat, writing custom batch files, etc, sure helped train my young mind.


  • CrushU (unregistered) in reply to GizmoC

    A-MEN to that PS. So much about learning in MS-DOS (actually first learned in Atari BASIC. Ugh.) has helped me think better about solutions.

  • wow gold (unregistered)
  • Paolo (unregistered)

    We had to manually install a COBOL application, executed in a MSDOS prompt under windows xp, on three hundred PC, via remote control. For evry installation, the application had to import a very large amount of data, and the process took more than 2 hours for every PC. Then we found that we could drammatically speed up the import speed, if the MSDOS promt windows was the active windows and keeping pressed the space key. (please, don't ask) A futrther improvement to the installation process was blocking the space key in the pressed position using a coin stuck between the key and the keyboard.

    ...

Leave a comment on “Oh, the Workarounds”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article