Running 32-bit CCL on 64-bit Linux (but it can happen in any setup),
I noticed that (osicat-posix:mmap) does not correctly handle return
addresses larger than the maximum C "long" value, but instead throws
an exception.
In such cases, it means the underlying C mmap() function returned
successfully a pointer in the top half of the addressable virtual
memory, but the Lisp wrapper for mmap() and mremap() chokes on such
pointers.
A patch that solves this problem is attached.
Feedback on the analysis and the solution is welcome :)
Best regards,
Massimiliano Ghilardi
------------------ longer explanation -----------------------------
While invoking
(osicat-posix:mmap (cffi-sys:null-pointer) 4096
(logior osicat-posix:prot-read osicat-posix:prot-write)
osicat-posix:map-shared
*fd* 0)
with a file descriptor *fd* correctly open on a 4096-byte file,
I encountered the error:
-------------------------------------------------------------------
The value -143798272 is not of the expected type (UNSIGNED-BYTE
32).
[Condition of type TYPE-ERROR]
Restarts:
0: [RETRY] Retry SLIME REPL evaluation request.
1: [*ABORT] Return to SLIME's top level.
2: [ABORT-BREAK] Reset this thread
3: [ABORT] Kill this thread
Backtrace:
0: (CFFI-SYS:MAKE-POINTER -143798272)
1: (CCL::CALL-CHECK-REGS OSICAT-POSIX:MMAP #<A Null Foreign Pointer>
4096 3 1 4 0)
2: (CCL::CHEAP-EVAL (OSICAT-POSIX:MMAP (CFFI-SYS:NULL-POINTER) 4096
(LOGIOR OSICAT-POSIX:PROT-READ OSICAT-POSIX:PROT-WRITE)
OSICAT-POSIX:MAP-SHARED *FD* ...))
-------------------------------------------------------------------
A simple analysis (cat /proc/<ccl-pid>/maps) shows that mmap() actually
succeeded and returned the value #xf76dd000, which was converted to
-143798272 because OSICAT wrapper for mmap() is defined to return
a C "long", that is limited to the range -#x80000000 to #x7fffffff,
thus converting #xf76dd000 to a C long overflows and gives a negative
value.
But calling (cffi-sys:make-pointer) chokes on negative values, at least
on CCL.
