How do I report a bug? What information should I include?

You should report a bug by sending an e-mail to magma-bugs@maths.usyd.edu.au.

The more information you can provide, the easier it is for us to duplicate and attempt to solve your problem. At the very minimum we will require:

If the bug appears to be sporadic, it most likely depends on the initial seed of the random number generator. You should include this information in your report. The initial seed is printed when you start Magma, e.g.

Magma V2.16-11    Tue 13 2010 11:07:05 on fano     [Seed = 1431482434]
If the problem is mathematical, we appreciate suggestions about how we might fix it, references to papers and algorithms, and so on.

Why should I bother reporting a problem?

Only a very small number of users regularly report bugs. Obviously this causes us problems: bugs exist because we don't know that they're there, and we depend on reports from the Magma community in order to find and fix them. We really appreciate bug reports, and promise that any problems you submit will not be ignored.

In addition to actual crashes, we also encourage users to report possible problems with, and improvements to, the algorithms Magma uses. If you're finding a particular computation unexpectedly slow and have a suggestion about how your case could be improved, please let us know.

How quickly will my bug be fixed?

Each major release of Magma contains many new algorithms, and will often push the software in a completely new direction. Unfortunately, bugs are inevitable. We regard it as absolutely vital to be able to provide bug fixes and get them out to users as quickly as possible; we release approximately fifteen patch releases each year. In this way users who commit to undertaking large projects with Magma have the assurance that any major problems they encounter will usually be rapidly resolved. If the problem is particularly urgent, we can sometimes send you a temporary fix before the official patch release is ready.

The latest patch release can be obtained from the downloads page. The release notes record the latest changes.

How can I recover my Magma session in order to include it in an e-mail?

You can recover your Magma session by typing %P (followed by enter or return) on the Magma command line. This will output a list of all the commands you've entered; if you send us this output, we will hopefully be able to recreate your problem.

What is an “Internal Error”?

An “internal error” will generate output similar to the following:

Internal Error
Machine type: intel64-osx
Initial seed: 1431482434
Time to this point: 1.36
Memory usage: 23.07MB
A brief description of the error
This is a defensive error message. The Magma code regularly asserts that the situation it expects to be in is, in fact, how things stand. For example, it might expect to be working over an algebraically closed field but, upon checking, discovers that it's working over . Generating an internal error is a way to report these problems before they lead to a more serious crash or, even worse, incorrect answers.

We encourage users to report all internal errors. They are often caused by an incorrect assumption or oversight on our part and, once we're made aware of them, can usually be fixed in time for the next patch release.

What does the Magma group do to check for problems?

The members of the Computational Algebra Group use Magma every day as an essential tool in their research. Through this, many bugs are found and fixed before they are exported to the wider community.

The Magma group runs nightly tests of the latest development version of the code, and the logs are reviewed each morning. This helps catch problems arising from changes to existing algorithms and unexpected interaction between exported functions. A significant part of Magma's development is in optimising and refining existing functionality; the nightly tests help keep new problems to a minimum. Most Magma developers also maintain private error-testing code that isn't part of the general release (usually because it takes a significant length of time to run, or because it requires unusual amounts of memory). We also have tools to see which parts of the package code are covered by the tests, and run a special version of Magma which performs many more checks than the released version.

Before a new version (or patch release) of Magma is made available, we verify the executable against our standard test files. This helps reduce the chance of compiler error, and catch any last-minute problems that might have crept in. Major releases of Magma are also distributed to a group of external “beta testers” several weeks before the version is made public.

Finally, the public version of Magma comes with a collection of test files so that you can verify that Magma is working correctly on your machine. These files can be found in your Magma installation directory, in libs/test/. The test directory contains a README file explaining how you can run the tests for yourself.

FAQ Index