Opened on 11/13/18 at 06:18:07
Closed on 12/12/19 at 18:19:17
#3605 closed defect (fixed)
RTL Allows Unloading a Module other Modules Depend Upon (cloned)
Reported by: | Kevin Gordon | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 5.1 |
Component: | lib/dl | Version: | 5 |
Severity: | major | Keywords: | RTL dlopen dlcose |
Cc: | Blocked By: | ||
Blocking: |
Description
Cloned from #3195:
Consider the following example using ELF .o files from compiled source files module-0.c and module-1.c from ticket #3194:
module-0.o is loaded using dlopen() with no code or data dependencies.
module-1.o is loaded using dlopen() with both code and data dependencies on module-0 which are resolved by RTL.
The RTL function dlcose() returns no error when module-0 is unloaded, when it should return an error and not unload module-0. This becomes quite dangerous because a subsequent call to module1Function1() in the currently-loaded module-1.o, which accesses shared_resource_0[ ] and calls module0Function0(), will result in an unexpected trap on qemu or the call succeeding with the correct return value on hardware when it should not.
The erroneous successful unload() of module-0 aside, it appears as though the resources are not actually deleted and I believe this ticket is related to tickets #3192 and #3194.
Architecture is sparc-leon3 using both the RTEMS 4.11.1 public release and rtems master @f043b9bd3bf25626fb1a311dd7fa041eacc68adc with rtems-source-builder @55f2d69e9b67cde23d61375fa34ef5b0f04a985d.
Execution environments are qemu-system-sparc and LEON3 UT700 hardware.
Change History (3)
comment:1 Changed on 11/22/18 at 02:17:31 by Chris Johns <chrisj@…>
comment:2 Changed on 12/12/19 at 17:08:23 by Chris Johns
Kevin, is this fixed? It would be nice if we can close this ticket.
comment:3 Changed on 12/12/19 at 18:19:17 by Chris Johns
Resolution: | → fixed |
---|---|
Status: | new → closed |
The email bounced. I will close this.
In [changeset:"03139d5b1cf95d5b2f699e8f56e1f0ba2d7f89e4/rtems" 03139d5b/rtems]: