| You've developed the next great program.
You've tested and re-tested, and you're confident there's no more major bugs. So you ship
it.
And then the bug reports come in. Nothing you can reproduce
locally, but your customers are getting them - and they're NOT happy.
Sound familiar? If you write software, you've no doubt had
this happen to you. No matter how carefully you test, someone with an unusual computer
setup can uncover a new one.
For years I've been a firm believer in instrumenting my
code, adding functions that catch unusual conditions and report them. I've used a
variation of assertions to do that, but now I've found something far better - EurekaLog.
Instead of a quick message telling me there's a failure,
EurekaLog provides a detailed look at the problem, and the environment that it occurred
in. It not only automates the information gathering, but the delivery as well, so you
offer a professional appearance to your software - even at the worst of times.
Installing EurekaLog
Written as a component for Borland's Delphi and C++
Builder, EurekaLog is a simple install. One feature I appreciated was a warning that I
needed to upgrade my Builder service pack - unlike some products, it didn't tell me what
to do and then abort, but just warned me, letting me make my own decisions about
upgrading.
Upon installation, you get a new component tab, and a
single EurekaLog component. As well, on my Builder 5 compiler, I had two new menu options
under 'Project' - a EurekaLog About box, and a dialog for options.
Using it is simple - just load a project and rebuild. By
default, it's included in the resulting code, but a single checkbox turns it off (and a
rebuild removes the code from your program). The component need be dropped on the form
only if you want design-time access to special error handlers (for custom handling of
exceptions).
Letting Eurekalog Catch My Errors
Now for the fun part - messing with my code and seeing how
EurekaLog handles it:
int *x=NULL;
*x=46;
That did it - recompiling and running my program provided a
NULL pointer exception right away. Then EurekaLog swung into action.
If this had been an obscure bug in a program that was
onsite, I'd want to know about the environment where the bug happened, what the program
was doing at the time, what else was running, and ideally the source code point where it
happened. And while I'm dreaming, how about the program call stack so I can see which
functions were called?
Imagine the tech support email I'd have to send out to get
this information...
In contrast, EurekaLog gathered this and more -
automatically. Just some items:
- Start time and error time of program - in case the error was
time related (such as slowly losing memory).
- A comprehensive computer environment listing - Memory (RAM
and hard drive), OS Version and Language, and the user name.
- Complete DLL listing - all the DLLs running in the program's
address space, with detailed information. For example, here is information on just one,
the Winsock DLL:
Handle: 78810000
Name: WSOCK32.DLL
Description: BSD Socket API for Windows
Version: 4.10.0.1998
Size: 40960
Path: C:\WINDOWS\SYSTEM
With information like this, I can check for unusual DLLs,
out of date ones, and possible conflicts. On one occasion I spent a day tracking down an
RTF problem that ended up being an updated DLL - this type of report would have shown it
at a glance, instead of the back and forth volley of emails I had to resort to.
- The actual line that failed, including source code file name
and line number, and call stack. One reason I like debugging in the Builder IDE is because
of the information it provides when a problem occurs. With EurekaLog this local
information is also available remotely, so I can see where the problem occurred in my
source code, as well as what functions called it.
- A memory dump of the offending area, and a register dump.
Although in my test case the problem is a null pointer, this would be useful for
displaying 'off by one' pointer issues, or confirming that data was valid.
- A screen shot. Screen shots have been invaluable for me time
and again. Often, just looking at the screen can tell me where the program failed. But
getting that snapshot is a real problem, especially for customers who aren't comfortable
with their computers. EurekaLog solves this by optionally grabbing the screenshot as a PNG
file, ready to send.
More EurekaLog Options
Once this data is generated on an error, you need to get
it. EurekaLog provides several options:
- The data can be viewed onscreen with a 'detailed' button,
which calls up a dialog with the report.
- You can check a box to copy the text data onto the
Clipboard, ready to paste.
- A disk log can be created, based on your settings.
- The report and optional screen shot can be emailed via MAPI
(user's email client) or SMTP (your server) - again based on your settings.
MAPI usage was straightforward - my email client popped up
with the email filled in and ready to send. For SMTP, I just filled in the email server
information (destination address and password), and rebuilt. Next error, the program
contacted my email server and sent everything quickly and easily.
And although I was at first concerned about security (email
passwords embedded in the program), a byte scan showed neither my email address nor
password in plain text form in the executable.
And Still More Options!
All dialog and message strings are changeable in the
EurekaLog Options dialog. As well, option settings can be saved and loaded, in case your
strings and other settings vary from project to project. This lets you adjust strings for
other languages, or for newer users who may wonder about 'Register' and 'Memory Dump'.
Another feature I found useful was the Terminate button.
Anyone who has debugged knows the first error is often the one that matters, and
subsequent ones are just because of the first. With EurekaLog, a Terminate button can
appear after the first, second, or any message, allowing the program to be aborted, rather
than multiple error messages being produced.
Support for frozen programs is also included, activating
EurekaLog after a timeout value is reached.
Conclusion
EurekaLog comes with good documentation and examples in C++
and Delphi (although I preferred to break my own code). The package is slick,
professional, and well worth a look at - and as a 'try-before-you-buy' product, you can
evaluate it for your needs before you buy.
If I had any comments, I would probably like to see a bit
more at the user end. For instance, when my SMTP login failed (after I put in the wrong
email address), there was no fallback position provided, such as pasting to the clipboard
(although you could enable disk logging, and instruct the user to copy and email that).
I'd also like an option to limit the error messages
directly, rather than just using the Terminate button. That way, when the first bug causes
a cascade of related bugs, the user only has the first one to deal with, instead of
repeated error dialogs.
(Note: mentioning these items to Fabio Dell'Aria, author of
EurekaLog, I found out that with a little coding in the error handlers, these and other
things are possible - proof that manuals make for valuable reading!)
In summary, I found EurekaLog a great tool for remotely
debugging code. The low cost of each package (with and without source code, and for single
user or company), the comprehensive information reported, and the ease of forwarding it to
technical support, all make this a great product. I look forward to adding it to my
projects to make offsite tech support easier - and cheaper.
When I think of all the bugs I could have solved quickly
with a detailed EurekaLog email, I'm sorry I didn't hear about this product long ago. Time
is money, and you're wasting both if you're not using EurekaLog to get accurate
information on bugs as they appear. It's a great tool for the serious developer and
company.
For more EurekaLog information, visit
http://www.EurekaLog.com/ |