Worst bug you had?

[Krice]

if you push on development the codebase will grow bigger and thus the bug will be harder to find.

Well I guess it's in the existing code..

[Krice]

The bug described in the first message still exists. It's crashing the program in one particular point about half of the test runs. It's very annoying. When I watch some variables it seems that usually it's crashing when a staff is created for the player. No idea why. Maybe there is something wrong with staff data, but more probably it has nothing to do with that, but something else is corrupting item data area.

It's crashing when item data is required so I should probably write test code that just fetches something from item data and then place that code along the trace of running program. Slow, but could help find when the item data area is corrupted (I think VC++ doesn't have this kind of option).

[gerryq]

Buffer overruns, dangling pointers, uninitialised variables... one reason to use C++ is that you don't need to have any of these things (maybe the occasional use of pointers for efficiency, but try to avoid it).

Always use vectors instead of arrays (you can make an exception for dungeon maps).

Always access objects in vectors using the index (a downside of using arrays is that pointers are dangerous, unlike in C-style arrays, because vectors can reallocate).

Try to use vectors in preference to lists.  Lists tempt you to use pointers.

Always initialise variables in the constructor (exceptions can be made for really small classes such as Point, Rect, etc.).

Whatever you do there will still be bugs.  Chase them hard when you see them.  Sometimes when you have a baffling bug, when you wake up ater a night's sleep you will know the cause.

[gerryq]

If it is crashing half your test runs, you should be able to find it.  Try giving the player a sword instead of a staff - does that fix it?

Try setting a breakpoint just before the bug happens and stepping through the code a line at a time, until you find what line the crash happens on.  What error message do you get? 

Then step through very carefully from a little before that, looking at all the variables.

[I_Own_The_Letter_O]

My code isn't really long enough to have bugs yet. It's a collection of various small programs (system dependant i/o stuff in a header; a CA cave generator; a turn program with only an 8-directional move, stay still or quit function; and a splash screen) and I've only just started slotting things together.

I had one bug when I started developing earlier this year. Turned out to be a fatal error in my compiler and I had to download a new compiler. That's was a pooper.

I had a real bug when I started developing again over the weekend. It was a stupid mistake and one that was quickly fixed. My little @man wasn't deleting his old self after moving. It turns out that I was deleting the wrong square, I forgot to reset the cursor after printing the '@' character so I was deleting an empty space to the right of the previous '@'. I'm sure I have a lot worse bugs waiting around the corner for me.

[Krice]

Try setting a breakpoint just before the bug happens and stepping through the code a line at a time, until you find what line the crash happens on.

I was able to trace back it to Create_Rooms and the routine searching through room tiles, generating a list and then possibly randomly selecting a location from room. But I don't know what is the actual bug.

[TeeEmCee]

Horrific.

Right in front of memory corruption that occurs randomly and plagues you for months or years (I'm suffering this - I think. Hard to keep track) without solution, is the bug that has no solution at all: those that are apparently due to your language (I'm amongst those working on an RPG engine in FreeBASIC) or prehaps some library you're using, and comes and goes depending on the month of the year.

Specifically, I and about 20% of users randomly get freezing when loading the game or quitting. OK, this isn't that bad, but it appears to be somehow due to reading data from files, and from past experience with FB (which is young and buggy, especially in the RTlib which eventually appeared to be the cause for a very similar bug that lasted a year), I blame my language and/or OS (observed in windows only so far). It doesn't seem to happen at any specific point in the loading code, just... randomly anywhere. What sort of bug report do I file?

Is it possible to investigate a hung program with a debugger? I can't gdb to work. Isn't gdb meant to support running its interactive prompt in a separate thread?

Bad bugs in libraries (like SDL_Mixer, which really sucks) can necessitate switching libraries, at possibly huge expense.

[Krice]

I blame my language and/or OS (observed in windows only so far).

I guess it's very rare that something is wrong in language generated code. You may start to suspect this when you just can't find the bug, but it's always there.

It doesn't seem to happen at any specific point in the loading code, just... randomly anywhere.

Loading routines are one possible reasons for buffer overruns. You might think that proper amount of data is loaded, but it's still loading too much, past the end of buffer.

By the way, I think I finally found the fatal bug in Kaduria. At least I know one possible location where to find it if it's still crashing.

[JoshuaSmyth]

If you suspect you have a bug to do with fileIO, check that you're reading/writing in the correct format (ie binary/text) I had a bug once where I didn't specify to open a binary file and reading from it worked *most* of the time. Forcing it to read in binary fixed the issue.

[I_Own_The_Letter_O]

Not so much as bug as a warning that I keep getting, constantly, but doesn't appear to affect anything. Apparently something is wrong in xlocinfo.h, something that I have never touched in my life (haven't been coding long enough to even understand some of the stuff in there let alone risk poking around with it). I assume from the name is does something when I call my f_SetCursorPos() function (an integral part of my Roguelikes system dependant i/o library which does pretty much what you'd expect it to). Hasn't broken anything yet so I'm ignoring it.

[Quasist]

In code part of a map generator, there was a variable named
"mmap[64][64]"

I spend a day polishing the generator and enjoing the win32 builds, but Linux version did not even launched(no errors from compiler). After few hours of debugging I found that mmap variable is some sort of reserved stuff in linux headers (I believe it refers to the memory mapping).

[ywgdana]

Yeah, mmap is a pretty standard system call in unix.  It's part of the posix spec, if I recall.

[Quasist]

Never drop it, ok?

[Scautura]

Which one?

• Infinite loop while the AI tries to reload its firearm (See player -> fire weapon -> no ammo -> reload -> no ammo in inventory -> see player... etc. Forgot to use the AI fire/reload routine not the player fire/reload routine Doh!)
• A* path finder worked backwards (errr, you're supposed to chase me, not run away from me?)
• Could throw items through/into walls (Errr, my grenade's on the other side of the wall? How'd that happen)
• Give the player an extra "process" in the priority queue when changing levels ("Why aren't the monsters moving?")
• Not giving the player presence when changing levels (my spirit moved levels, why did I leave my body behind? And why are the monsters shooting the stairs?)
• Player starts embedded in an impassable item (It's OK, he can walk out of it, just not back)

There's probably more, but those are among the most humorous that I've already fixed - there are probably some more in there somewhere.
Oh the trials of learning a new language on the fly while writing your first roguelike.

[Krice]

Double post, sorry:)