This page gives guidance on how to deal with bugs in the MINOS offline code. It includes:

1. Common bugs in the offline framework.

2. How to best report bugs you think you may have found in the offline framework.

3. ...

Common bugs in the offline framework

• Loon dies with a "Segfault", "SegV" or "Signal 11".

  This is caused by an attempt to access an illegal memory location. It can happen through one of these ways:

  • Indexing an array or std::vector beyond the end
  • Dereferencing a zero pointer
  • Dereferencing an uninitialized pointer holding garbage
• Loon dies with a "Floating point violation", "SIGFPE", or "Signal 8".

  This is caused by:

  • Division by zero
  • Using an illegal bit pattern that doesn't match the FP format
  • Illegal arguments to math functions
  For many years MINOSSOFT did not have the necessary code turned on so that Floating Point Signals would be emiitted. This caused any errors to silently propagate as "NaN" numbers. It was decided to turn this code on so the errors are caught at their source. As a consequence many errors are causing crashes.

How to best report bugs.

• If loon crashes, follow these steps and send all of the results to minos_software_discussion@fnal.gov.
  1. Include version info for:
     • GCC
     • MINOSSOFT
     • ROOT
     • Any third party packages that might relate to the problem.
  2. Generate a stack trace:

     shell> gdb loon
     (gdb) run [all the usual arguments to loon]
     ... let it run until crashing ...
     (gdb) list
     ... the area around the crash will be displayed ...
     (gdb) where
     ... stack trace prints ...
     

  3. Send the controlling macro (.C) file
  4. Give a URL to an input file that will reproduce the problem
  5. Any additional info that you think might be relavent.

• If there is no crash but results look weird send a description to minos_software_discussion@fnal.gov if you suspect the framework, or minos_reco@fnal.gov if you suspect reconstruction code.

Security, Privacy, Legal