[Openmcl-devel] Problem with files of some kind, linux x86-32

[Gary Byers]

Matt just fixed (in r11046) part of this; trying to seek to the end of
/proc/cpuinfo (to determine the length of the file) returns -1

> [pid  8335] lseek(4, 0, SEEK_END)       = -1 EINVAL (Invalid argument)

presumably because /proc/cpuinfo isn't a real file.  The "-1" in question
is 64 bits long, but the compiler was only picking up the low 32 bits
of that (which is where the #xfffffffff was coming from.)

So, the code attempted to store #xffffffff (which is a bignum on 32-bit
platforms) in a structure slot that's defined as:

(defstruct (file-ioblock (:include ioblock))
   ...
   (fileeof 0 :type fixnum)		; file length in elements

Who says that a file's length in elements is a fixnum, and does
anything actually believe that ?

(I'm pretty sure that nothing does believe that.  We started checking
type constraints on structure slots sometime in the last ~6 months or
so; prior to that, the type constaint above was wrong but completely
ignored.)

As if things weren't bad enough: the 64-bit return value from 'lseek'
was a 32-bit value, sign-extended to 64 bits (before we dropped the
high half.)  We really should be using 'lseek64' on Linux.

Lastly (with Matt's fix in place):

? (with-open-file (f "/proc/cpuinfo")
   (file-length f))
-22

Perhaps NIL (indicating that we can't determine the file's length)
would be a better answer ...



On Fri, 10 Oct 2008, David Brown wrote:

> Not sure all that is required to reproduce this.
>
> Welcome to Clozure Common Lisp Version 1.3-dev-r11045M-trunk  (LinuxX8632)!
> ? (machine-version)
>> Error: value 4294967295 is not of the expected type FIXNUM.
>> While executing: CCL::MAKE-FILE-STREAM, in process listener(1).
>> Type :POP to abort, :R for a list of available restarts.
>> Type :? for other options.
> 1 > :b
> *(F7AC4C74) : 0 (MAKE-FILE-STREAM "/proc/cpuinfo" :INPUT 'BASE-CHAR :IGNORED NIL 'CCL::BASIC-FILE-STREAM :DEFAULT :PRIVATE T) 2732
>  (F7AC4D10) : 1 (OPEN "/proc/cpuinfo" [...]) 751
>  (F7AC4D74) : 2 (MACHINE-VERSION) 199
>  (F7AC4DA0) : 3 (CALL-CHECK-REGS 'MACHINE-VERSION [...]) 247
>  (F7AC4DBC) : 4 (TOPLEVEL-EVAL '(MACHINE-VERSION) [...]) 759
>  (F7AC4DFC) : 5 (READ-LOOP [...]) 1567
>  (F7AC4F00) : 6 (TOPLEVEL-LOOP) 79
>  (F7AC4F08) : 7 (FUNCALL #'#<(:INTERNAL (TOPLEVEL-FUNCTION (CCL::LISP-DEVELOPMENT-SYSTEM T)))>) 87
>  (F7AC4F14) : 8 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER-PROCESS)>) 583
>  (F7AC4F60) : 9 (RUN-PROCESS-INITIAL-FORM #<TTY-LISTENER listener(1) [Active] #x1490D7A6> '(#)) 671
>  (F7AC4FA4) : 10 (FUNCALL #'#<(:INTERNAL CCL::%PROCESS-PRESET-INTERNAL)> #<TTY-LISTENER listener(1) [Active] #x1490D7A6> '(#)) 335
>  (F7AC4FCC) : 11 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION)>) 279
>
> Indeed, just (with-open-file (x "/proc/cpuinfo")) causes the same
> problem.  The value is #xFFFFFFFF, so probably an error code returned
> that isn't checking for a negative number correctly.
>
> strace shows:
> [pid  8335] open("/proc/cpuinfo", O_RDONLY) = 4
> [pid  8335] ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xf7bbe0b8) = -1 ENOTTY (Inappropriate ioctl for device)
> [pid  8335] fstat64(0x4, 0xf7bbe050)    = 0
> [pid  8335] fstat64(0x4, 0xf7bbe050)    = 0
> [pid  8335] ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xf7bbe0b8) = -1 ENOTTY (Inappropriate ioctl for device)
> [pid  8335] fstat64(0x4, 0xf7bbe050)    = 0
> [pid  8335] lseek(4, 0, SEEK_CUR)       = 0
> [pid  8335] lseek(4, 0, SEEK_END)       = -1 EINVAL (Invalid argument)
> [pid  8335] lseek(4, 0, SEEK_SET)       = 0
> [pid  8335] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> [pid  8335] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> [pid  8335] write(1, "> Error: value 4294967295 is not"..., 63) = 63
>
> David
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>