[ / / / / / / / / / / / / / ] [ dir / ausneets / film / leftpol / mde / sg / shame / vrtx / zenpol ][Options][ watchlist ]

/prog/ - Programming

Programming board
You can now write text to your AI-generated image at https://aiproto.com It is currently free to use for Proto members.
Name
Email
Subject
Comment *
File
Select/drop/paste files here
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Expand all images

File (hide): 1445968875001.jpg (28.57 KB, 600x338, 300:169, xtoanhero.jpg) (h) (u)

[–]

1d0a50 (4) No.3484>>5009 [Watch Thread][Show All Posts]

Tell me, /prog/, what were the nastiest bugs you ran into?

Mine was when I coded a multithreaded Java project for university. In our group was a girl which we considered incompetent and so we only gave her lowest-tier tasks where no sentinent being should be able to cause any harm. Stuff like putting the debug output calls in comments for the final version.

The result looked like this:


void runThreads() {
while(!done) {
iteration++;

if (iteration%10000 == 0)
//Debug.out("Iteration: " + iteration + ", State: " + state.toString());

/* I'm a huge comment explaining
what the critical section does*/

syncThreads();
doCriticalStuff();
}
};

Needless to say, our debug version sometimes had incorrect output due a data race resulting from the missing synchronization. The really annoying part was that this was part of the proven, extensively tested and seemingly unchanged core program and merged alongside with a large update to peripheral functions, so we spent several days testing the graphing, output, and other stuff before finding where the problem was. And then there was a huge comment in the middle which made it easy to overlook the if-statement when looking at the seemingly important parts.

1d0a50 (4) No.3492>>3493 >>4932

Nastiest bug I've ever seen? Probably the "Openoffice doesn't print on Tuesdays" bug:

https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619

Nastiest bug I've ever created myself? A memory leak in a HQ9+ interpreter I wrote in Haskell:

inc :: StateT Integer (ReaderT FilePath IO) ()
inc = modify (+1)

Since the accumulator in HQ9+ is never accessed, only incremented, every call to inc creates a thunk that never gets resolved, instead of simply incrementing the accumulator. Multiple calls to inc create a huge thunk stack.

If I print out the accumulator in order to debug the program, the memory leak vanishes.

Adding a bang pattern fixes it:

inc = get >>= (\ !s -> put (s+1))


1d0a50 (4) No.3493>>3494

>>3492

How did you even find that bug? Haskell doesnt have the best debugging tools for shit like this.


1d0a50 (4) No.3494

>>3493

Since an HQ9+ interpreter is so small in scale, I just fed in a bunch of different input files until I found out that the + instructions (which resulted in calls to inc) caused the memory leaks. The rest of it came down to figuring out why the inc function was a memory leak and how to fix it.


8533c7 (1) No.4864

Once I work in a project on the client-side, coding the mobile clients (iOS/Android). I worked with a lazy fatass son of a bitch in the server-side. I had to bust that guy's balls all week to get him finished a single endpoint. When he finished the endpoint the Json payload was some utter bullshit, for example in a response where I was supposed to get an user id, a building id and a section id I got some shit like:

```

{"payload":"userId:buildingId:sectionId"}

```

So I had to juggle that shit on the client-side. To get a list of the buildings I had to hit two different endpoints and merge the data locally on the client-side because some shit that was crashing on the server-side. Luckly I used Rx to do all that shit and It was pretty simple. But man that I hate 40yo old programmers that dont' give a shit about quality coding.


fe3481 (1) No.4899>>4925 >>4928

Literally anytime I get a seg-fault error.

It usually takes me a whole day at the least to figure it out.


d59718 (2) No.4925

>>4899

Learning how to use a debugger is probably the best time investment you can make. You don't have to learn much, just enough to be able to get a backtrace on the core dump. Knowing the line that triggers a segfault sooner you can then read the code that got to that point to see the obvious error or learn how to examine the stack/vars and print the pointers that look off.

The debugger saves time spent on hunting down faults that can be better spent testing and uncovering more segfaults you missed.

I am assuming straight gdb on the CLI. IDE tools make the job orders of magnitude easier.


b6902e (1) No.4928

>>4899

Check out Valgrind. It's good at tracking down memory errors.


000000 (1) No.4932

>>3492

Curious: why do you need `ReaderT FilePath`?


d59718 (2) No.5009

>>3484 (OP)

This is why we should require that single line ifs and loops have braces.

See Apple's goto fail bug for example:

	if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;

If you put braces on it

	if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) {
goto fail;
}
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) {
goto fail;
goto fail; // Mostly harmless
}
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) {
goto fail;
}

	if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) {
goto fail;
}
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) {
goto fail;
}
goto fail; // More obvious in code review than without
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) {
goto fail;
}




[Return][Go to top][Catalog][Screencap][Nerve Center][Cancer][Update] ( Scroll to new posts) ( Auto) 5
9 replies | 0 images | 6 UIDs | Page ?
[Post a Reply]
[ / / / / / / / / / / / / / ] [ dir / ausneets / film / leftpol / mde / sg / shame / vrtx / zenpol ][ watchlist ]