Debugging JEVEUX
===============

Using JEVEUX can lead to some specific errors.

There are two tools that allow the developer to detect these errors:


* the execution mode in "debug I want"


* the Jxveri.f90 routine




"debug I want"
--------------

The "debug I want" execution mode is activated in ASTK by checking Options/Parameters/dbgJeWeux before starting the execution.

The code then executes (more slowly) by systematically causing the JEVEUX objects to be read and/or written when they are requested or freed from memory (jeveuo, jelibe, jedema routines). In addition, when an object I want is destroyed (jedetr, jedetc), the memory area it occupied is set to "undef". This code behavior makes it possible to cause a run-time error when:


* You continue to use an object after it is destroyed


* We continue to use an object that has been "released"


* You write to an object when you requested "read" access.




JXVERI
------

Jxveri.f90 is the *Code_Aster* subroutine for detecting an overwrite in JEVEUX's static memory.

It is useful when the code stops with one of the following error messages:


.. code-block:: text

    JEVEUX_15: Upstream crash...

    JEVEUX_16: Downstream crash...

    JEVEUX_17: Broken chain...

The object of debugging is then to locate the instruction that is causing the memory JEVEUX to be overwritten. To do this, we act by successive iterations.

**1st step**

We locate the culprit command using **DEBUT (DEBUG =_F (JXVERI =' OUI ')**)

**2nd step**

We overload (in debug mode) the op00ij routine corresponding to the guilty command by "stuffing" it with **call jxveri (',')**:

.. code-block:: text


        subroutineop00ij (...)

        ...

        call jxveri ('', '')

        Block 1

        call jxveri ('', '')

        Block 2

        call jxveri ('', '')

        Block 3

        call jxveri ('', '')

        End

When executing the code overloaded in this way, the code will stop in a fatal error on the 1st call to guilty jxveri. For example, if it takes place at the end of block 2 (we know the line thanks to the "traceback" printed by the "*post-mortem*" debugger), then we repeat the process by adding "jxveri calls" between the various instructions in block 2. And so on...

In practice, the process converges fairly quickly into the faulty instruction.