Comment On Oh, the Workarounds

Of course, slow the server down, that makes so brillant.
Oh, and why wasn't Workaround2=8192 obvoius? I mean, I would have guessed it.

(Edited by moderator)

W.O.W. !!!

Sounds like someone coded themselves into a corner and put in an: if (hackFlag) goto xxx

Wow. Why 8192?

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.

Visual FoxPro has some things similar.  The SQL implementation has been getting tightened up.  Some people were using invalid aggregation/group queries.  (A column which is neither aggregated nor grouped is not allowed in such queries.)  Later versions of VFP enforce this.  To get around this, the later VFP versions also have a command to use the previous SQL behaviour.

Sincerely,

Gene Wirchenko

Anonymous:

Wow. Why 8192?

2^13.  I'd say that somewhere deep in the madness there is a bitfield...and each position along that bitfield is like a magic door to a hidden execution path, each leading somewhere fascinating and new.  And if so, the workarounds can be combined...heaped, one on top of the other...I wonder what setting it to 4294967295 might do?

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!

Edit: Drats! Beaten  by seconds.

  

Anonymous:

Wow. Why 8192?

Ever heard of binary?

8192 = 00010000000000000

Alex Papadimoulis:

• We have had success migrating a server to a slower, less-powerful 

  machine to minimize time creep i.e. Dual Pentium 200mhz instead 

  of Quad Pentium 400mhz.



• Add debug code to the NOTES.INI to generate more log output 

  which will slow the server down. The more logging a server does, 

  the slower it runs.

I heard a story about one of the clients of a lab I worked at in college: They had a scheduling application that ran on DOS and stored files in Novell. This is circa 2000, so they actually ran the app in a DOS box in Windows 9x (IIRC) on 486s and Pentiums. Well, certain functions of this program actually CRASHED if they took less time than the author expected. (Div0 error, maybe?)

The workaround: install old 'turbo' toggle switches connected to the vestigial speed switch header on the motherboard and slow the computer down to 40MHz (or so) while the app is active.

Brendan Kidwell:

I heard a story about one of the clients of a lab I worked at in college: They had a scheduling application that ran on DOS and stored files in Novell. This is circa 2000, so they actually ran the app in a DOS box in Windows 9x (IIRC) on 486s and Pentiums. Well, certain functions of this program actually CRASHED if they took less time than the author expected. (Div0 error, maybe?)

The workaround: install old 'turbo' toggle switches connected to the vestigial speed switch header on the motherboard and slow the computer down to 40MHz (or so) while the app is active.

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

Anonymous:

Anonymous:

Wow. Why 8192?

Ever heard of binary?

8192 = 00010000000000000

I'm sure everyone reading tdWTF is aware of what the number 8192 is.  But that question was "Why 8192?" 

Why not 4096?  Why not 8191, or 8000?  Is it a bitfield?  A bit mask?  Is it a countdown initializer?  Is it an index into some other structure?  Is it some other magic number (e.g. a dimension for an array)?

Gene Wirchenko:

Brendan Kidwell:

I heard a story about one of the clients of a lab I worked at in college: They had a scheduling application that ran on DOS and stored files in Novell. This is circa 2000, so they actually ran the app in a DOS box in Windows 9x (IIRC) on 486s and Pentiums. Well, certain functions of this program actually CRASHED if they took less time than the author expected. (Div0 error, maybe?)

The workaround: install old 'turbo' toggle switches connected to the vestigial speed switch header on the motherboard and slow the computer down to 40MHz (or so) while the app is active.

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

More likely, they were using hard coded timing loops, presuming that each iteration would take x amount of time. As processors got faster, the loop would finish before whatever was in the parallel execution path would complete, and continuing on after the timing loop completed  (too soon) would lead to unpredictable results.

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 ...

Isn't it always the small stuff? On the space shuttle Challenger, the guidance stuff worked perfectly - but the O-ring seal blew a hole and ...

