Debugging / dealing with users

[Zach]

Hi guys,

Another one of my randomly useless but personally interesting questions.
One thing that I have always thought a lot about, is if I were to ever create commercial software (i.e goods for money), how would I hold up under the pressure of unforeseen bugs, and more to the point for someone like me, how do you learn to "bug hunt" based on user reports or even crash dumps / report data??

I would be extremely nervous about this aspect of software development.. It is totally one thing when I am doing something and don't get the result I expect, and I start scrutinizing my own code for an answer, or come to a Forum to ask for help... But it feels like a totally different ball game when you've got an angry user on the line, wondering what just happened (possibly to their data!) and when it is going to get fixed..

Is it just something you learn over time with experience? I've seen plenty of BSOD screens, data dumps from a game or Windows crash, etc.. But even if it were my own program I wouldn't know how to make heads or tails of the data I wouldn't know how to even guess at what code section might be the problem just by looking at a memory address, or anything like that..


How do you do it? How do you "bug hunt"
What if you can't FIND the bug? How have you dealt with that situation?

[RichAlgeni]

The best way that I have found to troubleshoot is that you must eliminate possibilities. Start with the most obvious possibility, and narrow down from there. Software is especially difficult to troubleshoot, since hardware and users also contribute to problems. Ask your user if they can recreate the problem at will. The hardest types of problems is when they can't!

As far as attempting to keep your software bugs down, write small snip-its of code (procedures), and document it well. Try to reuse these procedures as much as possible, whether it's include files or dll's. The more you use a piece of code, the more familiar and comfortable you will be with it.

Create a logging or audit process, and use settings in ini files, that are easily changed. Create a method of turning logging on and off for each procedure. Search the forum for examples. I use a bitwise method, where 1 turns on logging for the first procedure in a program, 2 turns on logging for the second, 3 turns on logging for the first two procedures..., and so on. This way you can log only the questionable procedures.

Create a test environment that as closely as possible resembles your customer's machines. If they run XP, get an XP machine, or at least an XP virtual machine.

RTFM, read the online book for PureBasic by Kale, it's a great resource! Read the entries in the forums, and contribute where you can. Don't worry about making a mistake, everyone here has. Then write code! Check out different scenarios, and see what they do and how they work.

Don't forget to test! Then test some more, and when your done, test again! Consider writing your documentation first, then write your program to the documentation. Many memory problems have to do with mixing variable types, especially with 64 bit code. When writing 64 bit code, use type '.i' for integers. Don't assume code will run faster by using smaller typed variables, such as .a, .b or .l, it often comes back to bite you. I know from experience!

And finally, like you did here, ask for help when you need it! Don't be afraid of asking..., that's how you learn!

[MachineCode]

Zach, don't sweat it. Just have an EULA (End-User License Agreement) that states the user will not hold you repsonsible for any bug, both known or unknown, and neither will they hold you responsible for any data loss or other damages as a result of said bugs, and you'll be safe. Legally, it probably won't hold up (IANAL), but most people won't hassle you because they've agreed to it.

Then, for bug fixes, just mandate that they MUST provide reproducible steps to prove the bug, otherwise it can't be investigated and resolved.

It's really that simple. Been doing it that way for years.

[RichAlgeni]

It's really that simple. Been doing it that way for years.

Is your real name Bill Gates?

[MachineCode]

if I were to ever create commercial software (i.e goods for money)

BTW, you can sued for bugs in free software, too. Free software is not immune from legal action.

[RichAlgeni]

Tell your customers you will do your best, and if they find a problem, you'll do what you can to take care of it.

My end user license says that the software I write will do what the user expected when they purchased it, or I will do my best to fix it. I couldn't in good conscious do business any other way.

[Zach]

My concerns were more from the "how do you handle it as a developer" aspect, as opposed to the legal implications and EULA stuff.. But I appreciate that advice as well.
I know as a business person, if I sold someone something they couldn't use, and I couldn't fix it, I would just give them a refund.

I remember that one PB book, and I think I will go back to it. And I guess I will troll around the forum search for a while as well. I definitely have 0 experience when it comes to writing execution tracking, error catching, and debugging routines.

Thanks.

[RichAlgeni]

Just remember, for everything this is a first time.

[Zach]

Yes,

I would liken my feeling to a performer asking a season pro "so what did you do/how did you handle it, the first time you bombed on stage?"

[RichAlgeni]

Everyone is going to bomb at least once, you just have to suck it up and keep going. That's probably the biggest difference between those who succeed, and those who don't. When you write software, you have to have a think skin.

[Zach]

Was that a pun or did you mean thick skin

[MachineCode]

My concerns were more from the "how do you handle it as a developer" aspect, as opposed to the legal implications and EULA stuff

Just get the users to report the steps involved in making the bug appear. Without that, you can't really do much. Memory addresses and Microsoft debug information are 100% useless to me too; I don't understand them at all either. If the user can't at least tell you what they were doing at the time of the crash, then just politely respond that you need more information and ignore the fix until they do. As the saying goes, we're coders, not mind readers.

[Foz]

Just going back to the original question - At work we use "pro-active" debugging - simply because if the error does not "stop" them doing their job they won't report it.

Take for instance this scenario that actually happened before and after we implemented debugging reporting system: printing all the paperwork in one batch crashed the system, but individually selecting jobs, right clicking for the menu "print" worked. 26 separate people across all 26 sites just accepted it as the norm, and did the print outs by this way WITHOUT reporting it once.

So after living in a state of bliss (ignorance), we added in the error reporting (we suspected crashes were happening without us being told) - on a crash the app would submit the error report to our "Error Logging" system. Within the day we had more errors than we realised. By the end of the day we had rang up a handful of the sites trying to find out just how they were printing their paperwork (all attempting to print it in a batch, when it crashed then they went about printing individually).

As such, from my own experience - use the OnError support in PureBasic, run a simple server that is dedicated to receiving error reports, and simply transmit the error information to your server on a crash.

PureBasic gives you the tools - use them.

[Derren]

Isn't that what the OnError-lib is for? Heavily underused this thing.
I'm no expert but I think if you used it properly, the lib could tell you the exact line in your code in a compiled programm, in case of an IMA for example...

[Thorium]

In my experience creating a log file logging all actions of your program with handle numbers for objects etc. will help you a lot to find bugs. The more detailed the log is, the better. If will take more time on develpment but it will be totaly worth it.

Isn't that what the OnError-lib is for? Heavily underused this thing.
I'm no expert but I think if you used it properly, the lib could tell you the exact line in your code in a compiled programm, in case of an IMA for example...

It can, but that line dont have to be the source of the problem, it's just the line that finaly breaks because of the problem created at another line.