[RTEMS Project] #4212: libio leaks location clones
RTEMS trac
trac at rtems.org
Thu Jan 7 22:20:27 UTC 2021
#4212: libio leaks location clones
-------------------------+---------------------
Reporter: Chris Johns | Owner: (none)
Type: defect | Status: new
Priority: normal | Milestone: 6.1
Component: fs | Version: 6
Severity: normal | Resolution:
Keywords: | Blocked By:
Blocking: |
-------------------------+---------------------
Comment (by Chris Johns):
Replying to [comment:1 Sebastian Huber]:
> Do we have this resource leak with one of the current file systems?
Yes I believe there is a leak with `open` as stated above.
> If yes, could you please add test case for this resource leak.
A test is a good idea however as stated I do not understand the
''locations'' struct and the eval code in `libio`. I could create a test
and provide a fix and break an existing file system.
Maybe the following will help explain why I am confused:
1. Is this simply a bug in `open`? Does ...
{{{
rtems_filesystem_eval_path_cleanup( &ctx );
rtems_filesystem_eval_path_extract_currentloc( &ctx, &iop->pathinfo );
}}}
... resolve the leak? Does that create another leak and so should the code
be ...
{{{
rtems_filesystem_eval_path_cleanup( &ctx );
rtems_filesystem_eval_path_extract_currentloc( &ctx, &iop->pathinfo );
rtems_filesystem_eval_path_cleanup( &ctx );
}}}
... ? Would fixing the copy also resolve this leak? I have no idea which
of these is right solution because I do not understand how this is suppose
to work.
2. The call `rtems_filesystem_location_copy()` does not ''free'' the
resource. The only doco with this function says it is a bitwise copy yet
the resource will be added to the corresponding mount. This is confusing
because the resource is accounted for yet it does not perform a deep copy
of the contents when the file is required to provide an interface to do
this.
--
Ticket URL: <http://devel.rtems.org/ticket/4212#comment:2>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
More information about the bugs
mailing list