[Openmcl-devel] what is INVALID-MEMORY-OPERATION ?

[Gary Byers]

On Tue, 5 Jul 2011, ??? wrote:

>
> sorry. my english is pool~
>
> Welcome to Clozure Common Lisp Version 1.7-dev-r14860M-trunk  (DarwinX8664)!
> ? (ccl::foreign-symbol-address "gettimeofday")
> #<A Foreign Pointer #x7FFF83EE3644>
> ? (require :objc-support)
> :OBJC-SUPPORT
> ("OBJC-PACKAGE" "SEQUENCE-UTILS" "NAME-TRANSLATION" "OBJC-CLOS"
> "OBJC-RUNTIME" "BRIDGE" "OBJC-SUPPORT")
> ? (ccl::foreign-symbol-address "gettimeofday")
>> Error: Invalid memory operation.
>> While executing: CCL::%SAFE-GET-PTR, in process listener(1).
>> Type :POP to abort, :R for a list of available restarts.
>> Type :? for other options.
> 1 >
>
> 1 > (ccl::foreign-symbol-address "pthread_create")
> #<A Foreign Pointer #x7FFF83F18EE1>
> 1 > (ccl::foreign-symbol-address "pthread_join")
>> Error: Invalid memory operation.
>> While executing: CCL::%SAFE-GET-PTR, in process Listener(6).
>> Type cmd-. to abort, cmd-\ for a list of available restarts.
>> Type :? for other options.
>
>
>
> after loading "objc-bridge" or in IDE   ...... many(.....not all) C function & pointer access has
> error signal [ Invalid memory operation ].
>
> before loading "objc-bridge" ......all fine.
>
> in  DarwinX8632 version ...all fine. and 1.6-r14468M  (DarwinX8664)! ..all fine.
>
> is it bug?? ...
>

Yes.

An INVALID-MEMORY-ACCESS (or INVALID-MEMORY-OPERATION) condition is
signaled if an attempt is made to read from or write to a memory
address and either (a) there's no memory there or (b) the memory
that's there doesn't allow reading or writing.  The page at address 0
is almost always either unmapped or mapped with no access permission,
so:

? (%get-unsigned-byte (%null-ptr))

will signal one or the other of those condition types.  (Which is
signaled and how it's printed depends on how much is known about
the memory access in question.)

A pointer is considered (by the ObjC bridge) to be an instance of
an ObjC class if the first word at the pointer's address is an ObjC
class. (Yes, this is heuristic and it assumes that Apple hasn't invented
tagging yet.)  CCL::%SAFE-GET-PTR is supposed to suppress any memory
fault that occurs when indirecting through a pointer.  It's apparently
not working correctly in all cases, and a recent change to the trunk
is doing more of these speculative references, for reasons that I can't
talk about until Apple invents tagging, which should be Real Soon Now.

In a perfect world, it shouldn't be necessary to do this %SAFE-GET-PTR
stuff as often, but it's clealy a CCL bug that it doesn't work the way
it's supposed to.