[Openmcl-devel] resolver, uffi bug on OpenMCL 0.14.2-p1
gb at clozure.com
Tue May 25 04:00:56 EDT 2004
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
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
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:
> 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
More information about the Openmcl-devel