CS Seg Faults when using memory definition table (CS.DefMemoryTbl)

[dmknutsen]

Describe the bug
On a 64-bit system, CS will intermittently seg fault when it attempts to checksum an address defined by the memory definition table (CS.DefMemoryTbl). Further, when you dump the results table for a given address defined by the memory definition table - the address is byte swapped...which I do not believe to be the expected result and may help in de-bugging this issue.

To Reproduce
Steps to reproduce the behavior:

1. Start cFS
2. Load/validate/activate a memory definition table with a non-zero address
3. Observe Seg fault when CS attempts to checksum the entry with non-zero starting address.

System observed on:
Oracle VM VirtualBox
OS: ubuntu-20.10
Versions: cFS Versions: cfe v7.0.0-rc4+dev96, osal v6.0.0-rc4+dev66, psp v1.6.0-rc1+dev14.

Reporter Info
Dan Knutsen
NASA Goddard

[astrogeco]

CCB:2022-04-27 DISCUSSED

• @skliper to add details

[semaldona]

On Linux, the checksum addresses used in the memory tables must be accessible to the cFS process in userspace. CS uses the cFE API cFE_ES_CalculateChecksum, which makes the assumption that the memory addresses are directly accessible and do not require any special logic to access. See https://github.com/nasa/cFE/blob/main/modules/es/fsw/src/cfe_es_api.c#L1691. Any attempt to access memory not available to the cFS process will cause the Linux kernel to raise an exception and cause a segmentation fault.

Because the Linux process memory address range may change with each invocation of the cFS executable, a memory address that was once accessible on a previous run may not be accessible on a subsequent one. This makes it impractical to use hard coded addresses in CS memory tables on Linux without some special setup.

The byte swap issue was found to be caused by the CTF reqval plugin script not accounting for the endianness of the target platform.

Recommending closure of this issue as no CS defect was identified.

[skliper]

Marked for discussion (@astrogeco). One approach for systems that aren't using fixed addresses would be to create the table "on the fly". For CTF testing maybe use an app to generate the table that you could run, then load that generated table based on the currently valid addresses (all in the same run).

[astrogeco]

CCB:2022-05-04 Discussed

• Create table after you know what the valid addresses are
• Use dynamic lookup to choose a valid symbol in testing
• @dmknutsen to test manually and show that this works before closing
• Can we protect against segfaults?
• Should we deprecate hard-coded addresses in tables? What are the use cases? Are they frequent enough?
• This functionality can be replicated using the "one shot" checksum command

[dmknutsen]

We are looking into the possibility of creating 'tables on the fly' for CTF testing. This issue can be closed because the seg faults are the expected Linux behavior.

[skliper]

Just to clarify - the memory definition table memory addresses and sizes all need to be valid or a SEGFAULT could occur due to CS attempting to read invalid memory. The PSP could catch a SEGFAULT and handle it if needed.