[Openmcl-devel] RDNZL in CCL: Exception occurred while executing foreign code

John Miller millejoh at mac.com
Fri Oct 16 14:28:51 PDT 2009


Again, ample evidence that I should not quit my day job any time soon  
and stride boldy into the world of software development.  I would  
probably trip and break my nose in the fall.

The problem looks to be one of passing the wrong type of argument.   
The C function I am calling is defined as

void* invokeInstanceMember(const __wchar_t *methodName, void *target,  
int nargs, void *args[])

h-to-ffi.sh interprets that to be

(function ("/cygdrive/d/rdnzl-cpp-0.7.1/RDNZL/ffi-headers.h" 55)
  "invokeInstanceMember"
  (function
   ((pointer (unsigned-short ())) (pointer (void ())) (int ())  
(pointer (pointer (void ()))) )
   (pointer (void ()))) (extern))

Then, given the following definitions:

(defun %invoke-instance-member (method-name type nargs args)
   (ccl::with-native-utf-16-cstr (mn method-name)
     (#_invokeInstanceMember mn type nargs args)))

(defun test-invoke-2 ()
   (let ((obj (make-type-from-name "System.Reflection.Assembly")))
     (%invoke-instance-member "ToString" (pointer obj) 0 (ccl:%null- 
ptr))))

(defun test-invoke-3 ()
   (let ((obj (make-type-from-name "System.Reflection.Assembly"))
	(type (box* "System.Reflection.Assembly")))
     (ccl:rletz ((ptr (:array :address 1)))
       (setf (ccl:paref ptr (:array :address) 0) type)
       (%invoke-instance-member "GetType" (pointer obj) 1 ptr))))

I call (test-invoke-2) and all is hunky-dorey, but I try (test- 
invoke-3) and all heck breaks loose.  I have imagined, and tried a  
couple different ways of representing an array of pointers, but  
clearly I am not imaginative enough.

It would be interesting to know if anyone else has tried calling  
foreign functions that have arguments of type void *args[].  I mean  
other than the code in cocoa-ide/start.lisp that I based the code in  
test-invoke-3 off of.

Cheers,
John


(unwind-protect
On Oct 12, 2009, at 3:51 PM, Gary Byers wrote:

> 'exception' in this context almost certainly means machine-level  
> exception
> (e.g., attempt to reference memory that isn't there, attempt to  
> execute
> an illegal instruction ...) and doesn't likely refer to a C++ runtime
> exception.
>
> Beyond the fact that it can show a backtrace of the lisp stack leading
> up to the ff-call, CCL's kernel debugger isn't very useful for  
> debugging
> exceptions that occur in foreign (C, C++) code.  There are some  
> (somewhat
> Unix-centric) notes on using GDB at:
>
> <http://trac.clozure.com/openmcl/wiki/CclUnderGdb>
>
> Native Windows debuggers may work better for debugging crashes that  
> occur
> in Windows dlls; it's been a long time since I've tried to run CCL  
> under
> something like WinDbg, and I don't remember whether there were  
> issues or
> what they were.
>
> I suppose that there are other possibilities, but I'd be most  
> suspicious
> of the FFI/CFFI code: passing the wrong number/types of arguments to a
> C[++] function can certainly lead to a memory fault or other type of
> machine exception.
>
> [It varies a bit by platform, but CCL isn't always consistent about  
> telling
> you what general kind of machine exception occurred when that  
> exception
> occurred in foreign code; on OSX, trying to FF-CALL a null pointer  
> enters
> the kernel debugger with a (very) slightly more informative message:
>
> ? (ff-call (%null-ptr) :void)
> Unhandled exception 10 at 0x0, context->regs at #xb029b8f0
> Exception occurred while executing foreign code
> ? for help
> [2086] Clozure CL kernel debugger:
>
> The "unhandled exception 10" means "bus error" (SIGBUS = 10), which is
> at least a little better than saying nothing in this case.]
>
> On Mon, 12 Oct 2009, John Miller wrote:
>
>> All,
>>
>> On a wild hair, it seemed like it might be useful to have CCL  
>> running on my Windows XP 32-bit machine at work and use it to  
>> access Excel and Outlook using Dr. Edi Weitz's RDNZL (http://weitz.de/rdnzl/ 
>> ) package.  Doing this has turned out to be more difficult than I  
>> thought.  I built the FFI portion of the code using CFFI to look as  
>> close as possible to the FFI interfaces defined for the other lisps.
>>
>> For some things the FFI works.  For example:
>>
>> ? (make-type-from-name "System.Reflection.Assembly")
>> #<CONTAINER System.Type #x1532E08>
>> ? (import-assembly "mscorlib")
>> #<CONTAINER System.Reflection.Assembly #x1532EA8>
>>
>> But if I try to get fancy:
>>
>> ? (import-types "System.Windows.Forms" "MessageBox")
>> %eax = 0x00faf00c
>> %ecx = 0x00000000
>> %edx = 0x00000002
>> %ebx = 0x79f7697c
>> %esp = 0x00faf008
>> %ebp = 0x00faf05c
>> %esi = 0x00faf094
>> %edi = 0x0040a958
>> %eip = 0x7c812a6b
>> %eflags = 0x00000206
>>
>> %cs = 0x001b
>> %ds = 0x0023
>> %ss = 0x0023
>> %es = 0x0023
>> %fs = 0x003b
>> %gs = 0x0000
>> Exception on foreign stack
>>
>> Exception occurred while executing foreign code
>> ? for help
>> [2068] Clozure CL kernel debugger: t
>> Current Thread Context Record (tcr) = 0x5cbc20
>> Control (C) stack area:  low = 0xdb0000, high = 0xfb0000
>> Value (lisp) stack area: low = 0xfb0000, high = 0x0
>> Exception stack pointer = 0xfaf008
>> [2068] Clozure CL kernel debugger: b
>> current thread: tcr = 0x5cbc20, native thread ID = 0xde4,  
>> interrupts enabled
>>
>>
>> (#x010C0CD0) #x08D52435 : #<Function %INVOKE-STATIC-MEMBER  
>> #x08D52266> + 463
>> (#x010C0D14) #x08D794D5 : #<Function INVOKE #x08D7854E> + 3975
>> (#x010C0D78) #x08DD281D : #<Function IMPORT-TYPES #x08DD27CE> + 79
>> (#x010C0D88) #x0839E9BD : #<Function CALL-CHECK-REGS #x0839E8C6> +  
>> 247
>> (#x010C0DA4) #x083A8FE5 : #<Function TOPLEVEL-EVAL #x083A8CFE> + 743
>> (#x010C0DE8) #x083AAA35 : #<Function READ-LOOP #x083AA30E> + 1831
>> (#x010C0EFC) #x0839E60D : #<Function TOPLEVEL-LOOP #x0839E5C6> + 71
>> (#x010C0F04) #x0834222D : #<Function (:INTERNAL (TOPLEVEL-FUNCTION  
>> (LISP-DEVELOP
>> MENT-SYSTEM T))) #x083421CE> + 95
>> (#x010C0F14) #x0840FDED : #<Function (:INTERNAL MAKE-MCL-LISTENER- 
>> PROCESS) #x08$
>> 0FBA6> + 583
>> (#x010C0F60) #x083484DD : #<Function RUN-PROCESS-INITIAL-FORM  
>> #x0834823E> + 671
>> (#x010C0FA4) #x08348E7D : #<Function (:INTERNAL (%PROCESS-PRESET- 
>> INTERNAL (PROCE
>> SS))) #x08348D2E> + 335
>> (#x010C0FCC) #x083317A5 : #<Function (:INTERNAL THREAD-MAKE-STARTUP- 
>> FUNCTION) #x
>> 0833168E> + 279
>> [2068] Clozure CL kernel debugger:
>>
>> Note that I can get RDNZL to work fine using CLISP 2.48 on this  
>> same machine.
>>
>> I believe part of the problem with CCL is that Edi's C++ code will  
>> throw a C++ exception under certain conditions (though I can't  
>> figure out why the above call to %invoke-static-member is causing  
>> an exception).  Other Lisp's seem to handle this without going into  
>> the kernel debugger.  For example with Clisp 2.48 running on the  
>> same machine
>>
>> RDNZL[36]> (property "System.Reflection.Assembly" "FullName")
>>
>> *** - .NET error (System.Exception): Static property not found:
>>      System.Reflection.Assembly->FullName
>>
>> Trying to call property with the same arguments in CCL bumps me  
>> into the kernel debugger.  Again, I am not 100% convinced this is  
>> the problem, but I am not sure how to interpret the output from the  
>> debugger and come up with a better hypothesis of what is happening.
>>
>> Best regards,
>> John Miller
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20091016/a785be4d/attachment.htm>


More information about the Openmcl-devel mailing list