Opened 10 years ago
Last modified 10 years ago
#569 assigned defect
ccl:close-shared-library seems to loop forever?
Reported by: | xxxxxx | Owned by: | gb |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Foreign Function Interface | Version: | trunk |
Keywords: | Cc: |
Description
I am on Ubuntu Karmic (prerelease) with Version 1.4-dev-r12385M-trunk (LinuxX8664)
Quite often it seems to be impossible to unload a shared library -- close-shared-library gets stuck -- maybe related to trying to unload a library that has symbols on which another library depends?
I just made this simple test case but did not investigate further. Let me know if you cannot reproduce it.
(defvar *libs* nil)
(loop for lib in '("libxcb.so.1" "libxcb-shm.so.0")
do (push (ccl:open-shared-library lib) *libs*))
then
(ccl:close-shared-library (first (reverse *libs*)) :completely t)
Does not return.
Interrupt from Emacs
[Condition of type SIMPLE-ERROR]
Restarts:
0: [CONTINUE] Continue from break. 1: [RETRY] Retry SLIME REPL evaluation request. 2: [ABORT] Return to SLIME's top level. 3: [ABORT-BREAK] Reset this thread 4: [ABORT] Kill this thread
Backtrace:
0: (APPLY #<COMPILED-LEXICAL-CLOSURE #x30004171FA1F> NIL) 1: (CCL::THREAD-HANDLE-INTERRUPTS) 2: (CCL::XCMAIN 17524289175580) 3: (CCL::%PASCAL-FUNCTIONS% 1 17524289175580) 4: (CCL::%LIBRARY-BASE-CONTAINING-ADDRESS) 5: (CCL::%LIBRARY-BASE-CONTAINING-ADDRESS #<A Foreign Pointer #x7F81879FB000>) 6: (CCL::SHLIB-CONTAINING-ADDRESS #<A Foreign Pointer #x7F81879FB000> NIL) 7: (CLOSE-SHARED-LIBRARY #<SHLIB libxcb.so.1 #x30004155420D> :COMPLETELY T) 8: (CCL::CALL-CHECK-REGS CLOSE-SHARED-LIBRARY #<SHLIB libxcb.so.1 #x30004155420D> :COMPLETELY T)
Attachments (2)
Change History (4)
Changed 10 years ago by xxxxxx
comment:1 follow-up: ↓ 2 Changed 10 years ago by gb
- Status changed from new to assigned
I'm fairly sure that you can avoid the problem by passing :COMPLETELY NIL to CLOSE-SHARED-LIBRARY.
When :COMPLETELY is T (which is the default), it tries to repeatedly call #_dlclose until the library's unmapped. That can't work in this case (or in general): "libxcb.so.1" will stay mapped as long as "libxcb-shm.so.0" (which depends on "libxcb.so.1") is mapped. The best that :completely T can really do here is to call #_dlclose once for each preceding call to OPEN-SHARED-LIBRARY; it can't promise that the library won't be mapped in memory even if it's "completely" closed.
comment:2 in reply to: ↑ 1 Changed 10 years ago by xxxxxx
Replying to gb:
I'm fairly sure that you can avoid the problem by passing :COMPLETELY NIL to CLOSE-SHARED-LIBRARY.
That makes sense. I guess you would recommend changing CFFI to use :completely nil?
[We want to unload shared libraries before delivery (ccl:save-application) so that if their locations are different at startup the Lisp will not crash and we have a chance to look for them (the patch is here http://common-lisp.net/pipermail/cffi-devel/2009-July/003195.html).]
Thanks for your very fast response!
Test case as a small file for convenience