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)

ccl-lib.lisp (197 bytes) - added by xxxxxx 10 years ago.
Test case as a small file for convenience
close-shared-library.patch (953 bytes) - added by sionescu 9 years ago.
Add a limit for the dlclose() loop

Download all attachments as: .zip

Change History (4)

Changed 10 years ago by xxxxxx

Test case as a small file for convenience

comment:1 follow-up: 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!

Changed 9 years ago by sionescu

Add a limit for the dlclose() loop

Note: See TracTickets for help on using tickets.