Known problems with XALT
------------------------

Here is a list of known areas of concern.

Signal Handling
^^^^^^^^^^^^^^^

Some executable do not like the way XALT registers signals.  However
no reproducers have been reported.  To test if XALT's signal handler
presents a problem is to set the env. variable **XALT_SIGNAL_HANDLER**
to "no".  Note that it is optional to have XALT register a signal
handler.

Segfaults due to user's bad memory management
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

One reported case where a program worked without XALT and segfaulted
under XALT was due to bad memory management in the user's code. In
this particular case, the user code was using a link list.  The logic
in the code required that the next pointer in the link list struct was
NULL terminated at the end of the link list. However in this user
code, the step to NULL terminate the tail list was omitted.

Without XALT, the program gets the allocated memory with zero'ed
because every program starts that way.  With XALT, memory is used and
free'd which might have non-zero entries.

The fix for this particular program was to fix the link list
implementation. 

To minimize this risk, XALT uses *memset()* to clear the memory before
calling *free()*.  However, XALT can't control what system routines
such as *asprintf()* does with the memory they use internally.

A second case was reported where a code did something like the
following::

    #ifndef _GNU_SOURCE
    #define _GNU_SOURCE
    #endif

    #include <unistd.h>
    #include <stdio.h>
    #include <string.h>
    #include <stdlib.h>	

    extern char **environ;

    int my_copyenv(char *oldenv[])
    {
       char* eq;
       int   i;

       // The clearenv() function clears the environment of all
       // name-value pairs and sets the value of the external variable
       // environ to NULL. 

       clearenv();
       for (i = 0; oldenv[i]; i++) {
         if (!(eq = strchr(oldenv[i], '=')))
           continue;

         *eq = '\0';
         setenv(oldenv[i], eq + 1, 1);
       }
    }

    int main(int argc, char *argv[])
    {
       my_copyenv(environ);
    }
    
The problem with this code is that clearenv() is possibly freeing
memory that comes from **environ** then it walks the freed memory
via the **oldenv** variable.  This program doesn't normally seg-fault
but it can with XALT.  Because this program is walking freed memory it
is an unsafe program.

Segfaults due to name collision
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

When XALT is being used,  the names used in the libxalt.so are in the
same namespace as the original program.  In one particular case, a
fortan program was build that provided its own *random()* routine
which was different from the *random()* routine provide by the c
library. XALT requires a UUID library which needs to call the
*random()* function.  The user's own *random()* was used by uuid
library rather than the c library one causing the program to
segfault.

You can detect this kind of problem if the program aborts in the
*myinit()* routine.

Earlier versions of XALT include libuuid routines as part of the
user executable.  Later versions have moved these calls to the
*xalt_run_submission* program so this particular name collision has
been removed.

This name collision is a potential problem in any executable.  XALT
uses macros to rename all names under its control to names that is
exceedingly unlikely to be found in user code (see
src/xalt_obfuscate.h).  However XALT cannot control user codes,
particular FORTRAN codes, that reuse names of routines in the C
library that XALT depends on. Normally, FORTRAN programs do not
present a problem because the subroutine or function ABC is usually
linked in with the name *abc_*. But the fortran compilers can
optionally told to not add the trailing underscore. By removing the
trailing underscore, FORTRAN routines can collide with the names of C
routines including routines in the standard C library.

C or C++ programs are unlikely to reuse names from the C library but
this can be a problem for FORTRAN programs which turn off the trailing
underscore in the link name.

This issue appears to be rare as only one case has been reported.