[Openmcl-devel] Advice needed to debug shared library problem on Mac and Linux

[Gary Byers]

Is the library publically available ?  Googling found an API reference document,
but I didn't see a link to the library/headers anywhere.

IIRC, "strip" with no options on OSX removes symbols that the dynamic
linker uses.  It's The World's Most Advanced Operating System!

It sounds less likely that this is a name conflict, though in thinking about
that it seems clear that we want to be a little more careful about trying to
avoid such conflicts.

Whether the library's freely available or not, what does the C prototype for
the function that you're trying to call look like ?  What does the lisp code
that you're using to make that call look like ?  Are you just using the CCL
FFI, or a portability package like cffi or uffi ?


On Tue, 29 Mar 2011, Paul Meurer wrote:

> Hi Gary,
>
>> I'm confused. On the Mac, we don't try too hard to decode memory fault
>> info and so wouldn't say something like:
>>
>> invalid address alignment
>>
>> I think that we used to try to do that until a few versions ago.
>
> I updated to the newest kernel, and there this line is missing. But everything else is as before.
>
>>> On Linux, trying to load the library already results in a Kernel memory
>>> allocation failure, it tries to allocate a pointer of size 140332065189888
>>> bytes. I doubt that much memory is really needed.
>>
>> Are you saying that doing:
>>
>> ? (open-shared-library "/path/to/libcfsm.so")
>>
>> causes CCL to think that a very large amount of memory needs to be allocated ?
>
> No, sorry, I had overlooked one piece of code; loading the library does work. It first crashes when I execute a function from the library, just as on the Mac. Thanks anyway for the explanation of how loading shared libraries works.
>
>> If I'm correct in interpreting what you said as "things fail in or soon after
>> the call to OPEN-SHARED-LIBRARY", then I'd generally want to try and find and
>> fix the cause of that before worry about anything else; if it's dying because
>> an init routine is calling into the CCL kernel due to a name conflict, it's
>> believable that that could cause a random-looking error on Linux and "just"
>> incorrect initialization of the library on Darwin.
>
> I had also suspected a name conflict, but couldn't find common symbols in the library and the lisp kernel. Is that the right way to find out?
>
>>> I can imagine that this is difficult to make sense of.?But maybe you have
>>> some ideas how on could try to debug the problem. It seems like a bug in
>>> Clozure.
>>
>> Yup.  Either that, or something else ...
>
> Of course. It just struck me that the lib works fine in Allegro and SBCL. But a name conflict seems plausible.
>
> On the other hand, I now tested with a stripped kernel, but things don't change. (On the Mac, the stripped kernel does not load.) Shouldn't a name conflict go away here when there are no names left?
>
> -- 
> Paul
>
>