Reporting bugs...

OK, I know many of you will have had no experience in bug reporting or testing before, so I shall try to outline some points below that will make life easier for all of us:

Firstly, when describing a bug, "It doesn't work" is not going to help anyone. You should try to be as descriptive as possible.

Isolated bugs are almost impossible to find, so try to see if you can reliably reproduce the problem, and document the events required to get to the problem.

Crashlogs are usefull. GrimReaper will produce one for you, so use it. Posting crashlogs can sometimes be invaluable in tracking down issues in code.

Serial output is also recommended. Many programs will put warnings and errors out of the serial port. These can be trapped by SashimiPPC or a serial terminal connected via a null-modem lead.

Lastly, try to describe the system the program is running on as best you can, especially versions of libraries etc in use.

Some of you will be using English as a non-native language, so try to choose your words a little more carefully in order to make the report as clear as possible.

The official bugtracker can be found here so please use it to log any bugs, suggestions, enhancements etc. This way we can ensure that the issues do not get lost in forum postings.

Enjoy!

Simon

@Rigo

Nicely done here Rigo, just one small enquiry

where exactly and how much exactly are we looking at for these types of devices/setups?

SashimiPPC or a serial terminal

I guess the prior is an actual device?

and the latter is a choice of what one can use as a serial terminal.

I don't mind purchasing something that is custom built to make the job more precise if not more user friendly. I'd prefer to do that than lug an entire system over just to do that.

Since I will begin my own journey into the coding world eventually I will want to utilise this sort of thing myself

thanks for any insights

btw Rigo, why not make this thread a link in your signature? Could have the link say 'don't bug me or others, read this first'

or

'want to report a bug? avoid being squashed yourself read this first!'

@Slayer

"Debug" output is that printed using IExec->DebugPrintF() and is directed to what I call the "Debug port". If you have "serial" included in the OS4 command line (U-Boot prefs), then the debug port is directed to the serial port (if you have one).
Without "serial" selected, debug output is stored in an Exec buffer and can be recalled using the Shell command DumpDebugBuffer, even after a crash and restart. I don't use this mode (see below).

You can dowload Sashimi from OS4Depot (of course). It comes as an executable that you can run from a Shell or User-startup-sequence and it captures all output sent to the debug port (in my case, the serial port).

Best of all is a terminal (I use an old PC laptop) connected to the serial port. As Rigo said, some programs (especially debug versions of same) spit out diagnostic messages to the debug port during operation or faults. Sashimi will capture these and allow you to save the log *if the system doesn't go down*, but you are in trouble if the system freezes as a result of a crash. In that case only the output from the serial port can be captured by an external machine.

Most of my work is around kickstart modules, so a crash in my stuff usually locks up the machine. Hence, I don't bother with Sashimi, I rely on the serial output.

@Slayer

In the first instance, SashimiPPC is a software solution that redirects any information to the serial port. While this makes for a very easy and compact solution, because it runs on the host machine, if the crash is hard enough, you will lose the serial log. There is the DumpDebugBuffer command, but software solutions can be very hit and miss.

The second instance is a foolproof way to get the output, although not so compact. A machine with a serial port is required, and a null-modem cable which connects the two machines. To set up a machine purely just as a serial terminal can be quite extreme, although many people have another machine and an OS4.x machine. A terminal program is required to capture the output, but this is a much more stable way to read the output. One note here is to make sure both serial ports are set to the same transfer speeds.

Simon

@tonyw @Rigo

Very concise explanations guys, thanks very much for the insight, tips and general good reference.

I have now set up the bugtracker at http://bugs.os4depot.net, please use it to record issues.

Many thanks to Orgin and his hard work for the facility.

Simon