Jump to content
• Advertisement

# Bugs that only show up when attaching my debugger, what to do with them?

This topic is 3057 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

## Recommended Posts

Hi, I know there can be bugs because of using debug/release builds, but I didn't know you could have bugs because you attached your debugger. I'm using MSVC. I think I've heard this mentioned before though, and that there was a page full of tipses for this.

#### Share this post

##### Share on other sites
Advertisement
Quite a few things change when a debugger is attached to a process; are you running into a specific issue, or just looking for information in general?

#### Share this post

##### Share on other sites
Having a debugger attached or detached doesn't CAUSE bugs, but it can expose bugs that are in your code.

There are two ways to debug. You can either attach a debugger to a program, or your IDE can host the app. When a debugger is attached the app gets some data streams hooked up to it, and execution times are slightly changed (which can change race conditions). There are a few other changes but they are generally innocuous.

If you run the program through the IDE's debugger it will also run your app within a hosting process that speeds up debugging, bypasses some security systems, and slightly changes some .net functionality.

#### Share this post

##### Share on other sites
One unit test fails in both debug/release but if I attach my debugger it passes all tests. I've tried with printf debugging and placing debugBreak () calls all over. I think I'll find the problem eventually, but it's taking lots of time and I figured I'd ask if there are any general tips or workarounds.

Edit: Thanks Frob. Yes of course, the usage of a debugger doesn't cause or hinder bugs. That's not what I wanted to say, but did. ;) I didn't know attaching and actually launching the application inside the IDE was different stuff, that's useful to know.

#### Share this post

##### Share on other sites
Quote:
 Original post by SymLinkedOne unit test fails in both debug/release but if I attach my debugger it passes all tests. I've tried with printf debugging and placing debugBreak () calls all over. I think I'll find the problem eventually, but it's taking lots of time and I figured I'd ask if there are any general tips or workarounds.Edit: Thanks Frob. Yes of course, the usage of a debugger doesn't cause or hinder bugs. That's not what I wanted to say, but did. ;) I didn't know attaching and actually launching the application inside the IDE was different stuff, that's useful to know.

Usually it means a memory related error.

#### Share this post

##### Share on other sites
Few debuggers try to be entirely unintrusive and at the very least you can usually count on the timing changing. Count yourself lucky that you don't have the opposite problem with bugs mysteriously disappearing when you attach the debugger.

Quote:
 Original post by frobHaving a debugger attached or detached doesn't CAUSE bugs, but it can expose bugs that are in your code.
I see someone around here hasn't been doing much embedded development lately.

#### Share this post

##### Share on other sites
Quote:
Original post by implicit
Quote:
 Original post by frobHaving a debugger attached or detached doesn't CAUSE bugs, but it can expose bugs that are in your code.
I see someone around here hasn't been doing much embedded development lately.
I worked almost exclusively in embedded development from 1995 until 2002. So that isn't "recent", but it is more than most people on the forum. Most of it was z80 components used by mips3/mips4 processors; I also worked tangentially on several Motorola FPGA chips. Even then I never saw a case where the simple use of a hardware debugger actually introduced a bug. They certainly altered the state of the hardware and caused different timing, but any competent programmer can write code that isn't dependent on those things.

Since that time, the closest I've come to those small processors was the Nintendo DS.

But observe that the OP was specifically talking about Windows debugging in Visual Studio.

Getting back to the topic of conversation:

Exactly what about the unit test fails? It should be very easy to pinpoint because a unit test should isolate a few lines of code.

#### Share this post

##### Share on other sites
Quote:
 Original post by implicitCount yourself lucky that you don't have the opposite problem with bugs mysteriously disappearing when you attach the debugger.

Gah. That's exactly what's happening and I'm not sure how I could type the exact opposite both in the thread and the subject without noticing. I'm so tired.

In any case, I nailed it. This is basically what happened:

std::vector <int> numberList; // of size 100int randomNumber = getRandom (0, 100);numberList [randomNumber];

The max value of the getRandom () function call should have been 100 - 1, but this was only visible when the debugger wasn't attached. I guess it has to do with the fact that I use a timer to seed the random generator and it was different when the debugger was attached.

#### Share this post

##### Share on other sites
Quote:
 Original post by frobI worked almost exclusively in embedded development from 1995 until 2002. So that isn't "recent", but it is more than most people on the forum. Most of it was z80 components used by mips3/mips4 processors; I also worked tangentially on several Motorola FPGA chips. Even then I never saw a case where the simple use of a hardware debugger actually introduced a bug.
Interesting. Either you've been lucky or I've just been unlucky, but whatever the case may be I can tell you that shoddy tools seem to be par for the course on modern microcontrollers (I recently had a problem with a debugger triggering side-effects when disassembling memory-mapped I/O ports as code for instance.)

Quote:
 Original post by frobThey certainly altered the state of the hardware and caused different timing, but any competent programmer can write code that isn't dependent on those things.
I see someone hasn't been doing much multithreaded development lately ;)

[Edited by - implicit on February 8, 2010 5:42:10 PM]

#### Share this post

##### Share on other sites
Quote:
Original post by implicit
Quote:
 Original post by frobThey certainly altered the state of the hardware and caused different timing, but any competent programmer can write code that isn't dependent on those things.
I see someone hasn't been doing much multithreaded development lately ;)
Actually I'm currently doing multiprocessing on the PS3's SPEs. :-)

It was actually a jab at those who are unwilling to follow the basic steps needed to write proper code.

It truly is not difficult to write code that is both timing agnostic and thread safe (or at least thread neutral), but most people are too lazy to think about such things. Instead they rely on people like me to write simple utility classes for them. They are really basic things, such as ensuring locking order and simple templates to ensure particular data objects are locked before modification. And they rely on people like me to debug their problems when they break stuff.

Bad coding habits are just that -- bad habits. Just like someone had to teach you about not picking your nose, programmers need to be taught to avoid the bad habits of sloppy code.

There are very few requirements for good safe code. If you follow an order going in (1,2,3) follow the reverse order coming out (3,2,1). Lock and unlock in a consistent priority order. Don't change it if you don't own it. Check all return values or document why you mistakenly feel it is unnecessary. Release what you allocate. Assert that all parameters are valid. Don't touch my monitors with greasy fingers or I will cut them off. These are all basic, simple, easily learned behavior patterns.

We tried a number of things to correct bad behavior and have settled on a simple technique.

We have a policy of training, plus public humiliation for those who break the (very simple) coding standards. It applies to everybody, even me. That's been the most effective policy to reduce repeat offenses.

#### Share this post

##### Share on other sites

• Advertisement

### Announcements

• Advertisement

• ### Popular Contributors

1. 1
2. 2
3. 3
4. 4
Rutin
16
5. 5
• Advertisement

• 12
• 9
• 12
• 37
• 12
• ### Forum Statistics

• Total Topics
631419
• Total Posts
2999981
×

## Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!