3. 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

3.1. « 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.

3.2. 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:

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 (“,”):

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.