Reminds me of when I bought the PC release of Ultima I-VI on CD for $50. I would get a divide by zero error when I tried to run Ultima II. I had to download MoSlo to reduce chip-speed to play that game.

Though the best part was trying to board the new pirate ship on Ultima III before the supersonic whirlpool got it.

The year was 1979, and we were running an IBM product called "VNET" that allowed two mainframe computers to communicate directly over a "high speed" (9600 baud) phone line or a "channel-to-channel adapter" (CTCA) for job-sharing etc. Our end would occasionally drop the connection, often enough to be a problem but not often enough to have someone watch it for failures.

The product could have a console connected to it, and that proved to be the answer. When the console was connected, status and diagnositic messages were written to it, and the product as a whole slowed down. Not dramatically, but enough to keep the small timing problem from ever occurring. We ran that way for over six months, with a "DO NOT TOUCH ME" sign on that one terminal.

Gene Wirchenko:

Brendan Kidwell:

I heard a story about one of the clients of a lab I worked at in college: They had a scheduling application that ran on DOS and stored files in Novell. This is circa 2000, so they actually ran the app in a DOS box in Windows 9x (IIRC) on 486s and Pentiums. Well, certain functions of this program actually CRASHED if they took less time than the author expected. (Div0 error, maybe?)

The workaround: install old 'turbo' toggle switches connected to the vestigial speed switch header on the motherboard and slow the computer down to 40MHz (or so) while the app is active.

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

Oh, you mean something like:

int numOps = 1000;
startTime = getTime();
for (i = 0; i < numOps; i++);
endTime = getTime();
float speed = numOps/(endTime-startTime);

For years I wondered why Ultima II gave me a div by zero error. All so obvious in hindsight...

Coughptcha:

Anonymous:

Anonymous:

Wow. Why 8192?

Ever heard of binary?

8192 = 00010000000000000

I'm sure everyone reading tdWTF is aware of what the number 8192 is.  But that question was "Why 8192?" 

Why not 4096?  Why not 8191, or 8000?  Is it a bitfield?  A bit mask?  Is it a countdown initializer?  Is it an index into some other structure?  Is it some other magic number (e.g. a dimension for an array)?

Who cares about the implementation?

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. */

Here's a function I had to create to be able to turn on Option Explicit in our legacy ASP 3.0 site:

Function DimGlobalIfNecessary( variableName )

    On Error Resume Next

    ExecuteGlobal("Dim " & variableName)

End Function

The crazy thing is that it works.  Scripting languages amaze me sometimes...

Workarounds, ah yes... the bain and bastion for IT folk.

One workaround I was subject to was back in the old LANMan/OS2 days. Our local network administrator had a long-standing server called \\SPIDER and this was our knowledgebase for technical support. That was all well and good until one helpful individual at "corp" decided to put up another server called \\SPIDER which served no useful purpose.

Using the TCP/IP stack was "new" at the time and while it was the predominant protocol for the web, the office was still running XNS protocol, especially for those non-webby people in the building. As I was a webby tech I ran TCP/IP and found that blasted server at the head office, terribly distressing when trying to troubleshoot on the 24/7 shift!

Our local network admin had a solution, that workaround sort, make XNS your primary protocol. Aside from messing up some of my browsing capabilities... THE WAIT WAS OUTRAGEOUS... the preferred solution was to call "corp" and have the Network sorts there STOMP ON THE OFFENDING SPIDER. The problem was solved and never came back... oddly.

Time Creep:
Why does this occur?

There is a need in the product to generate Unique Time Values for
things such as Replica ID's and document UNID's. To implement this
unique time/date, a function was created that would increment a time
value if the current time returned is not unique. The granularity of
time in the Notes products is 1/100th of a second. Therefore this
unique time value would be increased by 1 tick when it is not unique.


Wow.  Let's have a function that returns the current time, unless it already returned the currrent time, then we'll return some arbitrary time in the future.  What could possibly go wrong with that?

We were using a third party Java program that provided a form of XML-based interface in front of a SQL database, connected by JDBC.  We ran into a problem whenever a database table had any form of date, the program would crash.  For a while we were able to make due with just not having any date types in the database.

