FAQ's - APPX Software, Inc. : APPX Utility : APPX System Administration :
"mm free()-corrupted trailer"
If environment variable APPX_TRAILER_COUNT has been set, you can get the message mm.c.876 - "mm free()-corrupted trailer". This message indicates that some unexpected condition is causing memory to be overwritten.
(Without APPX_TRAILER_COUNT, real data or executable code would have gotten overwritten, with an unpredictable results, probably a cassert message, that is otherwise unexplainable.)
As of 4.1.4 and later, also set the environment variable:
APPX_LABEL_MEMORY=1This tells APPX to attach a label to each chunk of allocated memory. This label will be included in the "corrupted trailer" message and should give us a clue as to what is being corrupted.
If this error occurs, the user should immediately write down the last few things he/she did, prior to the error occurring. User should then exit APPX.
If APPX_SCRIPT_OUT tracking is enabled, the script-log should be preserved, for analysis. APPX can then safely be reentered.
To diagnose, run:
Application Design > Utilities > Toolbox > Conversion Utilities > Check for Duplicate ANO and EMs.
If any Applications don't pass ("No Lines Were Output" means they pass), perform the following procedure:
1) Run:
Conversion Utilities > Reset Process Date Add Fields
Conversion Utilities > Reset DD for full process
3) Go into System Admin > Source File Management for your
application, initialize the 4 DD object files (BITMAP,
ELEMENT, FILE, INITIAL), and recompile the Data
Dictionary.
4) Restructure your enduser datafiles.
(This shouldn't take long.)
5) Delete your Application's EMs
If this doesn't help, go into a more manual debugging mode. You'll need to be able to make this condition occur, upon demand. Make a copy of the process family involved, make sure the error still exhibits itself, then start stripping design elements out of it, until you zero in on the design element that is causing the error. You may want to call Appx Support to get guidance on this.APPX_TRAILER_COUNT tells APPX to append additional "trailer" bytes to every memory allocation. Example:
export APPX_TRAILER_COUNT=40These bytes are filled with known values and checked for corruption when the memory is given back to the system. This can find if APPX is writing beyond the end of an allocated chunk of memory or if, for some other reason, the memory is getting stepped on.
APPX presents a "mm.c.876: mm free()-corrupted" cassert immediately upon detecting memory corruption that steps on this trailer. The message comes at the end of the job, when Appx is cleaning up (returning to the OS) memory that it allocated and wrote to earlier in the job.)
It may be prudent to keep the APPX_TRAILER_COUNT environment variable
permanently on, in order to avoid unexpected and harder to detect memory
corruption. APPX_TRAILER_COUNT has very low overhead.
As an example, an error message of: "mm free() - corrupted trailer (AREA: 0LA:7.2)" indicates that there has been memory overwritten associated with the writing of ERROR statement error log. In this case, an ERROR statement may be trying to write more than 250 bytes to the Appx error log when an UPDATE has just run.
(This might happen by the execution of an ERROR --- TEMP 2K statement, where
TEMP 2K was populated with more than 250 bytes of data. This can be diagnosed
by looking at the ERROR log produced by the update. At least one line should
be filled with 250 bytes of Error text, and probably truncated.)
See also FAQ:
How do you diagnose strange or generic errors (such as bus errors, seg faults, attempting to free freed memory errors, or "an internal error has been detected" errors)?(from ecr #3353)
French Characters in Oracle