What to Include

The more information you can give us about the problem and the environment in which it occurs, the faster we can resolve the problem. Below is a list of information that is helpful to us. Not every item is appropriate for a particular report, but please include whatever you can.

1.

Tell us what release of Shore you're using (the current release is Version 1.1.1 ).

2.

Tell us what operating system and architecture you are using.

3.

Indicate whether you are using one of the binary releases (and if so, whether it is the debugging or no-debugging version) or you compiled Shore yourself. If you compiled it yourself, what version of the compiler did you use? What configuration options did you use (IncludeDebugCode, Optimize, etc.)? Include a copy of config/config.h.

4.

Is the problem reproducible or sporadic? If it is reproducible, tell us exactly what sequence of events led up to the problem. Send us a typescript if possible.

5.

What compiler (including version) are you using to compile your application (or value-added server, if that's what you are building)? Run gcc -v to get this version number. If this is not a version supported by Shore (see the Requirements section of the Installation Manual), don't send a problem report; upgrade your compiler. Similarly, check versions of other software mentioned in the Requirements .

6.

What error messages or warnings were produced by your failed program? Don't try to reproduce them from memory. Yank the messages verbatim with your mouse, or better still capture the output by rerunning your program with the Unix script(1) utility and send the resulting typescript.

7.

If the program that failed is a client, what did the server have to say about it? Did the server produce any error messages? If possible, run the server in the foreground with a Tcl shell and type "suppress off" and "log client info" before running your client. Once again, capture the actual server output and include it with your bug report.

8.

If your program aborted with a segmentation fault or an assertion failure, try to get a stack trace with gdb and send us the result.

If your program does not get a segmentation fault, but does get another error, run it with gdb and get a stack trace at perrstop (unless you are writing your own value-added server and using the Storage Manager directly).

Please do your best to track down the source of the problem with gdb, debugging print statements, and other debugging tools at hand (that is, to give us a reasonable amount of detailed information). Remember that Shore is freeware; the project runs on limited resources, and every bit of help you can give us allows us to do more work on Shore extensions.

9.

If you cannot compile your program because you get a compilation error that you do not understand, and if the error appears to be in the Shore sources, try using the -E -dD options on gcc. Send the output to a file and look at the file. Often these problems are due to the fact that a file (included before config.h or before the C++ language binding) defines a C-preprocessor-macro that confuses matters.

If you cannot glean any useful information from this, use the -E -dD -P options on gcc, and pipe the results to a file junk.C. Compile junk.C with gcc. Often this will pinpoint the problem.

If you still cannot glean any useful information, send us junk.C in a separate mail message , with the subject "junk.C".