lseek() past EOF then read() crashes

[Nick Withers]

On Tue, 2013-08-13 at 08:44 -0500, Joel Sherrill wrote:
> Could you post a small self contained example please?

See attached (apologies if it's been stripped...). "make
RTEMS_MAKEFILE_PATH=..." (with GNU make) should do the trick. Commenting
the lseek() or setting the offset to 0 should produce correct results,
with a 0 returned from the subsequent read().

It seems I have to rtems_tarfs_load() the file to reproduce; I was
unable to do so with an open()-created file.
-- 
Nick Withers

Embedded Systems Programmer
Room 2.26, Building 57
Department of Nuclear Physics
Research School of Physics and Engineering
The Australian National University (CRICOS: 00120C)

eMail: nick.withers at anu.edu.au
Phone: +61 2 6125 2091
Mobile: +61 414 397 446

> Nick Withers <nick.withers at anu.edu.au> wrote:
> 
> 
> Hey all,
> 
> (I'm not on the -devel list; please include me in any possible replies,
> if you'd like me to see them)
> 
> I seem to be able to reliably trigger an exception when using lseek() to
> jump past the EOF of a file on IMFS, followed by a read().
> 
> I believe this should not occur, per
> http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html : "No
> data transfer shall occur past the current end-of-file. If the starting
> position is at or after the end-of-file, 0 shall be returned. If the
> file refers to a device special file, the result of subsequent read()
> requests is implementation-defined"
> 
> This is on an MVME3100 (PowerPC) with Git HEAD RTEMS, circa 2013-08-12.
> 
> I've got a stack trace (not totally sure I trust it) if someone'd like?
> Perhaps lseek() isn't supported on IMFS? The file in question's been
> rtems_tarfs_load()ed there, if that could make a difference...?
> 
> If it's meant to work, would you like me to file a bug report with the
> stack trace?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lseek_read.tar.gz
Type: application/x-compressed-tar
Size: 1476 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130814/9e949f49/attachment-0001.bin>