Boneheaded moments in programming...

[Maximilian]

Ive been sat staring at the code ive written to make 6 threads of a class randomly add or subtract random numbers to a single shared object of another class, learning about synchronized and locks etc right now. I had no idea in hell why it would never work or just freeze every time. I followed the code through and it all seemed to make perfect sense, everything was there, synchronized the correct methods, notifyAll was in the right place... Problem was this was missing:

Thread thread1 = new Thread(numberMaker1);
Thread thread2 = new Thread(numberMaker2);

Wrap the damn things in a Thread class object if implementing Runnable.... doh! :\

Quite like these moments when i think i just dont get it or ive done it wrong but in fact ive got it right but just forgot something, feels good getting it working in the end. Anyone else get this?

 

[TecHNooB]

I was writing to a file and I opened and closed it on every write. doh!

 

[brandonb]

Not sure if I was the bonehead or not (maybe for not noticing)... But at a company I worked for, performance was key to everything (it was stock market company and had an order entry system), so by the time you clicked send on your order, it was supposed to end up at the exchange computer within a second.

So, it was running a bit slow. 1.2 seconds or so. So they told me to look at the timings, and add more timings to my code, using their common object. Their object basically just wrote to an in memory log that they could lookup how long various things took so we could narrow down what was going slow. My functions were quite sparse on the timings so we weren't able to identify each individual database queries. So we couldn't tell which query was causing the problem.

So I add some timings. So they are looking at it trying to figure out which database query was the problem or which ones to tweak. But it appeared all of them were running slow, much slower than they should, and when we ran the queries in SQL tools, we noticed a big difference. So they had me add more timings. It couldn't have been the queries since the SQL tools were indicating they were fast... It had to be the logic after the queries were done. Maybe the arrays or collections or whatever I was using, maybe filling that was the problem.

Every single time I added timings, the time taken went up. Now we were up to 2.4 seconds or so and people were freaking out wondering what the heck is going on.

Then I profiled the common object they told me to use that kept track of the timings. 100 milliseconds every call. So the more timings I put in, the slower things got. I removed all timings and we were under a second (their goal) until they fixed their object.

And the entire product suite was using this object and killing the performance enterprise wide.

Nobody bothered to ever put timings on the timing object.

 

[EagleKeeper]

Traffic signal control:

Calculated a checksum to send with the control message. Forget to send the checksum along with the message. No big issue right. Receiver should fail the checksum and reject the command.

In this case the receiver ignored that the checksum was zero and overwrote itself analyzing the checksum of zero. Had the checksum been anything else, it would have rejected.

Depending on what was being done when the command arrived, it could take from 30 seconds to 48 hours for the unit to swallow itself. At that point the signal went to all Red flash and required a hard reset by a tech. All initially was known is that the problems would happen late at night.

Because it was essentially a random but guarenteed occurance, it was difficult to track down. Took a week before the checksum issue on the main system was determined and another week to identify the field problem. We did not have the firmware for field units.

Why do long to find the original? Problem was in the time sync message sent out after 2AM. Once a day only.

 

[Crusty]

Not sure if I was the bonehead or not (maybe for not noticing)... But at a company I worked for, performance was key to everything (it was stock market company and had an order entry system), so by the time you clicked send on your order, it was supposed to end up at the exchange computer within a second.

So, it was running a bit slow. 1.2 seconds or so. So they told me to look at the timings, and add more timings to my code, using their common object. Their object basically just wrote to an in memory log that they could lookup how long various things took so we could narrow down what was going slow. My functions were quite sparse on the timings so we weren't able to identify each individual database queries. So we couldn't tell which query was causing the problem.

So I add some timings. So they are looking at it trying to figure out which database query was the problem or which ones to tweak. But it appeared all of them were running slow, much slower than they should, and when we ran the queries in SQL tools, we noticed a big difference. So they had me add more timings. It couldn't have been the queries since the SQL tools were indicating they were fast... It had to be the logic after the queries were done. Maybe the arrays or collections or whatever I was using, maybe filling that was the problem.

Every single time I added timings, the time taken went up. Now we were up to 2.4 seconds or so and people were freaking out wondering what the heck is going on.

Then I profiled the common object they told me to use that kept track of the timings. 100 milliseconds every call. So the more timings I put in, the slower things got. I removed all timings and we were under a second (their goal) until they fixed their object.

And the entire product suite was using this object and killing the performance enterprise wide.