Eventually we wound up requiring a date field, and since this was essentially a test database before connecting to an actual live data source, we couldn't simply remove columns with dates in them.  Plus, we wanted to be able to write queries against the date column.  Since it was eventually going to connect to a "live" datasource, we couldn't simply replace the date field with an INTEGER or something like that.

So I wound up writing a JDBC3 driver wrapper that removed dates from incoming query results and translated them into integers.  When a query was sent to the database, it would be parsed (-ish, not a full SQL parser, but enough to handle queries the program generated), and any date column that was found would be translated from an integer back into a date.

(It's worth noting that by "integer" I mean Java's int primitive, because returning longs from Date.getTime() would crash the program...)

Our final solution looked like:

[Crappy Java XML Query Program] -> [JDBC wrapper that replaces dates] -> [Actual JDBC driver] -> [SQL database]

Eventually the wrapper got upgrade to add the feature to search on substrings, which the XML query program didn't provide.  Any time a SQL wildcard was seen in a string match, it would be replaced with a LIKE match.  Of course, string matches from the program looked like column >= 'String' AND column <= 'String', so it had to be able to handle that.

And, as people can probably guess, "enterprise" was involved in the project.

(Well, this looks right in the preview, can't wait to see what the forum does to it when I post it!)

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. */

I've had a very similar experience.  Mine was that a 300-line function in a utility library was throwing an exception.  When I began adding try/catch blocks all over the place to find it, however, the problem disappeared.  After a couple hours of exasperation, I discovered that adding this to the very top of the function would prevent the exception:

try{
   ;
}
catch{
   throw;
}

To this day, I have no idea why this works.

Workaround on a game:



Users on my wiki report my game engine crashing on linux (my engine is
a Windows one, but some people on Linux like it). Clever users report
that you can avoid that crash running the engine with -no-ipx, to disable the use of ipx.



$ wine telejano.exe --no-ipx -game malize

.

.

.

crash



The next version whas released with ipx disabled by default and a new command:  -ipx, to enable ipx :D



$ wine telejano.exe -game malize



--Tei

9600 baud in 1979....Holy crap.... I didn't think that was available yet.

My BBS was running 2400 until the 90's

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 ...

I knew it sounded wrong

A data conversion from 64-bit floating point to 16-bit signed integer value had caused a processor trap (operand error). The floating point number had a value too large to be represented by a 16-bit signed integer. Efficiency considerations had led to the disabling of the software handler (in Ada code) for this trap, although other conversions of comparable variables in the code remained protected.

Source: http://en.wikipedia.org/wiki/Ariane_5#Launch_history

codeman:

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.

More likely, they were using hard coded timing loops, presuming that each iteration would take x amount of time. As processors got faster, the loop would finish before whatever was in the parallel execution path would complete, and continuing on after the timing loop completed  (too soon) would lead to unpredictable results.

That is probably closer to what I thought.  Parallel execution sounds a bit too late for this though.  Anyway, Bad Stuff happened whatever the cause.  Memory bit rot strikes again.

Sincerely,

Gene Wirchenko

Anonymous:

Anonymous:

Wow. Why 8192?

2^13.  I'd say that somewhere deep in the madness there is a bitfield...and each position along that bitfield is like a magic door to a hidden execution path, each leading somewhere fascinating and new.  And if so, the workarounds can be combined...heaped, one on top of the other...I wonder what setting it to 4294967295 might do?

I was going to say because
8192/42 = 195.04761_

But upon retrospect, I like your answer better.

Our shop just got rid of Sybase ASE. The good ol' workarounds2 is a great example of stuff I won't miss.

Anonymous:

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 ...

I knew it sounded wrong

A data conversion from 64-bit floating point to 16-bit signed integer value had caused a processor trap (operand error). The floating point number had a value too large to be represented by a 16-bit signed integer. Efficiency considerations had led to the disabling of the software handler (in Ada code) for this trap, although other conversions of comparable variables in the code remained protected.

Source: http://en.wikipedia.org/wiki/Ariane_5#Launch_history

 

Sorry, I stand corrected:

The Ariane 5 software reused the specifications from the Ariane 4, but the Ariane 5's flight path was considerably different and beyond the range for which the reused code had been designed. Specifically, the Ariane 5's greater acceleration caused the back-up and primary inertial guidance computers to crash, after which the launcher's nozzles were directed by spurious data. Pre-flight tests had never been performed on the re-alignment code under simulated Ariane 5 flight conditions, so the error was not discovered before launch.

SourcE: http://en.wikipedia.org/wiki/Ariane_5_Flight_501

Uhhh yeah.... That's why I've never reccomended Lotus Notus to anyone
anywhere ever. Also why I've reccomended that everyone using Notes
ditch it ASAP. I really think that Engineers should choose the software
the company uses instead of managers. If that were the case, then Notes
would be LONG GONE. Technically just an opinion tho ;-).



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!

