Skip to content

Commit c2f32b7

Browse files
committed
Fix DISASSEMBLE in some situations by falling back to funcall
Originally part of <armedbear#437>
1 parent 039e322 commit c2f32b7

1 file changed

Lines changed: 9 additions & 2 deletions

File tree

src/org/armedbear/lisp/disassemble.lisp

Lines changed: 9 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -148,8 +148,15 @@ SYS:*DISASSEMBLERS*."
148148
(let ((classloader (java:jcall "getClassLoader" class)))
149149
(if (or (java:jinstance-of-p classloader "org.armedbear.lisp.MemoryClassLoader")
150150
(java:jinstance-of-p classloader "org.armedbear.lisp.FaslClassLoader"))
151-
(disassemble-bytes
152-
(java:jcall "getFunctionClassBytes" classloader class))
151+
(disassemble-bytes
152+
(or
153+
(ignore-errors
154+
(java:jcall "getFunctionClassBytes" classloader class))
155+
;;; alanr found that in certain situations (under
156+
;;; OSGI?) that one has to explicitly FUNCALL the
157+
;;; function slot, so we fall back to that strategy.
158+
(ignore-errors
159+
(funcall (java:jfield "org.armedbear.lisp.Function" "FUNCTION_CLASS_BYTES") function))))
153160
(disassemble-bytes
154161
(read-byte-array-from-stream
155162
(java:jcall-raw

0 commit comments

Comments
 (0)