Nobody bothered to ever put timings on the timing object.

Similar issues using Goldman Sachs REDI+ API. They had multiple send_order methods with the same parameters, just a different # appended to the method name. send_order1, send_order2 etc etc. After experiencing severe performance problems, only sending 3-4 orders per second, I got someone on the phone that told me to use send_order2. He couldn't tell me WHY it was faster, or what it did differently, just that it was 2 orders of magnitude faster.

Several years later, and we're now enjoying sub-ms round trip times for orders using a custom FIX engine.

 

[Red Squirrel]

if(condition);
{
some stuff that has to be done
}

Spent HOURS trying to figure out why the condition was always true. Turns out that's not what was happening.

 

[dwell]

Still learning Scala and was stuck a while on why this prefix tree code wasn't working as expected:

    def contains(word: String): Boolean = {
        var current = root

        for(ch <- word) {
            current.child(ch) match {
                case Some(node) => current = node
                case None => false
            }
        }

        current.isWord
    }

The line:

 case None => false

Should be:

 case None => return false

Scala's optional use of return in places really leads to a rough learning curve. Funny being "fluent" in Java and moving to another language that's a lot the some but completely different.

 

[Ken g6]

I once had a C function with a bunch of small variables followed by a short array:

int a, b, c, d, arr[4];

'd' seemed to be getting changed, but I could find nowhere in the code that could cause it. Finally I looked at the indices being given to arr. It turned out I was modifying arr[-1], which got mapped to 'd'.

 

[BrightCandle]

Programming away in Scala on a serialiser library. I had a trait with a serialise and deserialiser function in a trait with a type parameter that was covariant. It become apparent when trying to do a combined deserialiser for all the primitives that it was impossible to combine these traits in a type safe way. Clearly I was trying to use a covariant class type in a contravarient way.

The better way to do this is actually to use PartialFunctions for the serialise and deserialise, with nothing to do with each other and combine them using a Monad based on combining into a tree like structure. Should have seen that one coming way off.

 

[exdeath]

Couldn't figure out why my Gameboy Advance programs ran fine on an emulator but not on real hardware for like a week.

The problem was the DMA code. A DMA is three instructions: a write to source address register, a write to destination address register, and write to control register to set DMA options and start the transfer.

I caught a break when I noticed it worked if I wrote the DMA in C without it being inlined. Turned out the DMA controller needs two cycles to latch the source/dest values internally from the CPU accessible memory mapped registers. The prologue/epilogue code in C provided me the necessary delay.

I ran back to back DMAs at times, that is I did set source, set dest, go, set source set dest go, etc.

I had figured since GBA's ARM7 doesn't have cache, the CPU should stop on the third instruction that starts the DMA. Which is true, the CPU is halted while DMA is running so you don't need to busy loop or set interrupts for DMA completion; it will be done by the time the CPU resumes. But since it takes two cycles to latch the source/dest regs, I was getting off two more cycles, think of them like "delay slots" I guess, before the DMA took over the bus... Since I was doing back to back transfers, those next two instructions were modifying the DMA source/dest registers with the next DMA addresses while it was still trying to latch/start the previous DMA. Result = frozen DMAC, locked bus, and halted CPU, and an ugly white screen.

Yay.

Two NOPS after write to DMA control register and 99% of my GBA roms were running on real hardware with no other changes.

Didn't have the benefit of the official Nintendo AGB dev manual back then. Pissed me off to know the "allow two cycles after starting DMA before modifying DMA regs again" thing was documented.

 

[Lorne]

I forgot a RETURN from Gosubxx once, Well actually several times.

 

[PCTC2]

I think one of the stupidest moments I have had has to do with variable names. .

I stopped using 1-char variable names back in high school. Back then, everyone thought using a,b,c,x,y,z,etc was an okay idea.

So recently I was writing this function in ruby. Every time it ran, it skipped over a lot, and ended up with either nil returns, or something completely off.

Apparently the main script and a iterative loop inside the script used the same variable name "audit". Apparently I named the object I was working on "audit" and at some point in the loop, I was looking for associated "audits", looping over the variable "audits" with the iterative variable being "audit".

Whoops.

 

[Cogman]

for (i : range)
{
  if (i == x)
    alert("You can't do that!");
    return;
  doOtherUsefulStuffs();
}

Yeah... I forgot to put the curly braces after the if statement and the return statement. All the sudden, the usefulStuffs was never done .