Troubleshooting. Bugs and fixing them.

A script is a simple text file, so you can type anything in it, even complete nonsense. But even scripts that look perfectly fine at first glance can behave very different than the programmer intended. In the simplest case, the compiler throws an error message and displays the faulty line. You should be able to fix that unaided. Otherwise just go again through the C tutorial.

In less trivial cases you'll see an error message when the script is running, and it may be not as informative. The worst case is code that gives no error message at all, but just does not do what it should, or even crashes or freezes. Don't panic: Any programmer encounters such issues all the time. Beginners often cannot imagine that they made a mistake, and suspect a Zorro bug. Seasoned programmers are used to producing bugs and know what to do for fixing them. So get out of beginner mode as soon as possible. Utilize the many books and online seminars about the C language and script writing with Zorro. If you cannof find a bug in your script, check also your historical data - maybe it has gaps, outliers, or irregular time stamps that cause strange results. If you're really stuck, we provide a script fixing service. But first try to solve the problem on your own.

Clean code

The best way to avoid bugs is good coding style that allows quick reading and understanding the code. This should be no problem with strategy scripts that are normally short and have a linear structure. Still, even a 20-line script can be written as a cluttered lump of spaghetti code. Some suggestions for avoiding bugs already when writing the script:

Error messages

All error messages when compiling the script indicate simple syntax errors. Something is mistyped, or a bracket or semicolon is missing (often in the previous line), or an object got the same name as a pre-defined function or variable (their names can be found in the include\functions.h and include\variables.h files), or a variable had a wrong type, or a function had wrong parameters. The script file and line in question is printed in the error message. This makes those errors easy to identify and fix, even for a beginner.

More subtle errors cannot be detected by the compiler, but produce a message at runtime. Under error messages you'll find a list of all such errors and warnings, and their likely reasons. Messages related to opening and closing positions are listed under Log; known issues with brokers are described on the related page (FXCM, IB, Oanda, MT4, etc). The answers to many typical issues of script development can be found in the FAQ list.

If you see a runtime error message (like "Error 123: ....") in the message window, but have no clue at which part of your code the problem happens, the quickest way to find it is placing watch("?...") statements before suspicious places. The parameter is then displayed at the end of the error mesage. For instance, watch("?10") will add a (10) at the end of all subsequent error messages, and watch("?TEST") will add (TEST). You can remove the statements when the error is fixed.

If you trade live and see an error message beginning with an exclamation mark "!", it's a message from your broker, often giving the reason for not opening or closing a trade. For details, see Log about a list of all possible messages in a live trading session.

Unexpected results or strange differences

If backtest results seem not to be right, first look into the log (LOGFILE must be set). Select one or two trades and check them from begin to end. Many parameters can affect trade results in many different ways - make sure to check them all, and also read the remarks on their manual pages. Look for outlier trades with extremely high profits or losses. If needed, make sure that your script can deal with events such as price shocks or stock splits.

Most typical coding errors are easy to spot:

Other errors are not as easy to find. Typical problems:


You expect your script to do something, but it does something else instead. That's a bug. The worst bugs are those that go unnoticed. That's why you should always carefully check the log, even if you don't get any error messages and all seems ok. If you notice something wrong in the log - for instance, the script trades too often, or not often enough, or at the wrong time - first go through your code. Sometimes you will directly see what's wrong, sometimes not. Then you must debug it.

Debugging strategy scripts is a special case of program debugging. You're normally interested in the behaviour of a variable or signal from bar to bar. There are several methods to observe the behavior of variables, either from code line to code line, or from bar to bar, or during the whole test run:

Single Step Debugging
                                 A strategy in the visual debugger

Crashes and freezes

They seem more serious, but are often easier to identify and fix than the bugs that only cause wrong behavior. You can encounter three types of crashes:

For fixing a freeze, first check all loops and recursions in your script and make sure that they terminate. Loops waiting for user input should check with a wait() call if the [Stop] button was hit. Most crashes are normally easy to fix when they happen regularly or always at the same bar or script position. They are only hard to find when they happen irregularly and their reason is not immediately obvious. Zorro has several mechanisms for detecting hard-to-find problems:

If the problem is not caused by the script - for instance, when it happend while trading a Z system - you need to look for an external reason. Activate diagnostics mode as above. If the program then freezes or crashes again, you can see in the last line of the diag.txt at which place it happened. This can indicate which module on your PC is possibly malfunctioning. There are websites and forums on the Internet with more hints for PC troubleshooting.

Zorro bugs

The hopefully least likely reason of script troubles is a bug in Zorro. Look first in the bug list. If you think you've encountered a new Zorro bug that no one else has seen before, please report it to Please give a precise description of what's happening under which circumstances and how to reproduce the problem; include your script, the log, and all related data such as asset list and asset history. You need no support ticket for bug reports. If the bug can be confirmed, it will appear on the bug list and will normally be fixed within a few days.

Don't be disappointed when your bug report is quickly returned to sender, since this happens with 90% of them. You can then safely assume that it's your own task to fix that bug. Use the methods described above, or hire our script fixing service.

Getting help

If really stuck, you can ask for help on the Zorro user forum, or contact with a support ticket. Zorro support will answer all technical questions about Zorro, and give suggestions for solving a particular problem or finding a bug in your script. You don't need a support ticket:

What Zorro support cannot do is teaching the C language or debugging your script. For C, there are lots of books, tutorials, and courses available on the Internet. For hiring a programmer to fix or improve your script, contact us. It takes usually 1-2 hours to find and fix any bug. You can also hire a service for installing a system on your VPS, or for writing specific asset lists and data conversion scripts. The most frequent support issues are listed here

See also:

watch, debugger, error messages, bug list
► latest version online