Coughptcha:

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 ...

Yes, I read a fair bit about that and did a report while taking my diploma.  There was a routine that allowed for a fast reset.  In the case of an aborted launch, it would take several hours to reset an Ariane 4.  This routine dealt with shortcutting that.  It was this routine executing on the Ariane 5 that caused the problem.  The big WTF is that the routine was not required on the Ariane 5.

Sincerely,

Gene Wirchenko

Oh my.



Borland C circa 1995.  I have a exception being thrown, but I
can't figure out where, while messing around I simply changed the order
of 2 lines, from:

i++;

nCounter=nCount2 + nCount3;



to:

nCounter=nCount2 + nCount3;

i++



no idea why this resolved it, but we were under time pressure to release so I could not investigate further.



lots of other incidents, but that one stood out for just pure
WTF.  My current code base starts out written by folks in the late
80's in pascal and assembly, then converted over to c++ on windows 3.1
machines, then upgraded for win95 while retaining 3.1
compatibility.  Theres some WTF's in here, and tons of "band aids".

Anonymous:

I've had a very similar experience.  Mine was that a 300-line function in a utility library was throwing an exception.  When I began adding try/catch blocks all over the place to find it, however, the problem disappeared.  After a couple hours of exasperation, I discovered that adding this to the very top of the function would prevent the exception:

try{
   ;
}
catch{
   throw;
}

To this day, I have no idea why this works.

I had one that bugged me for a long time. We had an old program written in C that, occassionally, would crash for no bloody reason at all. I was able to track it down to certain types of input, but it wouldn't always occur with any given input. Like one in a 10,000, sort of thing. This wouldn't have been so bad, if I had the ability to log the damned data.

See, the logging functionality was all implemented by this pre-existing chunk of code. It is quite nice, actually, you can turn logging on and off, levels of logging etc, etc, but the problem is that the crash never happened if you turned on the logging. I turned on the logs on the system and let it run for months that way, never got the problem to recur. Turn logging off and the crash happened 8 times a day.

Natural workaround: Leave logging on. Unfortunately, the logging in the program itself was rather robust, it put out huge amounts of logfile and rapidly filled the disk. Solution: cron job to clean the logs every hour or so.

After running this way for about 8-9 months, eventually someone was finally able to track it down to a stack overflow problem in some really obscure way that nobody had ever seen before. Turning on the logging changed the way variables were allocated on function calls because it loaded the logfile name into the stack before the rest of the stuff, or something to that effect. So the overflow went into a different place at the end of the function. Without logging, the logs filename wasn't on the stack, and so it overwrote the return address instead.

loneprogrammer:

Time Creep:
Why does this occur?
There is a need in the product to generate Unique Time Values for things such as Replica ID's and document UNID's. To implement this unique time/date, a function was created that would increment a time value if the current time returned is not unique. The granularity of time in the Notes products is 1/100th of a second. Therefore this unique time value would be increased by 1 tick when it is not unique.


