[RTEMS Project] #4212: libio leaks location clones
RTEMS trac
trac at rtems.org
Mon Jan 11 05:25:37 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 Sebastian Huber):
From looking at the code, I don't see an issue in the restart code:
{{{!c
void rtems_filesystem_eval_path_restart(
rtems_filesystem_eval_path_context_t *ctx,
rtems_filesystem_global_location_t **newstartloc_ptr
)
{
free_location(&ctx->currentloc);
rtems_filesystem_instance_unlock(&ctx->startloc->location);
rtems_filesystem_global_location_assign(
&ctx->startloc,
rtems_filesystem_global_location_obtain(newstartloc_ptr)
);
rtems_filesystem_instance_lock(&ctx->startloc->location);
rtems_filesystem_location_clone(&ctx->currentloc,
&ctx->startloc->location);
}
}}}
It first frees the current location and then continues with a clone of the
new start location. A test case would definitely help.
The locations are just pointers which are registered in the system. I
think the documentation of rtems_filesystem_location_copy() is in line
with its implementation.
--
Ticket URL: <http://devel.rtems.org/ticket/4212#comment:5>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
More information about the bugs
mailing list