[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