Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CFE_PSP_MemValidateRange() always fails on 64-bit targets #281

Closed
jphickey opened this issue Mar 29, 2021 · 0 comments · Fixed by #283 or #288
Closed

CFE_PSP_MemValidateRange() always fails on 64-bit targets #281

jphickey opened this issue Mar 29, 2021 · 0 comments · Fixed by #283 or #288
Assignees
@jphickey
Labels
bug Something isn't working
Milestone
Caelum

Comments

@jphickey
Copy link
Contributor

Describe the bug
When attempting to telemeter Memory Pool stats, CFE ES calls CFE_PSP_MemValidateRange() on the address of the pool data. However on 64 bit Linux this function ends up always returning an error, because the internal table is not set up for 64 bit address

To Reproduce
Run CFE on a 64-bit pc-linux platform, then issue CFE ES command code CFE_ES_SEND_MEM_POOL_STATS_CC (22) with a valid Pool ID.

This always fails and says invalid handle, even though the handle is actually fine, because it is not passing the CFE_PSP_MemValidateRange() check.

Expected behavior
Check should pass.

Code snips
If applicable, add references to the software.

System observed on:
Ubuntu 20.04 (64-bit)

Additional context
This table is still using uint32 sizes. It must have been missed in the previous updates that changed much of this to size_t.

Reporter Info
Joseph Hickey, Vantage Systems, Inc.
@jphickey jphickey self-assigned this Mar 29, 2021
@jphickey jphickey added the bug Something isn't working label Mar 29, 2021
jphickey added a commit to jphickey/PSP that referenced this issue Mar 29, 2021
@jphickey
Fix nasa#281, cleanup memory range table
d69b175 
A number of cleanup items related to the PSP memory range API

- Make the table itself an internal object - should only be accessed
via the PSP API.
- Update to use size_t instead of uint32
- Update the Linux/RTEMS implementation to use full range (SIZE_MAX).
jphickey added a commit to jphickey/PSP that referenced this issue Mar 29, 2021
@jphickey
Fix nasa#281, cleanup memory range table
42f0914 
A number of cleanup items related to the PSP memory range API

- Make the table itself an internal object - should only be accessed
via the PSP API.
- Update to use size_t instead of uint32
- Update the Linux/RTEMS implementation to use full range (SIZE_MAX).
@jphickey jphickey mentioned this issue Mar 29, 2021
Merged
jphickey added a commit to jphickey/PSP that referenced this issue Mar 29, 2021
@jphickey
Fix nasa#281, cleanup memory range table
94f104b 
A number of cleanup items related to the PSP memory range API

- Make the table itself an internal object - should only be accessed
via the PSP API.
- Update to use size_t instead of uint32
- Update the Linux/RTEMS implementation to use full range (SIZE_MAX).
jphickey added a commit that referenced this issue Mar 29, 2021
@jphickey
Fix #281, cleanup memory range table
4db4fbe 
A number of cleanup items related to the PSP memory range API

- Make the table itself an internal object - should only be accessed
via the PSP API.
- Update to use size_t instead of uint32
- Update the Linux/RTEMS implementation to use full range (SIZE_MAX).
@skliper skliper added this to the 1.6.0 milestone Mar 30, 2021
jphickey added a commit that referenced this issue Apr 2, 2021
@jphickey
Merge pull request #283 from jphickey/fix-281-memrange-cleanup
54083e1 
Fix #281, cleanup memory range table
@astrogeco astrogeco mentioned this issue Apr 2, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jphickey jphickey

Labels
bug Something isn't working
Projects
None yet
Milestone
Caelum
2 participants
@jphickey @skliper