debugmode

Guide

The DebugMode evaluation mode includes a number of self-checks and assertionsthat can help to diagnose several kinds of programmer errors that can lead toincorrect output.

It is much slower to evaluate a function or method with DebugMode thanit would be in 'FAST_RUN' or even 'FAST_COMPILE'. We recommended you useDebugMode during development, but not when you launch 1000 processes ona cluster.

DebugMode can be used as follows:

  1. import theano
  2. from theano import tensor
  3. from theano.compile.debugmode import DebugMode
  4.  
  5. x = tensor.dscalar('x')
  6.  
  7. f = theano.function([x], 10*x, mode='DebugMode')
  8.  
  9. f(5)
  10. f(0)
  11. f(7)

It can also be used by setting the configuration variable config.mode.It can also be used by passing a DebugMode instance as the mode, as in

  1. >>> f = theano.function([x], 10*x, mode=DebugMode(check_c_code=False))

If any problem is detected, DebugMode will raise an exception according towhat went wrong, either at call time (f(5)) or compile time (f = theano.function(x, 10*x, mode='DebugMode')). These exceptionsshould not be ignored; talk to your local Theano guru or email theusers list if you cannot make the exception go away.

Some kinds of errors can only be detected for certain input value combinations.In the example above, there is no way to guarantee that a future call to say,f(-1) won’t cause a problem. DebugMode is not a silver bullet.

If you instantiate DebugMode using the constructor compile.DebugModerather than the keyword DebugMode you can configure its behaviour viaconstructor arguments.

Reference

  • class theano.compile.debugmode.DebugMode(Mode)[source]
  • Evaluation Mode that detects internal theano errors.

This mode catches several kinds of internal error:

  • inconsistent outputs when calling the same Op twice with the sameinputs, for instance if ccode and perform implementations, areinconsistent, or in case of incorrect handling of output memory(see _BadThunkOutput)
  • a variable replacing another when their runtime values don’t match. This is a symptom ofan incorrect optimization step, or faulty Op implementation (raises BadOptimization)
  • stochastic optimization ordering (raises StochasticOrder)
  • incomplete destroy_map specification (raises BadDestroyMap)
  • an op that returns an illegal value not matching the output Variable Type (raisesInvalidValueError) Each of these exceptions inherits from the more generic DebugModeError.

If there are no internal errors, this mode behaves like FAST_RUN or FAST_COMPILE, but takesa little longer and uses more memory.

If there are internal errors, this mode will raise an DebugModeError exception.

  • stability_patience = config.DebugMode.patience

  • When checking for the stability of optimization, recompile the graph this many times.Default 10.

  • check_c_code = config.DebugMode.check_c

  • Should we evaluate (and check) the c_code implementations?

True -> yes, False -> no.

Default yes.

  • check_py_code = config.DebugMode.check_py
  • Should we evaluate (and check) the perform implementations?

True -> yes, False -> no.

Default yes.

  • check_isfinite = config.DebugMode.check_finite
  • Should we check for (and complain about) NaN/Inf ndarray elements?

True -> yes, False -> no.

Default yes.

  • require_matching_strides = config.DebugMode.check_strides
  • Check for (and complain about) Ops whose python and Coutputs are ndarrays with different strides. (This can catch bugs, butis generally overly strict.)

0 -> no check, 1 -> warn, 2 -> err.

Default warn.

  • init(self, optimizer='fast_run', stability_patience=None, check_c_code=None, check_py_code=None, check_isfinite=None, require_matching_strides=None, linker=None)[source]
  • Initialize member variables.

If any of these arguments (except optimizer) is not None, it overrides the class default.The linker arguments is not used. It is set there to allowMode.requiring() and some other functions to work with DebugMode too.

The keyword version of DebugMode (which you get by using mode='DebugMode)is quite strict, and can raise several different Exception types.There following are DebugMode exceptions you might encounter:

  • class theano.compile.debugmode.DebugModeError(Exception)[source]
  • This is a generic error. All the other exceptions inherit from this one.This error is typically not raised directly.However, you can use except DebugModeError: … to catch any of the morespecific types of Exception.
  • class theano.compile.debugmode.BadThunkOutput(DebugModeError)[source]
  • This exception means that different calls to the same Op with the sameinputs did not compute the same thing like they were supposed to.For instance, it can happen if the python (perform) and c (c_code)implementations of the Op are inconsistent (the problem might be a bug ineither perform or c_code (or both)). It can also happen ifperform or c_code does not handle correctly output memory thathas been preallocated (for instance, if it did not clear the memory beforeaccumulating into it, or if it assumed the memory layout was C-contiguouseven if it is not).
  • class theano.compile.debugmode.BadOptimization(DebugModeError)[source]
  • This exception indicates that an Optimization replaced one variable (say V1)with another one (say V2) but at runtime, the values for V1 and V2 weredifferent. This is something that optimizations are not supposed to do.

It can be tricky to identify the one-true-cause of an optimization error, butthis exception provides a lot of guidance. Most of the time, theexception object will indicate which optimization was at fault.The exception object also contains information such as a snapshot of thebefore/after graph where the optimization introduced the error.

  • class theano.compile.debugmode.BadDestroyMap(DebugModeError)[source]
  • This happens when an Op’s perform() or c_code() modifies an input that it wasn’tsupposed to. If either the perform or c_code implementation of an Opmight modify any input, it has to advertise that fact via the destroy_mapattribute.

For detailed documentation on the destroy_map attribute, see Inplace operations.

  • class theano.compile.debugmode.BadViewMap(DebugModeError)[source]
  • This happens when an Op’s perform() or c_code() creates an alias or alias-likedependency between an input and an output… and it didn’t warn theoptimization system via the view_map attribute.

For detailed documentation on the view_map attribute, see Views.

  • class theano.compile.debugmode.StochasticOrder(DebugModeError)[source]
  • This happens when an optimization does not perform the same graph operationsin the same order when run several times in a row. This can happen if anysteps are ordered by id(object) somehow, such as via the default objecthash function. A Stochastic optimization invalidates the pattern of workwhereby we debug in DebugMode and then run the full-size jobs in FAST_RUN.
  • class theano.compile.debugmode.InvalidValueError(DebugModeError)[source]
  • This happens when some Op’s perform or c_code implementation computesan output that is invalid with respect to the type of the corresponding outputvariable. Like if it returned a complex-valued ndarray for a dscalarType.

This can also be triggered when floating-point values such as NaN and Inf areintroduced into the computations. It indicates which Op created the firstNaN. These floating-point values can be allowed by passing thecheck_isfinite=False argument to DebugMode.