[Openmcl-devel] Missing header(s) for OpenGL FFI?
pbpublist at comcast.net
Sat Aug 12 19:43:22 UTC 2006
So it sounds like for the time being the workaround is to revert to
the old interfaces until a fix is available?
I know very little about the Obj-C runtime and less about how the
bridge works under the covers so I'm preparing to duck after asking
this naive question ;-) Is it not possible to query the Obj-C
runtime itself with the pointer and let it tell OpenMCL whether the
pointer is something it knows about and, if so, what it is?
On Aug 12, 2006, at 3:00 PM, Gary Byers wrote:
> Someone somewhere once said that "simple binary search" is never
> Or something like that.
> The way that the bridge usually tries to determine whether or not a
> random pointer is or is not an instance of some ObjC class is to
> ask #_malloc for information about the memory region where the pointer
> is allocated; if #_malloc knows about the pointer, then the bridge
> looks to see if the first word in the pointer references an ObjC
> (The #_malloc check is basically there to ensure that the pointer
> points to mapped memory and that we won't segfault when trying to
> look at its first word.) The check's obviously a little slow, but
> information about the results of the check are cached in bits in
> the pointer object, so it's only done at most once per (EQ) unique
> Unfortunately, that isn't adequate to recognize all instances of
> NSConstantString and related (CF) classes, which are often just
> embedded in the data segments of libraries. The bridge tries to keep
> track of the memory regions associated with all known shared
> libraries, and does a binary search through that list of regions to
> see if a given pointer is contained within any of them. (If so, it's
> safe to indirect through the pointer and look at its first word, and
> that first word -might- reference a class like NSConstantString, in
> which case the pointer will be recognized as an instance of that
> (At one point a couple of years ago, the binary search was a linear
> search and was naturally even slower. There are a finite number
> of NSConstantString instances in all loaded libraries at any given
> time, and I think that it'd be possible to enumerate them by looking
> at relocation information and make it much easier to recognize these
> Anyway, the short version is that there's a bug in that binary search
> code that makes it impossible to determine the class of some
> possible-ObjC-objects. Presumably, the recursive error failure has
> to do with trying to print an object whose class can't be
> determined without
> signalling an error.
> It may be the case that there appears to be nothing different between
> the environment where the error occurs and the environment where it
> doesn't besides the set of interfaces in use, but I'd guess that (for
> some reason) either a slightly different set of shared libraries is
> loaded or (for some reason) they're mapped at slightly different
> and one or the other of these differences is enough to trigger the
> in the binary search routine (CCL::POINTER-IN-CFSTRING-SECTION-P).
> I thought that I'd fixed the real (fencepost) problem at some point
> I'm pretty sure that I remember that it was a fencepost problem in
> that binary search routine, which is of course so simple that it's
> impossible to get right ...), but if I remember that correctly it
> doesn't look like I checked the fix in.
> The runtime doesn't expect CLASS-OF to fail; that's a generally
> reasonable assumption, but the fact that it is failing seems to
> be what's causing the error death-spiral.
More information about the Openmcl-devel