[Openmcl-devel] Advice needed to debug shared library problem on Mac and Linux
Paul.Meurer at uni.no
Tue Mar 29 10:40:47 UTC 2011
> 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
> 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?
More information about the Openmcl-devel