[Openmcl-devel] resolver, uffi bug on OpenMCL 0.14.2-p1

[Gary Byers]

On Mon, 24 May 2004, Steve Jenson wrote:

> Hi everybody,
>
> I'm patching resolver-0.5 to work on OpenMCL and am having some trouble:
>
> ? (lookup "www.google.com" 'a)
> Unhandled exception 11 at 0x900a30d8, context->regs at #xf01350f8
> Read operation to unmapped address 0x00000000
>   In foreign code at address 0x900a30d8
>
> To my untrained eye, it looks like a linker didn't fill in an address
> properly.
>

One reason why people always say "it'd be helpful to know exactly what
OS version you're running" is that it allows cheating: if I have the
same version installed somewhere, I can look at the address 0x900a30d8
and see what's going on there.

If you're running the exact same 10.3.3 variant that I am, that address
is in "dn_comp()"

0x900a30d8 <dn_comp+120>:	lbz	r29,0(r3)

trying to load a byte 0 bytes from R3.  Since R3 is 0 in the register
dump you posted, that's a possibility.  If you're dying in the same
place that I'm looking at, it seems that that instruction's only
reachable if dn_comp() is called with its "dnptrs" arg NULL, and it
seems that the "exp_dn" arg is the NULL pointer that's in R3 now.

The backtrace you posted indicated that the pending return address
is at res_mkquery+316, and the previous instruction (at res_mkquery+312)
is a call to dn_comp().

dn_comp()'s first argument (the value in R3 that you seem to be choking
on) is res_mkquery()'s second argument (by way of R21): a string called
"dname" in the man page.  That seems to be the same "dname" that
res_query() recieved as its first argument, which seems to have been
set by the UFFI:WITH-CSTRING form in:


(defun res-query (dname class type buffer buffer-size)
  "A simple wrapper around the res-query-c function. Returns the
length of DNS data in the buffer or a negative value error code."
  (uffi:with-cstring (cdomain dname)
    (let ((answer-size (res-query-c cdomain
				    class
				    type
				    buffer
				    buffer-size)))
      answer-size)))

Whether the problem's in UFFI:WITH-CSTRING, in the glue that UFFI
uses to make the function RES-QUERY-C, or elsewhere, it looks like
the problem is that res_query()'s receiving a NULL pointer instead
of a domain name string.

(Or maybe we're using very different OS versions, but I doubt that ...)

> FYI, resolver relies on UFFI and links to the platform's resolv.so. The
> only patch I made was for it to find resolv.dylib when using openmcl.

I'm not sure that this is necessary; /usr/lib/libresolv.dylib seems
to contain a different set of resolver routines (most of which seem
to have "9" in their names.)  Things like "res_mkquery" are built in
to the standard system library (libSystem.dylib), which is always open.

(As a random aside, only slightly related to this issue: does anyone
else find it unsettling that much of the Darwin C library comes from
a version of FreeBSD (<5.x) that didn't have kernel threads and is
therefore not concerned with thread-safety issues ?  Hint: the Mach
kernel -does- have threads ...)

> I've placed a fuller openmcl transcript at:
> http://saladwithsteve.com/tmp/resolver-kernel-panic.txt
>
> I installed 0.14.2-p1 this afternoon, wiped everything clean and only
> reinstalled asdf-install, uffi, and my patched resolver-0.5
>
> Sorry for the lack of insight, I'm a newbie with UFFI.
>
> Thanks so much,
> Steve Jenson
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>