[Bug 1902] failure to copy node_access contents in sup_fs_get_start_loc.c

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1902

--- Comment #2 from Carl Lionberger <calionberger at lbl.gov> 2011-08-24 14:24:42 CDT ---
(In reply to comment #1)
> (In reply to comment #0)
> [...]
> > This causes
> > the node_access contents of both loc and rtems_filesystem_current to be free'd
> > when the loc node info is free'd.  I am attaching the diff that fixes this for
> > tftpfs although I've heard other file systems store other types of objects
> > here.
> 
> Is the "loc node" the one of "*loc = rtems_filesystem_current;"?  Who frees the
> loc node?

Yes.  This copy is done in the course of the C library open() function.  The
freeing occurs in the tftpfs driver operation rtems_tftp_free_node_info() 
("freenodeinfo" in op table).  This happens at the end of the close() function. 
> 
> Do you have a sequence of function calls that reproduce the problem?

 If you set a working directory (chdir()) it will be in the node_access member
of rtems_filesystem_current after the eval_path operation.  Then you can open a
file, using a relative path, successfully, and read from it.  Then when you
close it the loc copy is run through the freenodeinfo operation and the (in
tftpfs its a string) node_access is free'd.  But that is the same object still
pointed to by the node_access field in   rtems_filesystem_current.  So now the
pointer in rtems_filesystem_current is invalid.  Anything could in principle
happen on subsequent opens but with my situation the current working directory
is of zero length -- does the rtems free() [perhaps accidentally] put a null in
the first byte or something? Anyway, the relative path evaluation fails,
although absolute path opens will still work.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.