Wow.  Let's have a function that returns the current time, unless it already returned the currrent time, then we'll return some arbitrary time in the future.  What could possibly go wrong with that?

You got a better idea?  I've done this lots of times.

Who's gonna know - or care - whether the 2nd transaction occurred at 12:34:56.42 (as it claims) or when it really happened, which was sometime shortly after 12:34:56.41 (cause we know .41 already happened!).

You can increase the resolution of the timer, but it'll never solve the problem - just put it off for another day when they get faster computers.

If it helps, don't think of it as a timestamp - think of it as an arbitrary sequence number that (in virtually all cases) can be readily mapped back to a human-comprehensible date/time value by a human.

As long as the transaction don't often come in at a rate of >100/sec, you're fine. And even if they do, you're still fine, but the "virtually all cases" claim above gets weaker and weaker...

Anonymous:

I simply changed the order
of 2 lines, from:

i++;

nCounter=nCount2 + nCount3;



to:

nCounter=nCount2 + nCount3;

i++

In a long-ago job (before I started using Perl) I had a longish awk/ksh script that started giving me a Bus Error. Adding traces made the error stop (frustrating).



I eventually checked in a workaround: the original script with two new lines at the top.



# do not remove the following line

echo '';

You know, I've been lurking here for quite some time... mostly looking for examples of things not to do but today I came across something that I just felt I had to share. Let me preface this by saying that the horror that I'm maintaining was not produced by me. I inherited it.

We have an.... application that is essentially a front end for our SQL database. It was done in unfortuenately, Access. So one day I was trying to figure out why it took so long for labels to print for the product that was ready to be shipped. Well the label program actually updated our database in a scan_ship field. I ran the query in Query Analyzer and the average time the query took was a minute and thirty seconds. It was the access front end that was to blame. When an order was made this frontend actually CREATED TRIGGERS that would email the customer when the tub shipped. So I checked our main table. It had 200+ triggers on it that ran when scan_ship was updated. The funny thing is that I think this actually was a workaround because my predecessor couldn't figure out a better way to do it. So I wrote 1 trigger that did the work of all of those others, deleted the 200+ triggers and the query suddenly takes less than a second to run.

*stabs self in eye with spork*

Coughptcha:

Is it a bitfield?  A bit mask?  Is it a countdown initializer?  Is it an index into some other structure?  Is it some other magic number (e.g. a dimension for an array)?

It's a bit flag indicating a behavior to take in the event-handler that calls for this registry value to be checked.  As another poster pointed out, setting WorkArounds2 = 8192 wipes out all other flags in the DWord.  Unless this was the desired result, they should have said, "Or the value of WorkArounds2 with 8192".

Alex Papadimoulis:

Today's post is an "interactive" one, so go ahead and post your own workaround stories

Well, anyone who's tried to get a standards-compliant website to work in Internet Explorer could fill a fortnight's worth of DailyWTF with horrible work-arounds. But those are perhaps a bit too well known.

My most memorable work-around involved the driver I wrote for an electro-mechanical device which used electric motors and belts to move products, and light-emitting and light-sensitive diodes to detect their positions. It was working fine - then one day it suddenly developed intermittent faults which looked suspiciously as if they might have something to do with my driver. After puzzling over it for a while my colleague came up with a brilliantly simple and effective work-around - he put a cardboard box on the machine.

Puzzled? Well, I was for a few seconds as well. What was happening was that when the sun came out, enough light was getting on the light-sensitive diodes to overwhelm them, and they could no longer "see".

I had game from sierra called Gabriel Knight. The games manual said something to the extent "This game was built for 386 -- 486 computers. If you are using a pI of 1 gig or more you need to run the program called cpu eater (or sum such name)." The program would actually eat up clock cycles slowing the processor down however many percents you chose. I typically used 50% which ofcourse slowed my computer down half way.

We could use this application on the server any time you need to slow it down just increase the percentage rate!

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. */

I'm going to guess that you were using C/C++ for this?

