Hello again!
I am working on a project which used to be completely in C++, now i am gradually moving some of it to CL. For this reason i need to work on both sides, which requires me to reload cffi bindings too often. I couldn't find anything related to this in documentation. Probably this is not an intended use case so there is no support. Which means i need to use my hammer again, restart image :)
So, i started playing with load-foreign-library/close-foreign-library (probably not intended for this purpose) and whenever i call close-foreign-library with the result of load-foreign-library, i get this explosion:
Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion `map->l_init_called' failed!
Tracing this assert shows it was triggered from dlclose system call in sbcl source, and i am not entirely sure where i should report this bug.
I am still on archlinux using sbcl-git package from aur. Could it be another archlinux related bug?
Thanks.
On Thu, Mar 21, 2013 at 4:53 AM, nan noncopyable@gmail.com wrote:
I am working on a project which used to be completely in C++, now i am gradually moving some of it to CL. For this reason i need to work on both sides, which requires me to reload cffi bindings too often. I couldn't find anything related to this in documentation. Probably this is not an intended use case so there is no support. Which means i need to use my hammer again, restart image :)
FWIW, it's a use case that should work.
Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion `map->l_init_called' failed!
Tracing this assert shows it was triggered from dlclose system call in sbcl source, and i am not entirely sure where i should report this bug.
A Google search for that error string turns up this: https://savannah.gnu.org/bugs/index.php?34195#comment0. Perhaps your library is being marked as RTLD_NODELETE by glibc as described in that bug report. I suppose a good way to check that this is something glibc-related would be to write a small C program that opens and reloads your library. Can you try that?
Cheers,
On Thu, 21 Mar 2013 11:50:42 +0200, Luís Oliveira luismbo@gmail.com wrote:
A Google search for that error string turns up this: https://savannah.gnu.org/bugs/index.php?34195#comment0. Perhaps your library is being marked as RTLD_NODELETE by glibc as described in that bug report. I suppose a good way to check that this is something glibc-related would be to write a small C program that opens and reloads your library. Can you try that?
Attached code loads and unloads using flags based on the example on the man page: http://pubs.opengroup.org/onlinepubs/007904975/functions/dlsym.html
In addition to that, since sbcl calls dlopen with RTLD_GLOBAL|RDLD_NOW flags, i tried that too, all works as expected.
On Thu, Mar 21, 2013 at 10:22 AM, nan noncopyable@gmail.com wrote:
In addition to that, since sbcl calls dlopen with RTLD_GLOBAL|RDLD_NOW flags, i tried that too, all works as expected.
In that case, can you try it with another Lisp?
On Thu, 21 Mar 2013 12:50:25 +0200, Luís Oliveira luismbo@gmail.com wrote:
On Thu, Mar 21, 2013 at 10:22 AM, nan noncopyable@gmail.com wrote:
In addition to that, since sbcl calls dlopen with RTLD_GLOBAL|RDLD_NOW flags, i tried that too, all works as expected.
In that case, can you try it with another Lisp?
cmucl gives the same error. ecl takes the easy way out, %close-foriegn-library not implemented (which is so much better than that assert) clisp looks like it works, returns T. ccl couldn't manage to install it with archlinux-aur package abcl stuck at: ; Compiling xxx/quicklisp/dists/quicklisp/software/cffi_0.11.0/src/cffi-abcl.lisp ... #<THREAD "interpreter" {7F81C2}>: Debugger invoked on condition of type SIMPLE-ERROR Don't know how to REQUIRE JSS. Restarts: 0: RETRY Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl">. 1: ACCEPT Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl"> as having been successful. 2: TOP-LEVEL Return to top level
Should i try allegro and lispworks? (I don't have them installed yet, forms and registrations scare me!)
Thanks for quick response!
On Thu, Mar 21, 2013 at 11:10 AM, nan noncopyable@gmail.com wrote:
cmucl gives the same error. ecl takes the easy way out, %close-foriegn-library not implemented (which is so much better than that assert) clisp looks like it works, returns T. ccl couldn't manage to install it with archlinux-aur package
CCL would be a good one to try. It's easy to download a binary following the instructions from their website.
In any case, it would be nice to come up with a minimal reproducible test case. First off, do you see the same error if you try to load and reload the libtest.so library that comes with the CFFI test suite?
On Thu, 21 Mar 2013 13:14:39 +0200, Luís Oliveira luismbo@gmail.com wrote:
CCL would be a good one to try. It's easy to download a binary following the instructions from their website.
In any case, it would be nice to come up with a minimal reproducible test case. First off, do you see the same error if you try to load and reload the libtest.so library that comes with the CFFI test suite?
Thanks for the suggestion CCL indeed a good one. I just downloaded and set the init file, it just works and compiles very fast.
close-foreign-library too works on CCL with no problems. It looks like a sbcl/archlinux issue.
Thanks a lot for your time :)
On Thu, 21 Mar 2013 13:14:39 +0200, Luís Oliveira luismbo@gmail.com wrote:
In any case, it would be nice to come up with a minimal reproducible test case. First off, do you see the same error if you try to load and reload the libtest.so library that comes with the CFFI test suite?
For this one, i tried using all the compilers i got, After (ql:quickload :cffi-tests), all stuck at:
External process exited with code 1. Command was: "cc" "-m32" "-I/mnt/e/dev/quicklisp/dists/quicklisp/software/cffi_0.11.0/" "-o" "/home/nan/.cache/common-lisp/ccl-1.9-f96-linux-x86/mnt/e/dev/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix" "/home/nan/.cache/common-lisp/ccl-1.9-f96-linux-x86/mnt/e/dev/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c" Output was: /home/nan/.cache/common-lisp/ccl-1.9-f96-linux-x86/mnt/e/dev/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:7:17: fatal error: ffi.h: No such file or directory compilation terminated.
[Condition of type SIMPLE-ERROR]
Restarts: 0: [RETRY] Retry PROCESS-OP on #<GROVEL-FILE "cffi-libffi" "libffi" "libffi">. 1: [ACCEPT] Continue, treating PROCESS-OP on #<GROVEL-FILE "cffi-libffi" "libffi" "libffi"> as having been successful. 2: [ABORT] Give up on "cffi-tests" 3: [RETRY] Retry SLIME REPL evaluation request. 4: [*ABORT] Return to SLIME's top level. 5: [ABORT-BREAK] Reset this thread
On Thu, Mar 21, 2013 at 12:20 PM, nan noncopyable@gmail.com wrote:
For this one, i tried using all the compilers i got, After (ql:quickload :cffi-tests), all stuck at:
[...]
fatal error: ffi.h: No such file or directory
cffi-tests tries to load cffi-libffi which requires libffi's development headers. You don't need to actually load cffi-tests though. Just cd into the tests/ directory and run make to compile libtest.so.
On Thu, 21 Mar 2013 22:47:54 +0200, Luís Oliveira luismbo@gmail.com wrote:
cffi-tests tries to load cffi-libffi which requires libffi's development headers. You don't need to actually load cffi-tests though. Just cd into the tests/ directory and run make to compile libtest.so.
Tested both libtest.so and my library, loading/unloading libtest.so was fine. So i tried removing shared dependencies of my library (i actually had 4 shared libraries, cffi dynamically loads one of them, the one that dynamically linked to other 3) After converting 3 of 4 shared libraries to static library loading/unloading works.
I think, with load-foreign-library/close-foreign-library i was replicating what reload-foreign-libraries already does.
Now the hard part, making this reload cycle work, to see the changes i made with compiling c code take effect. Which i think won't be as easy as i thought it would :)
Thanks Luis!
On Fri, Mar 22, 2013 at 7:27 AM, nan noncopyable@gmail.com wrote:
Tested both libtest.so and my library, loading/unloading libtest.so was fine. So i tried removing shared dependencies of my library (i actually had 4 shared libraries, cffi dynamically loads one of them, the one that dynamically linked to other 3) After converting 3 of 4 shared libraries to static library loading/unloading works.
Interesting. Any clue why the shared dependencies are tickling the glibc assertion?
On Fri, 22 Mar 2013 11:02:38 +0200, Luís Oliveira luismbo@gmail.com wrote:
Interesting. Any clue why the shared dependencies are tickling the glibc assertion?
I have no idea. Other than this one i didn't have any issues with having 4 shared libraries. If i find why, you'll be first to know.
-
Luís Oliveira -
nan