Types Of Bugs
Pierpont Oldham
Any bug based on timing conditions. These often come when working with inter-thread communication, an external system, reading from a network, reading from a file, or communicating with any external server or device.
We were developing a database to hold words and definitions in another language. It turns out that this language had only recently been added to the Unicode standard and it didn't make it into SQL Server 2005 (though it was added around 2005). This had a very frustrating effect when it came to collation.
Words and definitions went in just fine, I could see everything in Management Studio. But whenever we tried to find the definition for a given word, our queries returned nothing. After a solid 8 hours of debugging, I was at the point of thinking I had lost the ability to write a simple SELECT query.
When a collation doesn't know about a certain character, it can't sort them. If it can't sort them, it can't tell whether two string match or not (a surprise for me). So frustrating and a whole day down the drain for a stupid collation setting.
The hardest ones I usually run into are ones that don't show up in any log trace. You should never silently eat an exception! The problem is that eating an exception often moves your code into an invalid state, where it fails later in another thread and in a completely unrelated manner.
That said, the hardest one I ever really ran into was a C program in a function call where the calling signature didn't exactly match the called signature (one was a long, the other an int). There were no errors at compile time or link time and most tests passed, but the stack was off by sizeof(int), so the variables after it on the stack would randomly have bad values, but most of the time it would work fine (the values following that bad parameter were generally being passed in as zero).
The most frustrating for me have been compiler bugs, where the code is correct but I've hit an undocumented corner case or something where the compiler's wrong. I start with the assumption that I've made a mistake, and then spend days trying to find it.
I was working on a bug with all these features this week. It was necessary to reverse engineer the library to find out what it was up to; then generate hypotheses about which two devices were racing; then make specially-instrumented versions of the program designed to provoke the hypothesized race condition; then once one of the hypotheses was confirmed it was possible to synchronize the timing of events so that the library won the race 100% of the time.
There was a project building a chemical engineering simulator using a beowulf cluster. It so happened that the network cards would not transmit one particular sequence of bytes. If a packet contained that string, the packet would be lost. They solved the problem by replacing the hardware - finding it in the first place was much harder.
The hardest one ever was actually a bug I was helping a friend with. He was writing C in MS Visual Studio 2005, and forgot to include time.h. He further called time without the required argument, usually NULL. This implicitly declared time like: int time(); This corrupted the stack, and in a completely unpredictable way. It was a large amount of code, and we didn't think to look at the time() call for quite some time.
One of the hardest bugs I had to find was a memory corruption error that only occurred after the program had been running for hours. Because of the length of time it took to corrupt the data, we assumed hardware and tried two or three other computers first.
The bug would take hours to appear, and when it did appear it was usually only noticed quite a length of time after when the program got so messed up it started misbehaving. Narrowing down in the code base to where the bug was occurring was very difficult because the crashes due to corrupted memory never occurred in the function that corrupted the memory, and it took so damned long for the bug to manifest itself.
In the end the debugger proved next to useless because the crashes never occurred in the call tree for the offending function. A well sequenced stream of fprintf(stderr, ...) calls in the code and dumping the output to a file was what eventually allowed us to identify what the problem was.
Concurrency bugs are quite hard to track, because reproducing them can be very hard when you do not yet know what the bug is. That's why, every time you see an unexplained stack trace in the logs, you should search for the reason of that exception until you find it. Even if it happens only one time in a million, that does not make it unimportant.
Since you can not rely on the tests to reproduce the bug, you must use deductive reasoning to find out the bug. That in turn requires a deep understanding of how the system works (for example how Java's memory model works and what are possible sources of concurrency bugs).
Here is an example of a concurrency bug in Guice 1.0 which I located just some days ago. You can test your bug finding skills by trying to find out what is the bug causing that exception. The bug is not too hard to find - I found its cause in some 15-30 min (the answer is here).
P.S. Faulty hardware might cause even nastier bugs than concurrency, because it may take a long time before you can confidently conclude that there is no bug in the code. Luckily hardware bugs are rarer than software bugs.
A friend of mine had this bug. He accidentally put a function argument in a C program in square brackets instead of parenthesis like this: foo[5] instead of foo(5). The compiler was perfectly happy, because the function name is a pointer, and there is nothing illegal about indexing off a pointer.
Last year I spent a couple of months tracking a problem that ended up being a bug in a downstream system. The team lead from the offending system kept claiming that it must be something funny in our processing even though we passed the data just like they requested it from us. If the lead would have been a little more cooperative we might have nailed the bug sooner.
I'm currently trying to debug why an application has an unhandled exception in a try catch block (yes, unhandled inside of a try / catch) that only manifests on certain OS / machine builds, and not on others.
Memory issues, particularly on older systems. We have some legacy 16-bit C software that must remain 16-bit for the time being. The 64K memory blocks are royal pain to work with, and we constantly add statics or code logic that pushes us past the 64K group limits.
To make matters worse, memory errors usually don't cause the program to crash, but cause certain features to sporadically break (and not always the same features). Debugging is a non-option - the debugger doesn't have the same memory constraints so the programs always run fine in debug mode ... plus, we can't add inline printf statements for testing since that bumps the memory usage even higher.
After that, bugs which turn out to be due to a freak series or concurrence of events. These are at least reproducable, but obviously they can take a long time - and a lot of experimentation - to make happen.
Hope everyone is doing safe in these stressful times. I am just getting started with Julia programs and wanted to know about the bug types that typically occur. Are bug types the same as C/C++ or Java? Do different Julia bug types have different consequences?
If you just write pure Julia, then memory allocation bugs (as eg in C) will not happen, but all kinds of other bugs can. Generally the (near-)zero cost abstractions are a good way to guard against a lot of bugs: eg in
I figured that test-driven development is super important for a dynamic language like Julia. So, I started making small functions and writing tests at the same time. Now, I just need to run the tests before I run the program. Perhaps unsurprisingly I am also making the code better. Functions become more composable. They are also smaller and easier to read.
There are a few classes of performance bugs new Julia users often run into. Things like allocating tons of data, using non-const globals, and writing type unstable code are the main ones. Your program will still run, but it is definitely possible to be 1000x slower than you would be with more idiomatic code.
I have coded the same programs (e.g., lattice Boltzmann method in Computational Fluid Dynamics) in the Julia language and C language. I have found that despite all similarities between the Julia and C language, if I code in Julia with the concepts of C language in mind, I will probably face some problems which are not necessarily a Julia language problem. For example, Julia continues doing operation with NaN values, which in C language would throw an error and exit the program. Although, I consider these bad programming, not bugs.
Read about the pest guide. Learn about the pest characteristics, habits, habitats, threats, signs of an infestation, and prevention and control measures. The pest photos serve as another method of pest, rodent, or insect identification.
Contact a licensed pest control professional. If you think you properly identified what kind of bug it is from our insect list, discuss eradication methods with a professional before trying to do it yourself. Some pest problems are better left to professional treatment.
Typical household bugs can vary greatly depending on where you live, but some of the most common house pests include ants, bed bugs, cockroaches, and flies, not to mention rodents. To determine what kind of pests you are dealing with, we recommend using our bug identifier above, as well as hiring a pest control professional.
Depending on the common house bug infestation you have, a pest control professional (also known as an exterminator) can provide you with a plan to eradicate these pests from your home and prevent future infestations. Use the pest and insect identification guide above to get started.
In majority of our Jira projects our development and QA teams track various bug types in our Jira - issue types are Functional Bug, Localization Bug and Documentation Bug. Loc and Doc bugs are separated mainly because of they are resolved by independent Localization and Documentation teams (regardless which project these bug types are located in).
268f851078