I've dealt with tonnes and tonnes of similar problems in C over the years. They've always been the result of a buffer overflows of some sort. Having that extra code there sets things up just right that its able to continue on. Pain in the butt to track down the problem without help from compiler tools, since it could be anywhere.

The real WTF is idea of 'code reuse', which caused this whole "Time Crap" problem and blew up the Ariane the5th.

Everyone knows that the quickest way to fix timing issues is simply to change the timing.

The x2 has a bit of problems with certain poor programmed games.  A couple of ways around that.  First make sure you've downloaded the x2 Driver from AMD.  Then if the game still screws up, grab a utility that allows you to set the affinity of the game to only CPU0.

If you can get the game to boot up, you can go to task manager and change the affinity of the process manually by right clicking, "Set Affinity" and then uncheck CPU1.  You'll have to do this everytime unless you use a utility that remembers that sort of thing.  Before I knew about the x2 Driver, EQ2 would crash if I didn't change the affinity.  Hope this helps!

-TheErk

we have to stick with PHP 5.0.4 for a particular application for reasons that are too boring to list here.

unfortunately, this particular version has a bug[1] that truncates some file-read operations at exactly 2,000,000 bytes. our application needs to read some files that are larger than this limit.

fortunately, giving a http:// URL to fopen() and friends will work pretty much the same as reading the file from disk. so, we have the files in a restricted <Directory> container in Apache, and the code reads:

$stream = @fopen("http://127.0.0.1/tps_files/" . $fname, "rb")



[1] http://bugs.php.net/bug.php?id=32553

Years ago I was doing C programming for an embedded system (a micro-ammeter, to be specific) based on the Motorola 6809 microprocessor. The system used a lightweight multi-tasking OS of my company's own design. The program would just go off into the weeds at seemingly random times, and this was driving me nuts. Finally I was able to determine the cause: the run-time library was not designed for re-entrancy. To save ROM space the compiler converted multiply and divide operations on long integer arguments to a call to a hidden library routine. This library routine was allocating local variables BELOW the stack pointer, rather than decrementing the stack pointer by the size of the required local variables. If an interrupt occured while one of the tasks was executing in one of these math routines, most if not all the local variables got overwritten when the processor's interrupt acknowledge cycle saved the context on the stack.

I could not get the compiler vendor to fix their library, even though they, with great embarrasment, admitted to the problem.

My workaround was to write my own (correctly coded) version of these library routines, and call them directly instead of using the C language * and / operators. Ugly.

Sounds like a timing issue. The debug mode / dialog boxes changed the timing just enough sort of like hooking up a console to the mainframe like someone else posted about.

In the mid-70s we were using a certain brand of ASCII dial-up terminals that had a forms feature. When the terminal received certain character sequences, they defined protected and unprotected regions on the screen. However, occasionally a user would hit the Send key and the system (IBM 360 DOS) would receive multiples of some of the characters from the unprotected regions. We went to the manufacturer's HQ to try to get them to fix the problem, which of course they stoutly denied. The meeting was getting pretty ugly when one of their engineers literally burst into the room, shouting "I've found it". He found that the terminal sent the extra characters each time the number of characters in a protected region was "too small" because their hardwired circuitry couldn't grab the data from the terminal memory. The workaround, of course, was to add some extra spaces in the protected regions.

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!

That is a stupid workaround -- you probably just need to set CPU affinity to one processor only. You can try this in task manager, right click process, set affinity. If this works for you, then you want to make it a permanent settig -- which windows cannot do. You will need a utility like this:

http://www.valhallalegends.com/adron/prioaff/prioaff.zip



found in

http://www.techspot.com/vb/all/windows/t-3913-Making-a-program-remember-its-priority.html




Or wait until these developers get their act together and realize that some multi CPU machines actually have multiple independent CPUs, not just Intel HyperThreaded fakery.

Good luck.

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, [..]

That looks more like your code was smashing the stack and creating some variables in it prevented it from overriding the function's return address, or some other critical data. However, it's a common workaround against programmer errors :)