• Forum
  • Lounge
  • What was your least productive day ever?

 
What was your least productive day ever?

Pages: 12
Mine was between yesterday noon and now, which was spent changing a ">=" to a "<". Yeah, eighteen hours to invert a relational operator. I'll spare you the details, but suffice it to say that it's more pleasurable to stick certain sensitive body parts in a meat grinder than to use Eclipse under Debian.
LOL....that sucks SO BAD.

Mine was two years ago. I spent about a week of work trying to fix a single run time error...it all boiled down to incrementing where I should of decremented. Should be obvious no? well it wasn't >_>
Missing the line of text in the man page for strncpy() that says it ALWAYS writes
N bytes, even if the source string is less than N bytes in length.
Does it really? Wow, that's stupid.
That kind of doesn't make sense.

What makes it different from memcpy, then?
It backfills with zeroes.
eighteen hours to invert a relational operator.


there's this thing called perl

;-)

haha mine was working 12 hours to find a } missing in a loop, which failed the whole program to work...
there's this thing called perl
Yes, and?
Trying to find an error in our Project for 3 weeks. Tested each component having 1000s of lines of code, only to find out in the end that the error was done by a team member in a function, which was being invoked repeatedly!!

1
2
3
4
5
6
void myfunc()
{
    static int a;
    a = 0;      //Damn
    a++;
}


Reason: Project Coding guidelines state each variable should be initialized before being used!

...
My record is I think 3 days - something like
Day 1. 10 hours for finding that the mistake in my large integer arithmetic.
Day 2. 10 hours+ for trying to find the exact place it pops.
Day 3. Total rewrite from scratch of the three badly implemented functions (up to this date, I do not know where exactly the mistake was). Surprisingly, this took like just a couple of hours.

And another horrendous one:
Mistake pops after 45 minutes of computation at 100% CPU in a 5 dimensional computation. No 2, 3 or 4 dimensional example showed any symptoms of bugs. It took me 30+ hours to find, but most of the time was spent in building printout techniques so I can visualize the data.

It payed off later of course, since I started using the printouts :)
Last edited on
5 days adjusting scrollabrs along with an application inside a main window when finally it was decided that scrollbars are to be managed by the inside application. Later the whole resize functionality was scrapped and the window was to be of a fixed size.
@ mgupta mwahahahhahaa the most evil bugs are those with organizations and people
Update: It wasn't Debian's fault (well, not directly). Debian installs by default GCJ, which causes Eclipse to misbehave (read: crash at random, run painfully slow, and fail to properly call programs [g++ failing, but /usr/bin/g++ working]). Solution: send GCJ to Software Hell and install Sun's JRE.
I guess I could list today as one of my least productive days...

A friend of mine from university took a class on non-linear system analysis. The professor asked him to write a program about calculating the spectrum of Lyapunov exponents for some systems of his choice (don't worry if you don't know what this is. Neither did I a couple of days ago, and to be honest I can't really say I know now...). My friend can't even write a Hello World program, so he asked for my help...

We found some resources on the net but the code was for PowerBASIC and this compiler isn't free AFAIK, and I couldn't find any decent torrent for it. I tried to compile it with other BASIC compilers without success... Finally I offered to port the code to c++ myself... It worked ok for the specific system analyzed (henon map) but we wanted to add more - lozi and holmes maps. Holmes was easy, we found the non-linear equations that describe it, did the required linearization and all was good. However, for lozi, it took me almost half the day to realize that instead of this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
double a=1.7;
double b=0.5;

//lozi 

xnew[1]=1-a*fabs(x[1]) + b*x[2];
xnew[2]=x[1];

//lozi linearized

xnew[3]=-a*fabs(x[3]) + b*x[5];
xnew[4]=-a*fabs(x[4]) + b*x[6];
xnew[5]=x[3];
xnew[6]=x[4];

I should have done this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
double a=1.7;
double b=0.5;

//lozi 

xnew[1]=1-a*fabs(x[1]) + b*x[2];
xnew[2]=x[1];

//lozi linearized

int sign=1;
if (x[1]<0) sign=-1;

xnew[3]=-a*sign*fabs(x[3]) + b*x[5];
xnew[4]=-a*sign*fabs(x[4]) + b*x[6];
xnew[5]=x[3];
xnew[6]=x[4];

EDIT: Guess what... That was wrong too... The right way is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
double a=1.7;
double b=0.5;

//lozi 

xnew[1]=1-a*fabs(x[1]) + b*x[2];
xnew[2]=x[1];

//lozi linearized

int sign=1;
if (x[1]<0) sign=-1;

xnew[3]=-a*sign*fabs(x[3]) + b*x[5];
xnew[4]=-a*sign*fabs(x[4]) + b*x[6];
xnew[5]=x[3];
xnew[6]=x[4];


Last edited on
Yesterday again...
The program literally needed a break...

a fallthrough in a switch statement caused further tasks to happen, which were going undetected...!!!
... one of the most evil mistakes I have ever made (took me 8+ hours to find):

There was completely no mistake in the main stream algorithm/data structure. The only bug was in routine whose only purpose was to make consistency checks.

While I was running the optimized for speed version, I get no problem. Then I program a save/load to hard drive to manage heavy computations taking more than a day. Just in case, I run a consistency check after every save/load... and the asserts start popping! The more I add debug code, the more asserts start going off...

To make things "nicer", the first time the problem popped, it took half a day of computations. It took me 1/2 day of random experimentation to find a small enough example that popped the assert quick enough. Naturally, I couldn't use my save-to-harddrive routines while doing the testing (which I thought originally were defective)...


[Edit:] I posted this originally in the wrong forum section... my brain is fried lol! It's 5:05 am, I am dead tired but extremely happy now that my code passes all tests it should :))))
Last edited on
The only bug was in routine whose only purpose was to make consistency checks.
D'oh! Quis custodiet ipsos custodes?
the application crashed while parsing a string searching for a newline character... unable to find the \n, token ended up as null and program crashed when trying to trim this null token...
spent 3 days determining what the rest of the code did after crash point and modified the string accordingly... truncating it with newline in the end as required...

just to find out today that there was already a newline character which had been replaced by a \0 in another function.
Commented the replacement and delivered the code.
Wow, most of these mistakes are minor and fixed in a reasonable time frame. Am I the only one who has spent weeks debugging without progress?
Pages: 12