Date: Thu, 13 Nov 2003 01:04:24 -0800 (PST) From: Marcel Moolenaar <marcel@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/usr.bin/truss syscalls.c Message-ID: <200311130904.hAD94Oms092178@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
marcel 2003/11/13 01:04:24 PST
FreeBSD src repository
Modified files:
usr.bin/truss syscalls.c
Log:
Do not ignore any possible errors that fseeko() may have. The fact
is that fseeko() fails in very predictable and frequent ways on ia64.
This is because the offset is actually an address in the process'
address space, which on ia64 can be larger than long (for lseek) or
off_t (for fseeko). The crux is the signedness. The register stack
and memory stack are in region 4 on ia64. This means that the sign bit
is 1. The large positive virtual address is wrongly interpreted as
a negative file offset.
There's no quick fix. Even if you get around the API by using a
SEEK_SET up to LONG_MAX and follow it up with a SEEK_CUR for the
remainder, the kernel simply cannot deal with it. and the second
seek will just fail.
Therefore, this change does not actually fix the root cause. It just
makes sure we're not spitting out all kinds of garbage or that the
get_struct() function in particular does not cause truss(1) to exit.
This, I might add, invariably happened way too soon for truss(1) to
be of any use on ia64...
Revision Changes Path
1.33 +24 -22 src/usr.bin/truss/syscalls.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311130904.hAD94Oms092178>